H 264簡單介紹
阿新 • • 發佈:2018-05-28
不同 基本概念 怎麽辦 DC stream 也不會 分辨 消息 數據
一、H264 在H264協議裏定義了三種幀,完整編碼的幀叫I幀,參考之前的I幀生成的只包含差異部分編碼的幀叫P幀, 還有一種參考前後的幀編碼的幀叫B幀。 H264采用的核心算法是幀內壓縮和幀間壓縮,幀內壓縮是生成I幀的算法,幀間壓縮是生成B幀和P幀的算法。 一個序列的第一個圖像叫做 IDR 圖像(立即刷新圖像),IDR 圖像都是 I 幀圖像 二、音視頻基礎知識 采樣率表示了每秒鐘的采樣次數。 比特率表示了每秒鐘傳輸的音頻數據量,該值也和采樣率相關。 采樣率類似於動態影像的幀數,比如電影的采樣率是24HZ,P AL制式的采樣率是25HZ,NTSC制式的采樣率是30HZ。 當我們把采樣到的一個個靜止畫面再以采樣率同樣的速度回放時,看到的就是連續的畫面。 同樣的道理,把以44100HZ采樣率記錄的CD以同樣的速率播放時,就能聽到連續的聲音。 顯然,這個采樣率越高,聽到的聲音和看到的圖像就越連貫。 可是人的聽覺和視覺器官能分辨的采樣率是有限的,基本上高於44100HZ采樣的聲音, 絕大部分人已經覺察不到其中的分別了。 而聲音的位數就相當於畫面的顏色數(8位就是0-255),表示每個取樣的數據量, 當然數據量越大,回放的聲音越準確,不至於把開水壺的叫聲和火車的鳴笛混淆。 同樣的道理,對於畫面來說就是更清晰和準確,不至於把血和西紅柿醬混淆。 不過受人的器官的機能限制,16位的聲音和24位的畫面基本已經是普通人類的極限了, 更高位數就只能靠儀器才能分辨出來了。比如電話就是3000HZ取樣的7位聲音, 而CD是44100HZ取樣的16位聲音,所以CD就比電話更清楚。 有了以上這兩個概念,比特率就很容易理解了。以電話為例,每秒3000次取樣, 每個取樣是7比特,那麽電話的比特率是21000。而CD是每秒44100次取樣,兩個聲道, 每個取樣是16位PCM編碼,所以CD的比特率是44100*2*16=1411200,也就是說CD每秒的數據量大約是176KB。 三、H264是的編碼知識 在H.264/AVC視頻編碼標準中,整個系統框架被分為了兩個層面:視頻編碼層面(VCL)和網絡抽象層面(NAL)。 其中,前者負責有效表示視頻數據的內容,而後者則負責格式化數據並提供頭信息,以保證數據適合各種信道和存儲介質上的傳輸。 因此我們平時的每幀數據就是一個NAL單元(SPS與PPS除外)。 在實際的H264數據幀中,往往幀前面帶有00 00 00 01 或 00 00 01分隔符,一 般來說編碼器編出的首幀數據為PPS與SPS,接著為I幀…… 我們還是接著看最上面圖的碼流對應的數據來層層分析,以00 00 00 01分割之後的下一個字節就是NALU類型, 將其轉為二進制數據後,解讀順序為從左往右算,如下: (1)第1位禁止位,值為1表示語法出錯 (2)第2~3位為參考級別 (3)第4~8為是nal單元類型 例如上面00000001後有67,68以及65 其中0x67的二進制碼為: 0110 0111 4-8為00111,轉為十進制7,參考第二幅圖:7對應序列參數集SPS 其中0x68的二進制碼為: 0110 1000 4-8為01000,轉為十進制8,參考第二幅圖:8對應圖像參數集PPS 其中0x65的二進制碼為: 0110 0101 4-8為00101,轉為十進制5,參考第二幅圖:5對應IDR圖像中的片(I幀) 1、對於H.264而言,每幀的界定符為00 00 00 01 或者00 00 01。 例如下面是一個H264的文件片段 00 00 00 01 67 42 C0 28 DA 01 E0 08 9F 96 10 00 00 03 00 10 00 00 03 01 48 F1 83 2A 00 00 00 01 68 CE 3C 80 00 00 01 06 05 FF FF 5D DC 45 E9 BD E6 D9 48 B7 96 2C D8 20 D9 23 EE EF … 第一幀是00 00 00 01 67 42 C0 28 DA 01 E0 08 9F 96 10 00 00 03 00 10 00 00 03 01 48 F1 83 2A 第二幀是00 00 00 01 68 CE 3C 80 第三幀是00 00 01 06 05 FF FF 5D DC 45 E9 BD E6 D9 48 B7 96 2C D8 20 D9 23 EE EF .. 2、幀類型有: NAL_SLICE = 1 非關鍵幀 NAL_SLICE_DPA = 2 NAL_SLICE_DPB = 3 NAL_SLICE_DPC =4 NAL_SLICE_IDR =5 關鍵幀 NAL_SEI = 6 NAL_SPS = 7 SPS幀 NAL_PPS = 8 PPS幀 NAL_AUD = 9 NAL_FILLER = 12 3、PPS 與SPS SPS 對於H264而言,就是編碼後的第一幀,如果是讀取的H264文件,就是第一個幀界定符和第二個幀界定符之間的數據的長度是4 PPS 就是編碼後的第二幀,如果是讀取的H264文件,就是第二幀界定符和第三幀界定符中間的數據長度不固定。 在H264碼流中,都是以"0x00 0x00 0x01"或者"0x00 0x00 0x00 0x01"為開始碼的,找到開始碼之後,使用開始碼之後的第一個字節的第5位判斷是否為7(sps)或者8(pps), SDP中的H.264的SPS和PPS串,包含了初始化H.264解碼器所需要的信息參數,包括編碼所用的profile,level,圖像的寬和高,deblock濾波器等 再給avc解碼器送數據流之前一定要把sps,pps信息送出,否則的話不能正常解碼。而且在解碼器stop之後再次start之前,比如seek,快進快退狀態切換等,都需要重新發送一遍sps和pps信息 pps sps 在片的頭信息和數據解碼前送至解碼器,否則播放不出來 rtmp數據包,在I幀數據前,有SPS也不會影響rtmp流的播放,但在轉成ts數據包的時候,是將sps數據和I幀數據前加NALU頭後,進行TS封裝的。 4、I 和IDR都是使用幀內預測的,要首個I幀和其他i幀區別開,所以才把第一個i幀叫做IDR。IDR幀的作用是立即刷新,使錯誤不至傳播 從IDR幀開始,重新算一個新的序列開始編碼。而I幀不具有隨機訪問的能力,這個功能是由IDR承擔。 5、h264 在H.264/AVC視頻編碼標準中,整個系統框架被分為了兩個層面:視頻編碼層面(VCL)和網絡抽象層面(NAL)。 其中,前者負責有效表示視頻數據的內容,而後者則負責格式化數據並提供頭信息,以保證數據適合各種信道和存儲介質上的傳輸。NAL占一個字節。 NAL單元(NALU):NAL的基本語法結構,它包含一個字節的頭信息和一系列來自VCL的稱為原始字節序列載荷(RBSP)的字節流。 數據流是儲存在介質上時: 每個NALU 前添加起始碼:0x00000001(或者0x000001),用來指示一個 NALU的起始和終止位置。我們平時的每幀數據就是一個NAL單元(SPS與PPS除外)。 編碼器將每個NAL各自獨立、完整地放入一個分組,因為分組都有頭部,解碼器可以方便地檢測出NAL的分界,並依次取出NAL進行解碼。 每個NAL前有一個起始碼 0x00 00 01(或者0x00 00 00 01),解碼器檢測每個起始碼,作為一個NAL的起始標識,當檢測到下一個起始碼時,當前NAL結束。 同時H.264規定,當檢測到0x000000時,也可以表征當前NAL的結束。那麽NAL中數據出現0x000001或0x000000時怎麽辦?H.264引入了防止競爭機制, 如果編碼器檢測到NAL數據存在0x000001或0x000000時,編碼器會在最後個字節前插入一個新的字節0x03 三、流的基本概念 1、 四、rtmp協議 1、rtmp客戶端與服務器一般握手的順序是: |client|Server | |---C0+C1—->| |<--S0+S1+S2– | |---C2----> | 2、 Message(消息) 這裏的Message是指滿足該協議格式的、可以切分成Chunk發送的消息,消息包含的字段如下: Timestamp(時間戳):消息的時間戳(但不一定是當前時間,後面會介紹),4個字節 Length(長度):是指Message Payload(消息負載)即音視頻等信息的數據的長度,3個字節 TypeId(類型Id):消息的類型Id,1個字節 Message Stream ID(消息的流ID):每個消息的唯一標識, 劃分成Chunk和還原Chunk為Message的時候都是根據這個ID來辨識是否是同一個消息的Chunk的, 4個字節,並且以小端格式存儲 3、Chunking(Message分塊) 發送端,會把message 拆分成chunk, 在一個Chunk發送完成之後才能開始發送下一個Chunk 每個Chunk中帶有MessageID代表屬於哪個Message,接受端也會按照這個id來將chunk組裝成Message 數據量較大的Message可以被拆分成較小的“Message”, 這樣就可以避免優先級低的消息持續發送阻塞優先級高的數據 hunk的默認大小是128字節,在傳輸過程中,通過一個叫做Set Chunk Size的控制信息可以設置 Chunk數據量的最大值,在發送端和接受端會各自維護一個Chunk Size 在實際發送時應對要發送的數據用不同的Chunk Size去嘗試,通過抓包分析等手段得出合適的Chunk大小, 並且在傳輸過程中可以根據當前的帶寬信息和實際信息的大小動態調整Chunk的大小, 從而盡量提高CPU的利用率並減少信息的阻塞機率
H 264簡單介紹