人間觀察
我好像還什么都沒有準備好，就到了而立之年的年紀，不是吃一個糖就能開心的年紀了。
前面我們了解了H264/AVC的一些知識。今天我們看H265 , 只有了解了這些基礎的，什么協議（flv等）啦，什么封裝格式（mp4等）啦，網絡傳輸啦等都是很有幫助的。
背景知識
H265 又被叫做HEVC（全稱叫做 Hight Efficiency Video Coding，高效率視頻編碼），它同H264一樣也是ITU-T和ISO兩個組織共同制定的視頻壓縮標準，是H264/AVC標準的繼承者。
H265/HEVC是面向更高清晰度、更高幀率、更高壓縮率視頻的協議標準，是一套標準組織制定的視頻壓縮標準、規范。
為什么會有h265
說白了就是人們對視頻的要求清晰度越來越高，而在有限的帶寬下保證視頻的質量是很難的。對于2k,4k的高清視頻來說在存儲空間和網絡帶寬有限的情況下，現有的視頻壓縮技術已經不能滿足現實的應用需求。為了解決高清及超高清視頻急劇增長的數據率給網絡傳輸和數據存儲帶來的沖擊，所以有了具有更高壓縮效率的新一代視頻壓縮標準H265/HEVC。
標清：480x800
普通高清：720x1280 720P
高清：1920x1080 1080P
2K：2048*1024
超高清 4K：3840x2160
嗯，說白了，就是需求導致，然后產生的標準。ok，我們看一下技術上：
(1) 視頻畫面要求更高（如上），視頻流暢度要求更高，幀率從30fps到60fps甚至更高，會導致H264的如下情況：
- 宏塊(MB)個數爆發式增加
- 宏塊內容的復雜度升高
- 運動矢量數值的大幅度增加
(2) 由于H264本身的缺點
由于宏塊級壓縮視頻的處理過程，很久沒有改變了，還是2003年發布的實現方式，它的壓縮算法沒有調整。
H265延續了H264的很多定義，兩個都是基于宏塊的視頻編碼技術，h265是在H264的基礎上進行了一些強優化。比如：
- 以宏塊來劃分圖像，并最終以塊來細分。
- 使用幀內壓縮技術減少空間冗余
- 使用幀間壓縮技術減少時間冗余（運動估計和運動補償）
- 使用轉換和量化來進行殘留數據壓縮
- 使用熵編碼來減少殘留，運動矢量傳輸和信號發送中的最后冗余。
上面的描述太過于官方了，但是我這里還是參考一些書籍寫下了（怕有遺漏造成理解偏差/知識的丟失就不好了），上面的這些技術都是編碼器的內部實現，都是算法。我也知道這些概念而已，至于如何實現的我還清楚，我覺得我還沒有到達到這一步，前幾天看到了阿里淘系的音視頻團隊有自己的編碼器實現，叫奇點編碼器，還是覺得很厲害的。
H265的碼流結構
H265 的碼流結構和H264的結構類似
網絡分層結構
和H264/AVC結構類似，H265/HEVC也采用了視頻編碼層（video code layer ，簡稱VCL）和網絡適配層（network abstract layer，簡稱NAL）.VCL層包含了視頻壓縮的數據， NAL主要負責對數據的壓縮數據進行劃分和封裝，保證數據在磁盤上保存和網絡上進行傳輸。
和h264的碼流結構一樣，也是通過啟始碼（0x000001或者0x00000001）進行分割壓縮數據，每一個稱為NAL單元（NAL Unit，簡稱NALU）。NALU有不同的類型，主要是對數據內容進行區分。
對于一個碼流文件來說，和h264一樣，有一系列的NALU的類型定義，可以分為VPS,SPS,PPS,SEI,I幀,P幀 6種類型。碼流結構如下所示：
啟始碼+VPS+啟始碼+SPS+啟始碼+PPS+啟始碼+SEI+啟始碼+I幀+啟始碼+P幀+啟始碼+P幀+.....
如上就是一個圖像系列的組成，為什么這么說呢？ 一般我們在網絡上發送數據，比如采集端一般在發送壓縮數據的I幀前先發送VPS,SPS,PPS。解碼端不可能先啟動后等著發送端數據到來吧，只有解碼器拿到VPS,SPS,PPS后才可以解碼H265的數據。VPS，SPS,PPS，SEI，一個I幀，一個P幀都可以常委一個NALU。
從上面可以看到h265比h264多了一個VPS，VPS是視頻參數集。
我們這里看一下經過h265編碼器編碼后的碼流文件，截取文件開頭的數據，
因為h265碼流最開始永遠是VPS，SPS,PPS，可能含有SEI，后面接著是I幀P幀數據。
16進制打開文件如下：
0000 0001 4001 0c01 ffff 0160 0000 0300 // 4001
b000 0003 0000 0300 5aac 0900 0000 0142 // 4201
0101 0160 0000 0300 b000 0003 0000 0300
5aa0 0442 00f0 77e5 aee4 c92e a520 a0c0
c05d a142 5000 0000 0144 01c0 e30f 0330 // 4401
840a 0000 0001 2601 af0b e075 8d53 b010 // 2601
af65 bfb4 0b53 823d e91c ad66 f973 ce21
5d92 9227 9159 3dc6 2cae 5adf 4cda f9b5
6105 3165 97cd 64cd f04d 09d5 5e10 d231
// ...省略其它數據
2f04 c9cc 1e01 700a 0000 0001 0201 d08f // 0201
// ...省略其它數據
單元NALU的結構
可以看到上面的數據和h264一樣，H265的NALU的結構也是：啟始碼+ NALU頭+NALU數據。
如果NALU對應的Slice為一幀的開始（即視頻流的首個NALU）就用0x00000001，否則就用0x000001。
- 啟始碼：是一個固定值4個字節
00 00 00 01（十六進制）或者3個字節00 00 01（十六進制） - NALU的頭大小為2個字節，第1位是0，第2-7位是NALU的類型，表示該NALU的數據內容是什么類型的，是VPS，SPS,PPS，SEI，I幀還是P幀。第8-15位是1
- NALU的數據就是編碼器編出來的圖像信息或者圖像壓縮數據了
NALU的nal_unit_type官方文檔所示：
可以上面的文件數據片段中可以計算出6種NALU的頭類型nal_unit_type，取2個字節的2-7位即可。計算方法：
// 0x7E的二進制的后8位是 0111 1110
int naluType = (byteOffset & 0x7E) >> 1
byteOffset就是00 00 00 01或者00 00 01后面的2個字節。
- VPS（視頻參數集）NALU的頭值為0x4001（十六進制），取出2-7位
（40 & 0x7E）>>1 =32(十進制) - SPS(序列參數集)NALU的頭值為0x4201（十六進制），取出2-7位
（42 & 0x7E）>>1 =33(十進制) - PPS(圖像參數集)NALU的頭值為0x4401（十六進制），取出2-7位
（44 & 0x7E）>>1 =34(十進制) - SEI(補充增強信息)NALU的頭值為0x4e01（十六進制），取出2-7位
（4e & 0x7E）>>1 =39(十進制) - I幀 NALU的頭值為0x2601（十六進制），取出2-7位
（26 & 0x7E）>>1 =19(十進制) - P幀 NALU的頭值為0x0201（十六進制），取出2-7位
（02& 0x7E）>>1 =1(十進制)
NALU的類型官方文檔所示：
RBSP的結構
H265的 RBSP（raw byte sequence payload）和H264的一樣。
NAL 根據送壓縮數據的規則，可以封裝稱不同的NALU, NALU包含VPS,SPS,PPSl類型信息，還包含視頻片（Slice）的壓縮數據，包含壓縮的NALU被稱為VCLU(VCL NALU)，包含其它信息的壓縮數據的NALU,則被稱為non-VCLU(non-VCL NALU)。
H265下的NALU包含兩部分數據結構：NALU頭（header）和負載（payload），NALU頭長度為固定的2字節，反應NALU的內容特征，而NALU的負載長度為整數字節，包含視頻壓縮后的原始字節序列負載RBSP（raw byte sequence payload）。RBSP是對視頻 編碼后的原始比特流片段SODB（string of data bits）進行添加尾部（添加比特1，以湊足整字節）的包裝。
同樣在H265中，為了避免字節流片段和NALU的啟起碼及結束碼發生沖突，需要對RBSP的字節流進行沖突處理0x3，經過處理后的rbsp才可以直接作為NALU的負載信息，才可以進程磁盤保存和網絡傳輸。
關于沖突和RBSP的結構的結構可以參考之前的h264碼流分析文章：
Android音視頻【二】 H264碼流結構
H265遠比此篇介紹的復雜的多，如果哪里不正確，歡迎指正。
H265官方文檔，可以下載里面的pdf文件：
https://www.itu.int/rec/T-REC-H.265-201911-I/en
