5.1 视频采集与渲染管线

5.1 视频采集与渲染管线

视频引擎的第一段路：一帧画面从摄像头到编码器入口之间被怎样对待。本节的核心是一个反直觉的设计——画面尺寸不是采集端说了算，而是下游说了算。理解"诉求上传、上游降载"这个机制，很多采集端的怪现象都能一次说通。

诉求上传：尺寸与节奏由消费方决定

采集端最容易产生的误解是"我开多高，上游就给我多高"。实际链路上，每个消费者都可以向自己的上游声明诉求：我最多能处理多大的画面、期望多少帧率、是否需要特定的像素格式。适配器站在采集与消费者之间，按收到的最苛刻诉求对帧做降载——缩小分辨率按整数倍裁剪，帧率按比例丢弃。上游多给的部分在进入消费者之前就被拦下，机器的算力与内存带宽因此不会浪费在"编了也没人要"的帧上。

这个设计在多消费者场景下威力尽显：同一份采集源可以同时喂本地预览、编码上行、录制三条通路，各自声明诉求，适配器按最严格的一条统一降载。代价是所有消费者被最弱一环绑架——预览窗口小不是问题，但如果某个消费者声明了一个过小的诉求，整条链的画质都会被拉低。排查"画面莫名变小"时，第一个要问的问题就是：链上所有消费者的诉求分别是多少，谁在要求最小。

旋转处理也值得交代一句。移动设备横竖屏切换时，设备给出的帧方向随之变化，引擎不在采集层硬转像素——那要付出整帧拷贝的代价——而是给帧打上旋转标记一路传递，在最终呈现或编码必需时才做一次变换。应用层自己拿到帧做二次处理时，如果忽略旋转标记，就会出现"对方看画面转了九十度"的经典事故：数据没错，是元信息被丢了。

降载的两种触发：要得少与扛不住

适配器的降载由两类信号驱动。第一类是下游诉求，上一段已讲。第二类是机器负载：引擎持续测量编码一帧的耗时占帧间隔的比例，占比持续偏高说明编码跟不上节奏，继续硬编只会积压——此时引擎按预设的降档序列主动降低对上游的要求，分辨率一档一档往下走，直到负载回到安全区。两类信号在适配器处汇合，帧在进入消费者前完成裁剪。

值得一提的是降档的恢复是不对称的：降档果断，升档谨慎。负载超限的代价是即时可见的卡顿，而升档过快会导致反复震荡——刚升上去又超载，再降下来，画面尺寸来回跳。引擎用持续观察窗口与冷却时间抑制震荡，宁可晚几秒恢复高清，也不让用户看"呼吸式"画面。这个不对称原则与第七章拥塞控制的升降不对称一脉相承，是整个实时系统的通识。

自定义采集与自定义渲染的接入要点

替换采集源或渲染出口是业务定制的高频需求——相机增强、多路合成、特殊窗口捕获都走这条路。接入点在管线的两端，引擎对此有明确的接口约定：自定义采集实现"请求产出"的生产者接口，把帧连同元信息推进管线；自定义渲染实现消费者接口，按帧的呈现建议上屏。两头的接入各有几条铁律。采集侧：帧的时间戳必须如实携带采集时刻，它是后续所有时刻估计的锚点，伪造时间戳会让 jitter 计算与同步全部失真。渲染侧：不要在渲染回调里做帧的深拷贝或重计算，回调在渲染节拍上，重了就掉帧。

多消费者诉求合并的策略也值得交代。当同一条采集源要同时供预览、编码、分析三类消费者时，诉求合并规则是"最苛刻者胜"，但这未必是业务想要的——分析通道往往需要原始分辨率，而编码只能承受低档。此时正确设计不是改合并规则，而是把高诉求消费者挂到独立分支：引擎允许在管线中途"分叉"，各分支独立降载。理解了这一点，"接了分析模块后预览变糊"这类问题就有了标准解法：分析挪去独立分支，别让它绑架主链。

帧元信息的完整性清单

本节反复强调元信息（旋转标记、时间戳、格式声明）与像素本体同等重要，这里把它们收成一份完整性清单，自定义采集接入时逐项核对：时间戳为采集时刻、单位与时钟域符合接口约定；旋转标记如实反映设备方向，不做"顺手转正"的预旋转；像素格式与声明一致，特别是行对齐与色彩范围的常见偏差；帧的存放是"借出"语义，回调返回后不再持有。清单上的每一项都有对应的一类经典事故，核对成本分钟级、漏核代价天级。

案例：一次"预览正常、远端模糊"的全链排查

背景。桌面端产品反馈：同一场会议里，本机预览清晰，远端看到自己却模糊；且只在开着屏幕共享的机器上出现，共享一停画面就恢复。

操作。先排除采集本身：在采集回调处抽样记录帧的原始尺寸，确认送进引擎的画面规格正常，问题在下游某处被降载。再沿两个消费者分别取证：本地预览窗口小、诉求小，不是它；编码侧查降载统计，发现编码耗时占比持续逼近上限，负载降档被触发，分辨率已降了两档。继续查负载来源：屏幕共享与摄像头画面并发编码，机器是集成显卡的老机型，两路硬编能力不足，共享那路抢占了编码器，摄像头这路只能靠降档自保。

结果。处置分两步：短期在共享开启时预先降低摄像头的初始档位，避免负载过冲后再震荡降档；中期给老机型配置共享画面单独的降档策略，两路不再互相挤压。上线后投诉消失。

解读。这个案例的排查路径完全顺着"诉求与负载"两条线走：预览正常说明采集与本地通路无恙，远端模糊指向编码侧降载，负载统计直接点名原因。两条线里只要有一条没建证据，排查就会退化成瞎猜——比如直接怀疑对方网络差，方向就完全错了。第五章案例反复强调的证据链，在这里表现为"先分清是哪一侧的哪一个消费者在提出诉求或超载"。

变式。如果反过来——预览也模糊——问题就在采集到适配器之间：或是某个消费者声明了过小诉求，或是采集设备的规格本就低于预期。此时遍历全部消费者的诉求即可定位。另一类高频变式是移动端前后台切换：后台时渲染消费者被系统暂停，若其诉求未及时撤销，整链可能被拉到极低档位，切回前台后要等冷却期结束才恢复，表现为"切回来画面糊一阵"——解法是在生命周期回调里主动同步诉求。

要点回顾

本节要点：画面规格由下游诉求与上游负载共同决定，适配器是执行者；多消费者共享采集源时按最苛刻诉求统一降载，排查变小先查诉求清单；旋转靠元信息传递，丢标记就是转屏事故；降档果断升档谨慎，不对称是为了防震荡。下一节进入编码内部，看带宽与负载这两路信号怎么拧动码率、分辨率、帧率三个旋钮。