AMCap源码深度解析：DirectShow摄像头采集链路与工程改造指南

简介AMCAP 是基于 DirectShow 的经典音视频捕获示例由微软官方提供适合 Windows 多媒体开发者研究摄像头设备采集流程。代码在 Visual Studio 中实测可通过编译后即可打开摄像头并预览画面解决 DirectShow 采集管线搭建、设备枚举与参数控制等常见问题。资源包共 96 个文件大小约 1.63 MB以 38 个头文件、34 个 C 源文件为主体同时包含工程配置、资源文件与预编译产物完整还原官方示例的编译环境此外还保留了旧版本工程文件与编译中间产物便于对照不同环境下的生成差异。核心实现涵盖 AMCap 主程序、BaseClasses 基础类库、Crossbar 视频路由、视频控制及设备通知等模块既可直接集成到项目中也适合按文件逐段学习 DirectShow 的 Filter 图构建、媒体类型协商与渲染流程。目前已有 1410 人浏览学习适合有一定 C 基础、希望入门 DirectShow 或快速实现 USB 摄像头采集的开发者。1. 为什么要啃 amcap source code源代码一个经典采集Demo到今天仍能撑起采集项目做Windows下的USB摄像头采集绕不开amcap source code源代码。这套经典示例把采集全景摊在一个对话框程序里设备枚举、格式协商、视频预览、亮度曝光控制、AVI录制、单帧保存每个环节都有能直接对照的调用和回调。现在做工业相机取图工具、网课摄像头测试程序、嵌入式主板配套的采集上位机拿它当骨架改造依然是最短路径。它适合两类人刚接触DirectShow、想弄明白采集链路的新手以及要在几天内交付可用采集程序的熟手。读懂它等于把Windows视频采集的地基打了一遍。2. 源码结构梳理MFC外壳之下真正值钱的是采集管线2.1 顶层分层应用壳、设备枚举、图管理与采集控制的四层划分拿到源码第一件事不是编译而是先分清楚哪些代码能留、哪些代码要扔。AMCap表面是一个带菜单和工具栏的MFC对话框程序界面代码占了不少篇幅但真正值得迁移到自有项目的是界面下面那套采集逻辑。常见排布是分成四块应用壳程序入口、窗口初始化、菜单命令的转发。这块和业务无关移植时基本可以整个丢掉。设备层专门负责枚举系统里的视频输入设备记住用户上次选了哪台创建源Filter。这层值得保留因为“枚举设备”这件事无论你用什么界面框架都得做。图管理层负责创建Filter Graph、把源Filter加进图里、运行/暂停/停止处理图事件。这层是采集程序的骨架移植时建议原样拷贝。采集控制层管预览、抓帧、录像、压缩器选择还负责把亮度、曝光这些相机参数映射到DirectShow接口上。这层代码最杂也是踩坑最多的地方。我一般建议按这个边界去读源码先找到每次“开始预览”都走到的那个函数从它往上读是界面往下读是采集核心。如果某个精简版把设备枚举和图构建写在一个类里说明它牺牲了复用性改起来会很别扭。把四层边界画清楚后你会发现无论源码怎么改版核心调用链都绕不开下面这一节的内容。2.2 采集核心调用链从“选设备”到“预览出画”的接口顺序一次完整预览的调用顺序在AMCap源码里是有固定模式的。先创建Filter Graph再创建捕获图构造器然后把设备枚举阶段得到的Moniker绑定成源Filter最后把预览引脚渲染到窗口。下面这段代码是这个模式的常见写法也适合作为你自己工程的起点// 从“选设备”到“预览出画”的典型调用顺序 // 省略错误处理用于说明调用关系不是可直接编译的完整代码 HRESULT StartPreview(HWND hwnd, IMoniker* pMoniker) { IGraphBuilder* pGraph nullptr; ICaptureGraphBuilder2* pBuilder nullptr; // 1. 图容器所有Filter的宿主 CoCreateInstance(CLSID_FilterGraph, nullptr, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(pGraph)); // 2. 捕获图构造器负责找Pin、搭链路 CoCreateInstance(CLSID_CaptureGraphBuilder2, nullptr, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(pBuilder)); pBuilder-SetFiltergraph(pGraph); // 3. 把设备枚举得到的Moniker变成真正的源Filter IBaseFilter* pSource nullptr; pMoniker-BindToObject(nullptr, nullptr, IID_PPV_ARGS(pSource)); pGraph-AddFilter(pSource, LCapture Source); // 4. 让构造器自动找预览Pin并连到渲染器 pBuilder-RenderStream(PIN_CATEGORY_PREVIEW, MEDIATYPE_Video, pSource, nullptr, nullptr); return S_OK; }逻辑说明第一步和第二步创建的两个COM对象生命周期要覆盖整个采集会话源码里通常在“打开设备”时创建、在“关闭设备”时释放而不是每次预览都新建。第三步的BindToObject把设备枚举阶段拿到的Moniker解析成真正的Filter这一步失败多半是设备被占用或驱动异常。第四步的RenderStream是整条链里最省事的接口它会自动找到合适的Pin、自动挑选预览渲染器、自动完成连接代价是你对中间环节的控制变弱。参数说明PIN_CATEGORY_PREVIEW和PIN_CATEGORY_CAPTURE是两种逻辑引脚同一个物理摄像头引脚经常同时扮演两个角色预览链和录像链不要混着连否则你会收到重复帧或者画面卡顿。补充一个容易忽略的点RenderStream之前往往要先协商格式。源码里典型做法是拿IAMStreamConfig接口枚举出所有可用的分辨率、帧率和像素格式选一个再SetFormat。AMCap的设备设置对话框干的就是这件事。协商失败时程序会跳下一种格式继续试直到找到能用的组合——这解释了为什么有些摄像头在设置面板里显示不全但预览却正常。2.3 源码里最常碰到的DirectShow接口各管什么把AMCap源码里出现频率最高的接口列成一张速查表读代码时可以对照着看。很多看起来像“玄学”的报错最后都落在这张表的某个调用上。接口在源码里承担的事遇到问题的排查方向IEnumMoniker / IMoniker枚举视频输入设备记录设备标识枚举为空时查驱动和占用IGraphBuilderFilter的添加、连接、运行控制AddFilter失败多半是Filter未注册ICaptureGraphBuilder2RenderStream、FindInterface、设置输出文件名链路连不上时先检查Pin类别IAMStreamConfig查询/设置分辨率、帧率、像素格式设置不了时先枚举再SetFormatIAMVideoProcAmp亮度、对比度、饱和度、白平衡、曝光不支持时返回E_NOTIMPL界面置灰IAMCameraControlPan、Tilt、Zoom、Roll等机控云台式摄像头才支持普通UVC返回失败ISampleGrabber抓单帧、回调原始采样数据放错链路位置会导致只预览不回调IFileSinkFilter修改录像输出文件名、分段切换录像写到一半要换文件时用它这张表覆盖了这套源码里八成以上的调用剩下的基本都是辅助接口和COM基础操作。读源码时如果遇到不认识的名字先回这张表定位它属于哪一层再去搜接口定义效率会高很多。特别说明一下别在源码里找所谓的“主函数”从头开始读应该从你要实现的某个功能反向定位你要做帧处理就从ISampleGrabber回调往前找你要做录像就从SetOutputFileName往前找。这比从头读到尾效率高太多也是我把这套源码读透的路径。3. 环境准备与编译改造先把旧工程在新SDK里跑起来3.1 老工程为什么在新SDK下几乎必挂编译AMCap这类经典源码的年代较早工程文件是基于老式工具链生成的。直接拿新版本开发环境打开最常见的三个问题平台工具集不识别、字符集不匹配、DirectShow相关头文件和库的路径变化。平台工具集的问题最表面。新开发环境一般会提示“是否执行一次性升级”点确认后如果还报“工具集未安装”就在项目属性里把平台工具集改成当前环境自带的版本。字符集问题更隐蔽老工程不少默认走多字节字符集而新SDK的头文件对Unicode的支持更彻底一旦工程里混用了char和TCHAR编译会报一堆字符串转换错误运行期还会出现菜单乱码、文件名乱码。DirectShow方面新SDK仍然保留dshow.h和strmiids.lib这些基础件但如果你拿到的是被精简过的单文件版头文件引用顺序一变就会冒出莫名其妙的重定义错误。所以拿到源码后我建议不要在老工程文件上死磕直接把采集核心摘出来放到一个新工程里。老工程里那些界面资源、工具栏位图、对话框布局对一个要二次开发的项目来说基本是负资产。3.2 最小改造清单字符集、附加依赖与CMake骨架把采集核心抽出来之后工程配置可以简化成三件事字符集统一走Unicode链接库补上DirectShow需要的几个库编译宏里把UNICODE和_UNICODE都定义上。下面的CMake骨架是我常用的做法cmake_minimum_required(VERSION 3.20) project(amcap_port LANGUAGES CXX) # 把从AMCap抽出的源文件列进来界面文件不参与编译 add_executable(amcap_port CaptureCore.cpp DeviceEnum.cpp GraphManager.cpp ) # 统一走Unicode字符集避免char/TCHAR混用 target_compile_definitions(amcap_port PRIVATE UNICODE _UNICODE) # DirectShow依赖库 target_link_libraries(amcap_port PRIVATE strmiids.lib quartz.lib)逻辑说明这两个要链接的库一个提供Filter、Moniker等基础CLSID的绑定一个提供Filter Graph相关的实现。如果你的代码里还用了音频采集可能还要补ole32和winmm之类的系统库但视频采集主链路通常只需要这两个。参数说明UNICODE和_UNICODE成对出现前者影响Windows API版本选择后者影响C运行库的TCHAR映射只定义其中一个_tcslen这类宏会指向错误版本的实现属于低频但难查的坑。如果编译时出现函数重定义优先检查是不是间接include了两个版本的streams.h解决办法是用新SDK的dshow.h替代老SDK的streams.h这是老代码适配新环境最常见的翻车原因之一。3.3 编译通过不算完先跑一段设备枚举自测程序能编译过只说明语法层面没问题。采集程序的第一步验证永远是设备枚举。设备枚举如果跑不通后面所有环节都没有意义。下面这段代码是从AMCap的设备层抽出来的核心逻辑可以直接放到一个控制台工程里验证设备是否可见#include dshow.h #include iostream #include string #pragma comment(lib, strmiids.lib) void EnumerateCameras() { HRESULT hr CoInitializeEx(nullptr, COINIT_MULTITHREADED); if (FAILED(hr)) { std::cerr CoInitializeEx failed std::endl; return; } ICreateDevEnum* pDevEnum nullptr; IEnumMoniker* pEnum nullptr; hr CoCreateInstance(CLSID_SystemDeviceEnum, nullptr, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(pDevEnum)); hr pDevEnum-CreateClassEnumerator(CLSID_VideoInputDeviceCategory, pEnum, 0); // 枚举不到视频设备时CreateClassEnumerator会返回S_FALSE而不是错误码 if (hr ! S_OK) { std::cerr no video device category std::endl; return; } IMoniker* pMoniker nullptr; ULONG fetched 0; while (pEnum-Next(1, pMoniker, fetched) S_OK) { IPropertyBag* pBag nullptr; pMoniker-BindToStorage(nullptr, nullptr, IID_PPV_ARGS(pBag)); VARIANT var; VariantInit(var); if (SUCCEEDED(pBag-Read(LFriendlyName, var, nullptr))) { std::wcout Lcamera: var.bstrVal std::endl; VariantClear(var); } pBag-Release(); pMoniker-Release(); } pEnum-Release(); pDevEnum-Release(); CoUninitialize(); }逻辑说明这段代码的核心在CreateClassEnumerator它把系统里所有视频输入设备归成一个枚举集合然后逐个Moniker读取设备名。AMCap的设备下拉列表就是从这里填充的。如果返回S_FALSE说明系统里没有可见的视频设备这时候先别怀疑代码优先检查摄像头是否被占用、驱动是否异常。参数说明CLSID_VideoInputDeviceCategory专指视频输入设备如果你要枚举音频采集设备可以换成对应的Category GUID。读取FriendlyName用延迟绑定的BindToStorage而不是BindToObject因为读属性不需要真正创建设备Filter速度更快也不会把设备占住。冒烟测试我个人会做三组不接摄像头跑一次预期是枚举为空接普通UVC相机跑一次预期看到设备名再接一个虚拟摄像头软件跑一次预期也能枚举到且能读出FriendlyName。三组都通过才说明环境这一关真正过了。接下来才能放心地把采集图搭起来。4. 采集管线最短实现预览、抓帧与录像参数一起说清4.1 五步搭出一条可用预览图再做参数调整设备枚举通过后最优先要做的是让画面显示出来。搭一条预览图在AMCap里就是五步创建Filter Graph、创建捕获图构造器并关联、把Moniker绑定成源Filter并加图、用RenderStream找预览Pin、最后运行图。前面第2章的代码已经演示了前四步这里补上运行和停止的规范写法// 预览图运行与停止的常见写法 pBuilder-RenderStream(PIN_CATEGORY_PREVIEW, MEDIATYPE_Video, pSource, nullptr, nullptr); // 渲染器由系统自动挑选 // 运行图让视频流开始流动 pGraph-Run(); // 需要停止时先暂停再停止避免某些Filter出现状态错乱 pGraph-Pause(); pGraph-Stop();逻辑说明Run之后视频流才开始流动预览窗口才能出画面。停止时先Pause再Stop不是强迫症而是给部分Filter一个状态机缓冲直接从Run调Stop会让某些渲染器收到一个未预期的状态切换造成下次重建图时残留帧。参数说明RenderStream的第五个参数是可选的渲染器Filter传nullptr表示让系统自己选通常是VMR如果你想控制渲染行为可以自己创建VMR9并把指针传进去这样能拿到窗口控制接口后续做全屏、缩放、截图都更方便。预览能出画面后再回头设置格式。格式协商的正确顺序是先拿IAMStreamConfig枚举再从中挑一个组合SetFormat最后才RenderStream。反过来先连好再改格式有些驱动会拒绝变更这是很多改过AMCap的人踩过的坑。4.2 抓帧的正确位置Sample Grabber该插在哪条链上预览稳定后最常见的需求变成“我要拿到每一帧数据做处理”。AMCap的抓帧路径用的是Sample Grabber过滤器但它的位置很有讲究。直接连在源Filter输出Pin后面再把后续连到Null Renderer是最稳的组合// 抓帧链路的搭建要点省略COM初始化和错误处理 IBaseFilter* pGrabberFilter nullptr; ISampleGrabber* pGrabber nullptr; CoCreateInstance(CLSID_SampleGrabber, nullptr, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(pGrabberFilter)); pGrabberFilter-QueryInterface(IID_PPV_ARGS(pGrabber)); // 让回调收到原始视频帧数据 AM_MEDIA_TYPE mt; ZeroMemory(mt, sizeof(mt)); mt.majortype MEDIATYPE_Video; mt.subtype MEDIASUBTYPE_RGB24; pGrabber-SetMediaType(mt); pGrabber-SetCallback(YourCallbackImpl, 0); // 0表示用回调缓冲模式 // 把Grabber插到源Filter和Null Renderer之间 pGraph-AddFilter(pGrabberFilter, LGrabber); pGraph-AddFilter(pNullRenderer, LNull Renderer); pBuilder-RenderStream(PIN_CATEGORY_CAPTURE, MEDIATYPE_Video, pSource, pGrabberFilter, pNullRenderer);逻辑说明Sample Grabber不能作为链路的终点后面必须再接一个Filter否则它会认为图不完整而拒绝连接。Null Renderer就是一个光接收不显示的终点专门用来配合抓帧。SetMediaType里传RGB24是让Graph在Grabber上游自动插入颜色转换器把摄像头输出的YUY2或MJPEG统一转成RGB24你的回调代码就不需要自己解码了。参数说明SetCallback的第二个参数是缓冲模式0表示回调模式每次收到采样都会触发1表示缓冲模式需要主动等下一帧两种模式对MJPEG数据的行为不同做实时处理建议用回调模式。这里有个细节要提醒预览链和抓帧链如果都挂在同一个物理Pin上带宽会翻倍一些老摄像头会掉帧。常见做法是让源Filter分出Preview和Capture两个Pin或者用Smart Tee把一路信号拆成两路。源码里处理这个问题的方式和我下面讲录像参数时是同一套思路。4.3 录像参数别拍脑袋FourCC、帧率与AVI封装选型录像这块最容易犯的错误是拿到源码里的默认值直接用。AMCap录像走的经典链路是源Filter → 压缩器 → AVI Mux → 文件写入。决定录像质量的关键参数有三个像素格式、帧率、压缩器。像素格式在UVC摄像头上通常可选YUY2和MJPG两种YUY2画质好但数据量大MJPG带宽小但解码有损做长时间录像我一般选MJPG压缩再进AVI能显著降低CPU占用和磁盘写入压力。帧率不要拍脑袋写死。正确做法是枚举VIDEO_STREAM_CONFIG_CAPS// 枚举帧率并设置常见于源码的参数配置代伪代码级 IAMStreamConfig* pConfig nullptr; // 从预览Pin或Capture Pin上拿到IAMStreamConfig pPin-QueryInterface(IID_PPV_ARGS(pConfig)); int count 0, size 0; pConfig-GetNumberOfCapabilities(count, size); for (int i 0; i count; i) { VIDEO_STREAM_CONFIG_CAPS caps; pConfig-GetStreamCaps(i, pMediaType, (BYTE*)caps); // caps.MaxFrameInterval / caps.MinFrameInterval 是帧率范围 // 从里面挑一个想要的区间再构造AM_MEDIA_TYPE设置回去 }逻辑说明GetNumberOfCapabilities拿到的是该设备在当前分辨率下的能力数量每种能力包含像素格式、帧率范围、是否支持隔行等。AMCap不会直接暴露这个循环但它的设置对话框数据最终就是从这里取的。参数说明MaxFrameInterval单位是100纳秒算帧率要用10000000去除比如间隔333333对应约30帧。设完格式后一定要再调SetFormat部分驱动不重新协商会继续按默认格式输出。录像输出格式上AVI封装本身有单文件大小限制的风险长时间录像建议用IFileSinkFilter在写满前切换文件名或者直接换用MP4封装方案。如果你是在老代码基础上改压缩器选型不要追求“无损”UVC摄像头输出的本来就是压缩或未压缩的原始数据再走一遍无损压缩只会浪费CPU。到这里主链路已经通了剩下的问题大多藏在细节里下一章集中梳理高频翻车点。5. 避坑清单把AMCap源码改造成产品前先查这5个高频翻车点5.1 预览黑屏但设备枚举正常别急着查驱动现象程序能枚举到摄像头RenderStream也返回成功但预览窗口一片黑或者只有第一次预览正常关掉再开就黑屏。原因常见的不是驱动问题而是预览渲染器跑到了错误的窗口句柄上。AMCap的预览窗口往往绑定在对话框的子窗口上窗口重绘、DPI变化、最小化恢复都会让渲染器失去有效的呈现目标。另一个高频原因是RenderStream里让系统自动选了渲染器但图是旧的Filter状态已经停在Stop之后没有复位。解决把预览渲染器显式换成VMR9拿到IVMRWindowlessControl后自己设定视频窗口和位置同时在图停止后把源Filter从图里移除再次预览时重新AddFilter。这样每次预览都是全新链路避免了老Filter残留状态的问题。改完这条黑屏问题能消掉一大半。5.2 摄像头被占用打开失败并不等于硬件坏了现象枚举一切正常但BindToObject或RenderStream返回设备打开失败换一台电脑又正常换别的软件却能打开。原因可能是另一个进程已经占用了设备的独占通道或者该设备在同一时刻只允许一个过滤器连接。老版本的AMCap和很多精简版采集程序不做共享打开设备时直接占用别的程序再开就冲突。解决先关闭所有可能占用摄像头的程序再测试排查时用系统的相机设置页面或另一个采集软件做对照。如果确定为占用可以在代码里对设备打开失败做重试延迟几百毫秒后再试几次无法强制抢占只能提示用户释放占用。这个问题在产品交付后特别多建议出错信息里直接带上“检查是否有其他程序占用摄像头”这句话能减少大量售后咨询。5.3 抓帧回来的BMP是倒的biHeight正负的坑现象Sample Grabber回调里拿到的RGB24数据保存成BMP后图像上下颠倒但预览画面正常。原因视频帧的数据行序在不同驱动下不一样。UVC摄像头输出很多时候是bottom-up即第一行数据对应图像最下方而BMP文件格式规定存储顺序必须是top-down写文件前不处理就会倒过来。很多初次做抓帧的人以为是自己解码错了实际上是行序问题。解决在回调里检查AM_MEDIA_TYPE对应的BITMAPINFOHEADER看biHeight的正负。biHeight为正表示top-down可以直接写入BMP为负表示bottom-up写入前要把每个像素行倒过来。处理行倒置时注意按行拷贝一行一行翻转不要按整块内存倒因为行补齐字节会让整体翻转出错。5.4 同一份代码在x64下偶发崩溃指针被窄整型截断现象Debug在x86下正常换到x64构建后偶发崩溃崩溃点经常在回调函数或自定义消息处理里看起来毫无规律。原因老代码里有不少用DWORD或LONG保存指针的写法x86下指针和DWORD等宽能正常运行x64下指针长64位被塞进32位整型后高32位直接丢失等再用这个“假指针”转回真实指针时访问的就是野地址。回调里收到的IMediaSample指针尤其容易踩这个坑。解决全局搜索代码里所有把指针或句柄存进DWORD、LONG、UINT的地方统一改成LONG_PTR、INT_PTR或者直接用指针类型凡是跨线程传递窗口句柄和COM接口指针的都要检查一遍变量宽度。编译时打开“将警告视为错误”并开启C4302这类截断警告辅助排查。这条不改x64版本上线后会是概率性崩溃调试也难复现。5.5 录像文件秒断或无法播放Smart Tee没进图现象录像开始后几秒就停或者生成的AVI文件能写入但播放器打不开单独关闭预览再录却能正常录像。原因源Filter只有一个物理输出Pin却同时接了预览和录像两条链路。DirectShow会把这条Pin的信号同时推给两个下游Filter没有拆分器时参考时钟和带宽会被抢AVI Mux拿不到连续正确的采样就会中断写入或者写出不完整的索引。解决在预览和录像共用一条物理Pin的场景里显式把Smart Tee放进链路源Filter → Smart Tee → Preview走一路、Capture走另一路。AMCap里处理“一边预览一边录像”的方式就是这个方案。如果不需要同时预览和录像录像前先断开预览链再连录像链也能规避但切换时会有黑屏体验不如Smart Tee顺。6. 进阶技巧把采集核心抽成后台线程在回调里拿原始帧做实时处理把AMCap这套链路读通之后最值得做的改造不是美化界面而是把采集核心从UI线程里剥出来放到独立线程里跑。原因很直接预览和抓帧的运行、停止、重建图在UI线程里执行时摄像头拔插一次界面就卡死而放到后台线程后UI线程永远可以响应关闭窗口、切换设备的请求这是把Demo变成产品必须跨过的一步。做法是在后台线程里创建图、运行图主线程通过自定义消息通知后台线程做操作。下面这个模式可以套到自己的工程里// 后台采集线程的简化模式 std::thread captureThread([this] { // 线程内创建Filter Graph并Run m_hr BuildGraph(); if (SUCCEEDED(m_hr)) m_pGraph-Run(); // 停在消息循环里等主线程下发停止/切换命令 MSG msg; while (GetMessage(msg, nullptr, 0, 0)) { if (msg.message WM_APP_CAPTURE_STOP) break; if (msg.message WM_APP_CAPTURE_SWITCH) { m_pGraph-Stop(); TeardownGraph(); BuildGraph(); m_pGraph-Run(); } } }); // 回调里拿到帧不要做重活只负责投递 HRESULT YourCallbackImpl::BufferCB(double SampleTime, BYTE* pBuffer, long BufferLen) { // 拷贝一份或者把指针交给固定大小的环形缓冲 PostFrameToQueue(pBuffer, BufferLen); return S_OK; }逻辑说明采集线程跟UI线程之间不要共享Filter指针所有图操作都通过消息在线程内完成这样不会出现两个线程同时访问Graph导致的动作冲突。回调BufferCB里不要做图像处理、不要写文件那些操作会阻塞采集线程导致帧缓冲被填满、画面越来越卡正确的做法是把帧拷进预先分配好的环形缓冲由另一个“处理线程”取走。参数说明环形缓冲的大小要按最大分辨率计算比如192010804字节一轮留上五六轮的余量再大就丢帧做提示不要无限增长。这套模式改完你会明显感受到稳定性变化摄像头随便拔插、预览窗口随便拖拽采集线程都不受影响。我最早改这套源码时贪图方便把Graph和界面塞在同一个线程结果一次现场演示时摄像头被误拔界面直接假死被问得哑口无言。后来立了一条规矩再没破过Graph可以停线程不能死。希望你也能在动手前先定好这条边界能省下后面大量排查时间。希望帮到你。本文还有配套的精品资源点击获取