整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
文引用了微信公眾號“鮮棗課堂”的《視頻編碼零基礎入門》文章內容。為了更好的內容呈現，引用和收錄時內容有改動，轉載時請注明原文來源信息，尊重原作者的勞動。
如今我們所處的時代，是移動互聯網時代，也可以說是視頻時代。從快播到抖音，從“三生三世”到“延禧攻略”，我們的生活，被越來越多的視頻元素所影響。
而這一切，離不開視頻拍攝技術的不斷升級，還有視頻制作產業的日益強大。
此外，也離不開通信技術的飛速進步。試想一下，如果還是當年的56K Modem撥號，或者是2G手機，你還能享受到現在動輒1080P甚至4K的視頻體驗嗎？
除了視頻拍攝工具和網絡通信技術升級之外，我們能享受到視頻帶來的便利和樂趣，還有一個重要因素，就是視頻編碼技術的突飛猛進。
視頻編碼技術涉及的內容太過專業和龐雜，市面上的書籍或博客多數都只是枯燥的技術概念羅列，對于新手來說讀完依舊蒙逼是常態，本文將借此機會，專門給大家做一個關于視頻編碼的零基礎科普。
▼ 本文涉及概念較多，為了方便閱讀，本文的內容目錄對應如下：
1、引言
2、系列文章
3、圖像基礎知識
3.1）什么是像素？
3.2）什么是PPI？
3.3）顏色在計算機里是如何表示的？
4、視頻編碼基礎知識
4.1）視頻和圖像和關系
4.2）未經編碼的視頻數據量會有多大？
4.3）什么是編碼？
5、視頻編碼的實現原理
5.1）視頻編碼技術的基本原理
5.2）視頻編碼技術的實現方法
6、視頻編碼的國際標準
6.1）視頻編碼格式的標準化
6.2）視頻數據的封裝
（本文同步發布于：http://www.52im.net/thread-2840-1-1.html）
家久等了，這是多媒體文件格式系列課堂文章的第三篇，前面已經講過了容器與音頻編碼，現在我們要看到最為復雜的視頻編碼了，人們一直在想盡辦法提高視頻編碼的效率，讓它在盡可能小的體積內提供最好的畫面質量，從而滿足人們對于視頻傳輸、存儲的需求。和前兩篇文章中介紹的容器與音頻編碼不同的是，視頻編碼有一條較為清晰的發展脈絡，比種類繁多且不統一的音頻編碼要容易理順，目前國際通行的視頻編碼標準基本上都是由MPEG（動態圖像專家組）和ITU-T（國際電信聯盟電信標準化部門）等組織牽頭開發的，另外還有一些零星的編碼，它們可能在一段短暫的時間內占據主流地位，不過最終還是讓位于國際通行標準。
國際上主要通行的編碼標準為ITU-T組織的H.26x系列視頻編碼和MPEG組織制定的部分編碼標準，有一點需要說明的是，同樣的一個標準在不同組織那兒可能會叫成不同名字，比如最典型的就是AVC（高級視頻編碼），大家可能更熟悉它的另一個名字——H.264，AVC是MPEG組織在標準中給它起的名字，MPEG組織從屬于國際標準化組織（ISO）和國際電工委員會（IEC），所以在ISO標準中，它的正式名字是“MPEG-4 Part 10, Advanced Video Coding”。這種情況多見于H.26x系列編碼，下文會注出。
而在這條主要脈絡中，基本上囊括了接近半個世紀以來，視頻編碼的技術發展，我們將主要沿著H.26x以及MPEG這條主要脈絡，為各位讀者簡單梳理出一條視頻編碼的發展歷程。
很簡單，就是為了減小視頻占用的容量大小。
數字視頻實質上就是一幀幀連續的圖像，雖然一幀圖像的大小并不大，但每秒至少得有24幀圖像（一般情況），它們累計起來就會占據非常大的空間，我們沒有那么多的地方存儲原始數據，那么只有一條路可以走，對它進行壓縮。而視頻的編碼過程就是這個壓縮過程，但與音頻一樣，在傳統數據壓縮算法來看視頻文件里面基本上是沒有什么冗余信息的，所以人們就有必要去開發針對視頻的壓縮算法，把實際存在的冗余信息給去掉，從而減少它的數據量，達到減小占用容量的目的。因此，目前的視頻編碼基本上都是有損的，意味著編碼過后的視頻在畫面質量上會有損失。
讓我們首先沿著國際標準，按時間順序來看看視頻編碼是怎么一步一步“現代化”的。
在模擬電視和膠片電影時代，我們看到的內容都是模擬信號還原出來的。但隨著人們的需求不斷提高，和計算機、網絡的蓬勃發展，我們需要新的、能夠承載視頻內容的數字編碼，用來支持視頻內容在互聯網上的傳輸，或是將其存儲在數字化的存儲設備中。
在上世紀七十年代末八十年代初的時候，人們已經研究出了不少新的針對圖像等多媒體內容的壓縮算法，此時開發數字視頻編碼的條件已經基本成熟，而第一個開發出實際編碼的，就是后來在數字視頻編碼領域中起領頭作用的視頻編碼專家組（VideoCodingExpertsGroup），他們是當時名字還是“國際電報和電話咨詢委員會（CCITT）”的ITU-T（國際電信聯盟電信標準化部門）組織下面的專家組。這個編碼被命名為H.120，它誕生于1984年，是一種偏向于實驗性質的早期編碼，主要基于差分PCM編碼，用來保存電視內容，但是它并沒有大規模的實際運用。
在制定完H.120過后幾年，VCEG并沒有停止他們在視頻編碼上面的研究。此時很多跨國公司已經使用網絡進行視頻會議的需求了，在互聯網帶寬尚不充裕的年代里，人們需要新的視頻編碼來實現流暢而優質的實時視頻通信，H.261就應運而生了。
H.261與首個數字視頻編碼標準H.120并沒有直接的繼承關系，它可以說是完全另起爐灶的一種編碼。在針對圖像的壓縮算法上，H.261使用了我們現在比較熟悉的離散余弦變換（DCT）算法， 它在后來的JPEG編碼中起主要作用。但不止于此，它引入了一系列針對視頻的特性，奠定了現代視頻編碼的基礎，其中主要有宏塊（Macroblock）和基于宏塊的運動補償（Motion Compensation）。
我們知道，視頻是由一幀一幀的圖像組成的組合，一般情況下一秒鐘的視頻中會包含24、25、30、60或更多張圖片，它們按照一定的時間間隔播放出來，基于視覺殘留原理形成了流暢、會動的畫面。在連續的幾幀之間，實際上存在著大量重復的畫面，比如說下面這個例子：
一個白色臺球在綠色桌面上面運動
用小球運動的方向和距離來描述圖像的變化
如果是以傳統的思路對每一幀圖像做壓縮的話，顯然整個視頻在壓縮過后仍存在大量的冗余。那么怎么辦呢？H.261標準引入了宏塊的思維，它將整個畫面切分為許多小塊，然后再引入基于運動補償的幀間預測——畫面的大部分都是不動的，那么我們將不動部分的區塊沿用之前的壓縮結果，動的部分用運動方向加距離這樣一個矢量來描述不就可以節省出大量的存儲空間了嗎？
將8x8個像素分成一個塊
DCT算法起源于上世紀70年代，到了80年代中后期，有研究者開始將其用于圖像壓縮。這種算法可以將圖像從空間域轉換到頻率域，然后做量化——減少人眼敏感程度較低的高頻信息，保留絕大部分低頻信息，從而減少圖像的體積。最后再用高效的數據編碼方式將處理過后的數據進一步壓縮，這里使用了Zig-Zag掃描和可變長編碼。
注：圖像的高頻部分存有很多細節信息，而低頻部分則存有輪廓等覆蓋范圍較大的信息。
亮度通道做DCT變換后的圖像，可以看到上方顏色連續部分非常平坦，而下方則擁有諸多細節
在H.261及之后基于H.261框架的視頻編碼中，DCT算法主要針對的是關鍵幀的壓縮，所謂關鍵幀，就是在運動補償中作為基準參考的一幀。打個比方，就像Flash動畫中的關鍵幀一樣，它定義了一個起點，后續的幾幀都是基于這個關鍵幀演算出來的。因為它只做幀內壓縮，不涉及其他幀，又被稱為Intra-frame（幀內編碼幀），簡稱I幀。
H.261設計的目標是編碼出比特率在64~2048kbps范圍內的視頻，以用于實時的視頻電話等應用。它首次確立了幀內預測與幀間預測同時使用的編碼框架，在消除每一幀本身存有的冗余外，消除了幀與幀之間的冗余信息，從而大幅度降低了碼率，成為了實際可用性相當高的一種視頻編碼。而它的編碼框架也影響到了之后幾乎所有的視頻編碼，尤其是H.26x和MPEG家族。
需要說明的是，H.261只是規定了該如何解碼，只需要編碼器最終產生的視頻流可以被所有H.261解碼器順利解碼即可。至于你前面怎么編碼的，具體用的算法如何不同都沒有關系，這點適用于之后幾乎所有的視頻編碼。
幾乎在H.261開發的同時間，1988年，ISO和IEC兩大國際標準化組織建立了MPEG（動態圖像專家組，MovingPictureExpertsGroup）以開發國際標準化的音視頻壓縮編碼。他們在1992年11月份完成了MPEG-1整套標準的制定，其中的第二部分標準化了一個新的視頻壓縮編碼，它受到H.261的深刻影響，繼承和發展了分塊、運動補償、DCT算法等思想，并做出了自己的改進，比如引入新的雙向預測幀、亞像素精度的運動補償等新技術。
H.261引入基于運動補償的幀間預測算法之后，視頻中的幀其實就已經分成兩類了，一類是完整的，稱為關鍵幀（Intra-frame），它就是一張完整的靜態圖像，可以直接被解碼出來。另外的幀則是通過運動補償算法在關鍵幀之上計算得到的。
MPEG-1 Part 2引入了幀類別的概念，原來的關鍵幀被稱為“I幀”，基于幀間預測計算得到的幀為P幀。在這兩種H.261已有的幀類型外，它引入了一種新的幀：雙向預測幀，也叫作B幀。
原本的P幀只能夠前向預測，也就是說，它只能夠基于前一幀計算得到。雙向預測，顧名思義，它可以用前面的一幀作為自己的參考，也可以用后面那幀來進行預測。由于參考了更多的信息，B幀自身就可以包含更少的信息量，其壓縮比自然就要比只能做單向預測的P幀還要高了。但是，B幀的引入帶來了一個新的問題，即編解碼難度上升了。
幀序列是一些按順序排列的圖像幀的組合，簡稱為GOP。一個GOP的頭部是一個I幀，也只會有一個I幀，它包含了該GOP的基準參考圖像信息，其后是數個P幀、B幀，它們都是以開頭的I幀為基礎，經過計算得到的。
上面的圖片就描述了一個完整的GOP，可以看到一個I和P幀之間隔了三個B幀。實際應用中，B幀確實是數量最多的幀類型。
H.261中引入的幀間預測精度為像素級的，對很多分塊的運動瞄準是不精確的，這點在MPEG-1上得到了有效改進。他們引入了亞像素級別的運動補償，可以以1/2像素級別描述像素塊的運動。
MPEG-1成功地繼承了H.261的技術框架，并對其進行了有效的補充，從而達成了不錯的壓縮比。在那個人們普遍還在用VHS錄像帶的年代里，MPEG-1已經能夠以1~2Mbps的碼率提供類似于VHS錄像帶的畫質了。這也使得它被選用為VCD的標準，在世界范圍，尤其是在我國風行十余年。
不過MPEG-1主要面向低碼率應用，但實際上它在高碼率下的表現也不差，于是，MPEG很快推出了它的升級版本，也就是MPEG-2。
1994年推出的MPEG-2中標準化了一種新的視頻編碼，它在1995年被ITU-T接納為H.262，在這里我們簡單稱它為MPEG-2。相對于1993年推出的MPEG-1，它并沒有太大的改動，主要是針對DVD應用和數字時代進行了改良。
隔行掃描放在今天也并不是過時的概念，在九十年代初期，這種掃描方式有效降低了視頻傳輸所需的數據帶寬。平常我們看到的視頻畫面大部分都是逐行掃描（Progressive scan）的，比如說視頻的垂直分辨率為1080像素，那么每幀畫面的垂直分辨率就是1080像素。
而隔行掃描，顧名思義就是隔一行掃一次，它將每一幀畫面拆分成兩個場，每個場保留原有幀一半的信息。這種掃描方式在保證畫面流暢度的同時降低了對傳輸帶寬的需求，被各國的電視廣播系統采納使用。MPEG-2在制定時充分考慮到了數字電視系統的需求，加入了對隔行掃描的支持。
從上世紀90年代開始，數字電視系統逐漸開始普及，它帶來了更大的傳輸帶寬。同時，DVD標準也快要塵埃落定，它提供了比CD大幾倍的容量，能夠承載更為清晰的畫面。因此，MPEG-2提升了自己的目標碼率范圍，從MPEG-1時代的1~2Mbps實際豪爽地倍增到6~10Mbps，甚至在高清時代，它能夠用20Mbps左右的碼率傳輸高清畫面。
MPEG-2雖然沒有加入太多新的特性，在壓縮率方面實際沒有太大的提升，但由于它被選中成為DVD-Video、數字電視、DV等等一系列應用的標準編碼，順利地成為了世界范圍內通行的視頻編碼格式，時至今日，它仍然被大量地應用在數字電視等系統中。
原先的H.261和MPEG-1都是偏向于低碼率應用的，隨著互聯網和通訊技術的飛速發展，人們對網絡視頻的需求在提高，在低碼率下追求更高質量的視頻成為了新的目標，而作為通信業的一大標準制定者，ITU-T在1995年推出了H.261的直接繼承者——H.263。
H.263有多個版本，在1995年推出的初版中，它主要引入了在MPEG-1上開始應用的亞像素精度運動補償，同樣支持到1/2像素的精度。另外它改進了使用的DCT算法，加入了新的運動向量中值預測法，在編碼效率上相比H.261有較為明顯的提升。
需要注意的是，以上特性僅僅是它的基礎部分，只需要實現這些新東西就算是支持H.263了，但它還給出了一系列額外的、用于增強壓縮率的特性，比如說，在MPEG-1中新增的B幀，到了H.263中成了額外的PB幀。
H.263是一個被不斷升級的編碼，在初版之后還存在H.263+和H.263++兩個官方升級版。在H.263+中，它著重提升了壓縮率，相對初版有15~25%的總體提升。同時在2001年的修訂中，它還引入了“Profile”的概念，將各種特性分成幾個級別，完整支持某一級別的特性即為支持此Profile，比如說，初版H.263的基礎部分是它的“Baseline”Profile。
H.263在互聯網和通信業中得到了廣泛的應用，它一度活躍在各種視頻網站上面，和Flash播放器一起撐起了互聯網在線視頻的一片天，而在通信業中，被3GPP組織采納成為多種通信標準中的標準視頻編碼，比如說MMS——也就是彩信。
另外它還被MPEG組織參考，作為MPEG-4 Part 2的基礎。
在MPEG-2之后，MPEG組織有了新的目標——開發一套壓縮率更高的編碼框架，但同時保留對低復雜性的支持。1998年，MPEG-4標準正式誕生，其中第二部分定義了一套新的視覺編碼體系，是的，它并不是僅僅針對于視頻應用，而是廣泛意義上的視覺（Visual），故也被稱為MPEG-4 “Visual”。
它的核心設計實際上與H.263趨同，但是包含了更多關于編碼效率的增強。它定義了復雜度不同的多種Profile，從最基本的Simple Profile到非常復雜的Simple Studio Profile，前者不支持B幀，而后者甚至支持到4K分辨率和12-bit、4:4:4采樣的編碼。
盡管MPEG-4 Visual是一個野心勃勃的編碼，但它遭到了業界的冷待和批評。一個是它的壓縮率相比起MPEG-2并沒有重大提升，而因為授權和專利費用問題，很多廠商選擇自己去實現一套兼容MP EG-4 Visual的編碼，而不是直接采用標準，這其中就有經典的DivX和Xvid兩兄弟，微軟也拿它作為Windows Media Video的基礎，一點點升級到WMV9。
時間已經來到二十一世紀，高清視頻和高清電視開始普及，新的應用帶來了更高的需求，迫使業界開始研究新的更高效的視頻編碼，我們熟知的AVC即將登場，不過在介紹它之前，我們先來看看其他幾個有較多應用的視頻編碼。
JPEG想必大家都很熟悉，這個MJPEG跟JPEG之間有著千絲萬縷的關系。視頻不是一幀一幀的嗎？那每一幀都用JPEG進行壓縮，然后組合起來不就行了嗎？是的，MJPEG就是一個JPEG圖像組合，每一幀包含了完整的圖像信息，正因為如此，它的壓縮率并不高，但是實現起來簡單的特點讓很多數碼相機廠商將它作為相機的視頻編碼，實際上它得到了相當廣泛的利用。
對于國人來說，RealMedia絕對是一個帶有情懷的詞語。他們家的RM系列編碼在十多年前在國內網絡上曾有相當的覆蓋度。實際上它的實現基本上都是參考同時期的國際標準而來的，比如說清晰度和壓縮比都很高，壓過同時期DivX一頭的rv40是參考了H.264而形成的。
RM最大的問題還是支持范圍不廣，在瀏覽器中播放RM需要插件，基于Flash播放器的視頻網站的興起也讓它的用途逐漸變得狹隘，最終在正版H.264的沖擊下，RM慢慢的銷聲匿跡了。
微軟有自己的客廳夢想，除了Xbox以外，他們想讓PC走進客廳，當然這都與Windows Media Video無關。微軟基于MPEG-4 Part 2創造出了一系列新的編碼，起初它們都被稱為Microsoft MPEG-4或是Microsoft ISO MPEG-4，但很快，微軟將其歸入了Windows Media家族，首個版本是WMV7。
接下來微軟在WMV7的基礎上面不斷加入自家的東西，使得它能夠適應更高分辨率的視頻，最后，他們在WMV9中加入了新的Profile，產生了新的VC-1編碼。
在DVD普及之后，高清視頻的時代很快就到來了。人們很快發現，就算是雙層DVD，其容量對1080p視頻來說，也是完全不夠用的。很快，大公司開發出了兩種新的以藍光為激光束的光盤，一種是以DVD論壇為首開發的HD DVD，另一種是Sony牽頭另起爐灶的Blu-ray。兩種光盤格式的戰爭我們按下不表，這里要講的是，伴隨著新光盤制式一起出現的全新視頻編碼標準——VC-1和H.264。
HD DVD和Blu-ray的標準里一共支持了三種視頻編碼，其一是古老的MPEG-2，其二是微軟主推的VC-1，最后一種就是全新的AVC。別看它的名字很簡單，其實它大有來頭，是MPEG和ITU-T兩個組織聯合推出的新一代國際標準，在MPEG那兒被規范為MPEG-4 Part 10 Advanced Video Codec，在ITU-R那兒它又被標準化為H.264。
對于H.264這個名字，我想大家應該都不會耳熟。但就是這個現在我們每天都能夠接觸到的視頻編碼格式，曾在十多年前引發了一場軟解危機，將當時很多主流CPU挑落馬下，也使得ANI三家都在自己的產品中加入了輔助解碼的硬件加速單元，不過這與我們的主題沒什么關系，暫且按下不表。這里要講的，還是H.264的厲害之處，究竟它用了什么手段能夠在編碼質量上面實現飛躍，從而獨占市場十余年時間還沒呈現衰退跡象。
總結下來主要有如下的幾點：更靈活的宏塊劃分方法、數量更多的參考幀、更先進的幀內預測和壓縮比更高的數據壓縮算法。
之前的標準中，宏塊的劃分方法是固定的，以16x16個像素為一個宏塊。不過在新時代，這種粗放的劃分方法不夠靈活，于是H.264同時允許16x8、8x16、8x8、8x4、4x8和4x4這些精細度更高的劃分方式。同時H.264將亞像素精度的運動補償描述從1/2像素精度細化到了1/4的程度。這樣一來，在幀間預測中新的編碼擁有更高的精準度，但實際的數據量并不會增加太多，提高了壓縮率。
在以前的標準中，每個B或P幀可參考的幀數是有限且數量過少的，H.264一舉將限制放松到了16幀的程度，在大部分應用場景中，每幀的可參考幀數量至少都有4~5個，而在之前的標準中，P幀僅能參考1幀，B幀則是2。這一特性可以提高大多數場景的畫面質量，或是降低體積。
每個宏塊包含的預測模式信息
對于I幀，H.264也引入了新的壓縮方式。一般來說，對于圖像中的某一像素點，它與附近相鄰的像素的顏色是差距不大的，所以我們就可以利用這個特性進一步縮小單幀圖像的大小，怎么利用呢？H.264將單個宏塊內的像素顏色變化規律規范成了公式，編碼時只要寫此處應用哪個公式就行了。當然這里我表述的較為簡單，完整的幀內預測還是非常復雜的，H.264對4x4的宏塊規定了9種預測模式，對16x16的亮度平面宏塊規定了4種可用模式。大大減少了單幀圖像的數據量，同時保持了很高的圖像質量。
差分圖像加上預測信息可以還原出原始圖像
在編碼的最后階段，對數據進行無損壓縮時，H.264除了支持在H.261中就存在的VLC編碼外，新增加了兩種無損數據壓縮編碼，一種是VLC的升級版——CAVLC，另一種是復雜程度更高的CABAC（前文參考之適應性二元算術編碼，Context-basedAdaptiveBinaryArithmeticCoding）。
CABAC也是一種熵編碼，主要原理也是用長編碼替換掉出現頻率少的數據，而用短編碼替換出現頻率高的數據，但它引入了更多統計學優化，并且具有動態適應能力。雖然在解碼時需要更多計算，但它能夠比CAVLC節省更多的數據量，通常能有10%。
除了以上介紹的幾點外，H.264還有非常多的新特性，與MPEG-4 Visual不同的是，這些新特性有效地幫助H.264在節省容量方面取得了重大進展。這里我舉一個有強烈對比的例子，DVD Video標準的視頻，采用的是MPEG-2編碼，碼率約在9Mbps左右，但它的分辨率僅為720x480，而且在某些場景下我們可以很明顯看到有損壓縮產生的破壞；而同樣的碼率，放在H.264上面，已經可以承載起1080p的視頻，并且擁有良好的質量。
除了在編碼效率上有重大提升外，H.264針對網絡傳輸的特性對編碼組織方式進行了優化，讓它更能夠抗丟包，抗干擾。在種種手段之下，它成為了近十年來統治視頻領域的編碼，并且可以說它已經成為了HTML 5中的事實標準，現在你很難看到一件不支持H.264編碼的設備，從手機到攝像機，從流視頻到藍光光盤，它的應用范圍廣，效能強，即使在新編碼已經出現的當下，它仍然有很強的生命力和不可替代性，可以預見的是，H.264將在未來一段時間內繼續統治視頻編碼領域。
進入高清時代后，微軟也順應潮流，為WMV9進行了升級，加入了針對高清視頻的新特性，讓它能夠勝任1080p級別的高清視頻，新的編碼即為VC-1。與H.264相比，VC-1總體的復雜程度要低一些，也因此在軟解上對CPU更加友好。實際上VC-1也通過了國際組織SMPTE的標準化。
VC-1與HD DVD有一定的捆綁關系，在藍光大戰初期也通過這種方式得到了一定的推廣。然而，隨著HD DVD陣營的認輸，VC-1也隨之銷聲匿跡，很難再看到了。
H.264很強大，但是它在超清時代有點不夠用了。隨著視頻分辨率的跨越式提升，H.264表現出了疲態，它在應對4K視頻時已經沒有辦法提供很好的壓縮比了。很明顯，人們需要新的編碼來繼承它的位置，而它的直接繼承者——HEVC，在經過多年研究之后，終于在2013年被通過了。
HEVC，全稱高效視頻編碼（HighEfficiencyVideoCoding），同樣的，它也是由MPEG和ITU-T聯合制定的國際標準編碼。被包含在MPEG-H規范中，是為第二部分（Part 2），在ITU-T那兒，它是H.26x家族的新成員，為H.265。
HEVC主要是針對高清及超清分辨率視頻而開發的，相比起前代AVC，它在低碼率時擁有更好的畫質表現，同時在面對高分辨率視頻時，也能提供超高的壓縮比，幫助4K視頻塞入藍光光盤。
HEVC引入了新的編碼樹單元（CodingTreeUnits）概念，取代掉了存在于視頻編碼中多年的宏塊概念，它的單塊面積大了許多，達到了64x64，但仍然保留了可變大小和可分割特性，最小單元為16x16。單個編碼樹中包含了小的編碼單元，它們可以由四分樹形式呈現，并很快地可以確定下其中的單元是否可被再分割，內部編碼單元最小可以被分割為8x8大小，精細程度仍然是非常高的。
單個編碼單元也可以繼續被切割、分類，可以成為預測單元（Prediction Units），后者可以指示該單元的預測形式，是畫面內預測還是畫面間預測或者甚至是根本沒有變化、可以被跳過的單元；也可以成為轉換單元（Transform Units），它可以做DCT轉換或是量化。
編碼樹單元的引入讓HEVC既可以用大面積單元來提高編碼效率，也可在需要的時候細化，保留更精細的細節。所謂該粗略的地方就粗略，該精細的地方就精細，HEVC在它的幫助下讓碼流的效率更高。
既然分塊的最大面積大了，那么DCT算法也需要跟上才行，HEVC將DCT算法的最大尺寸擴大到了32x32的地步，對于圖像中變化較為平坦的部分，它有著更高的壓縮率。
還記得上面寫到H.264為4x4宏塊引入了9種幀內預測方向嗎？HEVC直接把這個數字提升到了33種，在靜態圖像的壓制上不僅實現了更高的效率，也實現了更高的精度，這也是它成功殺入靜態圖像編碼市場的一大利器。雖然編碼難度變高了，但只要用硬件編碼器就沒有那么多問題。
相較于AVC，HEVC在高分辨率下的編碼效率又有非常大的提升，舉個實例，同樣一段4K視頻，使用H.264編碼的大小可能會比使用HEVC大出個一倍。這種巨大的進步幅度也使得Blu-ray直接用它作為標準編碼，推出了UHD BD，而它在單幀圖像壓縮上面的改進也讓它擁有勝過JPEG的能力，于是我們看到在移動端，越來越多的設備選擇將其作為默認的視頻、照片輸出編碼。
但是相比起AVC，HEVC的推廣速度慢了很多，一個是它的編解碼難度比H.264高了太多，但這點通過各路硬件編碼器和軟件優化逐漸化解掉了，目前常見的設備基本上支持HEVC的硬件編解碼；第二個就是HEVC高昂的專利費用問題，它并不是一個免費的編碼格式，雖然個人使用它完全沒有問題，但對于想要兼容它的廠商來說，這筆高昂的專利費用足以讓他們卻步，尤其是崇尚自由開放的互聯網市場。于是，我們看到眾多廠商選擇了免費開放的VPx系列編碼，以及系列的后繼者——AV1。
VPx系列編碼實際上已經有很長的歷史了。它的前身是On2 Technologies公司的TrueMotion系列視頻編碼，在開發TrueMotion VP8編碼時，公司被Google收購了。在Google的介入下，VP8從原本的專有技術變成了開放技術，在BSD許可證下面進行開源。
從技術角度來說，VP8采用的技術是類似于H.264的。雖然在我們看到的宣傳中，VP8擁有比H.264更佳的壓縮效率，但在實際應用中，由于它在設計上有一定的瑕疵，表現并不如H.264，最終它雖然進入了Web標準，但也沒見有人用它，反而是由它的幀內壓縮技術提取而成的WebP受到了歡迎。
VP8的表現并不理想，Google很快就推出了它的繼任者——VP9。這次，他們參考的是HEVC，設計目標同樣是高分辨率下的高效編碼。VP9中的一些設計是受到了HEVC的影響的，比如說同樣最大為64x64的超級塊（Super Block）。最終VP9達成的結果是提供了比VP8高達50%的效率提升。看起來它能夠和HEVC比肩了，但是它也遇到了和VP8相似的問題，推廣不開。VP9的應用范圍實際也局限在Google自家的Youtube中，只能說是缺少實際應用場景。
但很快，一些廠商認識到HEVC高昂專利費用帶來的弊端，他們決定創立一個開放聯盟，推廣開放、免費的媒體編碼標準。這個聯盟就是開放媒體聯盟（Alliance forOpenMedia），創始成員有Amazon、Cisco、Google、Intel、Microsoft、Mozilla和Netflix這些我們熟悉的大公司，而后加入的還有蘋果、ARM、三星、NVIDIA、AMD這些同樣耳熟能詳的公司。
Google將他們還在開發中的VP10貢獻了出來作為聯盟新編碼的基礎，很快，名為AV1的編碼誕生了。在Facebook的測試中，它分別比VP9和H.264強上34%、46.2%，這次看上去是真的達到HEVC的級別了。
在這兩年中，AV1也確實開始得到廠商們的重視，比如說最近Netflix已經確定了要使用AV1作為主力編碼，而Intel也推出了開源免費的SVT-AV1編碼器，充分利用自家的AVX-512指令集。但是這種聯盟還是相當松散的，比如說聯盟成員之一的蘋果，目前對AV1根本是無動于衷，旗下設備中全部轉向HEVC。
不過從Netflix決定使用AV1作為主力編碼這種態度來看，AV1免費、開放的特性還是具有相當的吸引力的。但目前在硬件方面是缺乏對它的支持的，不僅是PC端沒有針對AV1做硬件解碼，數量更多的移動設備也沒有適配，前不久剛有一款宣傳是首個加入對AV1硬件解碼的SoC才發布。對比起硬件支持較為齊全的HEVC，這將是AV1推廣之路上的一道檻。
目前MPEG和VCEG已經開始研究HEVC的繼任者了，目前我們知道的信息是，它暫時被命名為Versatile Video Coding（多才多藝視頻編碼），并將會成為H.266。它是面向于未來視頻的編碼，將會支持從4K到16K分辨率的視頻壓縮，并且支持360°視頻，它的目標是在HEVC的基礎上將編碼效能提升一倍。
未來它可能加入的新特性有：更為復雜的編碼單元結構；更大、更細致的區塊劃分；全局幀參考；更多的幀內預測模式（目前已經有65種）……在復雜度上面，相比HEVC，VVC將會直接高出一個維度。但是國際標準目前面對著以AV1為代表的開放標準的挑戰，很難說他們會不會取消掉部分特性，從而將它正式發布的時間給提前。
顯示器、電視的分辨率越來越高，網絡帶寬越來越大，設備對于多媒體內容的處理能力越來越強，視頻編碼也一直隨著時代的變化而不斷進步著，但是它的框架從H.261開始就未曾有過重大的變化，只不過每個新編碼都在這個既定框架下利用半導體性能的成長而加入新的更為高效的算法。比起進步并不明顯的音頻編碼，新視頻編碼在帶寬與容量上面提供的節約效果要明顯得多了，甚至更新的編碼在畫質表現上也更有優勢。在不遠的未來，10-bit色深和HDR將會普及，在根本上取代掉還是上世紀標準的SDR內容，為我們帶來更為精彩的視覺體驗。諸如HEVC這樣的編碼實際早已做好了準備，在未來，它們的應用場景甚至將突破視頻領域，就以新的蘋果設備為例，HEVC實際已經成為它的標準編碼格式，通行于圖像和視頻領域中。
另外，根據最新的報告，當前互聯網流量中占大頭的就是視頻流量，隨著流媒體繼續深入日常生活，用于視頻傳輸的流量只會更大，而互聯網的總體帶寬并不是可以無限提升的，對于內容提供方來說，流量費用也是相當一部分開銷，壓縮效率更好的編碼自然也會受到他們的青睞。實際上，編碼不斷升級這件事情是雙贏的，用戶和內容提供方都可以從中獲利。
由于時間與作者個人能力限制，本篇文章也存在諸多的不足，但我仍然想通過對這些編碼的概述讓更多人了解到正確的編碼知識，如果能夠起到拋磚引玉的作用，讓更多人對編碼產生興趣，開始自己的研究，那是最好不過的事情了。
網頁中添加視頻、聲音、動畫等，可以增強用戶體驗。在HTML5之前，為網頁添加多媒體的唯一辦法，就是使用第三方的插件（如，Adobe Flash等）。
HTML5中，提供了對多媒體的原生支持，只需通過 video 元素，就可以向網頁嵌入視頻、電影或音頻資源，通過 audio 元素向網頁嵌入音頻資源，省時省力。
HTML中嵌入視頻和音頻代碼
在HTML5時代，在網頁中嵌入視頻非常簡單，只需要一個 video 元素，并設置它的 src 屬性，使其鏈接一個視頻地址就可以完全搞定了，這個太esay了
<video src="media/vedio.mp4"></video>
把這個網站在IE8中打開一看，網站上除了一片空白外，什么也沒有，這是為什么呢？
原來 video 是HTML5最新引入的元素，并不是所有瀏覽器都支持它，IE8及以下版本都無法識別 video 標簽。如果瀏覽器不識別 video標簽，則會忽略它，當做什么都沒有。這就是網站上一片空白的原因。
這個問題好解決，只需在 video 標簽之間放置文本信息，不支持 video 標簽的老瀏覽器，會顯示 video 標簽之間的文本信息，以提示用戶瀏覽器不支持 video，就這么簡單！
<video src="media/vedio.mp4">
你的瀏覽器已經老掉牙了，不支持video，還不趕快使用現代瀏覽器O(∩_∩)O~！
</video>
在IE8上打開一看，確實顯示了提示文本，這下好多了，至少用戶知道自己的瀏覽器不能播放視頻，該換瀏覽器了。
下載了Opera瀏覽器的最新版本25.0，打開一看，怎么還是一片空白外！Opera瀏覽器明明是支持video標簽的，那又是為什么呢？
這個就得從視頻的編碼格式說起了。video 元素支持三種視頻格式：Ogg、MP4、WebM。
Ogg是帶有Theora視頻編碼和Vorbis音頻編碼的文件，后綴名為 .ogg；MP4是帶有H.264視頻編碼和AAC音頻編碼的MP4文件，后綴名為 .mp4；WebM是VP8視頻編碼和Vorbis音頻編碼的文件，后綴名為 .webm。
這個Opera瀏覽器呢，它可以支持ogg，但不支持mp4。由于Opera支持video標簽，故video標簽之間的文本信息沒有顯示出來，但它不支持ogg，所以就不進行播放，最終導致頁面出現一片空白。這下可怎么辦呢？
其實辦法有的是，我們可以從網上下載一副圖像，放到視頻播放窗口，如果視頻無法播放，就顯示這張圖片，是不是更好呢？從網上下載一張美女圖片，干脆叫beauty.jpg吧。那這個圖像怎么添加到視頻窗口呢？
video標簽有個poster 屬性，就是專門在視頻窗口放置圖片的。poster是一個video的占位符，無論什么情況下，只要視頻還沒有播放（視頻下載過程中、視頻不存在、不支持該視頻類型、用戶點擊播放按鈕前），就會顯示該圖像，可以看做是視頻播放之前插入的宣傳畫或海報。
<video src="media/vedio.mp4" poster = "img/beauty.jpg">
你的瀏覽器已經老掉牙了，不支持video，還不趕快使用現代瀏覽器O(∩_∩)O~！
</video>
在Opera瀏覽器上刷新一下，真的有一個美女沖著自己微笑呢。雖然視頻沒有播放出來，這回心情卻是好多了。
那我可不能一天到晚只看美女呀，視頻還是還是要想辦法播放出來的。既然Opera瀏覽器不支持mp4，我們就換成需要ogg吧，這樣就肯定沒問題了。
我想了想，這個辦法不好，萬一某個瀏覽器只支持支持ogg，不支持mp4呢。這年頭，什么都缺，就是不缺點子，隨便在網上一搜，辦法就有了。
在 video 元素中添加 source 元素，就可以解決這個問題。在source 元素中，通過 src 屬性指定視頻的地址，通過 type 屬性指定視頻的類型，以幫助瀏覽器決定是否能播放該視頻。并且，在 video 元素中可以添加任意多個source 元素，讓不同的 source 元素鏈接到不同的視頻文件。
這樣的話，當瀏覽器發現 video 元素時，首先會查看它本身是否定義了 src 屬性。如果沒有，就會檢查 source 元素。瀏覽器會逐個查看這些視頻源，直到找到一個可以播放的視頻。一旦找到，就會播放它并忽略其他的視頻源。我們干脆添加兩個source，一個是mp4，一個是ogg，這下視頻是一定能播放出來了。
<video poster = "img/beauty.jpg">
<source src="media/vedio.mp4" type="video/mp4">
<source src="media/vedio.ogg" type="video/ogg">
你的瀏覽器已經老掉牙了，不支持video，還不趕快使用現代瀏覽器O(∩_∩)O~！
</video>
在Opera瀏覽器上又刷新一下，只有美女沖著我微笑，視頻還是沒播放出來。唉，太粗心了，忘記添加播放視頻的控件了。
在video標簽中，通過添加controls 屬性來為視頻添加播放控件，方便用戶執行播放、暫停操作和音量控制。
<video poster = "img/beauty.jpg" controls>
（此處略去500字…）
</video>
在Opera瀏覽器上又刷新一下，效果真的不一樣，這次不僅看到美女，還看到了視頻控件。用鼠標猛戳一下那個播放按鈕，哈哈，不錯，真的聽到美妙的旋律。我們的ogg文件，終于播放出來了，讓我們好好享受一下吧O(∩_∩)O。
聽了一會，忽然一想，不對呀，我剛才點了播放按鈕后，等了半天才聽到聲音。能不能我一點播放按鈕，就立即播放呢？
原來視頻也是需要下載緩存的，點擊播放按鈕后，首先緩存，然后才播放的。那能不能在頁面加載的同時就緩存呢。這樣，用戶點擊播放后，就不必等待了。
這當然可以，在video標簽中，通過添加preload屬性來為視頻添加預加載功能，在頁面加載的同時加載視頻。
<video poster = "img/beauty.jpg" controls preload>
（此處略去500字…）
</video>
關于 preload 屬性，稍微再啰嗦一點，就是可以把它設置為 metadata，讓瀏覽器僅僅預加載視頻的基本信息，如尺寸、時長、以及一些關鍵的幀。這樣的話，在開始播放之前，瀏覽器可以提前計算視頻的顯示尺寸。
既然一切都OK了！讓我們看看mp4是不是能正常播放。下載最新版的Google Chrome 38.0瀏覽器，打開網頁，猛戳一下播放按鈕。
等等~，等等~，不對，怎么只有聲音沒有畫面，明明是mp4格式的文件呀？使用暴風影音試了一下，是有畫面的呀！
辛辛苦苦又在網上搜了一番，花了整整586秒，終于找到了答案。mp4視頻需要h.264編碼格式才會有圖像的。
找了一個 h.264 編碼格式的 mp4 試了一下，不錯，確實有圖像了！看了半天，原來是一部老外的電影，嘰里咕嚕一陣，一句話也沒聽懂。那O(∩_∩)O~，能否提供中文字幕呢，這樣就不必費老大勁去聽了！
HTML5中，通過在video元素添加track元素為視頻添加字幕。字幕文件有兩種格式：WebVTT和TTML。WebVTT是Web視頻文本軌跡（Web Video Text Track），是UTF-8編碼格式的文本文件；TTML是時序文本標記語言（Timed Text Markup Language），是XML格式的文件。兩種文件的具體格式，已經超出我們的討論范圍。
video元素支持添加多個track元素，不同的track元素鏈接到不同的字幕文件。用戶可以在各個字幕間進行切換。
<video poster = "img/beauty.jpg" controls preload>
<track src="en_track.vtt" kind="subtitles" srclang="en" label="English" default>
<track src="cn_track.vtt" kind="captions" srclang="zh" label="簡體中文">
</video>
track元素中，src屬性指定字幕文件的URL；srclang屬性字幕文件的語言類型，若kind 屬性值是 "subtitles" 時，該屬性必需的；label 屬性指定字幕標簽，每個字幕元素必需設置一個唯一不重復的標簽，切換字幕時，會顯示標簽的名稱；kind指定字幕內容類型，只能是subtitles、captions、descriptions、chapters、metadata 之一；default屬性指定是否是默認字幕，如果一個都沒指定，將不會自動顯示字幕。
除了字幕外，我還希望對視頻進行過多的控制，比如讓視頻自動播放、循環播放、默認靜音，以及視頻窗口的尺寸等等，這些都能做到嗎？
這已經不是什么事了，video 元素已經提供了相關屬性，根據需要設置相應的屬性就可以了。這些屬性及含義見表 23：
HTML中嵌入視頻和音頻代碼
哦，原來這么簡單呀！那就到此為止吧，網頁中嵌入視頻的全部代碼都在這里，就打包給你吧！
<video width="300" poster="img/beauty.jpg" controls preload autoplay loop muted>
<source src="media/vedio.mp4">
<source src="media/vedio.ogg">
<track src="en_track.vtt" kind="subtitles" srclang="en" label="English" default>
<track src="cn_track.vtt" kind="captions" srclang="zh" label="簡體中文">
你的瀏覽器已經老掉牙了，不支持video，還不趕快使用現代瀏覽器O(∩_∩)O~！
</video>
睜大眼睛一看，卻只有7行代碼。然而，就這區區7行代碼，可把他折磨得夠嗆。
看著這一切都全部搞定，他仰望著天空，長長呼了一口氣，顯得是那么的放松，那么的愜意。此時，他閉上眼睛，在自己的夢幻世界里遨游！
有了在網頁中嵌入視頻的經歷，要在網頁中嵌入音頻，那簡直就是小菜一碟了。只要把vedio元素換成 audio 元素，就全部搞定。
但需要了解的是，audio 所支持的音頻格式只有Ogg Vorbis、mp3 和 wav。還要知道，由于音頻沒有畫面，也就沒有 width、height、poster 屬性，而其他屬性都支持，并且跟視頻的含義相同。
網頁中嵌入音頻的代碼如下：
<audio controls preload autoplay loop muted>
<source src="media/audio.mp3">
<source src="media/audio.wav">
<source src="media/audio.ogg">
你的瀏覽器已經老掉牙了，不支持audio，還不趕快使用現代瀏覽器O(∩_∩)O~！
</audio>
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
