許雪嬌 江蘇省廣播電視集團(tuán)有限公司

1．前言

隨著視頻技術(shù)的不斷發(fā)展，人們對(duì)視頻圖像質(zhì)量的需求越來(lái)越高，數(shù)字視頻傳輸對(duì)帶寬和存儲(chǔ)的要求越來(lái)越高。這不但提高了對(duì)信息的傳送、傳播和存儲(chǔ)速度的要求，更是對(duì)視頻圖像壓縮性能的考驗(yàn)。數(shù)字視頻的核心編碼標(biāo)準(zhǔn)在不斷地更新，國(guó)外視頻壓縮編碼的格式主要由二大組織制定。ITU-T視頻編碼專(zhuān)家組制定了H.26X，ISO/IEC運(yùn)動(dòng)圖像專(zhuān)家組制定了MPEG-X。HEVC/H.265是由以上兩大組織聯(lián)合制定的新一代高效視頻編碼標(biāo)準(zhǔn)，內(nèi)含先進(jìn)的編碼技術(shù)及并行處理能力，在相同編碼質(zhì)量條件下，比H.264/AVC能夠節(jié)約近50%左右的碼流利用率。

本文設(shè)計(jì)并完成了對(duì)H.265編碼視頻文件的深度分析。包括視頻基本信息（圖像長(zhǎng)寬、采樣方式、亮度和色度的采樣深度、幀數(shù)、層級(jí)信息等）、每個(gè)NALU基本信息（位置、字節(jié)長(zhǎng)度、NAL類(lèi)型、SLICE類(lèi)型）和RBSP內(nèi)容的詳細(xì)解析（H.265標(biāo)準(zhǔn)文檔目前定義了41個(gè)nal_unit_type的類(lèi)型，包括VPS、SPS、PPS、SEI、AUD 等）。

2．H.265碼流分析

在H.265編碼格式中，視頻文件被分為一個(gè)個(gè)NAL，為復(fù)雜的視頻數(shù)據(jù)增加友好的網(wǎng)絡(luò)接口。視頻壓縮數(shù)據(jù)根據(jù)其內(nèi)容特性被分成具有不同特性的NAL單元（NALU），并對(duì)NALU的內(nèi)容特性進(jìn)行標(biāo)識(shí)，即所有的壓縮視頻數(shù)據(jù)都被封裝到不同NALU的荷載部分。NALU除了承載VPS、SPS、PPS等信息，主要承載視頻片（Slice）的壓縮數(shù)據(jù)。每個(gè)NALU又分為NAL頭和NAL荷載。

表1　 H.265的NAL單元頭結(jié)構(gòu)

2.1　NAL頭結(jié)構(gòu)

H.265的NAL單元頭（nal unit header）與H.264的單元頭不同，H.264只有一個(gè)字節(jié)，而H.265的碼流開(kāi)頭是00000001，后面跟兩個(gè)字節(jié)的nal_unit_header，H.265的NAL單元頭結(jié)構(gòu)如表1所示。

NAL頭由固定的4部分構(gòu)成，分別是forbidden_zero_bit，nal_unit_type， nuh_layer_id 和 nuh_temporal_id_plus1，各自占用 1，6，6，3個(gè)比特。其中nal_unit_type占6個(gè)比特，意味著它的取值從0-63，每個(gè)編號(hào)代表不同的NALU類(lèi)型，如32代表視頻參數(shù)集VPS，35代表定界AUD。

2.2　NAL荷載

在H.265編碼文件中，各個(gè)不同類(lèi)型的NALU具有不同的NAL荷載，各NALU的類(lèi)型由NAL頭中的nal_unit_type決定。根據(jù)nal_unit_type的不同，可分為：VPS，SPS，PPS，SEI，AUD，EOS，EOB等。視頻在編碼過(guò)程中輸出的包含不同內(nèi)容的壓縮數(shù)據(jù)比特流片段被稱(chēng)為SODB。事實(shí)上，SODB指的是RBSP中的有效成分，去掉了RBSP結(jié)尾中為了取整的數(shù)字零。RBSP中可以包含一個(gè)SS的壓縮數(shù)據(jù)、VPS、SP、PPS以及補(bǔ)充增強(qiáng)信息等。

在H.265編碼視頻的碼流中，每一個(gè)NALU以0x000001作為起始碼，以0x000000作為結(jié)束碼。這就帶來(lái)了一個(gè)問(wèn)題，在NAL荷載中一旦出現(xiàn)上述的字節(jié)流，就會(huì)造成沖突，使一幀意外結(jié)束。為了解決這個(gè)問(wèn)題，H.265編碼規(guī)定將所有RBSP中非起始、結(jié)束碼的，會(huì)產(chǎn)生沖突的比特流作如下處理：

