视频编码和解码的互操作性问题，以及解决措施

在专业视频传输领域，你可能会想当然地认为，只要发送符合标准的流媒体，任何专业解码器都应该能够可靠地播放。毕竟，标准就是标准……对吧？

遗憾的是，现实世界并非如此。

事实上，视频编码器和解码器的互操作性仍然是实时视频工作流程中最令人头疼、最耗时的挑战之一，尤其是在基于 IP 的协议原生分发中。即使纸面上看起来一切正常，但屏幕上的结果也可能是各种问题，从播放流畅到视频卡顿、音频丢失。

为什么会出现这种情况？更重要的是，我们能做些什么？

为什么互操作性在直播贡献和分发中很重要

在现场直播操作中，有无数种情况需要混合不同供应商的设备，这不仅有帮助，而且是必不可少的。

例如，在大型体育赛事中，转播权要交付给几十个不同的接收方，而每个接收方都有自己的主控环境。或者是突发新闻，必须立即向世界各地的广播公司转播。没有时间，通常也没有能力提前运送和设置供应商特定的硬件。在这种情况下，将来自不同供应商的播出和分发设备进行混合的能力可确保内容能够可靠、快速地传输。

但互操作性的好处远不止这些关键时刻。

它使广播公司能够最大限度地利用现有基础设施，利用现有设备，而不是仅仅为了满足特定供应商的生态系统而更换设备。它还有助于组织自由地随着时间的推移发展其技术堆栈，而无需重建整个流程。

在日益全球化的行业中，地缘政治和监管现实也发挥着作用。由于制裁或贸易规则，某些地区无法使用某些供应商。标准化、可互操作的工作流程使参与成为可能，而不会排除整个地区或组织。

自由职业者和小型制作团队，尤其是在偏远或资源匮乏的地区，通常使用现有的任何设备进行工作。如果我们想要实现包容性、可扩展的贡献，互操作性就是将他们与更广泛的网络连接起来的桥梁。

对于体育赛事、新闻选举等全球重大事件而言，快速高效地扩展规模至关重要。能够混合搭配兼容的设备可以降低成本、缩短设置时间，并简化对数百个信号源的支持。

最终，通过实现互操作性，广播公司和服务提供商可以减少对专用运输设备的需求，减少碳影响，支持可持续发展目标，并为贡献者和接受者提供更大的灵活性。

并非所有标准都是真正的标准

虽然许多供应商声称符合 H.264、H.265、MPEG-TS 和 SRT 等标准，但实际操作中“合规”的含义可能千差万别。这些标准通常范围广泛，存在诸多解释空间，尤其是在时序、分组化、比特率控制和流复用等领域。

例如，两个编码器可能都声称符合 MPEG-TS 标准，但其中一个编码器可能更频繁地插入 PAT/PMT 表，或者以不同的方式复用 PCR 值，从而影响下游对流的解析方式。同样，即使在相同的“标准”下，音频流也可能使用不同的声道​​布局、编解码器配置文件或 PID 映射。

元数据处理（例如 SCTE-35 插入或隐藏字幕嵌入）是另一个常见的分歧点。有些解码器会优雅地忽略缺失或格式错误的元数据，而有些解码器则会完全失败或出现不可预测的行为。

对于 SRT 或 RIST 等 ARQ 协议来说也是如此。虽然这些协议确保了数据包的传递和完整性，但它并没有标准化在数据流被封装之前如何进行复用或时间戳处理。问题往往出在这里，并非出在网络，而是出在编码器和解码器实现的假设上。

编码器和解码器是根据特定假设构建的

没有哪个编码器能够完美地与所有解码器兼容。每个供应商在构建其产品时都会基于某些假设，例如网络行为、解码器缓冲区模型、时间戳对齐以及在负载下如何处理复用。

一个编码器可能期望解码器能够容忍轻微的 PCR 漂移，而另一个编码器可能假设解码器严格遵守 PCR/PTS/DTS 关系（例如专业 IRD 中的 PCR/PTS/DTS 关系）。一些解码器期望 GOP 结构完全恒定；而另一些解码器则可以处理变化。即使是 PAT/PMT 频率或音频帧间距的微小差异，也可能导致丢包或播放错误，尤其是在专业 IRD 或严格指定的接收器工作流程中。

