一、H.264編碼標(biāo)準(zhǔn)的背景：

視頻編碼標(biāo)準(zhǔn)的發(fā)展已經(jīng)有近40年的歷史了，在視頻編碼標(biāo)準(zhǔn)的發(fā)展中，國際電信聯(lián)盟(ITU)和運(yùn)動(dòng)圖像專家組(MPEG)這兩個(gè)組織具有舉足輕重的地位。

最早是視頻編碼標(biāo)準(zhǔn)H.120和H.261就是ITU在上個(gè)世紀(jì)80年代所制定，然后MPEG制定了MPEG-1，MPEG-1是以VCD之名被大家所熟知的編碼標(biāo)準(zhǔn)。

接下來兩大組織聯(lián)手成立了聯(lián)合視頻專家組(JVET)，聯(lián)合視頻專家組定了MPEG-2中的視頻部分，也被稱為H.262。MPEG-2是以DVD之名被大家所了解，可以說MPEG-2是迄今為止最成功的視頻標(biāo)準(zhǔn)之一。

后來ITU又制定了H.263標(biāo)準(zhǔn)，MPEG制定了MPEG-4，這兩個(gè)標(biāo)準(zhǔn)都沒有取得像MPEG-2這樣的成功。

然后兩大組織再次聯(lián)手（JVET）制定了H.264-AVC標(biāo)準(zhǔn)。H.264-AVC制定于2003-2006，到現(xiàn)在已經(jīng)近20年，卻依然在行業(yè)應(yīng)用占據(jù)了絕對(duì)的領(lǐng)先地位，是視頻編碼的首先標(biāo)準(zhǔn)。

一段30秒的簡單視頻的原始數(shù)據(jù)大概是1.24GByte，采用H.264 High Profile編碼后數(shù)據(jù)量減少到6MByte左右。壓縮比可達(dá)到1/200，在不降低太多主現(xiàn)質(zhì)量的前提下，大大減少了視頻的體積，節(jié)省了網(wǎng)絡(luò)傳輸流量消耗，減少了傳輸時(shí)延。

二、H.264的三大標(biāo)準(zhǔn)： 

• H.264 SVC 可適性視頻編碼（Scalable Video Coding, SVC）是傳統(tǒng)H.264/MPEG-4 AVC編碼的延伸，可提升更大的編碼彈性，并具有時(shí)間可適性（Temporal Scalability）、空間可適性（Spatial Scalability）及信噪比可適性（SNR Scalability）三大特性，使視頻傳輸更能適應(yīng)在異質(zhì)的網(wǎng)絡(luò)帶寬。

實(shí)際應(yīng)用中，存在不同的網(wǎng)絡(luò)和不同的用戶終端，各種情況下對(duì)視頻質(zhì)量的需求不一樣，利用可分級(jí)視頻編碼技術(shù)實(shí)現(xiàn)一次性編碼產(chǎn)生具有不同幀率、分辨率的視頻壓縮碼流，然后根據(jù)不同網(wǎng)絡(luò)帶寬、不同的顯示屏幕和終端解碼能力選擇需要傳輸?shù)囊曨l信息量，以此實(shí)現(xiàn)視頻質(zhì)量的自適應(yīng)調(diào)整。為了能夠?qū)崿F(xiàn)從單一碼流中解碼得到不同幀率（時(shí)間可分級(jí)）、分辨率（空間可分級(jí)）和圖像質(zhì)量（SNR可分級(jí)）的視頻數(shù)據(jù)的編碼技術(shù)，H.264 SVC以H.264 AVC視頻編解碼器標(biāo)準(zhǔn)為基礎(chǔ)，在編碼產(chǎn)生的編碼視頻時(shí)間上（幀率）、空間上（分辨率）可擴(kuò)展，并且是在視頻質(zhì)量方面可擴(kuò)展的，可產(chǎn)生不同幀速率、分辨率或質(zhì)量等級(jí)的解碼視頻。H264可分級(jí)視頻編碼采用分層編碼方式實(shí)現(xiàn)，由一個(gè)基本層（Base Layer）和多個(gè)增強(qiáng)層（Enhancement Layer）組成，增強(qiáng)層依賴基本層的數(shù)據(jù)來解碼。其中，基本層(base layer)編碼了基本的視頻信息，實(shí)現(xiàn)了最低圖像分辨率、幀率，并且基本層的編碼是兼容H264/AVC編碼標(biāo)準(zhǔn)的，能夠采用H264/AVC解碼器進(jìn)行解碼。 