其中，0x000002為預(yù)留碼。需要注意的是，當(dāng)RBSP數(shù)據(jù)的最后一個(gè)字節(jié)為0x00時(shí)，在數(shù)據(jù)結(jié)尾會(huì)加入0x03。

3．軟件整體設(shè)計(jì)

本H.265碼流分析軟件流程框圖見(jiàn)圖1。根據(jù)文件編碼格式判斷文件類(lèi)型，對(duì)于判斷類(lèi)型為H.265的視頻文件，由幀頭的起始碼來(lái)決定如何將視頻文件按幀分片，在一幀的數(shù)據(jù)中先讀取該幀中nal_unit_type的值，根據(jù)取值判斷該幀所屬的類(lèi)型。然后對(duì)提取出的幀數(shù)據(jù)進(jìn)行處理，按照幀的類(lèi)型分別將此幀中的各個(gè)語(yǔ)法元素提取并分類(lèi)存儲(chǔ)，包括在視頻參數(shù)集（VPS）中提取檔次和級(jí)別，在序列參數(shù)集（SPS）中提取圖像格式，量化信息，在片段（SS）中提取幀類(lèi)型等等，所有幀都依此進(jìn)行處理并保存生成的語(yǔ)法元素樹(shù)。

圖1　H.265碼流分析軟件流程框圖

圖2　視頻文件結(jié)構(gòu)和對(duì)應(yīng)的程序框圖

H.265視頻文件結(jié)構(gòu)和對(duì)應(yīng)的程序如圖2所示。H.265編碼的視頻碼流將壓縮視頻數(shù)據(jù)封裝成不同類(lèi)型的NALU，即所有的壓縮視頻數(shù)據(jù)都被封裝到不同NALU的荷載部分。在界面層獲取碼流信息時(shí)，先要將其分割成一個(gè)個(gè)NALU。對(duì)于每一個(gè)被分割的NALU而言，要分為三部分進(jìn)行處理。首先是NAL頭部分（NAL_Header），需要判斷該NAL的類(lèi)型，序號(hào)，參考幀等等。類(lèi)型信息在每幀的nalType參數(shù)中。其次，要根據(jù)NAL頭中判斷出的類(lèi)型，對(duì)NAL荷載進(jìn)行處理，將RBPS數(shù)據(jù)讀取進(jìn)來(lái)以后，根據(jù)各自的編碼特點(diǎn)，用類(lèi)BitReader進(jìn)行處理。最后，根據(jù)前兩步處理好的數(shù)據(jù)，用TreeMaker類(lèi)來(lái)生成每個(gè)NALU的樹(shù)形圖。

程序中依照實(shí)現(xiàn)的功能主要分為Stream處理，NalUnit處理，Bit處理和TreeNode生成這幾大模塊，程序模塊劃分如圖3所示。Stream類(lèi)負(fù)責(zé)初步處理一個(gè)視頻文件，生成視頻信息并掃描所有NALU信息。

首先對(duì)STREAM進(jìn)行初始化，將文件所有內(nèi)容讀取至_byteFile字節(jié)數(shù)組內(nèi)，提取讀到的數(shù)據(jù)中第一個(gè)NAL的第一個(gè)字節(jié)，由前文的幀結(jié)構(gòu)可以得知，每個(gè)NAL的第一個(gè)字節(jié)的第1-7個(gè)比特中含有該文件的類(lèi)型信息，如果nalType屬于在0和47之間的任意整數(shù)，則判斷類(lèi)型為H.265格式。判斷完文件類(lèi)型后返回，若文件類(lèi)型錯(cuò)誤，軟件將給出WARNING警告。以上功能由JudgeVideoFile類(lèi)實(shí)現(xiàn)。所有數(shù)據(jù)讀入數(shù)組后，將獲取所有NALU并生成NALU對(duì)象。具體流程是先將指針pos復(fù)位，用循環(huán)讀取持續(xù)_byteFile，邊讀邊判斷每個(gè)NAL的起始字節(jié)，如果讀到01則查看01與它之前是否滿(mǎn)足0001或001，變量out用于返回這個(gè)NAL的起始字節(jié)數(shù)。以上功能由FindNextNal類(lèi)實(shí)現(xiàn)。

圖3　程序模塊劃分

