Cap 的 Windows 摄像头统一采集层cap-camera-windows 在 Media Foundation 与 DirectShow 之间的智能路由设计【免费下载链接】CapOpen source Loom alternative. Beautiful, shareable screen recordings.项目地址: https://gitcode.com/GitHub_Trending/cap1/Cap在 Cap 这个开源屏幕录制项目中Windows 平台上的摄像头采集由cap-camera-windows这一 Rust crate 统一承载。它以单一、易用的 API 抽象了 Windows 摄像头生态中并存的两套底层技术——现代的 Media FoundationMF与遗留的 DirectShowDS并根据设备能力自动选择后端同时保证 OBS Virtual Camera 等虚拟摄像头和旧硬件的兼容性。读完本文你将掌握该 crate 的完整 API 面、后端选择与设备去重的实现原理、格式协商FormatPreference 评分算法的细节以及如何在 Cap 项目中实际枚举、选择并启动摄像头采集。设计背景为什么 Windows 摄像头采集需要“双后端”Windows 的摄像头驱动生态长期分裂Media Foundation是现代推荐路径异步采集模型、性能更好但不是所有设备尤其是旧摄像头、采集卡和部分虚拟摄像头都通过 MF 暴露完整能力DirectShow是历史遗留的 COM 过滤器图filter graph架构兼容面广但属于同步采集、接口繁琐。cap-camera-windows的目标见 crates/camera-windows/README.md是“能走 MF 就走 MF但设备在 MF 下不可用时仍会通过 DirectShow 列出”。它把 Windows 摄像头生态的复杂性收敛成一个内聚 API方便上层如 Cap 的录制管线无需关心后端差异。从 Cargo 依赖看crates/camera-windows/Cargo.toml该 crate 是一个薄封装层仅依赖两个平台专用后端 cratecap-camera-mediafoundationMF 后端的 Rust 封装负责 COM 初始化、设备枚举、格式协商与异步帧投递详见 crates/camera-mediafoundation/README.mdcap-camera-directshowDirectShow 后端的 Rust 封装负责 COM 单子moniker枚举、IAMStreamConfig格式协商与自定义 SinkFilter 的同步帧投递详见 crates/camera-directshow/README.md。另有cap-mediafoundation-utils提供底层工具。三者共同构成 Cap 在 Windows 上的摄像头采集栈。统一设备枚举一次get_devices()拿到全部摄像头get_devices()是整套 API 的入口实现在 crates/camera-windows/src/lib.rs它同时枚举 MF 与 DS 两套设备源先调用cap_camera_directshow::initialize_directshow()与cap_camera_mediafoundation::initialize_mediafoundation()完成 COM / 子系统初始化通过DeviceSourcesIterator枚举 MF 设备通过VideoInputDeviceIterator枚举 DirectShow 设备对每个设备调用detect_device_category()识别类别最后做DS 设备与 MF 设备的“配对去重”由于同一物理摄像头会同时被两套 API 暴露代码按name() model_id()生成的name_and_model()字符串匹配两个集合。每个 MF 设备最多挂接一个dshow_fallbackDirectShow 孪生设备未匹配到的 DS 设备则作为独立设备追加进结果列表。失败处理上单个设备读取元数据失败会被打印日志并跳过不会中断整体枚举返回的GetDevicesError区分MFDeviceEnumerationFailed与DSDeviceEnumerationFailed方便上层定位是哪一半枚举失败。设备元数据与类别识别每个VideoDeviceInfo提供id()、name()设备标识与显示名OsStrmodel_id()设备型号标识如VID_xxxxPID_xxxx上层可据此拆分 VID/PID见下文is_mf()判断该设备当前走的是 MF 还是 DS 后端category()/is_virtual_camera()/is_capture_card()设备类别。类别识别由源码中的模式匹配完成crates/camera-windows/src/lib.rs其核心价值在于虚拟摄像头如 OBS、Snap Camera、DroidCam、NVIDIA Broadcast和采集卡如 Elgato、AverMedia、Blackmagic、Razer Ripsaw往往存在特殊的格式与带宽行为需要上层区别对待。匹配优先级为采集卡 虚拟摄像头 物理摄像头。源码内置了约 20 条虚拟摄像头关键词obs、virtual、ndi、vtuber等与约 19 条采集卡关键词elgato、blackmagic、hauppauge等。在此基础上VideoDeviceInfo还提供了两个派生能力is_high_bandwidth()仅对采集卡有效若其任一格式达到 4K≥3840×2160且帧率 ≥30fps 则返回truemax_resolution()返回所有格式中像素总量最大的分辨率。配对去重的细节一对一映射源码在配对循环中特别注释同名设备会产生相同名字因此每个 DS 设备只与第一个“尚未挂载 fallback”的 MF 条目配对crates/camera-windows/src/lib.rs避免多个 DS 孪生全部堆到第一个匹配设备上保证映射一对一。同时MF 设备内部保存dshow_fallback: OptionVideoInputDevice用于后续格式枚举与采集失败时的降级详情见后文源码注释还指出了动机枚举阶段不主动探测 MF 格式否则每次轮询都会打开所有设备对应上游 issue CapSoftware/Cap#2132。后端选择与格式降级MF 优先、DS 兜底格式枚举MF 有结果就用 MFformats()crates/camera-windows/src/lib.rs的逻辑体现了“MF 优先”原则MF 设备先尝试用 MF 枚举格式若device.formats()非空则直接返回此时还会把 MF 格式包装为统一VideoFormat若 MF 一个格式都没产出则调用device.shutdown()释放驱动级资源源码注释说明重复请求格式不能让半开half-open的 MF 源堆积且独占式驱动在失败源仍占用设备时会拒绝 DirectShow 的绑定随后回退到dshow_fallback用 DirectShow 枚举纯 DS 设备则直接走ds_formats()。into_formats()消费式与formats()借用式的区别在于前者会主动shutdown()MF 设备专为“只读一次格式”的调用方设计避免与仍在运行的采集引擎的 teardown 竞争crates/camera-windows/src/lib.rs。统一格式对象与像素格式两套后端枚举出的原生格式分别被包装为VideoFormatInner::MediaFoundation(IMFMediaType)与VideoFormatInner::DirectShow(AMMediaType)外层统一为VideoFormat提供width()/height()/frame_rate()/pixel_format()分辨率与帧率is_bottom_up()帧内存方向标记inner底层原生格式句柄用于直接透传给对应后端的start_capturing。像素格式被规范为统一的PixelFormat枚举16 种其中大部分在 MF 与 DS 两侧都有映射统一 PixelFormatMF 子类型DirectShow 子类型YUV420PMFVideoFormat_I420/IYUVMEDIASUBTYPE_I420/IYUVRGB24MFVideoFormat_RGB24MEDIASUBTYPE_RGB24RGB32MFVideoFormat_RGB32MEDIASUBTYPE_RGB32YUYV422MFVideoFormat_YUY2MEDIASUBTYPE_YUY2UYVY422MFVideoFormat_UYVYMEDIASUBTYPE_UYVYARGBMFVideoFormat_ARGB32MEDIASUBTYPE_ARGB32NV12MFVideoFormat_NV12MEDIASUBTYPE_NV12MJPEGMFVideoFormat_MJPGMEDIASUBTYPE_MJPGYV12MFVideoFormat_YV12MEDIASUBTYPE_YV12GRAY8MF_VIDEO_FORMAT_L8MEDIASUBTYPE_Y800/RGB8NV21MEDIASUBTYPE_NV21与 DS 共用同一 FOURCC GUIDMEDIASUBTYPE_NV21RGB565MF_VIDEO_FORMAT_RGB565MEDIASUBTYPE_RGB565GRAY16/P010/H264MF 侧独有—转换失败会返回VideoFormatError区分“非视频类型”NotVideo与“无法识别的像素格式 GUID”InvalidPixelFormat源码中以常量MF_VIDEO_FORMAT_L8、MEDIASUBTYPE_NV21等显式定义 GUID。帧率换算也做了归一化MF 侧从MF_MT_FRAME_RATE的 64 位分子/分母比值计算DS 侧则按AvgTimePerFrame100ns 单位换算为10_000_000 / AvgTimePerFrame并四舍五入到两位小数。帧方向bottom-up判断由于 DirectShow 与 MF 对位图行序的约定不同VideoFormat/Frame都携带is_bottom_up标记。源码专门实现directshow_frame_is_bottom_up()crates/camera-windows/src/lib.rs仅当biHeight 0且像素格式属于“传统自下而上”类型RGB24/RGB32/BGR24/ARGB/RGB565时才判定为 bottom-up。这一规则由 3 个单元测试直接锁定crates/camera-windows/src/lib.rsRGB 正高度为 bottom-up、YUV 正高度不是、负高度一律不是。MF 侧则优先读取MF_MT_DEFAULT_STRIDE的符号位读取失败时回退到上述“传统类型”判断。格式协商FormatPreference与评分算法真实采集启动前通常需要从设备支持的众多格式中选出“最合适”的一个FormatPreference承担这一职责。偏好配置FormatPreference::new(1920, 1080, 30.0) // 默认1080p30 FormatPreference::for_hardware_encoding() // 硬件编码1080p30优先 NV12/YUYV422/UYVY422/YUV420P FormatPreference::for_capture_card() // 采集卡1080p60优先 NV12/YUYV422/UYVY422/P010默认的格式优先级队列是NV12 YUYV422 UYVY422 YUV420P MJPEG RGB32。两套“现成预设”各有侧重for_hardware_encoding()面向硬件编码场景偏好便于直接送编码器的 YUV 系列格式crates/camera-windows/src/lib.rsfor_capture_card()面向采集卡分辨率目标仍为 1080p 但帧率目标提到 60fps并把 10-bit 的P010纳入优先级适配采集卡常见的高带宽 HDR/10bit 输入crates/camera-windows/src/lib.rs。也可用with_format_priority(VecPixelFormat)完全自定义优先级。评分公式find_best_format(preference)对设备的每个格式打分crates/camera-windows/src/lib.rs取最高分格式优先级分在偏好队列中的位置pos折算为1000 - pos未在队列中的格式得 0 分——权重最大分辨率分像素总数恰等于目标给 500超出目标给400 - min(超量/10000, 300)低于目标给300 - min(不足量/10000, 200)——即宁可略高分辨率也不愿低于目标帧率分100 - min(|实际帧率 − 目标帧率| × 10, 100)帧率偏差越小越好。若最佳匹配不存在例如设备根本不支持偏好内的任何格式find_format_with_fallback()会依次遍历兜底格式列表NV12 → YUYV422 → UYVY422 → MJPEG → RGB32 → YUV420P对每种格式取“分辨率贴近目标 帧率贴近目标”的得分最高者全部失败则退回设备的第一个格式crates/camera-windows/src/lib.rs。这套“评分 多级兜底”机制保证了即便遇到格式极不规范的旧设备也能稳定选出一个可用的采集格式。采集管线统一回调接口与帧数据访问启动与停止VideoDeviceInfo::start_capturing(format, callback)按self.inner与format.inner的组合分发crates/camera-windows/src/lib.rsMF 设备 MF 格式调用 MF 后端的device.start_capturing回调内对IMFSample逐 buffer 拆包GetBufferCount/GetBufferByIndex后包装成统一FrameDS 设备或 MF 设备挂载了dshow_fallback DS 格式走 DirectShow 后端回调内从IMediaSample与AM_MEDIA_TYPE中解析KS_VIDEOINFOHEADER还原分辨率、高度方向与像素格式后端与格式不匹配时返回StartCapturingError::FormatMismatch。错误类型StartCapturingError统一封装了两端各自的错误以及格式错误crates/camera-windows/src/lib.rs上层只需处理一个错误枚举。采集句柄CaptureHandle同样是枚举类型pub enum CaptureHandle { MediaFoundation(cap_camera_mediafoundation::CaptureHandle), DirectShow(cap_camera_directshow::CaptureHandle), }调用handle.stop_capturing()会按后端分别停止会话并释放资源RAII 风格无需上层区分。帧对象与缓冲区管理每个回调携带一个统一Framepixel_format、width、height、is_bottom_up格式与内存布局信息timestampDuration与perf_counteri64时间信息供后续音视频同步使用bytes()返回FrameBytes它是DerefTarget [u8]的字节切片可当作普通[u8]使用。FrameBytes的两个变体体现了内存安全设计crates/camera-windows/src/lib.rsMF 侧返回IMFMediaBufferLock借用期内自动锁定缓冲区析构时自动解锁DS 侧从IMediaSample取指针与实际数据长度构造生命周期受限的切片。示例与工具交互式 CLI 与资源泄漏复现器交互式设备/格式选择器crates/camera-windows/examples/cli.rs 演示了完整的使用流程get_devices()枚举全部摄像头用inquire::Select让用户交互选择设备列表项会显示设备名及后端“Media Foundation / DirectShow”对选中设备列出formats()再次交互选择采集格式调用start_capturing(format.inner, callback)启动采集回调里打印每帧的bytes.len()、pixel_format、timestamp、perf_counterstd::thread::sleep(10s)后进程结束CaptureHandle析构自动停止采集。该示例仅在 Windows 上编译运行非 Windows 平台直接panic!(This example is only available on Windows)。枚举资源泄漏复现器crates/camera-windows/examples/enumeration_leak.rs 是针对上游 issueCapSoftware/Cap#2132的复现工具用于在反复枚举摄像头场景下排查线程、句柄与私有内存的增长usage: enumeration_leak.exe [mf|ds|both|mf-formats|ds-formats|formats] [iterations] [sleep_ms]mf/ds隔离枚举get_devices()的 MF 半区或 DS 半区哪个模式内存持续增长即泄漏在哪一侧mf-formats/ds-formats/formats额外读取各设备格式用于验证“格式探测”路径的资源稳定性每轮打印设备数、格式数与耗时墙钟时间线程/句柄累积时耗时也会上升可作为外部观测的辅助信号默认 60 轮、每轮间隔 1000ms无摄像头时直接报错退出避免无意义的运行。该示例体现了一个工程细节格式枚举路径必须显式device.shutdown()否则每次轮询都会在驱动侧留下半开源这正是into_formats()与formats()内部 shutdown 设计的由来。在 Cap 项目中的集成位置cap-camera-windows是 Cap Windows 端摄像头上层的“总入口”。在 crates/camera/src/windows.rs 中list_cameras_impl()直接调用cap_camera_windows::get_devices()汇总设备列表find_device()依据model_id()匹配MF/DS 配对后的统一设备集合无 model_id 时退回id()匹配CameraInfo::formats_impl()使用device.into_formats()拿到统一格式列表并读取pixel_format()的Debug文本作为格式名start_capturing_impl()把format.native()即VideoFormatInner透传给统一入口并将Frame包装成NativeCapturedFrame供上层如 crates/recording/src/output_pipeline/win.rs 的录制输出管线消费ModelID::from_windows()把model_id()形如VID_xxxxPID_xxxx拆成vid/pid两部分用于设备持久化记忆与重连。这套分层cap-camera-windows统一 API →cap-camera-mediafoundation/cap-camera-directshow后端 →crates/camera平台抽象 → 录制管线让 Cap 在 Windows 上能以“一个VideoDeviceInfo、一套回调”同时覆盖现代摄像头、旧驱动设备、虚拟摄像头与采集卡。小结cap-camera-windows通过四个关键设计解决了 Windows 摄像头采集的碎片化问题统一枚举get_devices()合并 MF/DS 两套设备源按名称 model_id 一对一去重智能后端选择MF 优先MF 无格式或采集失败时降级到挂载的 DirectShow 孪生设备统一格式模型PixelFormat归一化、帧率/分辨率统一换算、bottom-up 方向统一判定稳健的格式协商与资源管理FormatPreference评分算法 多级兜底配合 RAII 缓冲区锁与显式shutdown()防止枚举泄漏。对于想要在 Windows 上构建跨设备摄像头采集能力的开发者这套“统一门面 双后端 降级路由”的架构本身就是一个值得参考的样板对于 Cap 的贡献者crates/camera-windows/examples/cli.rs 是快速验证真实摄像头采集的最小入口而enumeration_leak示例则是验证资源稳定性的现成工具。【免费下载链接】CapOpen source Loom alternative. Beautiful, shareable screen recordings.项目地址: https://gitcode.com/GitHub_Trending/cap1/Cap创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考