比特率控制模型也各不相同，采用激进 VBR 的编码器可能会导致在针对 CBR 或上限 VBR 进行调整的设备上解码不稳定。此外，在低延迟场景下，某些编码器会优先考虑快速交付，而牺牲了 GOP 的一致性，而某些解码器在没有预缓冲的情况下无法处理这种情况。

这些问题通常不会在实验室条件下出现。只有在真实的网络负载下，现场使用实际的解码器硬件时，才会出现不兼容问题。到那时，通常已经来不及在不中断直播的情况下更换编码器或重新配置解码器了。

问题不在于传输，而在于互操作性

基于 IP 的工作流程中最容易引起误解的事情之一是，当传输看起来很完美时，SRT 上的数据包丢失为零，抖动稳定，RTT 低且一致，但解码器仍然遇到困难。

为什么？因为解码器不是解析网络数据包，而是解析嵌入其中的媒体流。如果底层流结构不是解码器能够处理的，即使 SRT 传输层完美地完成了工作，播放也会出现卡顿、卡顿或失败。

这通常是由于以下原因造成的：

• MPEG-TS 复用不良：PAT/PMT 表缺失或不常见、PCR/PTS/DTS 未对齐或连续性计数器损坏。
• 意外的 PCR 抖动：即使时钟稳定性中的微小不一致也可能导致严格的解码器失效，尤其是在广播链环境中的解码器。
• 音频通道不匹配：例如，解码器期望立体声的 PID 上出现了单声道音频，或者仅支持 HE-AAC 的 AAC-LC 配置文件。一些运营商甚至仍在使用 MPEG-1 Layer 2 音频。
• GOP 不一致：特别是在网络或处理条件波动的实时编码器中，一些解码器无法容忍 GOP 漂移或不规则的 IDR（关键帧）间隔。

这些问题在 ARQ 或 IP 层是看不到的。数据包可能以完美的顺序到达，但如果流中的内容不符合解码器的预期，解码器就会失败。这无关网络完整性，而关乎流兼容性。

这就是为什么传输层诊断是不够的。您需要了解复用行为、时间戳对齐以及解码器如何解释流，而不仅仅是它是否到达。

GlobalM 能做什么呢？

在 GlobalM，我们采取务实的方法来应对这个非常常见的问题，认识到编码器/解码器不兼容不是仅靠标准就能解决的问题，还需要智能架构和正确的工具。

1. 基于云的边缘处理

通过在分发路径中插入轻量级边缘处理层，我们可以实时对流进行重新混合、转码或版本控制，并根据接收解码器的预期需求定制每个输出。这使我们能够创建特定于解码器的流变体，而无需更改原始编码器输出。

例如：

• 如果 IRD 需要恒定比特率 (CBR) 并且无法处理可变比特率，我们可以将流重新混合为兼容的 CBR。
• 如果解码器无法接收 H.264 中的 1080i，我们可以转码为 1080p 或其他兼容格式。
• 如果解码器需要特定的音频布局或 PID 结构，我们可以相应地重塑流。

通过提前了解所使用的解码器型号及其预期的接收规格，我们可以在兼容性问题出现之前就将其解决。这种方法使我们能够构建一个支持来自多个制造商的各种编码器和解码器的交付网络，而不会影响性能或质量。

2. 互操作配置文件和测试

我们鼓励客户在直播活动开始前主动测试其编码器和解码器组合。码流处理方面的差异（例如比特率控制、复用结构或音频和分辨率预期）可能会导致难以实时诊断的播放问题。

一般来说，如果编码器和解码器使用相同品牌和型号，互操作性通常不会成为问题。问题通常出现在混合使用不同供应商的设备时，因为每个供应商对标准都有各自的假设和解释。

根据经验，大多数与解码器相关的问题可以通过提前验证并清晰了解每个设备的预期功能来避免。我们可根据需要在整个过程中为客户提供建议和支持。

3. 鼓励缓冲灵活性

我们强烈建议在解码器端配置足够的 SRT 链路延迟缓冲区，通常以测量 RTT 的四倍左右作为起始值。这个简单的设置可以显著提高在波动条件下的播放稳定性。

有些用户会将延迟推得更高，有时甚至超过 1000 毫秒，这可能会导致意外的缓冲区行为（具体取决于解码器型号）。了解每个设备如何处理大型缓冲区是防止不稳定的关键。

总结

这并不是要责怪编码器或解码器，而是要认识到复杂性存在于边缘。最好的解决方案是架构灵活性，能够适应实际应用，而不是依赖于理论上可行的方案。

作者：GlobalM 首席执行官 Paul Calleja