Stream處理的流程方法如圖4所示。ScanNalu()函數(shù)主要負(fù)責(zé)掃描_byteFile并分析其中所有NAL。首先定義新指針pos，將其指向第一個(gè)NAL的起始位置。如果指針位置為負(fù)數(shù)，則返回false，找不到NAL。用循環(huán)搜索下一個(gè)NAL，每搜索到一個(gè)新的NAL，就新建一個(gè)NALU對(duì)象，將指針數(shù)組指向該NAL的開(kāi)頭位置，用讀出的下一個(gè)NAL的開(kāi)頭位置減去這一個(gè)NALU的開(kāi)始位置，計(jì)算出這個(gè)NALU的長(zhǎng)度。記錄下長(zhǎng)度及NAL的內(nèi)容傳遞給NAL對(duì)象的_byteNALU變量，將此NAL加入_lstNALU中，最后指針指向下一個(gè)NAL，循環(huán)直到處理完成所有的碼流。當(dāng)所有NAL都讀取完畢后，此時(shí)可以將stream信息生成文字內(nèi)容以備輸出界面調(diào)用。

Nalu處理（NALU類(lèi)）包括NAL Header解析和rbsp解析兩部分功能，其中rbsp解析功能根據(jù)header中的type類(lèi)型，調(diào)用不同的模塊進(jìn)行解析（VPS,SPS,PPS,SEI,SS等）。

圖4　Stream處理流程圖

在對(duì)NALU解析時(shí)，要先進(jìn)行準(zhǔn)備工作，首先對(duì)NALU類(lèi)進(jìn)行定義。在每個(gè)NALU類(lèi)中含有基礎(chǔ)信息包括序號(hào)，長(zhǎng)度，偏移，文本說(shuō)明，start code的長(zhǎng)度；碼流信息包括存放NAL的字節(jié)數(shù)組，RBSP字節(jié)數(shù)組；文本格式的NAL字節(jié)顯示等等。

將NALU進(jìn)行初始化，新建一個(gè)BitReader的對(duì)象_bitNALU，將NAL的字節(jié)數(shù)組傳入，指針指向第一個(gè)比特，為防止顯示界面雜亂，如果此NALU超過(guò)5000字節(jié)，則只需將前5000字節(jié)放在待顯示的位置，接著處理NAL頭的數(shù)據(jù)，此處調(diào)用BitStream中已經(jīng)編寫(xiě)好的函數(shù)即可。為了避免幀中的數(shù)據(jù)和起始碼形成沖突，每個(gè)NAL中的RBSP都做了預(yù)處理，在讀取數(shù)據(jù)中的語(yǔ)法元素時(shí)，需要先將其恢復(fù)。

上述處理方法在NaluToRbsp程序段中有所體現(xiàn)，從byteNALU的起始位之后開(kāi)始檢測(cè)，count用來(lái)記錄0x00連續(xù)出現(xiàn)的個(gè)數(shù)，每當(dāng)讀取到0x03則判斷，不允許出現(xiàn)00000102這樣的組合，且03之后的一位不應(yīng)該大于03。如果判斷出沖突則將其記錄并更改，否則跳過(guò)這個(gè)0x03位。這樣，在將NALU轉(zhuǎn)換成RBSP的同時(shí)也檢測(cè)出了這些“競(jìng)爭(zhēng)機(jī)制”并進(jìn)行還原，以方便接下來(lái)的操作。

對(duì)nalType進(jìn)行判斷，調(diào)用BitStream中對(duì)應(yīng)的解析方法處理數(shù)據(jù)。此處以VPS為例，如果CASE語(yǔ)句判斷出該NAL的NAL_UNIT_TYPE為32，對(duì)應(yīng)的類(lèi)型就是視頻參數(shù)集VPS，程序轉(zhuǎn)到處理VPS的函數(shù)處繼續(xù)運(yùn)行。

具體類(lèi)型讀取方法，以讀取一個(gè)普通的SLICE為例，參考H.265標(biāo)準(zhǔn)文件《T-REC-H.265-201504-I!!PDF-E》中第7.3.6.1 節(jié)General slice segment header syntax中對(duì)碼流格式的定義，圖5說(shuō)明了讀取數(shù)據(jù)的流程。

