嵌入式Linux下MJPG-streamer的搭建原理与实战

这篇聊聊MJPG-streamer。

如果你在嵌入式Linux板子上做过USB摄像头采集，或者碰过物联网类的视频监控小项目，大概率听过这个名字。韦东山老师的视频里专门有一节课讲这个方案的实现和原理，我看完之后最大的感受是：它不像FFmpeg那样庞大复杂，也不像GStreamer那样概念满天飞，MJPG-streamer就是那种“小而美、拿来就能用”的典型代表，特别适合资源受限的物联网设备。这篇总结我把它掰开揉碎讲清楚：MJPG-streamer到底怎么工作、代码是怎么组织的、在开发板上怎么跑起来，以及我在实际操作中踩过的那些坑。

1. 整体设计思路：为什么物联网视频监控偏偏选它

1.1 物联网视频监控的场景约束

先说说物联网视频监控和普通网络摄像头的区别。普通的PC摄像头方案，你可以直接上FFmpeg做推流，或者用OpenCV处理画面，随便折腾，因为PC性能足够强。但换到嵌入式板子上，情况完全不同：处理器主频可能只有几百兆赫兹，内存可能只有128MB甚至更少，Flash存储也捉襟见肘。

物联网视频监控的核心场景是：一个低成本的摄像头节点，把采集到的画面通过网络传输到远端浏览器或客户端查看。这个场景要求三件事：一是采集端要足够轻量，不能在编码上消耗太多CPU；二是网络传输要尽量用HTTP这种通用协议，方便各种终端直接访问；三是代码要简洁可控，方便针对具体硬件裁剪。

MJPG-streamer恰好就是围绕这三个需求设计的。

1.2 选型对比：为什么不是FFmpeg或GStreamer

我经常被问到：既然FFmpeg功能那么强大，为什么还要用MJPG-streamer？这个问题得从实际资源消耗说起。FFmpeg是一个完整的音视频处理框架，它要做的是“转码”“封装”“滤波”“推流”这些全能型工作，你把它裁剪到嵌入式平台上，交叉编译本身就是一场折磨，而且运行时内存占用和CPU负载都不低。GStreamer则是一套插件化多媒体框架，概念非常灵活，但也正因为太灵活，调试管线反而成了麻烦事。

MJPG-streamer的思路完全不同。它不转码、不封装、不搞复杂的滤镜管线，它只做一件事：从摄像头拿到JPEG图像数据，然后通过HTTP协议把它们一张一张地推给客户端。每一个JPEG帧本来就是独立的图片，浏览器拿到后不断刷新显示，就形成了连续的视频效果。

这个方案的巧妙之处在于，它把“视频”这个复杂问题，降维成了“连续传输图片”这个简单问题。摄像头支持MJPEG格式时，硬件直接输出压缩好的JPEG帧，CPU几乎零负担；即使摄像头只支持YUYV原始格式，用libjpeg做软编码，也远比H.264编码要省资源得多。

1.3 MJPG-streamer的架构优势

MJPG-streamer采用了插件架构，整个程序由一个主程序和若干个动态加载的插件组成。输入插件负责从摄像头或文件获取图像数据，输出插件负责把数据分发到网络或保存到本地。这种设计让它的扩展性非常好：想增加一个输入源，写一个input插件就行；想增加一种输出方式，写一个output插件就行。

而且自带插件已经覆盖了最常见的需求：input_uvc对应USB摄像头（V4L2接口），input_file对应静态图片或文件回放，output_http提供HTTP网页访问，output_file可以把帧图片直接落盘。这意味着你不需要改一行代码，就能把USB摄像头变成一台可以通过浏览器直接访问的微型网络摄像机。对于物联网视频监控原型验证，甚至小规模产品部署，这个组合拳完全够用。

另外，如果你拿它和RTSP方案对比，HTTP方案还有一个隐藏优势：不需要特殊的播放器。手机浏览器、PC浏览器直接输入IP地址加端口就能看，跨平台兼容性极好。这对物联网项目来说非常关键，因为你不可能要求用户都安装VLC或者专门做一个客户端。

2. 核心原理拆解：从摄像头到浏览器的完整链路

2.1 V4L2采集流程

MJPG-streamer的input_uvc插件，底层走的是Linux内核的V4L2（Video for Linux 2）框架。V4L2是Linux下视频设备的标准接口，摄像头驱动会注册为类似/dev/video0的设备节点，应用层通过一系列ioctl调用来控制采集。

典型的采集流程是：

1. 打开设备节点，用VIDIOC_QUERYCAP查询设备能力，确认它确实是视频采集设备。

