把摄像头视频上传服务器这件事，在MFC框架下最稳妥的做法是用Live555或FFmpeg做推流，服务器端用SRS或Nginx-RTMP接收，MFC负责画面预览和控制逻辑，整个流程约300行核心代码就能跑通。
很多用MFC做上位机开发的工程师，第一次接触视频上传都会愣一下，MFC本身不直接提供网络视频传输能力，但通过Windows原生API组合，完全可以搭出一套稳定的视频上传链路，本文不讲虚的,直接拆解每一步的实现路径。
摄像头视频上传服务器的MFC实现思路
先捋清楚整体架构，摄像头采集视频流，MFC程序读取视频帧，通过RTMP或HTTP协议推到服务器，服务器端再用流媒体服务做转发或存储，现在主推的做法是MFC程序只做采集和推流，服务器承担转码和分发，这样MFC端的代码量控制在合理范围,避免把所有逻辑都塞进客户端。
MFC中视频采集的第一步：DirectShow还是Media Foundation
Windows下视频采集有两条老路，一条是DirectShow，一条是Media Foundation，DirectShow出身早，资料多，市面上大量USB摄像头和采集卡都支持，Media Foundation是后起之秀，Win7以上系统内置支持,但遇到老型号摄像头反而容易踩坑。
做MFC开发，优先选DirectShow，理由很直接：DirectShow的采集回调机制更灵活，拿到RGB帧数据后可以直接压缩编码，而且兼容性强，用Media Foundation的话,在Win10系统上跑老式USB摄像头可能出现无法枚举设备的问题。
具体实现需要做两件事：用CoInitialize初始化COM环境，然后创建Filter Graph管理器来枚举视频设备，示例代码网上不少，核心就是这几十行，这里提醒一句，摄像头分辨率别直接调到最高，1080P对于MFC程序来说太费CPU,720P到900P之间是个平衡点。
用H.264硬编码减少CPU占用
视频帧采集到手，接下来是编码，MFC程序里用X264软编码是过去的玩法，现在推荐直接调用Intel QuickSync或NVIDIA NVENC做硬编码，一块普通的i5-12400处理器，硬编码4路720P视频毫无压力,软编码跑两路就喘了。
如果考虑跨平台，首选FFmpeg封装，FFmpeg自带多种硬件编码器的接口，代码里通过av_hwdevice_ctx_create初始化硬编解码器，后面调用流程跟软编码一致，行业共识认为，FFmpeg是目前视频处理领域兼容性最好的库,MFC配合FFmpeg做视频上传是成熟方案。
局域网摄像头视频上传服务器的MFC开发细节
把单路摄像头搞定后，很多人会问，局域网里多台摄像头怎么整？MFC方案里，硬件NVR和纯软件方案各有利弊，硬件NVR的优点是省心，缺点是贵，而且协议封闭，纯软件方案用MFC做客户端，服务器端跑SRS,一台上万块的小主机就能带几十路摄像头。
推流协议选RTMP还是HTTP-FLV
摄像头视频上传服务器，协议选择直接影响延迟和兼容性，RTMP是基于TCP的长连接协议，延迟控制在1到3秒，对Flash时代的遗产支持好，现在依然有很多服务器在用，HTTP-FLV则更轻量，可以直接跑在CDN上,浏览器里的播放器几乎都支持。
从实现角度说，MFC端集成librtmp库做RTMP推流最省事，librtmp封装好了RTMP握手、数据包封装这些底层细节，开发量能省一半，如果你们公司服务器用的是Nginx，配个nginx-rtmp-module模块，就能直接接收RTMP流再转成HLS或者HTTP-FLV给网页端看,这个架构在安防监控行业用得最普遍。
断线重连和本地缓存必须做
局域网环境也不是绝对稳定，摄像头的供电、交换机端口的老化、路由器对长连接的超时限制，这些都可能让推流断掉，MFC端写好推流逻辑之外，断线自动重连和本地临时存储是两条保命代码。
断线重连的逻辑不复杂：检测到推流失败，先停掉当前视频帧推流，释放网络资源，等2秒再重新建立连接，这里注意重连次数要加上限，否则服务器挂掉之后，客户端会进入无限重启的死循环，本地缓存方案就是在网络恢复前，先把视频帧写到本地文件，等连接恢复后再把缓存文件追加上传，这个功能能救急，但注意不要让它长时间运行,把磁盘写爆就得不偿失了。
多个摄像头视频上传服务器MFC的高效方案
多路并发是MFC开发者的噩梦，早年大家都是一路视频一个线程，结果CPU跑满，画面全都卡成PPT。现在的做法是单线程事件循环配合异步I/O，Win32的消息循环本身就是个天然的事件分发器，每路摄像头的视频帧到达后发一个自定义消息,UI线程完成渲染和推流指令分发。
单线程处理多路视频帧的Win32消息循环优势
MFC的PreTranslateMessage和自定义消息配合起来非常顺手，每路摄像头数据流进来，从DirectShow回调里PostMessage到主线程，主线程再把该帧数据压入对应视频通道的推流缓冲区，这样规避了多线程加锁的问题,代码读起来也直观。
实际跑下来，四路720P视频的帧处理时间基本能控制在10毫秒内，这个方案有个额外好处，视频通道更容易做了，增删摄像头的操作只需要维护一个通道列表，很多MFC上位机软件里的监控墙界面,就是这么做的。
画面分割和本地预览与上传的同步问题
多路视频同时显示在MFC的CView或者CDialog上时，必须做局部刷新优化，整屏Invalidate会闪屏，还会拖慢推流节奏，正确做法是用双缓冲DrawText或者直接操作DIB Section,只重绘需要更新的区域。
本地预览和上传的同步问题也要小心，预览为了流畅，帧率一般保持在15到25帧；上传为了省带宽，可以降到10到15帧，MFC里把这俩逻辑分开写，各自跑各自的定时器，不要互相阻塞，给上传帧率低一点,服务器端压力也小一些。
摄像头视频上传服务器MFC常见问题与参数优化
做了那么多方案,真到部署的时候最常见的坑还是集中在网络和帧率参数上。
视频卡顿通常不是因为带宽不够
很多MFC开发者发现视频上传后播放卡顿，第一反应是加带宽，实际上卡顿的主因往往是丢包和抖动，RTMP走TCP确实不会丢包，但TCP的重传机制会带来延迟抖动,服务器端播放器看到的就是一会快一会慢。
解决办法有两个方向，一是MFC端把码率设成动态的，通过FFmpeg的AVDictionary参数调整目标码率范围，当网络波动时自动降低画质保流畅，二是服务器端加大缓冲队列的长度，但这会延迟增加，单路视频推流，可以选动态码率方案，多路视频推流,建议校准固定码率配合服务器缓冲。
帧率和关键帧间隔推荐配置
MFC推流时最常见的参数组是：视频帧率15fps，关键帧间隔2秒，码率1.5Mbps，这个组合在普通办公网络和手机4G环境下都能跑得开，如果要在公网传输，适当降低到1Mbps码率，帧率保持15fps,画面依旧能看。
开机自启和异常恢复机制
项目落地时，MFC程序往往要跑在工控机上，一个开机自启的Windows服务是常见需求，在控制面板里把MFC程序注册成服务，或者塞进启动文件夹，此外MFC程序挂在后台跑，要加一个看门狗进程，异常退出后自动拉起，有朋友在做MFC视频相关项目时遇到程序崩溃，结果发现是没有处理内存泄漏,千万记得定期清理DirectShow产生的GDI对象和COM引用。
摄像头视频上传服务器MFC的开发实战建议与Q&A
做MFC视频开发，本质上是跟Windows底层打交道，这套活儿现在年轻程序员很多不会，但老设备老系统还在稳定运行,MFC这套方案短时间内不会消失。
开发建议先跑通单路摄像头，再逐步加通道。 不要一上来就追求架构完美，先写一个能用的Demo，把采集、编码、推流、服务器接收、播放器验证这条链路跑通，再回头优化代码结构，工程实践里,第一步走通远比设计完美重要。
Q&A：MFC视频上传相关高频提问
问：MFC做摄像头视频上传，推荐用哪个开发环境版本？
答：Visual Studio 2019或者2026都行，安装时勾选”适用于最新v142生成工具的C++ MFC”组件，编译器选VS2015+的v141工具集，兼容性好，Windows SDK版本选最新的10.x即可，DirectShow的头文件在旧版SDK里，需要把mmreg.h和dshow.h都拷进工程。
问：MFC视频上传服务器，用云服务器还是本地服务器划算？
答：云服务器方便，简米云或酷番云的轻量应用服务器配个SRS，每月几十块就能跑起来，本地服务器前期成本高，但长期运行电费和带宽费用更低，适合监控路数多且稳定的场景，云服务对摄像头视频上传价格敏感的用户更友好，因为不需要一次性投入硬件设备,而且数据区域可以就近选择节点。
问：如果服务器只做存储不做直播，MFC还要走RTMP吗？
答：纯存储场景可以不用RTMP，直接走HTTP PUT或者multipart/form-data上传FLV或MP4文件即可，系统少一个流媒体服务器，维护起来更简单，只有当需要实时观看画面时，推流协议才有必要，存文件的代价是占存储，因为没有了流媒体的实时转码环节，存储的文件格式更通用,保存的视频可以用任意播放器打开验证。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/607229.html