在實(shí)時(shí)通迅中，SVC的落地有一定的困難，尤其server端的邏輯會(huì)變的更復(fù)雜。一般采用Simulcast+AVC（SAVC）的方式來實(shí)現(xiàn)可適性編碼，使業(yè)務(wù)更簡單化。

• H.264 MVC 多視角視頻編碼（Multiview video coding）

是在H.264標(biāo)準(zhǔn)當(dāng)中新增的內(nèi)容，其歷史淵源和概況可以參照《Overview of Multi-view Video Coding》這篇論文。在雙目3D視頻中，通常需要提供left/right view兩個(gè)視點(diǎn)的圖像，這兩個(gè)視點(diǎn)的圖像是有相關(guān)性的，同樣，對(duì)于多view視圖之間也是有一定相關(guān)性的，因此很自然的想法就是要利用view之間的相關(guān)性來提高壓縮效率，這就是MVC的目的。

三、H264算法流程

• H.264 編解碼流程主要分為 5 部分：
  • 幀間和幀內(nèi)預(yù)測(cè)（Estimation）
  • 變換（Transform）和反變換
  • 量化（Quantization）和反量化
  • 熵編碼（Entropy Coding）
  • 環(huán)路濾波（Loop Filter）主要用于濾除方塊效應(yīng)

• H.264編碼器流程圖，引用自http://www.rzrgm.cn/ioleon13/archive/2010/03/12/1684354.html

• H.264解碼器流程圖，引用自http://www.rzrgm.cn/ioleon13/archive/2010/03/12/1684354.html

四. H.264 AVC里的 I、B、P幀

在H.264 AVC編碼的過程中，部分視頻幀序列壓縮成為I幀，部分壓縮成P幀，還有部分壓縮成B幀。

• I幀又稱為內(nèi)部畫面 (Intra picture)，I 幀通常是每個(gè) GOP（Group of Pictures）的第一個(gè)幀，經(jīng)過適度地壓縮，做為隨機(jī)訪問的參考點(diǎn)，可以當(dāng)成圖像。

I幀法是幀內(nèi)壓縮法，也稱為“關(guān)鍵幀”壓縮法。 I幀法是基于離散余弦變換DCT（Discrete Cosine Transform）的壓縮技術(shù)，這種算法與JPEG壓縮算法類似。采用I幀壓縮可達(dá)到1/6的壓縮比而無明顯的壓縮痕跡。

I幀特點(diǎn):

1.它是一個(gè)全幀壓縮編碼幀。它將全幀圖像信息進(jìn)行JPEG壓縮編碼及傳輸;

2.解碼時(shí)僅用I幀的數(shù)據(jù)就可重構(gòu)完整圖像;

3.I幀描述了圖像背景和運(yùn)動(dòng)主體的詳情;

4.I幀不需要參考其他畫面而生成;

5.I幀是P幀和B幀的參考幀(其質(zhì)量直接影響到同組中以后各幀的質(zhì)量);

6.I幀是幀組GOP的基礎(chǔ)幀(第一幀),在一組中只有一個(gè)I幀;

7.I幀不需要考慮運(yùn)動(dòng)矢量; 8.I幀所占數(shù)據(jù)的信息量比較大。

• P幀:前向預(yù)測(cè)編碼幀。 P幀的預(yù)測(cè)與重構(gòu):P幀是以I幀為參考幀,在I幀中找出P幀“某點(diǎn)”的預(yù)測(cè)值和運(yùn)動(dòng)矢量,取預(yù)測(cè)差值和運(yùn)動(dòng)矢量一起傳送。

在接收端根據(jù)運(yùn)動(dòng)矢量從I幀中找出P幀“某點(diǎn)”的預(yù)測(cè)值并與差值相加以得到P幀“某點(diǎn)”樣值,從而可得到完整的P幀。

P幀特點(diǎn):

1.P幀是I幀后面相隔1~2幀的編碼幀;

2.P幀采用運(yùn)動(dòng)補(bǔ)償?shù)姆椒▊魉退c前面的I或P幀的差值及運(yùn)動(dòng)矢量(預(yù)測(cè)誤差);

3.解碼時(shí)必須將I幀中的預(yù)測(cè)值與預(yù)測(cè)誤差求和后才能重構(gòu)完整的P幀圖像;

4.P幀屬于前向預(yù)測(cè)的幀間編碼。它只參考前面最靠近它的I幀或P幀;

5.P幀可以是其后面P幀的參考幀,也可以是其前后的B幀的參考幀;