2. 用VIDIOC_S_FMT设置采集格式。这里要注意，如果你想让硬件直接输出MJPEG帧，需要把像素格式设置为V4L2_PIX_FMT_MJPEG，同时设置分辨率和帧率。

3. 用VIDIOC_REQBUFS申请帧缓冲区。通常申请4个缓冲区就够了，这些缓冲区由驱动分配，应用通过mmap映射到用户空间。

4. 把所有缓冲区都放入驱动的采集队列（VIDIOC_QBUF），然后调用VIDIOC_STREAMON开始采集。

5. 驱动采集到一帧数据后，会把它放入一个缓冲区，应用用VIDIOC_DQBUF取出这个缓冲区，处理完数据后再用VIDIOC_QBUF还回去，形成循环。

这个过程在代码里非常清晰，主循环就是DQBUF、处理、QBUF三个动作反复执行。很多初学者容易犯的错是在DQBUF之后忘记重新QBUF，导致缓冲区越用越少，最后采集直接卡死。MJPG-streamer的代码结构很适合当作V4L2编程的入门范本，逻辑比那些动辄几百行的框架代码干净得多。

2.2 JPEG编码的两种模式

这里要澄清一个概念：MJPEG并不是一种编码协议，它本质上是“Motion JPEG”，也就是一系列JPEG图片的连续播放。在摄像头层面，支持MJPEG输出的摄像头，内部其实有硬件JPEG编码器，能直接输出压缩好的JPEG帧。这种情况下，主控芯片只需要搬运数据，CPU占用率可以忽略不计。

如果摄像头不支持MJPEG，只输出YUYV这种原始格式，那么MJPG-streamer就需要借助libjpeg库把YUYV数据转换成JPEG。这个转换是纯软件计算，会消耗一定的CPU。以640x480分辨率为例，一帧YUYV原始数据大约614KB，软件压缩后可能只有30KB到80KB，压缩率非常可观，但CPU负担会明显上升。

韦东山老师在视频里特别强调了硬件MJPEG模式的重要性。我当时实验用的是中星微ZC0301芯片的USB摄像头，它支持硬件MJPEG输出，实测640x480@30帧的采集完全无压力。而如果换成只支持YUYV的摄像头，同样分辨率能跑到15帧就已经不错了。所以在选型上，我强烈建议优先选择支持MJPEG硬件输出的摄像头，这能直接决定方案的流畅度。

2.3 HTTP流媒体协议的秘密

MJPG-streamer的http输出插件，核心是一个轻量级HTTP服务器，它监听一个TCP端口（默认8080），然后根据客户端请求的URL路径分发不同的处理逻辑。

最常用的是两个URL：

• /?action=snapshot：获取单张JPEG静态图片。

• /?action=stream：获取连续的MJPEG视频流。

视频流背后的HTTP响应头非常关键，它用的是一种叫multipart/x-mixed-replace的MIME类型。这个类型的意思是：HTTP响应体里会包含多个部分（part），每个部分都是独立的JPEG图片，它们依次被发送到客户端。浏览器支持这种类型，所以收到第一帧后不会断开连接，而是一帧一帧地刷新显示。

响应头大致长这样：

HTTP/1.1 200 OK Content-Type: multipart/x-mixed-replace; boundary=frame --frame Content-Type: image/jpeg Content-Length: 45231 [JPEG二进制数据] --frame Content-Type: image/jpeg Content-Length: 45887 [JPEG二进制数据]

这个机制用生活化的比喻来说，就像是快递员不停给你送独立的照片，你每收到一张就把它贴到墙上，贴得够快，看起来就是动态画面。

2.4 缓冲区的共享与同步

MJPG-streamer里有一个全局的帧缓冲区数组，输入插件负责往里面填充数据，输出插件负责从里面读取数据。多个输出插件可以同时工作，比如一个输出HTTP流，另一个输出文件。

这里有一个多线程竞争问题：输入线程正在写缓冲区的时候，输出线程不能同时去读，否则会读到半帧数据，导致画面撕裂。MJPG-streamer的解决办法是每个缓冲区配一个pthread互斥锁和一个条件变量。输入线程写完一帧后，会更新帧序号，并广播条件变量通知所有输出线程。输出线程拿到锁后，检查帧序号是否变化，如果变化就读取最新数据，否则等待。

这套同步机制直接决定了多路输出的稳定性。我测试过同时开HTTP视频流和文件输出两个功能，只要摄像头采集帧率不低于10帧，两个输出端都能正常工作。

3. 实战过程：在开发板上从零跑通MJPG-streamer

