幀邊界識別簡介
h.264 將構成一幀影象所有nalu 的集合稱為乙個au，幀邊界識別實際上就是識別au。因為h.264 取消幀級語法，所以無法簡單地從碼流中獲取au。解碼器只有在解碼的過
程中，通過某些語法元素的組合才能判斷一幀影象是否結束。一般來說，解碼器必須在完成一幀新影象的第乙個slice_header 語法解碼之後，才能知道前一幀影象已經結束。
因此，最嚴謹的au 識別步驟如下：
步驟 1 對碼流實施「去03 處理」。
步驟 2 解析nalu 語法。
步驟 3 解析slice_header 語法。
步驟 4 綜合判斷前後兩個nalu 以及對應的slice_header 中的若干個語法元素，看是否發生變化。
如果發生變化，則說明這兩個nalu 屬於不同的幀，否則說明這兩個nalu 屬於同一幀。
----結束
顯然，在解碼前完成上述的au 識別消耗許多cpu 資源，因此不推薦使用au 方式解碼
為了提供一種簡單的
au 識別方案，
h.264
規定一種型別為
09 的
nalu
，即編碼器在每次完成乙個
au 編碼後，在碼流中插入乙個型別為
09 的
nalu
，在這個前提下，解碼器只需要從碼流中搜尋型別為
09 的
nalu
即可獲得乙個au。
h.264
並不強制要求編碼器插入型別為
09 的
nalu
，因此並非所有的碼流都具備這種特徵。對於編碼器和解碼器協同工作的應用場景，建議讓編碼器插入型別為
09 的
nalu
，這樣可以降低解碼器識別
au 的代價。
為了降低解碼器在解碼前識別au 的代價，本文提出一種高效的au 識別方法，其主要思路是利用一幀影象的第乙個slice_header 中的語法元素first_mb_in_slice 一般等於0 這
個特徵（對於包含aso 或者fmo 特性的碼流，這個條件不一定成立）。
typedef struct parsecontext parsecontext;
signed int decloadau(unsigned char* pstream, unsigned int istreamlen, parsecontext *pc)
for( i = 0; i < istreamlen; i++)
if( pstream[i] & 0x80) /* 查詢first_mb_in_slice為0的slice頭確定一幅影象的開始 */
else
} } if (i < istreamlen)
} pc->framestartfound = 0;
return -1; /* 沒有找到au邊界返回-1 */
}
H264中NAL幀識別
假設一段h264的碼流為 00 00 00 0141 e6 60 其中的00 00 00 01為起始碼，而起始碼之後的下乙個位元組就可以檢測出這一幀的型別。在上面的碼流中起始碼之後的位元組位 0x41，換算成二進位制為 0100 0001。注 我解讀順序為從左往右算。對於0100 0001 1 第1...
H 264參考幀管理
引言 h 264相對於以前的標準，採用了多參考幀的技術，提高了編碼器的效能，但也增加了實現的複雜度，在理解上也加大了難度。下面是我近來參閱一些資料的總結 frame num 標誌片的解碼順序，當前影象是idr 立即重新整理影象 時，設定為0 相對於前面乙個參考幀 解碼順序 增加1 poctype0 ...
H 264多參考幀
h264中允許從多至15個幀裡面選擇1幀或者2幀出來作為參考進行 所以必須引入乙個列表來管理這些參考影象，對與p slice而言，對應 list0，對於 b slice 而言，還需要多乙個 list1，因為 b slice 是進行的兩次 乙個前向乙個後向 兩個前向 兩個後向 參考幀分為 long t...