6.由于P幀是參考幀,它可能造成解碼錯(cuò)誤的擴(kuò)散 (error propagation) ; 7.由于是差值傳送,P幀的壓縮比較高。

• B幀:雙向預(yù)測(cè)內(nèi)插編碼幀。 B幀的預(yù)測(cè)與重構(gòu) B幀以前面的I或P幀和后面的P幀為參考幀,“找出”B幀“某點(diǎn)”的預(yù)測(cè)值和兩個(gè)運(yùn)動(dòng)矢量,并取預(yù)測(cè)差值和運(yùn)動(dòng)矢量傳送。

接收端根據(jù)運(yùn)動(dòng)矢量在兩個(gè)參考幀中“找出(算出)”預(yù)測(cè)值并與差值求和,得到B幀“某點(diǎn)”樣值,從而可得到完整的B幀。

B幀特點(diǎn):

1.B幀是由前面的I或P幀和后面的P幀來進(jìn)行預(yù)測(cè)的;

2.B幀傳送的是它與前面的I或P幀和后面的P幀之間的預(yù)測(cè)誤差及運(yùn)動(dòng)矢量;

3.B幀是雙向預(yù)測(cè)編碼幀;

4.B幀壓縮比最高,因?yàn)樗环从潮麉⒖紟g運(yùn)動(dòng)主體的變化情況,預(yù)測(cè)比較準(zhǔn)確;

5.B幀不是參考幀,不會(huì)造成解碼錯(cuò)誤的擴(kuò)散

因?yàn)锽幀會(huì)增加傳輸?shù)臅r(shí)延，實(shí)時(shí)通訊一般不用B幀，Openh264里也沒有實(shí)現(xiàn)B幀。 

五. IDR幀 （Instantaneous Decoding Refresh）

IDR 一個(gè)序列的第一個(gè)圖像叫做 IDR 圖像（立即刷新圖像），IDR 圖像都是 I 幀圖像。 I和IDR幀都使用幀內(nèi)預(yù)測(cè)。I幀不用參考任何幀，但是之后的P幀和B幀是有可能參考這個(gè)I幀之前的幀的。

IDR會(huì)導(dǎo)致DPB（DecodedPictureBuffer 參考幀列表）清空， 在IDR幀之后的所有幀都不能引用任何IDR幀之前的幀的內(nèi)容。 其核心作用是，是為了解碼的重同步，當(dāng)解碼器解碼到 IDR 圖像時(shí)，立即將參考幀隊(duì)列清空，將已解碼的數(shù)據(jù)全部輸出或拋棄，重新查找參數(shù)集，開始一個(gè)新的序列。這樣，如果前一個(gè)序列出現(xiàn)重大錯(cuò)誤，在這里可以獲得重新同步的機(jī)會(huì)。IDR圖像之后的圖像永遠(yuǎn)不會(huì)使用IDR之前的圖像的數(shù)據(jù)來解碼。

六. OpenH264 SVC里的 T0, T1，T2，T3幀

在碼流中，T0幀 61開頭， T1幀 01開頭，61優(yōu)先級(jí)最高。 

八. QP（quantization parameter）量化參數(shù)

量化參數(shù)qp_max過小，導(dǎo)致固定碼率控制失效。 Webex 360p QP取值范圍為 22~30。

QP值對(duì)應(yīng)量化步長的序號(hào)，為了避免在較高量化步長時(shí)的出現(xiàn)顏色量化人工效應(yīng)， H.264 規(guī)定，亮度 QP 的最大值是 51，而色度 QP 的最大值是 39。

值越小，量化步長越小，量化的精度就越高，意味著同樣畫質(zhì)的情況下，產(chǎn)生的數(shù)據(jù)量可能會(huì)更大。QP值每增加6，量化步長就增加一倍。其對(duì)應(yīng)關(guān)系如下表1。

九、H.264碼流的RTP分包格式 (參考RFC-3984)

• packetization-mode: SDP中的packetization-mode字段表示支持的封包模式.

packetization-mode = 0     一個(gè)NAL打成一個(gè)RTP包

packetization-mode = 1      多個(gè)NAL組合成一個(gè)RTP包 (SCR中，Cisco Teams都是用這個(gè)的)

packetization-mode = 2     一個(gè)NAL包可以分成多個(gè)RTP包

• H.264 RTP Payload格式分單NAL包和聚合包，參考：https://blog.csdn.net/yongkai0214/article/details/88872076
  • Single NAL Unit Packet