3.1 环境准备与交叉编译

我实验用的平台是韦东山老师的imx6ull开发板，运行Linux系统，USB接口接了一个支持MJPEG输出的摄像头。在PC上的Ubuntu交叉编译环境里，我需要准备好arm版本的交叉编译器、libjpeg库和MJPG-streamer源码。

首先解决libjpeg的交叉编译问题。MJPG-streamer依赖libjpeg做JPEG解码和编码，所以必须先把libjpeg编成arm版本：

wget http://www.ijg.org/files/jpegsrc.v9e.tar.gz tar xzf jpegsrc.v9e.tar.gz cd jpeg-9e ./configure --prefix=/opt/arm-libjpeg --host=arm-linux-gnueabihf make make install

--host参数指定目标平台是arm-linux-gnueabihf，--prefix指定安装路径，编译出来的头文件和静态库会放到/opt/arm-libjpeg目录下。

然后是MJPG-streamer的编译。它的Makefile不是标准的configure生成型，而是需要手动修改变量。核心要改的就是Makefile里的CC、CFLAGS、LDFLAGS等参数。我当时直接用命令行参数覆盖的方式：

cd mjpg-streamer/mjpg-streamer-experimental make CC=arm-linux-gnueabihf-gcc \ CFLAGS+="-I/opt/arm-libjpeg/include" \ LDFLAGS+="-L/opt/arm-libjpeg/lib -ljpeg"

这一行命令会编译出mjpg_streamer主程序，以及input_uvc.so和output_http.so等插件文件。如果你遇到链接报错找不到libjpeg，多半是-L路径没有指对，用find /opt/arm-libjpeg -name "libjpeg*"确认一下库文件位置。

3.2 开发板上的部署与运行

编译好的文件拷贝到开发板后，我习惯把它们统一放到/usr/bin和/usr/lib目录，这样省去设置环境变量的麻烦。也可以直接放一个单独的目录，比如/root/mjpg，然后用完整路径运行。

运行命令的基本格式是：

export LD_LIBRARY_PATH=/opt/arm-libjpeg/lib:$LD_LIBRARY_PATH ./mjpg_streamer -i "./input_uvc.so -d /dev/video0 -r 640x480 -f 30" -o "./output_http.so -w ./www -p 8080"

-i指定输入插件，-d是摄像头设备节点，-r是分辨率，-f是帧率；-o指定输出插件，-w是网页文件目录，-p是监听端口。-w目录下放着HTML页面和JavaScript脚本，MJPG-streamer自带的www目录里有一个简易的网页播放器，直接浏览器访问板子IP加端口就能看到画面。

实测下来，这个过程耗时极短：从启动到浏览器看到画面，大约只需两三秒。板子CPU占用率在10%以下，内存占用也只有几MB，对于一个完整的视频监控节点来说，这个资源消耗非常友好。

3.3 验证硬编码MJPEG模式是否生效

这里有一个排查重点：如何确认摄像头真的工作在硬件MJPEG模式，而不是软件编码模式？方法很简单，看启动日志。

./mjpg_streamer -i "./input_uvc.so -d /dev/video0 -r 640x480 -f 30" -o "./output_http.so -w ./www -p 8080" MJPG-streamer: starting application MJPG-streamer: input plugin: input_uvc.so input_uvc: using V4L2 device: /dev/video0 input_uvc: current format: 640x480 input_uvc: found format: MJPG

关键是这一行：found format: MJPG。这说明V4L2协商格式时，驱动接受了MJPEG格式，摄像头会直接输出JPEG帧。如果这行显示的是found format: YUYV，说明摄像头不支持硬件MJPEG，程序会走libjpeg软编码路径。

我用一个只支持YUYV的摄像头测试，同样的分辨率和帧率，CPU占用率直接飙升到40%以上。这个对比非常直观，也印证了韦东山老师在视频里强调的观点：硬MJPEG是流畅性的关键。

3.4 参数选择的经验值

分辨率、帧率、JPEG质量这几个参数之间是相互制约的。我整理了实际测试的一组数据，都是MJPEG硬编码模式：

从这个表格可以得出几个结论：分辨率和帧率越高，带宽占用越大；同一分辨率下帧率翻倍，带宽基本翻倍；JPEG帧大小受画面复杂度影响很大，画面里有剧烈运动或者高清纹理时，帧大小会明显变大。

物联网场景下，我建议优先选择640x480@15帧或320x240@15帧，这两个档位在带宽和画质之间平衡得比较好。如果你走Wi-Fi传输，注意摄像头帧率不要超过网络吞吐能力太多，否则路由器拥堵会出现严重延迟。

