实时音视频 rtc 的媒体格式支持列表：开发者和产品经理都应该了解的技术细节

如果你正在开发一款涉及音视频通话的应用，不管是社交产品、在线教育平台，还是企业协作工具，你迟早会遇到一个关键问题：我们的产品到底支持哪些音视频格式？这个问题看似简单，背后却涉及 Codec（编解码器）、容器格式、浏览器兼容性、终端适配等一系列技术细节。今天这篇文章，我想用最接地气的方式，把实时音视频领域的媒体格式支持这件事给大家讲清楚。

在说具体支持列表之前，我想先解释一个很多产品经理容易忽略的点：媒体格式支持不是简单的"支持"或"不支持"的问题，而是一个涉及性能、兼容性、带宽消耗的复杂权衡过程。同样是播放一段视频，用 H.264 和用 VP9 可能带来完全不同的用户体验和成本结构。这也是为什么像声网这样深耕音视频领域多年的技术服务商，会在格式支持上做大量的优化和权衡。

音频格式支持：听个响背后的技术活

先说音频，因为相比视频，音频格式的历史更长，也相对更容易理解。在实时音视频场景下，我们说的音频格式支持主要指的是音频编解码器的支持。

主流音频编码格式

目前业界应用最广泛的音频编码格式是 Opus，这是一个由 IETF（互联网工程任务组）标准化的高性能音频编解码器。Opus 的特点是全能——它同时适合语音和音乐场景，压缩率高，延迟低，所以在大多数实时音视频应用中都是首选。

另一个常见的是 AAC（Advanced Audio Coding），这是 MP3 的升级替代方案，在音乐流媒体和视频点播中用得很多，但在实时通话场景下因为延迟稍高，应用相对少一些。

还有 G.711 和 G.722 这类传统电信编码格式，它们更多用于传统电话系统和一些对兼容性有特殊要求的场景。G.711 是那种"老古董"级别的格式，诞生于上世纪 70 年代，但因为几乎所有电话设备都支持，所以在企业通信领域还有一席之地。

对于语音场景，Speex 和 iLBC 也偶尔会出现，它们在特定场景下有各自的优势。比如 iLBC 的抗丢包能力很强，适合网络条件不太好的环境。

音频编码格式	适用场景	特点
Opus	通用场景（语音+音乐）	高性能、低延迟、标准化
AAC	音乐为主的内容	音质好、压缩率高
G.711	传统电话兼容	兼容性极强、带宽占用大
G.722	宽带语音通话	音质优于 G.711
Speex	语音增强场景	支持噪声抑制
iLBC	弱网语音通话	抗丢包能力强

这里我想特别提一下采样率的问题。很多开发者会忽略这一点，但实际上音频采样率直接影响音质。常见的采样率有 8kHz（电话质量）、16kHz（宽带语音）、32kHz、44.1kHz（CD 质量）和 48kHz（专业音频）。在实时通话场景下，16kHz 到 48kHz 是比较常见的选择范围，具体取决于应用场景对音质的要求。

视频格式支持：清晰度和带宽的相爱相杀

如果说音频格式是一道选择题，视频格式就是一道综合题。视频涉及的参数更多，包括分辨率、帧率、码率、编码格式等等，每一个选择都会影响到最终的用户体验和成本。

视频编码格式的江湖纷争

视频编码器的江湖故事其实很有意思。早年间的 H.264/AVC 几乎是一家独大，因为它在当时展现了最优的压缩效率，而且专利池的授权模式也比较清晰。但随着时间推移，新的挑战者陆续出现。

H.264/AVC 依然是目前支持最广泛的视频编码格式，不管是浏览器、移动端还是桌面应用，对它的支持都非常好。这也是为什么在实时音视频领域，H.264 仍然是很多产品的默认选择。它就像音视频界的"普通话"，虽然不是最先进的，但谁都听得懂。

H.265/HEVC 是 H.264 的接班人，在同等画质下能节省约 50% 的带宽。这对高清视频来说是个巨大的优势。但 HEVC 的问题是专利授权复杂，存在多个专利池收费，这导致很多产品在对它支持上比较谨慎。另外，浏览器的原生支持也不如 H.264 广泛。

VP8 和 VP9 是 Google 推出的开源编码格式，VP9 的压缩效率和 H.265 差不多，而且没有专利费用问题。VP9 在 Chrome、Firefox 等浏览器中支持良好，但在 Safari 上支持有限。如果你面向的是 Web 端用户，这可能是一个需要考虑的因素。

AV1 是由开放媒体联盟（AOMedia）推出的新一代编码标准，Netflix、Amazon 等大厂都在力推。AV1 的压缩效率比 VP9 还要再提升约 30%，而且完全开源免费。但目前 encoding（编码）的计算复杂度很高，对硬件要求严苛，所以在实时场景下的大规模应用还需要时间。

分辨率与帧率的搭配

