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