https://goo.gl/nsHhUc
https://www.ptt.cc/bbs/C_and_CPP/M.1332759347.A.4D0.html
來源 : 工研院
1. 前言
且H.264/AVC也首次將
視訊編碼層(Video Coding Layer，VCL)與
網路提取層(Network Abstraction Layer，NAL)的概念涵蓋進來，H.264/AVC根據使用的編碼工具種類來提供三種編碼規模(Profile)，如表1所示分別為
Baseline Profile、Main Profile、Extension Profile，而相對應的影片尺寸與位元率等級由Level 1至Level 5.1，涵蓋小畫面與高解析度畫面的應用範圍。
Baseline Profile主要是著眼於低位元率的應用(例如：影像通訊)，而且其運算複雜度低，所以也適合應用於個人隨身的多媒體撥放機；
Main Profile因為有支援交錯式影片(interlaced content)的編碼，所以適合應用於HDTV數位電視廣播，而且非常容易整合在傳統的MPEG-2 Transport/Program Stream上來傳送H.264/AVC位元流；
Extension Profile是對於IP-TV或是MOD (Multimedia On Demand)等應用，使用包含高抗錯性編碼工具(error resilient tools).
1 .
Baseline Profile : 只使用 I-Frame 與 P-Frame 的 CAVLC 編碼
CAVLC (Context-Adaptive Variable-Length Coding) 上下文自適應可變長度編碼
(簡單說:p 為前一張的動態資訊圖,非完整圖片)
2.Main Profile:
相較於Baseline類型，加入交錯式(interlaced)影像(B-Frame)、及CABAC等工具.
3. High Profile:
High類型提高Main類型使用位階的上限，放寬採用8×8的DCT轉換，並提供較好的量化步階調整模式。High類型已經逐漸取代Main類型.
公司只用過base.
![[H264 Encoder]](https://erwinchang.github.io/2017/03/14/h264/h264-profiles.png)
2. 網路提取層 (Network Abstraction Layer，NAL)
亦即以
NAL封包為單位的方式來做為VCL編解碼的運算單位，這樣傳輸層拿到
NAL封包之後不需要再進行切割，只需附加該傳輸協定的檔頭資訊(adding header only)就可以交由底層傳送出去，如圖1所示，可以將NAL當成是一個專作封裝(packaging)的模組，用來將VCL壓縮過的bitstream(NAL unit stream)封裝成適當大小的封包單位(NAL-unit)，並在NAL-unit Header中的
NAL-unit Type欄位記載此封包的型式，每種型式分別對應到VCL中不同的編解碼工具。
一個完整的H.264/AVC bitstream是由多個NAL-units所組成的，所以此bitstream也稱之為NAL unit stream，一個
NAL unit stream內可以包含
多個壓縮視訊序列(coded video sequence)，
一個單獨的(coded video sequence)代表一部視訊影片，而壓縮視訊序列又是由
多個access units所組成，當接收端收到一個access unit後，可以完整地解碼成單張的畫面，而每個壓縮視訊序列的第一個access unit必須為Instantaneous Decoding Refresh (IDR) access unit，IDR access unit的內容全是採用intra-prediction編碼，所以自己本身即可完全解碼，不用參考其他access unit的資料。
access unit亦是由多個NAL-units所組成，標準中總共規範
12種的NAL-unit型式，這些可以進一步分類成
VCL NAL-unit及non-VCL NAL-unit，所謂的
VCL NAL-unit純粹是壓縮影像的內容，而所謂的
non-VCL NAL-unit則有兩種：Parameter Sets與Supplemental Enhancement Information (SEI)，SEI可以存放影片簡介、版權宣告、使用者自行定義的資料…等；
Parameter Sets主要是描述整個壓縮視訊序列的參數，例如：長寬比例、影像顯現的時間點(timestamp)、相關解碼所需的參數…等，以往像MPEG-2/-4都把這些資訊放在一般的packet header，所以很容易隨著packet loss而消失，現在
H.264/AVC將這些資訊獨立出來成為特殊的parameter set，可以採用所謂的out-of-band的方式來傳送，以便將out-of-band channel用最高層級的通道編碼(channel coding)保護機制，
來保證傳輸的正確性。
3. 視訊編碼層 (Video Coding Layer，VCL)
如圖1所示，H.264/AVC的視訊編碼機制是以圖塊(block-based)為基礎單元，也就是說先將整張影像分割成許多矩形的小區域，稱之為巨圖塊(macroblock，MB)，再將這些巨圖塊進行編碼，先使用畫面內預測(intra-prediction)與畫面間預測(inter-prediction)技術，以去除影像之間的相似性來得到所謂的差餘影像(residual)，再將差餘影像施以空間轉換(transform)與量化(quantize)來去除視覺冗餘，最後視訊編碼層會輸出編碼過的位元流(bitstream)，之後再包裝成網路提取層的單元封包(NAL-unit)，經由網路傳送到遠端或儲存在儲存媒體中。
H.264/AVC允許視訊影片以frame或是以filed的方式來進行編碼，兩者可以共存，而frame可以是progress或是interlace形式，對同一段影片來說也可使用兩者來混合編碼，這個特性與MPEG-2相同。而在影像色彩格式的支援上，H.264/AVC第一版的標準只支援
YCrCb 4:2:0 (又稱YUV420)取樣的方式，而在增修的
第二版標準中增加4:2:2與4:4:4取樣格式，通常這些格式會被數位電影或HDTV影片所採用。
3.1 H.264/AVC影像格式階層架構
H.264/AVC的階層架構由
小到大依序是sub-block、block、macroblock(MB)、slice、slice group、frame/field-picture、sequence。
對一個採用4:2:0取樣的MB而言，它是由16x16點的Luma與相對應的2個8x8點Chroma來組成，而在H.264/AVC的規範中，MB可再分割成多個16x8、8x16、8x8、8x4、4x8、4x4格式的sub-blocks。所謂的
slice是許多MB的集合，而一
張影像是由許多slice所組成(圖3)，slice為H.264/AVC格式中的最小可解碼單位(self-decodable unit)，也就是說一個slice單靠本身的壓縮資料就能解碼，而不必依靠其他slice，這樣的好處是當傳送到遠端時，每接收完一筆slice的壓縮資料就能馬上解碼，不用等待整張的資料接收完後才能開始，而且萬一傳送的過程中發生資料遺失或錯誤，也只是影響該筆slice，不會對其他slice有所影響，但跟MPEG-2的slice不同處在於它允許slice的範圍可以超過一行MB，也就是說
H.264/AVC允許整張影像只由單一個slice組成。H.264/AVC的slice架構還有一項特性稱為Flexible Macroblock Ordering (FMO)，也就是說組成slice的MB可以不必侷限於循序掃描(raster scan)的排列方式，例如：圖3最右側的排法就非常適用於多個前景(foreground) slice groups與一個獨自的背景(background) slice group，好處是對不同的slice group可以用不同品質的壓縮參數，例如：對於前景物件通常是人眼較感興趣的區域，可以用較小的壓縮率來維持較好的品質。
3.2 Slice的編碼模式
H.264/AVC的slice依照編碼的類型可以分成下列種類：
(1) I-slice:(2) P-slice:(3) B-slice: 與P-slice類.
H.264/AVC另外增加兩種特殊slice類型：(1)
SP-slice: 即所謂的Switching P slice，為P-slice的一種特殊類型，用來串接兩個不同bitrate的bitstream；(2)
SI-slice: 即所謂的Switching I slice，為I-slice的一種特殊類型，除了用來串接兩個不同content的bitstream外，也可用來執行隨機存取(random access)來達到網路VCR的功能。
這兩種特殊的slice主要是
為了讓相同content但不同bitrate的bitstream可以較平順地串接，對同一個視訊內容的影片來說，server會預先存放不同bitrate的壓縮影片，而當頻寬改變時，server就會送出適合當時頻寬位元率的影片，傳統的做法是需要等到適當的時間點來傳送新的I-slice (容量較P-slice大上許多)，但因為頻寬變小導致需要較多的時間來傳送I-slice，如此會讓client端的影像有所延遲，使用SP-slice會很容易來達成.
--------------------------------------------------------------------------
由下圖得知NAL Unit 組成 Access Unit 組成 RTP Packet(coded video sequence?)
![[RTP Packet]](https://erwinchang.github.io/2017/03/14/h264/VCL-Frame.png)
NAL Unit
一張會動畫面被H.264分成需多NALU(NAL Unit)
每個NAL Unit如下圖, 圖片來源： Exploring H.264. Part 2: H.264 Bitstream format
![[NAL Structure]](https://erwinchang.github.io/2017/03/14/h264/NAL_structure.png)
nal unit type為1-23的padload格式如下 (即在rtp padload第12byte開始)![[Single NAL Unit Packet]](https://erwinchang.github.io/2017/03/14/h264/Single-NAL-Unit-Packet.png "[Single NAL Unit Packet]")
nal header
ex. 0x67 (0110 0111)
b[0]: forbidden_zero_bit = 0,
b[1-2]: nal_ref_idc = 3,
b[3-7]: nal_unit_type = 7
根據RFC3984以
RTP 封裝H.264 raw data來作video streaming.
1.H.264 raw data
以00 00 01 或 00 00 00 01作為開頭(Start Code),接著是8 bit NALU
NALU的format
#define NALU_TYPE_SLICE 1( P-Frame?)
#define NALU_TYPE_IDR 5 (I-frame)
#define NALU_TYPE_SEI 6
#define NALU_TYPE_SPS 7
#define NALU_TYPE_PPS 8
正常的H264 NALU順序：
SPS(NAL type = 0x07) -> PPS(0x8) -> I-Frame(0X5), P-Frame(0x1)
把[SPS,PPS,IDR(即IFRAME)]當成一個Frame送到decoder
p.s. RTP?NALU定義?
我們header of rtp header?
參考來源:
https://erwinchang.github.io/2017/03/14/h264/
深入淺出
2020/01/16 新增 知呼(
來源)
*1 frame 可以有1~多個slice. (每個slice可放於NAL包中)
*公司中使用 I frame , P frame(依賴於I frame) ; (沒用B frame)(依賴於I,P,B frame 前後倒快轉用)
網絡抽象層單元類型 (NALU)
NALU header 由1byte組成; F ( forbidden_zero_bit)(1bit) ,NRI ( nal_ref_idc)(2 bit), type ( nal_unit_type)(5bit)=>用於區分SPS(0x67) ;PPS(0x68);IDR_SLICE(0x65);SLICE(0x41)
forbidden_zero_bit. 在 H.264 規範中規定了這一位必須為 0.
nal_ref_idc. 取 00 ~ 11, 似乎指示這個 NALU 的重要性. 00表示NALU解碼器可以丟棄.
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
如果一個H.264的NALU是這樣的：
[00 00 00 01 67 42 A0 1E 23 56 0E 2F ...]
這是一個序列參數集 NAL 單元. [00 00 00 01] 是四個字節的開始碼, 0x67 是 NALU header, 0x42 開始的數據是 NALU 內容.
封裝成 RTP 包將如下:
[ RTP Header ] [ 67 42 A0 1E 23 56 0E 2F ]
即只要去掉 4 個字節的開始碼就可以了.
可用
Elecard解析frame
已前攝影機有 I-720p or I-1080p
所以I,P frame 來可能為 intersect(交錯送)
海思decode 分為
frame mode &
stream mode
正常
frame mode 為
I , p , p , p.....這樣收frame
所以餵進去decode 沒問題
但是
stream(intersect) mode可能是
I(半張),I(half),p(half#1),p(half#1),p(half#2),p(half#2).....
半張,半張,或一部分一部分 分開送
所以收入會破圖, 以前頻寬不夠,所以採此做法