视频格式不仅仅是编码格式的问题，还涉及分辨率和帧率的支持。在实时音视频场景下，常见的分辨率档位包括 360p（640×360）、480p（640×480 或 854×480）、720p（1280×720）和 1080p（1920×1080），近年来 2K 和 4K 的需求也在增加，但实际应用比例还比较低。

帧率方面，15fps 是很多实时通话应用的最低配置，保证基本流畅；30fps 是最常见的标准，兼顾流畅度和带宽消耗；60fps 则用于对流畅度要求极高的场景，比如游戏直播、运动赛事转播等。需要注意的是，更高的帧率意味着更大的带宽和计算压力，在弱网环境下可能适得其反。

视频编码格式	压缩效率	浏览器支持	专利情况	实时场景适用度
H.264	基准	极佳	有专利池	★★★★★
H.265	高（省 50%）	一般	专利复杂	★★★☆☆
VP8	中等	良好	开源免费	★★★★☆
VP9	高	良好（Safari 除外）	开源免费	★★★★☆
AV1	最高	逐步普及	开源免费	★★☆☆☆

容器格式：容易被忽视的"包装盒"

如果说编码器是食物本身，容器格式就是装食物的盒子。在实时音视频场景下，我们很少直接接触容器格式，因为它通常由 SDK 或底层引擎自动处理。但了解容器的概念有助于理解一些技术问题的根源。

常见的视频容器格式包括 MP4、MKV、FLV、TS、WebM、Ogg 等。在 RTP（实时传输协议）传输中，最常用的是基于这些容器封装的流媒体格式。这里需要区分一下：我们在讨论"格式支持"时，通常指的是传输层的协议支持，而不是文件封装格式。

对于开发者来说，更实际的问题是：我需要在应用中处理哪些格式？答案是：大多数情况下，你只需要关心 SDK 暴露出来的编码器配置接口，容器格式的处理是 SDK 内部的事情。但如果涉及到录制、回放、云端转码等场景，你就需要考虑容器格式的兼容性问题了。

从实际需求出发：如何选择合适的格式

说了这么多技术细节，最后还是要落到实际应用上。作为开发者或产品经理，如何根据业务需求选择合适的音视频格式？

首先要考虑的是目标用户群体的设备分布。如果你的用户主要使用中低端 Android 手机，那么 H.264 是最安全的选择，因为硬件解码器支持最普遍。如果你的用户主要是 iOS 用户，那 H.264 和 H.265 都可以考虑，因为 Apple 的芯片对 HEVC 硬件解码支持很好。

其次要考虑网络环境。如果你的产品主要面向海外用户或网络条件较好的地区，可以考虑 VP9 或 H.265 来节省带宽成本。但如果用户网络环境复杂，可能需要更多关注抗丢包能力和编码效率的平衡。

还要考虑业务场景的特殊需求。比如在线教育场景可能需要更好的音频保真度来听清老师讲课；社交娱乐场景可能需要支持各种美颜和特效，这就要求编码器对后处理友好；游戏语音场景则对延迟极度敏感，需要选择编码延迟低的音频格式。

声网在媒体格式支持上的实践

作为全球领先的实时音视频云服务商，声网在媒体格式支持上有着丰富的积累。声网的实时互动云服务覆盖了全球超过 60% 的泛娱乐 APP，在这样大规模的应用中，格式兼容性已经被锤炼得非常成熟。

针对不同的业务场景，声网提供了灵活的编码器选择。以其秀场直播解决方案为例，支持从流畅到高清的多档画质选择，自动根据网络状况调整编码参数，确保在弱网环境下也能保持相对流畅的观看体验。其 1V1 社交场景更是实现了全球秒接通，最佳耗时小于 600ms，这种极致体验背后是对编码延迟、传输协议的深度优化。

值得一提的是，声网在对新兴编码标准的支持上也走在前列。除了成熟的 H.264 支持，声网也在 VP9、AV1 等新一代编码格式上持续投入研发，以应对未来更高清、更高效的行业需求。这种前瞻性的技术布局，让开发者可以专注于业务创新，而把底层格式兼容的复杂性交给云服务商来解决。

写给开发者的建议

如果你正在为产品选择音视频格式，我的建议是：不要追求最新的技术，而要选择最合适的方案。H.264 在短期内仍然是最稳妥的选择，除非你有充分的理由切换到其他格式。

另外，强烈建议在产品设计阶段就考虑录制和转码的需求。很多团队在产品上线后才意识到不同格式之间的转码会带来额外的服务器成本和延迟。如果早知道这一点，可能在架构设计上就会做出不同的选择。

最后，测试环节不要省。音视频的兼容性问题往往在特定机型、特定网络环境下才会暴露出来。用真机测试，用不同的网络环境测试，这才是发现问题的正确方式。

希望这篇文章能帮助你对实时音视频的媒体格式支持有一个全面的认识。如果还有其他技术问题，欢迎继续交流。