短影片平臺開發時那些容易掉進去的“深坑”

網際網路市場中之所以存在那麼多優質的 app，都是經過無數次的測試、最佳化和更新完成的。要想開發一款優質的app並沒有那麼容易。比如在短影片平臺開發時，不僅需要考慮音影片是否同步、首屏開啟速度等問題，還需要考慮介面的UI和功能等是否貼近使用者需求。所以難免會在開發過程中遇到問題，今天就簡單的盤點一下硬編解時可能會遇到的“坑”。

1.影像質量

在使用硬編碼之後，對比可以發現影片的畫質轉碼後影像質量會變差。原因是什麼呢？因為在使用 mediacodecAPI時，選擇了CBR。雖然CBR的優勢是位元速率比較穩定，但是它會犧牲一部分畫質，所以CBR更適合在移動的直播場景中應用。在短影片的轉碼過程中，使用硬編時更適合選擇VBR，這樣一來VBR能夠獲得更好的影像質量。但是在軟編時選擇VBR，情況就不太穩定，無法保證影像質量的“穩定輸出”。

2.硬解不相容

H.264是短影片編解碼過程中常用的標準格式，起碼流主要分為 AVCC和Annex-B兩種格式。其中兩者的主要區別在於引數集和幀格式。 Annex-B的引數集pps、sps及NAL的形式存在於碼流之中，也可以理解為是帶內傳輸，以startcode分隔NAL。而AVCC的引數集主要儲存在extradata中，即帶外傳輸，使用NALU長度分隔NAL，一般MP4和MKV都使用AVCC格式進行儲存。需要注意的是，Android端的硬解只接受Annex-B格式的碼流，所以相似解碼MP4demux出的影片流時，需要對extradata進行解析，取出pps和sps，藉助CSD進行初始化解碼器，並將AVCC碼流轉化為Annex-B，並在ffmpeg中使用H.264進行轉換。

3.時間戳不準確

通常硬解碼器會將影片解碼到 surface，這個時候我們所獲得的時間戳並不準確，某些機型還可能會出現異常。所以就需要使用解碼輸入的時間戳，從而將解碼過程由非同步轉為同步，或者也可以將pts儲存到佇列中實現。

4.硬編解的速度問題

Mediacodec音訊編解碼的具體實現跟機型也有一定的關係，根據相關的測試，mediacodec音訊硬編碼比起軟編碼有6%左右的提速，但是mediacodec音訊硬解反而比起軟解來速度更慢一些。

由於適用的應用場景和使用者需求各不相同，在硬編解和軟編解的選擇上也是非常的令人頭疼。但無論如何選擇，短影片平臺開發的大前提都是以使用者體驗為主。所以在開發時，需要進行多方考慮，不僅要保障 app的流暢執行，還要從功能機制上多下功夫。這樣一來，才能開發出優質的短影片app，從而在短影片領域激烈的競爭中“生存下去”。

本文宣告原創，轉載請註明出處。