Effectively, fragmentation. A frame (or more generally, a Temporal Unit) is made up of a number of different OBUs (similar to NALUs).

These can be split across packets, including in the middle of an OBU, but not across frame boundaries.

十. 碼流分析的方法和工具

• H.264編碼格式 可參考http://www.rzrgm.cn/jiayayao/p/7086711.html
•  Wireshark H.264 插件，可從RTP包中提出H.264碼流。插件地址 https://github.com/volvet/h264extractor
• 分析碼流的工具：收費(fèi)的推薦 Elecard Stream Eye，好用但價(jià)格比較貴。免費(fèi)的有VLC和FFplay，可以播放碼流。
• SPS PPS：SPS/PPS里包含的信息，可以參考 http://www.rzrgm.cn/wainiwann/p/7477794.html
• 碼流的解析   參考http://www.rzrgm.cn/zoneofmine/p/10784276.html

SODB（String of Data Bits，數(shù)據(jù)比特串）：最原始，未經(jīng)過處理的編碼數(shù)據(jù)

RBSP（Raw Byte Sequence Payload，原始字節(jié)序列載荷）：在SODB的后面填加了結(jié)尾bit（RBSP trailing bits 一個(gè)bit ‘1’）若干bit ‘0’，以便字節(jié)對(duì)齊。

EBSP（Encapsulated Byte Sequence Payload, 擴(kuò)展字節(jié)序列載荷）：

NALU的起始碼為0x000001或0x00000001（起始碼包括兩種：3 字節(jié)(0x000001) 和 4 字節(jié)(0x00000001)，在 SPS、PPS 和 Access Unit 的第一個(gè) NALU 使用 4 字節(jié)起始碼，其余情況均使用 3 字節(jié)起始碼。）

同時(shí)H264規(guī)定，當(dāng)檢測(cè)到0x000000時(shí)，也可以表示當(dāng)前NALU的結(jié)束。那這樣就會(huì)產(chǎn)生一個(gè)問題，就是如果在NALU的內(nèi)部，出現(xiàn)了0x000001或0x000000時(shí)該怎么辦？

在RBSP基礎(chǔ)上填加了仿校驗(yàn)字節(jié)（0x03）它的原因是：在NALU加到Annexb上時(shí)，需要填加每組NALU之前的開始碼StartCodePrefix,如果該NALU對(duì)應(yīng)的slice為一幀的開始則用4位字節(jié)表示，0x00000001,否則用3位字節(jié)表示0x000001.為了使NALU主體中不包括與開始碼相沖突的，在編碼時(shí)，每遇到兩個(gè)字節(jié)連續(xù)為0，就插入一個(gè)字節(jié)的0x03。解碼時(shí)將0x03去掉。也稱為脫殼操作。

十一、展望

H.264是目前實(shí)時(shí)通迅中使用的首選的編碼方案，絕大多數(shù)硬件編解碼芯片都支持H.264 High Profile編解碼。在未來相當(dāng)長的一段時(shí)間內(nèi)，視頻會(huì)議仍然會(huì)主要使用H.264視頻壓縮技術(shù)，所以我們有必要學(xué)好H.264標(biāo)準(zhǔn)，最大程度的去發(fā)揮它的作用。

與此同時(shí)，我們也要時(shí)刻關(guān)注著AV1的發(fā)展。以Google為代表的開放媒體聯(lián)盟(AOM)，AOM制定的AV1標(biāo)準(zhǔn)，展示出超過H.265-HEVC的編碼性能，擁有豐富的編碼工具支持，可以極大地提高視頻的壓縮比，節(jié)省大量帶寬。同時(shí)，AV1 作為開放媒體聯(lián)盟 AOM 制定的第一代標(biāo)準(zhǔn)，除了有非常好的生態(tài)支持，還提供了免費(fèi)的專利政策，相比 H.265 / H.266 等知識(shí)產(chǎn)權(quán)政策不明確的視頻標(biāo)準(zhǔn)，有巨大的優(yōu)勢(shì)。清晰明確的專利政策也是 AV1 在產(chǎn)業(yè)界被推崇的一大優(yōu)勢(shì)。

在1080p、4k分辨率的視頻編碼上，AV1比H.264的Rate-distortation性能有明顯的提升，但代價(jià)是其算法復(fù)雜度也有數(shù)倍的增漲。目前Cisco Webex已經(jīng)將AV1用在桌面分享上，隨著AV1算法的不斷優(yōu)化和硬件算力的不斷提升，AV1會(huì)得到更廣泛的應(yīng)用。