谈到音视频编解码的发展，人们很容易想到一条不断向前延伸的技术路线：从 H.264 到 H.265、H.266，从 AV1 到 AV2，再到神经网络参与甚至主导的压缩系统。新一代技术不断出现，讨论也往往围绕同一个问题展开：在相近画质下，究竟还能节省多少码率？
这个问题很重要，但对于真正交付音视频产品的人来说，它还不够。
一条视频流不仅要被压缩，还要经过采集、传输、解码、显示，可能同时进入录像、转发和智能分析链路。客户最终关心的，也不仅是文件有没有变小，而是画面能不能及时显示，网络波动后能不能恢复，设备能不能持续运行，以及关键细节有没有被保留下来。
大牛直播 SDK（SmartMediaKit）的产品范围覆盖采集RTMP/WHIP推流、RTSP/RTMP/HTTP-FLV/WHEP播放、轻量级 RTSP 服务、转发与录像等环节。这样的产品视角，决定了我们不能只从一个编码器的测试成绩判断技术价值，而要看它进入完整媒体链路后，能否形成可持续、可交付的收益。
在我们看来，下一轮音视频编解码竞争，不会停止于压缩效率，而会进一步走向压缩效率、实时性、计算成本、终端适配与信息有效性的联合优化。
这不是降低对先进编码技术的期待，而是对它提出更高的要求：不仅要压得更小，还要让这些收益在真实系统中兑现。
一、码效率的价值，必须放回真实约束中衡量
评价一种编码技术，最容易犯的错误，是把标准潜力、编码器实现能力和项目实际收益混为一谈。
同一种编码格式，也可以拥有差异很大的编码实现与运行配置。以 VVC 为例，Fraunhofer 的 VVenC 提供多个速度与质量预设，并具备不同的并行、码率控制和感知优化能力。这说明"使用了同一种标准"，并不意味着获得了同样的压缩效率，更不意味着付出了同样的计算成本。
因此，讨论"新编码比旧编码节省多少码率"，至少要说明内容类型、编码器版本、运行配置、质量评价方式，以及计算和时延限制。脱离这些条件，一个看起来漂亮的百分比，很难直接转化为产品选型依据。
对于离线内容，可以允许编码器进行较充分的分析与搜索；对于实时推流，编码器必须在持续到来的帧面前按时完成工作。我们真正应该比较的，不是两个名称不同的格式，也不是两个看起来相同的 preset，而是：在相近的画质目标、相近的端到端时延和相近的设备预算下，谁能交付更好的结果。
值得注意的是，标准研究本身也在强化这种约束。2026 年公布的面向超越 VVC 能力的联合技术提案征集，明确把编解码实现成本作为重要评价因素，并从一开始纳入运行时间受限的编码测试，同时考察低延迟与随机访问条件。传统信号处理与神经网络技术都在征集范围内。
这释放出的信号，比某个孤立的压缩率数字更值得关注：下一代编码技术不能只证明自己"在充分计算之后更有效"，还需要证明自己"在有限时间内依然有效"。
从工程角度看，未来值得投入的方向，既包括新的压缩工具，也包括更聪明的工具选择、更有效的搜索剪枝、更好的并行调度和码率分配。能够在目标设备上稳定兑现的压缩收益，才是可以写进产品能力的收益。
二、未来不是单一编码制胜，而是多技术路线长期并存
讨论编解码演进，不宜把行业想象成一场整齐划一的升级：新标准发布，旧标准退场，所有摄像头、服务器、浏览器和移动终端同步完成替换。
实际的产品规划，更适合建立在多编码长期共存的前提上。
AV2 就是一个值得观察的例子。AOMedia 已于 2026 年 6 月发布 AV2 正式规范；到 2026 年 9 月，官方披露的生态进展仍包括早期实现、开发工具与互操作工作。标准已经发布与大规模终端已经普遍可用，是两个不同的阶段。
AOMedia 在面向实现者的说明中，也明确预期 AV1 与 AV2 将长期共存：软件实现通常先行，更广泛的硬件支持随后逐步形成。新标准的出现，并不意味着上一代技术已经失去部署价值。
对于 SmartMediaKit 这样的跨平台 SDK，我们更倾向于按场景组织编码能力，而不是按发布时间给编码格式排座次。面对无法控制的存量设备，应优先保证互通；面对能够统一升级的封闭系统，可以更积极地评估新编码；面对功耗敏感的移动端，应以持续运行表现决定是否启用；面对带宽昂贵、观看终端可控的业务，则可以提高压缩效率在决策中的权重。
这里还有一个经常被忽略的问题："支持某编码"不是一个简单的开关。
能够识别码流，能够原样转发，能够写入文件，能够软件解码，能够硬件解码，以及能够在目标设备上稳定实时播放，是不同层次的能力。新标准进入 SDK 时，这些能力应分别验证、分别披露，而不宜用一个格式名称概括所有环节。
未来更成熟的媒体系统，不应只有"统一使用最新编码"这一种策略，而应能够根据终端、网络、内容与业务目标，选择合适的编码路径，并保留清晰的降级方式。
三、实时视频的核心指标，正在从清晰度转向时效性
在实时系统里，一帧画面的价值，不只取决于它有多清晰，还取决于它什么时候到达。
远程操控场景中，一张极其清晰、却已经明显过时的画面，可能不如一张清晰度略低但足够及时的画面有用。因此，实时编码必须关注时间依赖，而不能只关注空间压缩。
编码器的前向分析、未来帧引用和缓冲配置，都可能影响等待时间。NVIDIA 的编码器文档也明确区分不同的低延迟调优方式，并说明 lookahead 会通过缓冲后续帧进行分析。这些机制可以改善编码决策，但不能被当作没有时间成本的优化。
举一个纯粹的时序例子：对于每秒 30 帧的视频，若某项策略必须等待后续 3 帧，单是等待这些帧就大约需要 100 毫秒，尚未计算网络、解码和显示时间。这个数字不是某一种编码格式的固有延迟，而是说明：编码结构中的等待，最终会进入业务的响应时间。
同时，也不能把低延迟问题简化为"有 B 帧就一定高延迟"。真正需要检查的是参考关系和显示重排。部分实现支持只引用过去画面的单向 B 帧，并不需要像传统双向预测结构那样等待未来参考画面。
除了稳定播放时的时延，还必须考虑加入与恢复。长 GOP 本身不等于持续高延迟，但在缺少其他恢复机制时，新用户加入、参考帧损坏或解码器重建，可能需要等待合适的恢复位置。VVC 中的渐进解码刷新（GDR）则提供了不同于传统瞬时随机访问画面的恢复方式，不过"渐进恢复"不能被理解成任意时刻都能立即得到完整、干净的画面。
因此，我们认为实时编码的演进方向，应当是把码率控制、关键帧策略、发送节奏、拥塞反馈与恢复机制放在一起设计。网络容量下降时，编码器与发送端需要共同控制队列；需要恢复时，也不能无限制地堆积大关键帧。实时媒体拥塞控制的基本约束，正是避免排队造成持续延迟，并让数据在仍然有用的时间窗口内到达。
对应到测试方法，也不应只测平均延迟。我们建议同时关注首帧时间、网络突变后的恢复时间，以及最慢一小部分帧的延迟分布。平均表现优秀，却偶尔积累数秒缓冲的系统，不应被轻易定义为优秀的实时系统。
四、决定编解码体验的，不只是算法，还有整条数据链路
讨论编解码复杂度，人们习惯看 CPU 占用、编码帧率或者解码帧率。但在终端产品中，数据如何流动，同样值得关注。
例如，画面从解码器输出后，是直接交给显示系统，还是先回读到 CPU，再做颜色转换，最后重新上传 GPU？在 Android 上，MediaCodec 提供面向 Surface 的输入输出路径，输出端的消费方式、缓冲处理和背压，也会影响媒体管线的行为。仅仅知道"启用了硬件解码"，并不足以描述整条链路。
从架构设计上看，减少不必要的内存复制、颜色转换和 CPU---GPU 往返，是应该与更换编码器同时评估的优化方向。所谓零拷贝，也应理解为尽量避免不必要的数据搬运，而不是认为系统中完全不存在缓冲、同步与等待。
能力判断也需要更细。W3C 的 Media Capabilities 将"支持""流畅""能效"分别表达，并特别提醒：不能简单地把硬件加速等同于更高能效，某些低分辨率场景的软件处理也可能具有相近的效率。
这对跨平台 SDK 的启示是，编码能力表不应只记录 H.264、H.265、AV1 等名称，还应进一步关联分辨率、帧率、位深、色度格式、输入输出资源类型，以及运行时表现。
对于移动终端和边缘设备，我们建议把持续运行纳入选型，而不是只做短时跑分。同一个设备还可能同时承担摄像头采集、画面显示、AI 推理和通信任务。单独运行编解码时达到实时，不代表整套应用运行后仍有足够余量。
未来有竞争力的实现，应当在"压缩得更好"之外，回答"整台设备能否长期承受"。
五、AI 正在重构编码器，但不同技术路线不能混为一谈
谈到 AI 编解码，最需要避免的，是把所有使用神经网络的功能，都归入同一种技术路线。
第一种变化，是 AI 改善传统编码器的决策。
例如，让模型辅助判断哪些区域值得投入更多码率，哪些候选模式可以提前排除，或者如何在有限计算预算下安排编码搜索。只要最终输出仍然符合既有比特流规范，这类编码端优化就不必要求所有接收设备同步更换解码器。
第二种变化，是 AI 参与画面处理或重建。
编码前的降噪、编码后的增强，与进入编解码规范内部的神经网络工具，需要区别对待。前者可以作为媒体处理管线中的独立环节；后者一旦改变了解码所需的语法、模型或处理过程，就不能默认旧解码器仍然具备兼容能力。
第三种变化，才是 以学习式表示为核心的神经视频压缩。
这一方向已经在认真解决工程运行成本，而不仅是展示率失真曲线。微软公开的 DCVC-UF 工作，将重点放在多帧分块处理、并行重建，以及减少熵编码相关交互开销等方面，说明神经视频压缩研究正在更深入地面对实际执行效率。
但这里仍然需要保持一个清醒判断：吞吐量提高，不自动等于端到端延迟下降。如果一种实现通过等待更多帧、扩大批量来提高整体处理效率，就还需要单独考察单帧从采集到显示的等待时间。用于离线处理、高吞吐转码和实时交互的最佳配置，未必相同。
对于 SDK，我们认为另一项必须提前考虑的工作，是将模型版本、运行精度与实现兼容性纳入接口和发布管理。未来的媒体能力，可能不再只由一个 codec ID 描述，还需要明确对应的模型与执行条件。
更重要的是，AI 重建提出了一个业务层面的边界：看起来更自然，不代表更忠实地保留了原始细节。 感知自然度与逐像素失真并不是完全相同的优化目标，相关研究已经系统讨论了二者之间的权衡。
因此，对于安防、工业检测和需要回溯原始信息的业务，我们建议明确区分原始记录与增强展示。一个被增强得更悦目的画面，不应未经验证就承担精确识字、细微缺陷判断或者原始细节核对的职责。这不是否定神经编码，而是要求它具有与业务相匹配的真实性边界。
六、当视频开始服务机器，传统画质评价体系也要改变
当视频同时进入播放器和 AI 分析系统时，一个问题会越来越突出：人眼认为重要的信息，与机器任务需要的信息，未必完全一致。
设想一段工业检测视频。对普通观看者来说，整体画面平滑、噪声较少，可能意味着更好的观感；但对于检测细小划痕的模型，某一处弱纹理可能正是需要保留的目标。仅凭整体画质提升，不能推导出任务识别能力也同步提升。
这已经不只是应用层面的讨论。MPEG 的视频编码工作范围覆盖面向人类视觉与智能机器消费的表示，并分别推进 Video Coding for Machines（面向机器的视频编码）和 Feature Coding for Machines（面向机器的特征编码）相关工作。
两条路线需要区分。前者仍然围绕视频信息如何为机器任务服务，后者则进一步涉及特征表示的传输与压缩。对于产品规划，不能简单地把它们理解成"视频以后都不需要了，只传 AI 特征即可"。
我们更倾向于采用按用途组织媒体数据的方式：观看端获得适合显示的内容，分析端获得经过任务验证的数据，录像端保留与回溯要求相匹配的信息。这里不必机械地理解成永远编码三路视频，而应首先考虑共享采集、统一时间戳、复用可用数据，再决定是否需要独立的编码或预处理分支。
特征传输可以成为优化选项，但也需要考虑模型升级、任务变化以及历史数据能否重新分析。今天适用于某个模型的特征，不应未经验证就被当作长期通用的数据资产。
从 SmartMediaKit 的维度看，面向 AI 的演进不应只是增加一个 YUV 或 RGB 回调。更值得完善的是时间戳、采样节奏、图像资源类型、数据生命周期与任务背压，让媒体链路与分析链路能够协同，而不是互相拖慢。
七、音音频技术的下一步，是更低延迟与更强空间表达
讨论音视频技术时，音频经常被压缩成一句话：AAC 用于直播，Opus 用于实时通信。这样的归纳过于简单。
对于交互业务，我们认为音频首先应该回答三个问题：能否听清、能否连续、能否及时。音色是否悦耳当然重要，但如果指令中的关键音节被丢失，或者对话节奏被长缓冲打断，再好的频谱指标也难以弥补。
Opus 的演进提供了一个很有启发性的例子。2025 年 12 月发布的 Opus 1.6，在保持 RFC 6716 基础兼容性的同时，引入实验性的机器学习语音带宽扩展，并改进深度冗余相关能力。这表明，音频可以通过渐进式增强获得收益，而不一定每次都依赖一种全新的基础格式。
但基础兼容不等于所有增强能力都自动兼容。官方说明明确指出，Opus 1.5 与 1.6 的 DRED 模型版本之间存在差异，版本不匹配时，相应冗余信息不能被对端利用。更值得注意的是，1.6 的一项优化重点是提高语音可懂度，而非单纯提高主观悦耳程度。
这对实时产品很有启发：音频质量不应该只有一个评分维度。我们建议把清晰度、可懂度、对话时延和丢包后的连续性分别评估，并在风噪、混响、多人说话等目标业务条件下验证。
从系统设计角度看，缩短音频帧长，可以减少等待完整音频帧的时间，但在每帧独立发送等条件下，也会提高包头和调度开销的占比；依靠后续数据进行恢复的策略，则需要相应的时间窗口。因此，音频同样需要在压缩、传输与播放缓冲之间做整体取舍，而不是单独追求最低编码码率。
另一条发展方向，是声音的空间表达。2026 年 7 月，AOMedia 发布 Open Audio Renderer v1，并明确区分 IAMF 的表示与封装职责，以及渲染器面向扬声器、耳机等播放环境的处理职责。
这意味着，音频演进也在从"把波形压得更小"，扩展到"如何描述并还原一个声音场景"。对于远程协作与空间交互，未来需要关注的不只是解码器，还有声场描述、终端渲染与交互过程中的一致性。
八、从二维视频到多维媒体，编码对象正在发生变化
视频的演进也不应只被理解成二维画面压缩率的持续提高。
AV2 正式规范的相关说明中，已经把多流、多视图，以及纹理与深度、带透明度的前景与背景组合，作为值得关注的能力。这类设计关注的不只是单一路画面，而是多种有关联的视频信息如何被组织和同步。
从应用角度看，这为多摄像头协作、空间视频和复合画面提供了新的设计空间。未来的接收端可能不总是需要相同的信息：有的设备只需要基础显示，有的需要更高质量，有的还需要深度或其他辅助数据。
不过，可分层或多流表达，不应被理解为服务器可以随意删除任意部分而不影响解码。层间依赖、接收端能力与协商方式，仍然决定了哪些信息可以独立消费。即使在 WHIP 的相关规范中，使用可伸缩编码也需要考虑协商后的编码格式、用途与可用解码器，而不是自动获得普遍适用的分层转发能力。
我们认为，这一方向对 SDK 的长远影响，是媒体接口需要逐步具备表达关联关系的能力：哪些数据属于同一时刻，哪些属于同一视图，哪些是独立可解码内容，哪些依赖其他层或其他组件。
未来媒体系统需要管理的，可能不再只是"一条视频轨道加一条音频轨道"，还包括不同信息之间的同步、依赖和消费方式。
九、面向下一代编解码，真正需要的是可持续演进的架构
上述趋势最终都要落到产品架构上。以下是我们认为值得推进的方向，而不是将 VVC、AV2 或神经编解码描述为 SmartMediaKit 已经发布的能力。
首先，应当进一步分离编码格式、传输协议与业务控制。
一种视频格式能够封装进某种传输方式，并不代表接收端已经具备解码能力。例如，VVC 已有对应的 RTP 负载格式规范，但 RTP 封包定义解决的是传输映射问题，不会自动为终端增加 VVC 解码器。
因此，协议适配、码流处理、编解码后端与显示输出，应当保持清晰边界。这样，新编码接入时，才有可能复用已经稳定的连接管理、时间戳处理、录像管理和设备生命周期，而不是每增加一种格式，都重新搭建一套媒体系统。
其次，应当把"不必要的转码"视为需要避免的成本。
在目标容器与接收端允许的前提下，压缩码流可以不经解码和重新编码而直接复制、重新封装；这种路径与完整转码是不同的处理方式。
由此出发，我们建议优先保留已经满足目标需求的视频码流，只对确实不兼容的部分进行处理。例如，视频已经兼容而音频不兼容时，应评估仅转换音频，而不是默认整路媒体全部解码重编码。新编码往往意味着新的计算预算，更应该把转码放在必要的位置。
再次，应当将兼容性从"能否打开"扩展到"能否稳定运行与恢复"。
我们建议把参数变化、分辨率切换、时间戳连续性、解码器重建、随机访问位置，以及录像文件能否独立回放，纳入同一套验证流程。媒体流不是永远不变的文件，真实业务中对变化的处理能力，往往比一次成功播放更能反映工程成熟度。
最后，应当让编码策略具有可观测性和可回退性。
新编码上线后，需要知道收益发生在哪里：是降低了实际网络流量，改善了可用画质，还是增加了设备功耗和异常恢复时间？测试也不应只统计视频基本码流大小，而应明确是否包含音频、封装、重传与冗余开销，并保持比较口径一致。
对于 SmartMediaKit，我们认为有价值的投入，不只是再增加几个编码格式名称，而是形成一套可以反复使用的方法：识别终端能力，选择合适实现，管理媒体数据，验证完整链路，并在条件不满足时可靠回退，具备把先进编码技术转化为可用产品能力的本领。
结语：真正的进步，是让有限资源承载更多有效信息
音视频编解码仍然有广阔的发展空间。更高效的传统工具、学习式压缩、智能编码决策、机器视觉导向的表示，以及空间音视频，都在打开新的可能性。但它们不应被简化成一场"新格式淘汰旧格式"的竞赛。
对于实际业务，更重要的问题是：在给定带宽、计算能力、能耗和响应时间内，系统能否保住最有价值的信息，并把它可靠地交给需要它的人或机器。
从大牛直播 SDK（SmartMediaKit）的视角看，下一阶段的技术判断，应当同时守住两件事：一方面，积极跟进新编码带来的效率和表达能力；另一方面，坚持用完整链路验证这些能力，而不是把标准潜力直接当作产品承诺。
未来值得期待的编解码，不只是让同一段音视频占用更少字节，而是让有限资源，在合适的时间，传递更多真正有用、可信且可消费的信息。
📎 CSDN官方博客：音视频牛哥-CSDN博客