LTR 弱网对抗由于需要解码器的反馈，因此用硬件解码器实现时需要做一些特殊处理。另外，一些硬件解码器对 LTR 的实现不是特别完善，会导致出现解码错误。本文为 QoS 弱网优化系列的第三篇，将为您详解阿里云 RTC QoS 策略中的 LTR 抗弱网原理与实现硬解 LTR 时遇到的坑及其相应解法。
作者｜安基程、陶森柏、田伟峰
审校｜泰一
Long Term Reference (LTR) 抗弱网原理
参考帧丢失的 I 帧恢复
在 RTC 场景下一般的编码参考策略是向前一帧参考（在不考虑 temporal svc 的情况下），因为一般情况下参考距离越近，相似性越好，则压缩效果越好，出于实时的考虑编码只有 I 帧和 P 帧，没有 B 帧。在有 P 帧丢失的场景下，接收端需要重新请求 I 帧才能继续正确的解码和播放。
如上图所示，正常的 I P P P 帧编码，如果发生弱网导致中间的某个 P 帧（✖️ 标记）丢失，无法恢复，则接收端会请求发送端重新编码 I 帧，然而 I 帧只能使用帧内预测，所以编码效率低下。
参考帧丢失的 LTR 恢复
长期参考帧是一种可跨帧的参考帧选择策略，这种策略打破了传统的向前一帧的限制，可以更加灵活地选择参考帧。长期参考帧策略的目的是在有 P 帧丢失的场景下，接收端不需要重新请求 I 帧也能继续正确的解码和播放，其相对于 I 帧可以明显提升编码效率，节省带宽。该技术可以绕过丢失的帧，利用丢失帧之前的一个已经接收的长期参考帧作为参考进行编码 / 解码显示，从而提升弱网场景下的视频流畅性。
上图所示是引入 LTR 技术后的丢帧恢复策略，未发生弱网时仍然是正常的 I P P P 帧编码，只是会将其中的某些 P 帧标记为 LTR 帧（如图中的绿色 P 帧，以下称为 LTR 标记帧）。如果发生弱网中间的某个 P 帧（✖️ 标记）丢失，无法恢复，则接收端会请求发送端（编码器）利用 LTR 恢复，此时编码器会利用之前的已经确认收到的 LTR 标记帧做为参考编出一个 P 帧（图中红色 P 帧，以下被称为 LTR 恢复帧）。
由于之前的 LTR 标记帧已经被解码器确认收到，所以解码器参考帧 buffer 中必然存有此帧，所以利用此帧做参考的红色 P 帧必然可以被解码器正确解码。LTR 恢复帧由于是有参考的 P 帧，所以比 I 帧的编码效率显著提升。
根据上述 LTR 技术的特点和目的，可见 LTR 技术是一种网络模块和编码器共同配合完成的参考帧选择技术。实现 LTR 技术需要有接收端侧反馈信息，即编码器发出的 LTR 标记帧（图中的绿色 P 帧），如果被解码器成功收到，需要解码器
通知编码器其收到了这一帧，这样编码器在收到 LTR 恢复请求的时候，才可以 “放心的” 使用此帧做参考。
关于 LTR，前两篇文章中也有做部分介绍，感兴趣的读者可以参考：
1.《阿里云 RTC QoS 屏幕共享弱网优化之若干编码器相关优化》
硬件解码支持 LTR
硬件解码的优势
硬件解码相对于软件解码而言，具有低功耗的天然优势，所以，在有条件使用硬件解码且不影响视频观看体验的情况下，应首选硬件解码。
获取码流中的 LTR 相关信息
对于软件解码器而言，开发者可以直接在解码器中实现接口以从码流中读取 LTR 相关信息，比如此帧是否为 LTR 标记帧，及其 frame number 等信息。如果此帧是 LTR 标记帧，则将其 frame number 反馈给编码器以表示其已收到此帧。
然而对于硬件解码器，其接口软件开发者是无法修改的，一般硬件解码器也没有接口可以读取 LTR 的相关信息。那怎样才能读取到 LTR 的相关信息呢？
本文使用的方法是，在硬件解码器之外的 RTC level 再进行一次码流解析，读取 LTR 相关信息，反馈给编码器。由于该信息都在码流的 high level syntax 中，如 slice header 等，所以额外解析该部分码流并没有太大开销。
某些硬解不支持 LTR 及解决思路
由于 LTR 的上述功能并不是 codec 中特别常用的功能，所以一些硬解厂商并没有将 LTR 功能实现的很好，在本文的实测过程中，就发现了一些问题。
上图中如果红框中的普通 P 帧没有被丢失的话，则 LTR 恢复帧即红色 P 帧都可以被本文所测试的硬件解码器正确解码。但是如果红框中的 P 帧丢失了，则有一部分硬件解码器无法正确解码出后面红色的 LTR 恢复帧。本文实测了一些手机，发现使用苹果，高通，三星芯片的手机可以正确的解码，然而使用华为（海思）、联发科某些芯片的手机则不能正确解码此时的 LTR 恢复帧，会返回解码错误或输出花屏。
由于实际发生弱网的时候，肯定会伴随着丢帧，即红框中的 P 帧肯定会有所丢失，所以若此时 LTR 恢复帧不可解码，则就等同于 LTR 技术对于这些硬解不可用了。这应该是某些硬件解码器自身实现的问题，即没有完全按照标准去实现所致。但是要如何规避这种问题呢？
进一步测试发现，解码错误的原因是由于中间红框里面的 P 帧丢失导致 frame number 不连续，如果将后面帧的 frame number 改为连续的，则仍然可以正确的解码！所以，本文的解法是：对于一帧码流，在送给某些硬件解码器之前，如果发现其 frame number 和之前的是不连续的，则直接改写码流将其改为连续的，再送给硬解，这样，就可以很好的规避某些硬解无法解码 LTR 恢复帧的问题，从而兼顾功耗和弱网视频体验。
「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。
