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 帧能够明显提高编码效率，节省带宽。该技术能够绕过丢失的帧，利用丢失帧以前的一个已经接收的长期参考帧做为参考进行编码 / 解码显示，从而提高弱网场景下的视频流畅性。url
上图所示是引入 LTR 技术后的丢帧恢复策略，未发生弱网时仍然是正常的 I P P P 帧编码，只是会将其中的某些 P 帧标记为 LTR 帧（如图中的绿色 P 帧，如下称为 LTR 标记帧）。若是发生弱网中间的某个 P 帧（✖️ 标记）丢失，没法恢复，则接收端会请求发送端（编码器）利用 LTR 恢复，此时编码器会利用以前的已经确认收到的 LTR 标记帧作为参考编出一个 P 帧（图中红色 P 帧，如下被称为 LTR 恢复帧）。.net
因为以前的 LTR 标记帧已经被解码器确认收到，因此解码器参考帧 buffer 中必然存有此帧，因此利用此帧作参考的红色 P 帧必然能够被解码器正确解码。LTR 恢复帧因为是有参考的 P 帧，因此比 I 帧的编码效率显著提高。code
根据上述 LTR 技术的特色和目的，可见 LTR 技术是一种网络模块和编码器共同配合完成的参考帧选择技术。实现 LTR 技术须要有接收端侧反馈信息，即编码器发出的 LTR 标记帧（图中的绿色 P 帧），若是被解码器成功收到，须要解码器 通知编码器其收到了这一帧，这样编码器在收到 LTR 恢复请求的时候，才能够 “放心的” 使用此帧作参考。视频
关于 LTR，前两篇文章中也有作部分介绍，感兴趣的读者能够参考：blog
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 恢复帧的问题，从而兼顾功耗和弱网视频体验。
「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。