从 H.264、H.265 到 AV1、VVC，再到已经发布正式规范的 AV2，视频编码正在进入一个多标准长期并存的阶段。新的编码格式通常意味着更高的压缩效率、更强的屏幕内容处理能力、更丰富的分层结构和 HDR 支持，但对实时音视频 SDK 而言，问题远不只是“能不能调用一个新的编码器”。
真正困难的是：如何让新编码进入采集、编码、封装、传输、解码、渲染、录像和转发的完整链路，同时不破坏已有的低延迟能力、跨平台一致性和协议兼容性。
从大牛直播 SDK（SmartMediaKit）的角度看，新编解码适配的核心，不是追逐某个 Codec 名称，而是建立一种能够持续吸收新标准的媒体架构。
一、新编码适配，不等于增加一个解码器
很多系统对“支持新编码”的理解，停留在接入 libaom、dav1d、VVdeC，或者调用 MediaCodec、VideoToolbox 成功输出 YUV。严格来说，这只完成了最底层的一部分。
一个新编码从实验室进入产品，至少要跨过三个层次：
第一层是“能够解码”。输入一段标准码流，可以正确输出图像。这主要验证解码库、硬件单元和基本码流参数。
第二层是“能够进入业务链路”。码流能够通过 RTSP、RTMP、SRT、WebRTC、HTTP-FLV 或文件封装进行传输，能够正确处理时间戳、参数集、关键帧、分片、聚合、重排序和动态分辨率变化。
第三层才是“能够产品化”。它要求首屏足够快、延迟可控、弱网下能够恢复、软硬解可以切换、设备兼容性可管理、异常能够定位，而且不能因为增加 AV1 或 VVC，破坏原有 H.264/H.265 的成熟链路。
因此，新编码适配并不是：
Codec ID → Decoder → YUV
而应该是：
码流语义 → 标准化媒体帧 → 协议映射 → 能力协商 → 编解码后端 → 内存与渲染 → 实时控制 → 质量观测
这一区别，决定了 SDK 是“增加了一个格式”，还是具备了真正的编解码演进能力。
二、先抽象码流语义，而不是抽象几个函数
H.264、H.265、VVC 都建立在 NAL Unit 体系上，但 NAL Unit 类型、参数集结构、随机接入方式、分层信息和参考关系并不相同。AV1 则采用 OBU、Temporal Unit、Frame Unit 等结构，不能简单套入传统的 SPS/PPS 加 NALU 模型。
如果 SDK 内部把视频帧定义成“指针、长度、是否关键帧”三个字段，新编码接入后很快就会遇到问题。一个面向未来的统一压缩帧模型，至少应当表达：
- Codec、Profile、Level、Tier；
- 编码配置及配置版本；
- Access Unit 边界；
- DTS、PTS、Duration 和时钟基准；
- 解码顺序与显示顺序；
- 随机接入类型，而不只是一个
is_key_frame； - Temporal ID、Spatial ID 和可丢弃属性；
- 位深、色度格式、色彩空间和 HDR 元数据；
- 分辨率变化、参数集变化及流重置事件；
- 原始码流格式与规范化码流格式。
其中最容易被低估的是“随机接入语义”。传统系统经常把 IDR、CRA、Recovery Point、AV1 Key Frame 和 Switch Frame 全部压缩成一个布尔值。短期看实现简单，长期却会直接影响首屏、丢包恢复、切流、录像切片和协议网关。
正确的方向不是强迫所有编码遵循 H.264，而是在 SmartMediaKit 内部建立与具体编码相对独立的 RandomAccessType、DependencyInfo 和 CodecConfig。只有内部媒体对象足够准确，外部协议和平台差异才不会不断侵入播放、推流与录像模块。
三、把“编解码能力”从布尔值升级为能力空间
在跨平台 SDK 中，判断某台设备是否“支持 AV1”没有太大意义。真正需要回答的是：
它是否能够以硬件方式、在当前分辨率、帧率、Profile、位深和低延迟要求下稳定处理这一路 AV1？
Android 的 MediaCodec 不仅可以枚举编码器和解码器，还提供分辨率、帧率与性能点等能力查询；Apple VideoToolbox 也提供硬件解码能力检测接口。
因此，SmartMediaKit 的能力描述不应只是：
support_av1 = true
而应该接近一个多维能力集合：
Codec + Profile + Level + BitDepth + Chroma
+ Resolution + FrameRate + Bitrate
+ Encode/Decode + Hardware/Software
+ Surface/Buffer Output
+ LowLatency + DynamicReconfigure
+ MaximumConcurrentInstances
能力查询之后还应进行轻量级运行时验证。移动端硬件编解码器具有明显的芯片、系统版本和厂商差异：系统声明支持，不代表特定 Profile 能初始化；能够初始化，不代表 4K 60fps 可以实时运行；单路正常，也不代表多路不会触发资源不足、降频或硬件实例抢占。
所以产品级策略应当是“能力查询 + 创建试探 + 运行监测 + 动态降级”，而不是静态设备名单。软件解码也不应该只是编译时备用项，而应成为可以受策略控制的后端：硬解初始化失败、输出异常或运行性能不足时，SDK 可以在明确边界内切换软解，而不是让业务层重新创建整条播放链路。
四、新编码最大的挑战，往往不在 Codec，而在内存和渲染
新一代编码通常伴随 10bit、HDR、BT.2020、P010、多平面纹理和更复杂的显示元数据。如果仍然采用“硬件解码—复制到 CPU—转换成 I420—再上传 GPU”的处理方式，即使编码节省了带宽，也可能把收益全部消耗在内存复制、格式转换和 GPU 上传上。
对 SmartMediaKit 这类重视低延迟的 SDK，编解码适配必须同时设计两条输出路径：
- Surface、IOSurface、D3D Texture 等零拷贝或少拷贝渲染路径；
- YUV、RGB 等可供业务处理的内存回调路径。
两条路径不能互相替代。实时预览更适合直接渲染，算法分析、图像处理、截图和第三方合成则可能需要原始数据。底层需要统一管理图像的所有权、生命周期、同步栅栏、色彩信息和线程边界，而不能默认所有解码结果都是 8bit I420。
还要避免在内部过早“降维”。如果解码器输出的是 P010 和 BT.2020，SDK 在中间层立即转成 8bit NV12，即使画面能够显示，也已经丢失了新编码带来的高动态范围价值。新编码适配必须与色彩管线同步升级，而不是只升级压缩模块。
五、协议适配必须和编解码适配分离
编码标准规定如何压缩图像，却不负责解决这段码流如何进入 RTSP、RTMP、WebRTC 或 SRT。每增加一个 Codec，都可能对应多套完全不同的承载方式。
以当前标准体系为例，HEVC、VVC 和 EVC 已分别具有 RTP Payload 标准；VVC 的 RTP 负载格式由 RFC 9328 定义，可以承载单个 NAL Unit、聚合包和分片包。
Enhanced RTMP 则通过扩展 FLV/RTMP 视频消息支持 HEVC、AV1、VP9、HDR 元数据等，同时尽量保持对传统 RTMP 体系的兼容。
这说明 SDK 不能把协议封装逻辑写进编码器或解码器。更合理的结构是：
| 层次 | 主要职责 |
|---|---|
| Codec Parser | 识别帧边界、参数集、随机接入点和依赖关系 |
| Bitstream Adapter | Annex B、Length-Prefixed、OBU 等格式转换 |
| Codec Backend | 软件及各平台硬件编解码 |
| Packetizer | RTP、RTMP、MPEG-TS 等协议封装 |
| Depacketizer | 分片重组、乱序恢复、参数还原 |
| Negotiation | SDP、Codec String、Profile 与能力协商 |
| Policy Engine | 编码选择、软硬切换、转码或透传决策 |
这样，同一个 HEVC Access Unit 可以按需进入 RTSP/RTP、Enhanced RTMP、SRT/MPEG-TS 或录像模块，而不需要在各协议中重复解析 VPS、SPS、PPS。
尤其需要明确：SRT 解决的是可靠传输，并不会自动让 MPEG-TS 支持任意编码；WHIP/WHEP 解决的是 WebRTC 的 HTTP 信令，也不会自动突破浏览器和 WebRTC 栈的 Codec 能力；QUIC/WebTransport 改变的是传输方式，同样不会替代码流封装、能力协商与播放端解码能力。
六、压缩效率越高，实时控制反而越重要
新编码可以在相近画质下降低码率，但更强的帧间预测和参考关系也意味着：一个关键数据包丢失后，错误可能传播到更多后续帧。因此，离线测试中的压缩效率，不能直接等同于实时链路中的体验提升。
实时编码适配需要重点控制：
- 是否启用 B 帧和帧重排序；
- Lookahead 深度；
- GOP 长度和随机接入周期；
- Tile、Slice、Subpicture 或分层结构；
- 编码器内部缓存；
- Intra Refresh、长期参考帧与关键帧请求；
- Temporal Layer 和 Spatial Layer 的丢弃策略；
- 码率变化的响应速度；
- 编码复杂度与设备温度、功耗之间的平衡。
对于直播和远程交互，编码器不应只暴露 bitrate、fps 和 gop 三个参数，而要向上提供统一的实时控制接口。网络层输出的带宽估计、RTT、丢包、重传、抖动和队列积压，需要被转换成编码器能够理解的动作：降低目标码率、调整帧率、丢弃增强层、缩短预测链或触发状态刷新。
RFC 9627 定义的 Layer Refresh Request，以及 RFC 9626 定义的 Video Frame Marking，也反映了一个趋势：网络节点和接收端需要理解帧或层的重要性，而不能再把所有视频包视为等价数据。
因此，SmartMediaKit 的优势不应只是“支持多少种编码”，而应当是把弱网反馈、编码控制、解码恢复和播放缓冲纳入同一个闭环。
七、不要追求所有链路同时转码，应优先建设压缩域能力
在多协议系统中，一个常见误区是：遇到协议或编码不一致就解码再编码。这样虽然容易打通链路，却会引入额外延迟、算力消耗、画质损失和授权成本。
更合理的处理优先级应当是：
- 同编码、同参数体系：直接压缩码流透传；
- 同编码、不同封装：只做 Bitstream Conversion；
- 同编码、不同协议：重新分包和时间戳映射；
- 接收端能力不足：选择兼容编码或多路输出；
- 只有在必须改变编码、分辨率或画面内容时才转码。
这也是 SmartMediaKit 现有 RTSP、RTMP、SRT、WHIP/WHEP、HTTP-FLV、录像和轻量级服务能够进一步形成协同价值的关键。真正有技术含量的多协议网关，不是“每条流都转码”，而是在理解编码语义的基础上，尽可能保持压缩域传递，只在必要节点进行转码。
八、用可验证的工程体系替代“播放器能出画面”
新编码的测试不能以“播放正常”作为完成标准。至少需要建立四类测试：
- 标准符合性：官方测试码流、边界 Profile、异常参数集、分辨率和位深组合；
- 网络扰动：丢包、乱序、延迟突增、突发抖动、长时间无关键帧；
- 生命周期：启动、Flush、Seek、切流、动态改分辨率、软硬解切换；
- 性能稳定性：多路并发、内存峰值、GPU 占用、温升、降频和长时间运行。
真正需要观测的指标包括首帧时间、解码排队深度、帧重排序深度、端到端延迟、丢帧原因、关键帧等待时间、错误恢复时间、内存复制次数、音视频漂移以及硬件编解码失败码。
对于 AV1、VVC 乃至 AV2，还应保存“原始码流片段 + 能力快照 + 解码器实现信息 + 状态迁移记录”。否则，同一个异常在某款手机上出现时，很容易被笼统归结为“硬解兼容性”，却无法进一步定位。
九、SmartMediaKit 应当如何看待 AV1、VVC 与 AV2
截至 2026 年，AV1 已经形成从码流规范、容器绑定到 RTP 承载的较完整体系；VVC 已有正式的 ITU-T H.266 标准和 RTP Payload RFC；AV2 1.0 规范则于 2026 年正式发布，并引入了更强的分层、多流、多视角和屏幕内容能力。
但三者所处的产业阶段不同，适配节奏也不应相同。
对 SmartMediaKit 来说，H.264/H.265 仍然是安防、工业视觉、移动布控、教育和传统直播中最重要的现实基础，不能为了追逐新标准而牺牲已有链路的低延迟和兼容性。AV1 更适合优先建设解码、透传、录像和协议承载能力，再根据平台硬件成熟度逐步开放实时编码。VVC 可以结合超高清、专用终端和行业客户需求推进，不必一开始追求所有消费设备覆盖。AV2 当前更适合进入技术验证和架构预留阶段，而不是急于做宽泛的商业承诺。
音频也应采用类似思路：AAC、PCMA、PCMU、Opus 并不是简单的新旧替代关系。实时交互、直播分发、GB28181 和传统设备接入需要不同的音频能力组合。视频编码升级不应牵动已经稳定的音频、同步和协议模块。
结语：新编码时代，真正需要适配的是架构
编码标准一定会继续变化。AV1 不会终结 H.265，VVC 不会立即替代 H.264，AV2 也不会让现有协议一夜之间失效。未来很长一段时间，实时音视频系统面对的都将是多编码、多协议、多硬件能力和多业务目标共存的局面。
对大牛直播 SDK（SmartMediaKit）而言，真正的技术护城河不是在产品列表上更快增加一个 Codec 名称，而是做到：
- 新编码接入不需要重写播放、推流和录像链路；
- 新协议接入不需要重新实现编解码逻辑；
- 软硬编解码可以基于运行状态动态选择；
- 压缩码流能够在不同协议之间低成本透传；
- 低延迟、弱网恢复和跨平台一致性不会因编码升级而丢失。
最好的编解码架构，不是只为 AV1、VVC 或 AV2 设计，而是当下一个编码标准出现时，系统需要新增的只是一个解析器、一个后端和若干协议映射，而不是再次重构整个媒体内核。
这才是新一代编解码适配真正应该达到的高度。
