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 恢復幀的問題，從而兼顧功耗和弱網視訊體驗。
「視訊雲技術」你最值得關注的音視訊技術公眾號，每週推送來自阿里雲一線的實踐技術文章，在這裡與音視訊領域一流工程師交流切磋。