3.5 多路输出的并发测试

MJPG-streamer的一个典型玩法是同时开启多个输出插件。比如我想一边在浏览器看实时画面，一边把关键帧落到本地存储，方便事后分析。这时命令可以写成：

./mjpg_streamer -i "./input_uvc.so -d /dev/video0 -r 640x480 -f 15" \ -o "./output_http.so -w ./www -p 8080" \ -o "./output_file.so -f /tmp/frames -d 1000"

output_file.so的-d参数是保存帧的时间间隔，单位毫秒，-d 1000表示每秒存一张图。两个输出插件共用同一份输入数据，靠之前讲到的锁机制保证同步。

实测中我发现，只要输入帧率不低于10帧，两条输出链路都能保持稳定。但如果帧率降得太低，比如只有5帧，HTTP流会出现明显的卡顿感，文件输出倒是无所谓，因为反正每秒钟只需取一帧。

4. 性能瓶颈分析与优化技巧

4.1 局域网传输的带宽瓶颈

用手机浏览器和PC浏览器同时访问同一个MJPG-streamer节点，它们各自收到一份完整的视频流。也就是说，客户端数量乘以单路码率，就是总出口带宽。以640x480@30帧为例，单路约10Mbps，两个客户端就需要20Mbps，这对百兆有线网络来说还好，但如果节点接的是Wi-Fi，很容易把无线带宽吃满。

优化思路有两个方向：一是降低视频参数，对源端做限制；二是在传输层做改造，比如加一层简单的带宽限制或缓存策略。不过MJPG-streamer本身没有做客户端数量的限制，生产环境中一般建议在前面加反向代理做访问控制，否则任何知道IP的人都能直接看到你的画面。

4.2 延迟构成分析

视频监控的延迟来自采集、编码、传输、解码、显示五个环节。MJPG-streamer方案里，硬件MJPEG模式把采集和编码合二为一，延迟极低。HTTP协议本身的传输延迟也基本可以忽略。真正影响体验的延迟，主要来自浏览器端的播放策略和网络缓冲。

实测从摄像头捕捉到动作，到浏览器屏幕上出现对应画面，整体延迟在100到300毫秒之间。对于监控场景这个数值完全够用。如果你追求更低延迟，可以在摄像头输出参数里把帧率调高，并确保同一局域网内没有大流量下载任务干扰。

4.3 压缩质量与CPU的取舍

如果你只能用YUYV软编码模式，libjpeg的质量参数就非常关键。MJPG-streamer的input_uvc插件里有一个-q参数，取值范围50到100，默认80。数值越高，图片越清晰，但压缩率越低，CPU负担越大。

我的建议是：监控画面通常不需要100%质量，-q 80到-q 85是一个甜点区，肉眼几乎看不出画质损失，但帧大小能控制在合理范围。不要把质量调到90以上，除非你每帧是一张要保存的高清证据图，否则纯粹是浪费带宽和CPU。

4.4 开机自启与看门狗

物联网设备往往无人值守，需要保证视频监控进程断了能自动拉起来。我当时在开发板上写了一个简单的守护shell脚本：

#!/bin/sh while true; do if ! pgrep -f mjpg_streamer; then /root/mjpg/mjpg_streamer \ -i "/usr/lib/input_uvc.so -d /dev/video0 -r 640x480 -f 15" \ -o "/usr/lib/output_http.so -w /root/mjpg/www -p 8080" >> /var/log/mjpg.log 2>&1 & fi sleep 10 done

把脚本放到init.d或者systemd里，设置开机启动。每10秒检查一次进程是否存在，如果异常退出就自动拉起。这个简单粗暴的方案在生产环境里跑了很久都很稳定。

5. 常见的坑与排查实录

5.1 打开摄像头失败：No such file or directory

这个报错十有八九不是文件真的不存在，而是没有权限。开发板上的/dev/video0设备往往属于root或video组。排查步骤：

• 先ls -l /dev/video0确认设备节点存在。

• 再看用户是否在video组里，可以用id命令查一下。

• 如果不想换用户，可以直接用chmod 666 /dev/video0临时解决，然后重启mjpg_streamer。

要注意系统重启后权限会重新分配，所以最好还是把用户加入video组，或者写udev规则。

5.2 画面花屏或偏绿

花屏的原因通常是像素格式不匹配。比如软件包默认协商成YUYV，但摄像头实际输出的格式顺序不同，或者分辨率设置超出了摄像头的实际支持范围。

排查顺序：

