對於任何H.264解碼器而言，都要將SPS和PPS信息傳遞給解碼器。FFmpeg內部做了設置，所以沒有顯示設置。但是對於硬件解碼器來講，開發者必須手動設置。另外，使用FFmpeg解碼出來的視頻幀是以YUV格式存儲於內存中的，但是對於硬件解碼器來講，一般都是直接解碼到顯存，便於后續的處理與渲染。H.264有兩種封裝格式，一種是Annexb封裝，另外一種是mp4(AVCC)封裝。輸入數據給解碼器時需要特定的格式。VTB decoder要求的是mp4(AVCC)格式的輸入，而MediaCodec要求的是Annexb格式的輸入。但是FFmpeg解封裝出來的AVPacket通常是mp4(AVCC)格式的。
最近被拉去解決一個iOS VTB解碼失敗的問題，現象是省流模式下DecodeFrame時返回-12911，callback里返回-12909，標清以上沒有這個問題。
問題分析：
1. 視頻源有沒有問題？省流模式下H.264的profile是baseline，是否跟這個有關系？
iOS系統播放器播放正常，所以跟baseline無關；PC VLC播放正常，所以視頻源沒有什么問題。
2. 是否是SPS/PPS等參數設置有問題？
仔細查看SPS/PPS設置的字節數和內容，其中H.264的extradata的格式有做轉換，但是仔細分析，確實沒有問題。另外如果有問題，標清模式以上應該也有這個問題。
3. 傳入的數據包有無區別？
最開始分析的是省流和標清模式傳遞的數據包有無區別，仔細分析后，發現一切正常，傳入的字節數跟具體內容都是正確的。
網上搜索-12909和-12911提示的都是傳入的數據包有誤，但是分析下來，確實沒發現什么問題。這時候只能對比其他開源軟件的做法了。編譯了ijkplayer的demo，傳入省流的url，斷點分析其VTB代碼邏輯。這里主要是因為VTB有幾套API，我們的程序跟ijkplayer用的API還不完全一致，一開始以為是API調用錯誤導致的，后來對其API后，問題還是沒有解決。然后接着分析了SPS/PPS傳遞邏輯和傳遞的第一個數據包，注意，一定要是第一個AVPacket，才能排除其他外界因素的干擾。
問題定位：
對比ijkplayer，我們送入的第一個AVPacket要比ijkplayer多了十幾個字節，這十幾個字節實際上存儲了MPEG格式的streamID。但是ijkplayer調用了av_packet_split_side_data將讀取到的pkt的最后的side_data去除了，而我們的程序沒有去除side_data。去除side_data后，首幀解碼成功，問題解決。
思考：
這個問題的詭異就在於同樣的程序標清以上解碼是ok的，省流解碼就有問題，導致一開始查問題的思路偏了，猜測這應該與VTB的內部實現有關。另外一點就是問題總是能解決的，不僅僅是不斷試錯，還需要不斷克服一次次試錯時的沮喪心理。