完成一個H.265/HEVC碼串流分析工具

來源:互聯網
上載者:User

經過大約一個月左右的業餘時間,終於初步完成一個H.265/HEVC碼串流分析工具。時間包括平時的周末、晚上,以及調休的集中時間。當然,中秋回家過節不寫代碼。截至今天,經過多種H.265序列測試,也有各種工具對比,基本上無大問題,v2.0版本終於釋放出來。v1.x版本是去年年初做的,彈指間一年多的今天又繼續做。但後面也不知道有沒有時間和心情完善,隨緣吧。 一、背景

按慣例,每年年中的時候,公司都要講新平台預研,但不等預研結束,公司高層就開會舉手敲定一個新平台,而使得“預研”結束。今年主題之一是上H.265。第一個H.265標準在2013年1月出來,至今不夠3年時間,有很多公司盯上了這領域,勢頭很好,但畢竟只是開始的幾年,還是有待發展。

這種宣傳性的東西,估計產品經理、行業總監們要關注,咱們這些寫代碼的其實不用關心太多。但對於技術的研究、探索,還是很有必要的。網上已經有很多商用的工具開發出來了,在文章《初識HEVC/H.265》中提到一些。鑒於以前也寫了H264碼串流分析工具,從這方面入手會好一些,一來練練手,保持代碼熟悉度,二來在寫的過程對照標準手冊學習,效果比單看手冊好很多。於是就在原來工具基礎上,繼續做H265的分析。 二、思路

在文章《完成一個分析H264碼流的工具》中大概寫了一些思路,但不是很系統。這裡再寫一下。核心代碼為h264bitstream開源庫,它提供了一個很好的H.264碼流讀、寫的方案,而且開源。它提供了基本的讀寫碼流的介面。比如尋找NAL,指數哥倫布編碼等。因此,使用該開源庫,只需根據標準手冊裡的文法規定去一一解析即可。關於這個庫,不在此處詳細展開描述。

0、根據標準手冊文法,建立全域結構體,每個欄位都單獨儲存。所有結構體歸屬於h264_stream_t和h265_stream_t結構體。對於數量不確定的欄位,統一使用vector儲存。

1、使用者開啟檔案時,先判斷檔案類型,目前只支援H.264和H.265兩種格式,如有尾碼名,優先使用尾碼名判定,否則讀取檔案開始處的NAL頭,查看手冊,兩種碼流的NAL頭有差異,故可以使用該種方法。

2、按位元組讀取檔案,根據start code解析NAL,得到NAL位移量、長度、類型(如果是slice,還會解析出slice的類型,如I幀、P幀、B幀),儲存於vector中,同時,為了得到如視頻解析度,幀率、YUV空間等資訊,在解析NAL時,一併進行。做這些工作,是為了在介面的列表中列出各個NAL資訊以及視頻的概要資訊。詳見下文的介面截圖。

3、滑鼠雙擊某一個NAL時,根據前面得到NAL索引、位移,讀取檔案並解析,從而得到該NAL詳細資料,這裡使用的方法,就是根據手冊,逐一讀取碼流。 三、實現

此處講述一下在編碼、學習過程的經驗。

未動手寫代碼時,去下載商業工具玩玩,但只有幾天的試用期,就把幾個關鍵的NAL截圖儲存起來,方便日後對比。後面到期了,就拿HM的工程做對比,該工程開啟幾個宏就可以把運行過程的資訊列印出來,包括解析碼流的各個欄位。

然後按手冊的文法,參考h264bitstream代碼,建立H.265的對應結構體,基本上文法大的方面保持一致,但H.265多了一個VPS結構體,還有ptl(profile tier level)。添加這些文法,耗時很多,一來文法欄位本來就多,二來要對著手冊看——即使這樣,後面還是發現有個別錯誤、疏漏的。H.264/H.265有很多欄位是屬於數群組類型,根據某一數值來確定範圍。起初參考h264bitstream,數組統一使用255,但後來想想還是用Vector好一些,就改了。

讀取碼流完成了,列印欄位也完成了,再從宏觀上看整個工程,發現寫有亂。這次是在去年寫的工具上進行的,其實改善空間很大,只是自己懶,不去做。於是趁機會把代碼重構了,重構後條理性好了很多。

之後就進行調試。在這個過程,還是有不少問題。

有些是細節問題,比如有個地方判斷B幀,結果把“==”寫成“=”,查了半天才發現。還有一個地方是pred_weight_table的判斷,判斷P和B幀的條件不同,但代碼複製時不注意,沒搞對,又花了很久排查。還有一個是讀取slice頭部的num_ref_idx_l1_active_minus1欄位,同樣是代碼複製,沒有注意是ue(),在和HM代碼運行結果對比時,花了很多時間才確定問題。

列印NAL欄位函數裡,有些不按文法上寫,導致個別欄位和其它工具的不一致,於是又對著手冊改——開始時就應該如此,又是懶沒用心寫。

下面說說其它的問題。

解析NAL,是要將碼流轉換成RBSP,代碼工程統一使用h264bitstream提供的nal_to_rbsp函數,但該函數只針對只有一個位元組的H.264碼流的,而H.265的NAL頭有2個位元組。在轉換時是不包括NAL頭的,於是就手動修改該函數的參數。

關於SEI,h264bitstream庫並沒有做過多解析。或許是SEI資訊重要程度不高吧。還有一個問題。在PPS中,more_rbsp_data的判斷不正確。導致後面的欄位不再解析。幾經搜尋,最終使用FFMPEG代碼的判斷方法,似乎是正常的了,就不再深究。

而至於其它的修改、完善,我在另一篇文章《關於h264bitstream的bug修正及完善》裡寫了,這裡不再寫出了。 四、介面

無論怎樣,還是完成了。此事務算告一段落。介面如下:

原始碼倉庫地址為:https://github.com/latelee/H264BSAnalyzer。後續不確定是否要繼續維護、更新,以倉庫代碼為準。

後記:調休期間,有傳言說大大boss拍板停止調研某國產的支援H.265的晶片平台,但我沒有在正式場合得到資訊,不懂是否真實。在不確定是否上H.265時,我決定搞這個工具,在不確定是否停止H.265時,完成這個工具。有始有終。

2015.11.21的更新:

發布v2.1版本。使用樹形控制項顯示碼流文法元素。增加介面的縮放功能。離上個版本有差不多2個月了,理論上搞這麼個小功能不用花那麼久的,主要還是因為自己懶,一到周末就完全不想寫代碼了。新版本介面如下(一眼看上去,頓時覺得高端好多):


李遲 時值中華人民共和國成立66周年,祖國萬歲  

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.