讀取一個(gè)新的SS時(shí)，首先要將指針POS復(fù)位，指向第0個(gè)比特位。首先根據(jù)H.265編碼定義表判斷第一個(gè)語(yǔ)法元素有沒(méi)有前置判斷因素，是否由于前面的FLAG標(biāo)識(shí)而導(dǎo)致這個(gè)元素不存在，如果該元素存在，就根據(jù)編碼方法選擇讀取方式。如果是固定比特位，就調(diào)用BitReader中的函數(shù)ReadU1()或者ReadU3()等等；如果是不固定比特位數(shù)，則分為兩種情況，無(wú)符號(hào)零階熵編碼調(diào)用BitReader中的函數(shù)ReadUE()，有符號(hào)零階熵編碼調(diào)用BitReader中的函數(shù)ReadSE()。該語(yǔ)法元素讀取完畢，指針POS移動(dòng)至該語(yǔ)法元素末尾，如果指針已經(jīng)移動(dòng)到整個(gè)片段SS的末尾，即將整個(gè)片段SS讀取完畢，如果是，則整個(gè)流程結(jié)束，如果沒(méi)有讀取完畢，則繼續(xù)循環(huán)讀取下一個(gè)語(yǔ)法元素，直到讀取完畢為止。

在讀取過(guò)程中，需要注意片段中slice_type表達(dá)的片段的類(lèi)型，slice_type類(lèi)型對(duì)照如表2所示。

由于H.265提升了編碼的效率，同樣的信息可以引用前面已經(jīng)表述的內(nèi)容，不用重復(fù)編碼，所以，大多數(shù)幀都有對(duì)前面幀的引用。在分析當(dāng)前SS的程序中，要注意SS引用PPS的ID號(hào)和從PPS可找到引用的SPS的ID號(hào)。在編碼中引用的內(nèi)容被省略了，但是，程序在翻譯編碼時(shí)要將其翻譯出來(lái)。

BitReader類(lèi)中包括字節(jié)流-比特流轉(zhuǎn)換模塊和比特流信息讀取模塊兩部分功能。這個(gè)類(lèi)更多的是提供輔助性的功能，實(shí)現(xiàn)了byte字節(jié)數(shù)組轉(zhuǎn)為bit數(shù)組的方法，將所有碼流由十六進(jìn)制轉(zhuǎn)換為二進(jìn)制數(shù)據(jù)，為其他部分的讀取數(shù)據(jù)提供方便。

同時(shí)，由于在H.265視頻編碼的規(guī)則中，每個(gè)語(yǔ)法元素并不是以字節(jié)為單位進(jìn)行表達(dá)，而是以非整數(shù)字節(jié)的零散比特位為單位。所以，在BitReader類(lèi)中，還提供了一些以比特為單位讀取數(shù)據(jù)的函數(shù)，如ReadU()/ReadU1()/ReadUE()/ReadSE()等方法調(diào)用。在H.265視頻編碼的規(guī)則中，使用了一些不定比特?cái)?shù)的語(yǔ)法元素，它們被稱(chēng)為零階指數(shù)哥倫布編碼，讀取這類(lèi)語(yǔ)法元素時(shí)，必須根據(jù)編碼特點(diǎn)，單獨(dú)用函數(shù)讀取。

在H.265視頻編碼標(biāo)準(zhǔn)中，由于語(yǔ)法元素是層層歸屬的，在表現(xiàn)形式上，比起常規(guī)的表格或是圖片，更傾向于展現(xiàn)語(yǔ)法元素的歸屬關(guān)系。而樹(shù)形結(jié)構(gòu)是典型的層次的嵌套結(jié)構(gòu)，一個(gè)樹(shù)形結(jié)構(gòu)的外層和內(nèi)層有相似的結(jié)構(gòu)，在編碼中更是能以遞歸的形式展現(xiàn)，所以本軟件采用了樹(shù)型結(jié)構(gòu)來(lái)表達(dá)語(yǔ)法元素的歸屬關(guān)系。

圖5　讀取數(shù)據(jù)流程圖

表2　 slice_type類(lèi)型對(duì)照表

TreeMaker類(lèi)包括了一個(gè)公有方法MakeTree()和多個(gè)nodeMaker模塊，可根據(jù)傳入的NALU對(duì)象來(lái)生成對(duì)應(yīng)的TreeView節(jié)點(diǎn)用以直接在界面中顯示。在TreeMaker類(lèi)中，只要將tree調(diào)用，即可實(shí)現(xiàn)軟件右下角的展現(xiàn)每幀的語(yǔ)法元素的功能。

最后在用戶(hù)界面中，主要實(shí)現(xiàn)了將H.265視頻文件讀入，顯示NAL列表的信息，以十六進(jìn)制顯示原始碼流，顯示STREAM流基本信息和以樹(shù)形結(jié)構(gòu)圖顯示任一NAL的語(yǔ)法元素分布這5種功能。軟件編輯界面示意圖如圖6所示。

