互聯(lián)網(wǎng)市場中之所以存在那么多優(yōu)質(zhì)的app，都是經(jīng)過無數(shù)次的測試、優(yōu)化和更新完成的。要想開發(fā)一款優(yōu)質(zhì)的app并沒有那么容易。比如在短視頻平臺開發(fā)時，不僅需要考慮音視頻是否同步、首屏打開速度等問題，還需要考慮界面的UI和功能等是否貼近用戶需求。所以難免會在開發(fā)過程中遇到問題，今天就簡單的盤點一下硬編解時可能會遇到的“坑”。

1.圖像質(zhì)量

在使用硬編碼之后，對比可以發(fā)現(xiàn)視頻的畫質(zhì)轉(zhuǎn)碼后圖像質(zhì)量會變差。原因是什么呢？因為在使用mediacodecAPI時，選擇了CBR。雖然CBR的優(yōu)勢是碼率比較穩(wěn)定，但是它會犧牲一部分畫質(zhì)，所以CBR更適合在移動的直播場景中應用。在短視頻的轉(zhuǎn)碼過程中，使用硬編時更適合選擇VBR，這樣一來VBR能夠獲得更好的圖像質(zhì)量。但是在軟編時選擇VBR，情況就不太穩(wěn)定，無法保證圖像質(zhì)量的“穩(wěn)定輸出”。

2.硬解不兼容

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

3.時間戳不準確

通常硬解碼器會將視頻解碼到surface，這個時候我們所獲得的時間戳并不準確，某些機型還可能會出現(xiàn)異常。所以就需要使用解碼輸入的時間戳，從而將解碼過程由異步轉(zhuǎn)為同步，或者也可以將pts存儲到隊列中實現(xiàn)。

4.硬編解的速度問題

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

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

本文聲明原創(chuàng)，轉(zhuǎn)載請注明出處。