1. 用v4l2-ctl --list-formats-ext -d /dev/video0查看摄像头支持的所有格式。

2. 确认你的-r分辨率在摄像头支持列表里。

3. 确认启动日志里current format显示的确实是MJPG或YUYV，而不是奇怪的格式。

如果摄像头只支持某些固定分辨率，而你设置了一个它不支持的尺寸，V4L2驱动往往不会直接报错，而是默默输出一个不正确的画面。这就是“能跑但画面异常”的根本原因。

5.3 HTTP访问返回404

-w参数指定了网页根目录，如果目录不存在，或者里面没有index.html，访问根路径就会返回404。排查方法是先确认-w目录下文件确实存在，然后在开发板上用curl http://127.0.0.1:8080/?action=snapshot测试，直接看命令返回的HTTP状态码。

如果snapshot没问题，但stream打不开，多半是防火墙或路由器封了8080端口。开发板上先关掉不必要的防火墙规则，或者把端口换成8081试试。

5.4 画面断断续续，帧率上不去

这个问题要从两头排查：一是摄像头端的输出帧率，二是网络端的带宽。最简单有效的定位方法是先在开发板本地测试，不经过HTTP，直接让output_file插件往磁盘写帧，看写帧速度是否达到预期。如果本地写帧速度正常，那问题就在网络上；如果本地速度也很慢，那就要看看摄像头信号线、USB带宽或者供电是否足够。

USB摄像头供电不足是经常被忽略的元凶。某些摄像头在USB 2.0口上，如果主板供电能力弱，会出现帧率抖动甚至设备反复离线。这时候换一个带独立供电的USB HUB，问题往往迎刃而解。

5.5 内存耗尽与缓冲区不足

MJPG-streamer的--buffer参数控制线程间共享缓冲区的数量，默认是10帧。如果客户端连接数量多或者读取速度慢，缓冲区会被占满，新的帧没有位置存放，输入线程会被阻塞。表现就是摄像头采集卡顿，或HTTP流延迟越来越大。

这种情况可以适当调高缓冲区数量，比如：

./mjpg_streamer --buffer 20 -i "./input_uvc.so -d /dev/video0" -o "./output_http.so -p 8080"

但也要注意缓冲区越大内存占用越高。一帧640x480的JPEG大约45KB，20帧也就不到1MB，对现代设备完全不是问题。真正容易爆内存的是有些板卡默认的/dev/shm分区太小，如果输出插件把帧临时存到共享内存里，就可能写满。遇到这个情况，检查一下df -h /dev/shm，空间不足就重新挂载大一点。

6. 扩展方向：从MJPG-streamer出发还能怎么玩

6.1 视频流加密与鉴权

MJPG-streamer原生没有用户名密码验证，直接暴露在公网等于裸奔。你要部署到公网环境，一定要在前面加一层保护。最省事的方案是用Nginx做反向代理，把8080端口隐藏起来，通过HTTPS和Basic Auth访问。Nginx的auth_basic指令五分钟就能配置好，效果立竿见影。

6.2 对接云平台

物联网场景下，视频监控通常需要接入云平台。你可以写一个简单的上报任务，周期性通过/?action=snapshot抓取某一帧，然后用MQTT协议把它发布到云端的主题里。云平台收到图片后，可以做AI分析或者归档存储。这样既保留了MJPG-streamer实时预览的能力，又补上了云端接入能力。

6.3 录像回放

搭配output_file插件，定时保存帧图片，然后在服务器上把这些JPEG序列编码成MP4。这个方案不需要修改MJPG-streamer的代码，只需要写一个调度脚本。缺点是文件是离散的图片，整理起来相对繁琐。更高级的做法是改造output插件，直接封装成AVI或在MJPG流的基础上做H.264转码，但这个工作量会大不少。

6.4 替代与延伸方案思考

如果你对延迟和编码效率有更高的要求，建议在MJPG-streamer的基础上接入RTSP或WebRTC链路。不过也要注意，这些方案复杂度会直线上升，需要的CPU和内存也更多。我的原则很清楚：场景简单，能用MJPG-streamer就直接用；场景复杂，先算清楚成本，再考虑替换路线，不要一上来就上重框架。

我个人在实际项目里一直把MJPG-streamer当作物联网视频节点的“标配底座”，它能让你在十分钟内看到画面，给后续开发和调试建立充足的信心。作为入门嵌入式视频开发的第一课，它的代码量适中，原理清晰，踩完坑之后再去看更复杂的GStreamer或者FFmpeg，你会觉得那些框架里很多概念都能在MJPG-streamer里找到对应，理解成本会低得多。