在程序運(yùn)行和軟件進(jìn)行交互的過(guò)程中，為了完成用戶(hù)發(fā)出的指令，常常不可避免地需要從一個(gè)線(xiàn)程中調(diào)用另一個(gè)線(xiàn)程，而這種操作在C#中是絕不允許的，因?yàn)镃#的編程邏輯認(rèn)為這樣操作會(huì)出現(xiàn)循環(huán)調(diào)用，一旦程序的邏輯出現(xiàn)問(wèn)題，就將陷入死循環(huán)。所以，軟件采用了一種特殊的邏輯。以TreeView界面的更新為例，當(dāng)軟件操作觸發(fā)了TreeView的調(diào)用時(shí)，首先判斷這是否為界面線(xiàn)程的調(diào)用，當(dāng)一個(gè)控件的InvokeRequired屬性值為真時(shí)，說(shuō)明有一個(gè)創(chuàng)建它以外的線(xiàn)程想訪問(wèn)，如果判斷為真的話(huà)，就新開(kāi)辟一個(gè)線(xiàn)程，再調(diào)用一次TreeView的更新函數(shù)，這時(shí)，由于之前已經(jīng)開(kāi)辟過(guò)一個(gè)新的線(xiàn)程，不會(huì)產(chǎn)生沖突，所以程序會(huì)轉(zhuǎn)到TreeView真正的更新程序上運(yùn)行。程序?qū)崿F(xiàn)的方法如圖7所示。

圖6　軟件編輯界面示意圖

圖7　調(diào)用新界面線(xiàn)程

其他更新界面進(jìn)行顯示的程序中，使用的方法是類(lèi)似的，這里不做贅述。

4．軟件的調(diào)試和分析

軟件完成后，用20多個(gè)不同大小的文件對(duì)軟件進(jìn)行了測(cè)試，文件格式有hm10，h265和bin兩種，都是官方指定的H.265格式文件。文件大小從十幾K到幾兆不等。

在測(cè)試到suzie_qcif.h265文件，點(diǎn)選第4幀NAL_UNIT_PREFIX_SEI，生成該幀語(yǔ)法元素樹(shù)狀圖時(shí)，程序沒(méi)有響應(yīng)。推測(cè)該處程序陷入死循環(huán)中，在TreeMakeer.cs的C#程序段中，找到了出錯(cuò)的程序。在程序進(jìn)行到制作SEI的樹(shù)狀圖時(shí)，轉(zhuǎn)到了函數(shù)MakeSEINode中，首先添加了sei_payload這個(gè)語(yǔ)法元素，對(duì)payloadType進(jìn)行判斷，不同的payloadType值會(huì)添加不同的數(shù)節(jié)點(diǎn)。但針對(duì)出錯(cuò)的這個(gè)視頻文件來(lái)說(shuō)，第四幀中的payloadType取值為5。原程序中只是在樹(shù)中添加了user_data_unregistered()節(jié)點(diǎn)，將程序擴(kuò)充并修改后，添加了2個(gè)三層的子節(jié)點(diǎn)，使得樹(shù)狀圖中此節(jié)點(diǎn)可以被展開(kāi)，從而消除錯(cuò)誤。

最后經(jīng)核對(duì)，修改過(guò)錯(cuò)誤的本軟件和商業(yè)化的H.265分析軟件Elecard HEVC Analyzer得出的結(jié)論完全相同，所以，本軟件均成功通過(guò)樣例測(cè)試。

5．結(jié)束語(yǔ)

本文提供了H.265編碼方式的詳細(xì)分析和基本設(shè)計(jì)思路。根據(jù)本文提供的思路和方法，可以完成一個(gè)清晰簡(jiǎn)潔的H.265分析軟件，得到視頻文件的幀基本信息、語(yǔ)法元素信息和STREAM流信息，并將幀的樹(shù)狀結(jié)構(gòu)圖與原碼流信息進(jìn)行對(duì)比查看，為研究H.265編碼方法提供了方便。

參考文獻(xiàn)：

[1]萬(wàn)帥,楊付正.新一代高效視頻編碼 H.265/HEVC：原理、標(biāo)準(zhǔn)與實(shí)現(xiàn)[M].北京：電子工業(yè)出版社.2014：22-94,230-237,269-291.

[2]H.265標(biāo)準(zhǔn)文檔《T-REC-H.265-201504-I!!PDF-E》