共计 2162 个字符，预计需要花费 6 分钟才能阅读完成。
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 屏幕共享弱网优化之若干编码器相干优化》
2.《阿里云 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 复原帧的问题，从而兼顾功耗和弱网视频体验。
「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实际技术文章，在这里与音视频畛域一流工程师交换切磋。