零基礎，史上最通俗視頻編碼技術入門

本文引用了微信公衆號「鮮棗課堂」的《視頻編碼零基礎入門》文章內容。爲了更好的內容呈現，引用和收錄時內容有改動，轉載時請註明原文來源信息，尊重原做者的勞動。

一、引言

現在咱們所處的時代，是移動互聯網時代，也能夠說是視頻時代。從快播到抖音，從「三生三世」到「延禧攻略」，咱們的生活，被愈來愈多的視頻元素所影響。

而這一切，離不開視頻拍攝技術的不斷升級，還有視頻製做產業的日益強大。

此外，也離不開通訊技術的飛速進步。試想一下，若是仍是當年的56K Modem撥號，或者是2G手機，你還能享受到如今動輒1080P甚至4K的視頻體驗嗎？

除了視頻拍攝工具和網絡通訊技術升級以外，咱們能享受到視頻帶來的便利和樂趣，還有一個重要因素，就是視頻編碼技術的日新月異。

視頻編碼技術涉及的內容太過專業和龐雜，市面上的書籍或博客多數都只是枯燥的技術概念羅列，對於新手來講讀完依舊蒙逼是常態，本文將藉此機會，專門給你們作一個關於視頻編碼的零基礎科普。

（本文同步發佈於：www.52im.net/thread-2840…）

二、系列文章

本文是系列文章中的第19篇，本系列文章的大綱以下：

• 《即時通信音視頻開發（一）：視頻編解碼之理論概述》
• 《即時通信音視頻開發（二）：視頻編解碼之數字視頻介紹》
• 《即時通信音視頻開發（三）：視頻編解碼之編碼基礎》
• 《即時通信音視頻開發（四）：視頻編解碼之預測技術介紹》
• 《即時通信音視頻開發（五）：認識主流視頻編碼技術H.264》
• 《即時通信音視頻開發（六）：如何開始音頻編解碼技術的學習》
• 《即時通信音視頻開發（七）：音頻基礎及編碼原理入門》
• 《即時通信音視頻開發（八）：常見的實時語音通信編碼標準》
• 《即時通信音視頻開發（九）：實時語音通信的迴音及迴音消除概述》
• 《即時通信音視頻開發（十）：實時語音通信的迴音消除技術詳解》
• 《即時通信音視頻開發（十一）：實時語音通信丟包補償技術詳解》
• 《即時通信音視頻開發（十二）：多人實時音視頻聊天架構探討》
• 《即時通信音視頻開發（十三）：實時視頻編碼H.264的特色與優點》
• 《即時通信音視頻開發（十四）：實時音視頻數據傳輸協議介紹》
• 《即時通信音視頻開發（十五）：聊聊P2P與實時音視頻的應用狀況》
• 《即時通信音視頻開發（十六）：移動端實時音視頻開發的幾個建議》
• 《即時通信音視頻開發（十七）：視頻編碼H.26四、V8的前世此生》
• 《即時通信音視頻開發（十八）：詳解音頻編解碼的原理、演進和應用選型》
• 《即時通信音視頻開發（十九）：零基礎，史上最通俗視頻編碼技術入門》

  
  

三、圖像基礎知識

3.1 什麼是像素？

說視頻以前，先要說說圖像。圖像，你們都知道，是由不少「帶有顏色的點」組成的。這個點，就是「像素點」。

像素點的英文叫Pixel（縮寫爲PX）。這個單詞是由 Picture(圖像) 和 Element（元素）這兩個單詞的字母所組成的。

▲ 電影《像素大戰（Pixels）》，2015年

像素是圖像顯示的基本單位。咱們一般說一幅圖片的大小，例如是1920×1080，就是長度爲1920個像素點，寬度爲1080個像素點。乘積是2,073,600，也就是說，這個圖片是兩百萬像素的。

1920×1080，這個也被稱爲這幅圖片的分辨率。

▲ 分辨率也是顯示器的重要指標

3.2 什麼是PPI？

那麼，咱們常常所說的PPI又是什麼東西呢？

PPI，就是「Pixels Per Inch」，每英寸像素數。也就是，手機（或顯示器）屏幕上每英寸面積，到底能放下多少個「像素點」。這個值固然是越高越好啦！PPI越高，圖像就越清晰細膩。

之前的功能機，例如諾基亞，屏幕PPI都很低，有很強烈的顆粒感。

後來，蘋果開創了前所未有的「視網膜」（Retina）屏幕，PPI值高達326（每英寸屏幕有326像素），畫質清晰，再也沒有了顆粒感。

3.3 顏色在計算機裏是如何表示的？

像素點必需要有顏色，才能組成繽紛絢麗的圖片。那麼，這個顏色，又該如何表示呢？

你們都知道，咱們生活中的顏色，能夠擁有無數種類別。

▲ 光是妹紙們的口紅色號，就足以讓咱們這些屌絲瞠目結舌。。。

在計算機系統裏，咱們不可能用文字來表述顏色。否則，就算咱們不瘋，計算機也會瘋掉的。在數字時代，固然是用數字來表述顏色。這就牽出了「彩色份量數字化」的概念。

之前咱們美術課學過，任何顏色，均可以經過紅色（Red）、綠色（Green）、藍色（Blue）按照必定比例調製出來。這三種顏色，被稱爲「三原色」。

在計算機裏，R、G、B也被稱爲「基色份量」。它們的取值，分別從0到255，一共256個等級（256是2的8次方）。因此，任何顏色，均可以用R、G、B三個值的組合表示。

▲ RGB=(183,67,21)

經過這種方式，一共能表達多少種顏色呢？256×256×256=16,777,216種，所以也簡稱爲1600萬色。RGB三色，每色有8bit，這種方式表達出來的顏色，也被稱爲24位色（佔用24bit）。這個顏色範圍已經超過了人眼可見的所有色彩，因此又叫真彩色。再高的話，對於咱們人眼來講，已經沒有意義了，徹底識別不出來。

四、視頻編碼基礎知識

4.1 視頻和圖像和關係

好了，剛纔說了圖像，如今，咱們開始說視頻。所謂視頻，你們從小就看動畫，都知道視頻是怎麼來的吧？沒錯，大量的圖片連續起來，就是視頻。

衡量視頻，又是用的什麼指標參數呢？最主要的一個，就是幀率（Frame Rate）。在視頻中，一個幀（Frame）就是指一幅靜止的畫面。幀率，就是指視頻每秒鐘包括的畫面數量（FPS，Frame per second）。

幀率越高，視頻就越逼真、越流暢。

4.2 未經編碼的視頻數據量會有多大？

有了視頻以後，就涉及到兩個問題：

一個是存儲；

二個是傳輸。

而之因此會有視頻編碼，關鍵就在於此：一個視頻，若是未經編碼，它的體積是很是龐大的。

以一個分辨率1920×1280，幀率30的視頻爲例：

共：1920×1280=2,073,600（Pixels 像素），每一個像素點是24bit（前面算過的哦）；

也就是：每幅圖片2073600×24=49766400 bit，8 bit（位）=1 byte（字節）；

因此：49766400bit=6220800byte≈6.22MB。

這是一幅1920×1280圖片的原始大小，再乘以幀率30。

也就是說：每秒視頻的大小是186.6MB，每分鐘大約是11GB，一部90分鐘的電影，約是1000GB。。。

嚇尿了吧？就算你如今電腦硬盤是4TB的（實際也就3600GB），也放不下幾部大姐姐啊！不只要存儲，還要傳輸，否則視頻從哪來呢？若是按照100M的網速（12.5MB/s），下剛纔那部電影，須要22個小時。。。再次崩潰。。。

正由於如此，屌絲工程師們就提出了，必須對視頻進行編碼。

4.3 什麼是編碼？

編碼：就是按指定的方法，將信息從一種形式（格式），轉換成另外一種形式（格式）。視頻編碼：就是將一種視頻格式，轉換成另外一種視頻格式。

編碼的終極目的，說白了，就是爲了壓縮。各類五花八門的視頻編碼方式，都是爲了讓視頻變得體積更小，有利於存儲和傳輸。

咱們先來看看，視頻從錄製到播放的整個過程，以下：

首先是視頻採集。一般咱們會使用攝像機、攝像頭進行視頻採集。限於篇幅，我就不打算和你們解釋CCD成像原理了。

採集了視頻數據以後，就要進行模數轉換，將模擬信號變成數字信號。其實如今不少都是攝像機（攝像頭）直接輸出數字信號。信號輸出以後，還要進行預處理，將RGB信號變成YUV信號。

前面咱們介紹了RGB信號，那什麼是YUV信號呢？

簡單來講，YUV就是另一種顏色數字化表示方式。視頻通訊系統之因此要採用YUV，而不是RGB，主要是由於RGB信號不利於壓縮。在YUV這種方式裏面，加入了亮度這一律念。在最近十年中，視頻工程師發現，眼睛對於亮和暗的分辨要比對顏色的分辨更精細一些，也就是說，人眼對色度的敏感程度要低於對亮度的敏感程度。

因此，工程師認爲，在咱們的視頻存儲中，沒有必要存儲所有顏色信號。咱們能夠把更多帶寬留給黑—白信號（被稱做「亮度」），將稍少的帶寬留給彩色信號（被稱做「色度」）。因而，就有了YUV。

YUV裏面的「Y」，就是亮度（Luma），「U」和「V」則是色度（Chroma）。

你們偶爾會見到的Y'CbCr，也稱爲YUV，是YUV的壓縮版本，不一樣之處在於Y'CbCr用於數字圖像領域，YUV用於模擬信號領域，MPEG、DVD、攝像機中常說的YUV其實就是Y'CbCr。

▲ YUV（Y'CbCr）是如何造成圖像的

YUV碼流的存儲格式其實與其採樣的方式密切相關。（採樣，就是捕捉數據）

主流的採樣方式有三種：

1）YUV4:4:4；

2）YUV4:2:2；

3）YUV4:2:0。

具體解釋起來有點繁瑣，你們只需記住，一般用的是YUV4:2:0的採樣方式，能得到1/2的壓縮率。

這些預處理作完以後，就是正式的編碼了。

有關視頻編碼的更多專業知識，能夠詳細閱讀如下文章：

《即時通信音視頻開發（一）：視頻編解碼之理論概述》

《即時通信音視頻開發（二）：視頻編解碼之數字視頻介紹》

《即時通信音視頻開發（三）：視頻編解碼之編碼基礎》

《即時通信音視頻開發（四）：視頻編解碼之預測技術介紹》

《即時通信音視頻開發（五）：認識主流視頻編碼技術H.264》

五、視頻編碼的實現原理

5.1 視頻編碼技術的基本原理

前面咱們說了，編碼就是爲了壓縮。要實現壓縮，就要設計各類算法，將視頻數據中的冗餘信息去除。當你面對一張圖片，或者一段視頻的時候，你想想，若是是你，你會如何進行壓縮呢？

▲ 對於新垣女神，我一bit也不捨得壓縮…

我以爲，首先你想到的，應該是找規律。是的，尋找像素之間的相關性，還有不一樣時間的圖像幀之間，它們的相關性。

舉個例子：若是一幅圖（1920×1080分辨率），全是紅色的，我有沒有必要說2073600次[255,0,0]？我只要說一次[255,0,0]，而後再說2073599次「同上」。

若是一段1分鐘的視頻，有十幾秒畫面是不動的，或者，有80%的圖像面積，整個過程都是不變（不動）的。那麼，是否是這塊存儲開銷，就能夠節約掉了？

▲ 以上圖爲例，只有部分元素在動，大部分是不動的

是的，所謂編碼算法，就是尋找規律，構建模型。誰能找到更精準的規律，創建更高效的模型，誰就是厲害的算法。

一般來講，視頻裏面的冗餘信息包括：

視頻編碼技術優先消除的目標，就是空間冗餘和時間冗餘。

接下來，就和你們介紹一下，到底是採用什麼樣的辦法，才能幹掉它們。如下內容稍微有點高能，不過我相信你們耐心一些仍是能夠看懂的。

5.2 視頻編碼技術的實現方法

視頻是由不一樣的幀畫面連續播放造成的。

這些幀，主要分爲三類，分別是：

1）I幀；

2）B幀；

3）P幀。

I幀：是自帶所有信息的獨立幀，是最完整的畫面（佔用的空間最大），無需參考其它圖像即可獨立進行解碼。視頻序列中的第一個幀，始終都是I幀。

P幀：「幀間預測編碼幀」，須要參考前面的I幀和/或P幀的不一樣部分，才能進行編碼。P幀對前面的P和I參考幀有依賴性。可是，P幀壓縮率比較高，佔用的空間較小。

▲ P幀

B幀：「雙向預測編碼幀」，之前幀後幀做爲參考幀。不只參考前面，還參考後面的幀，因此，它的壓縮率最高，能夠達到200:1。不過，由於依賴後面的幀，因此不適合實時傳輸（例如視頻會議）。

▲ B幀

經過對幀的分類處理，能夠大幅壓縮視頻的大小。畢竟，要處理的對象，大幅減小了（從整個圖像，變成圖像中的一個區域）。

若是從視頻碼流中抓一個包，也能夠看到I幀的信息，以下：

咱們來經過一個例子看一下。

這有兩個幀：

好像是同樣的？

不對，我作個GIF動圖，就能看出來，是不同的：

人在動，背景是沒有在動的。

第一幀是I幀，第二幀是P幀。兩個幀之間的差值，就是以下：

也就是說，圖中的部分像素，進行了移動。移動軌跡以下：

這個，就是運動估計和補償。

固然了，若是老是按照像素來算，數據量會比較大，因此，通常都是把圖像切割爲不一樣的「塊（Block）」或「宏塊（MacroBlock）」，對它們進行計算。一個宏塊通常爲16像素×16像素。

▲ 將圖片切割爲宏塊

好了，我來梳理一下。

對I幀的處理，是採用幀內編碼方式，只利用本幀圖像內的空間相關性。對P幀的處理，採用幀間編碼（前向運動估計），同時利用空間和時間上的相關性。簡單來講，採用運動補償(motion compensation)算法來去掉冗餘信息。

須要特別注意，I幀（幀內編碼），雖然只有空間相關性，但整個編碼過程也不簡單。

如上圖所示，整個幀內編碼，還要通過DCT（離散餘弦變換）、量化、編碼等多個過程。限於篇幅，加之較爲複雜，今天就放棄解釋了。

那麼，視頻通過編碼解碼以後，如何衡量和評價編解碼的效果呢？

通常來講，分爲客觀評價和主觀評價。客觀評價，就是拿數字來講話。例如計算「信噪比/峯值信噪比」。

信噪比的計算，我就不介紹了，丟個公式，有空能夠本身慢慢研究...

除了客觀評價，就是主觀評價了。主觀評價，就是用人的主觀感知直接測量，額，說人話就是——「好很差看我說了算」。

六、視頻編碼的國際標準

6.1 視頻編碼格式的標準化

接下來，咱們再說說標準（Standard）。任何技術，都有標準。自從有視頻編碼以來，就誕生過不少的視頻編碼標準。

提到視頻編碼標準，先介紹幾個制定標準的組織。

首先，就是大名鼎鼎的ITU（國際電信聯盟）。

ITU是聯合國下屬的一個專門機構，其總部在瑞士的日內瓦。

ITU下屬有三個部門：

1）分別是ITU-R（前身是國際無線電諮詢委員會CCIR）；

2）ITU-T（前身是國際電報電話諮詢委員會CCITT）；

3）ITU-D。

除了ITU以外，另外兩個和視頻編碼關係密切的組織，是ISO/IEC。

ISO你們都知道，就是推出ISO9001質量認證的那個「國際標準化組織」。IEC，是「國際電工委員會」。1988年，ISO和IEC聯合成立了一個專家組，負責開發電視圖像數據和聲音數據的編碼、解碼和它們的同步等標準。這個專家組，就是大名鼎鼎的MPEG，Moving Picture Expert Group（動態圖像專家組）。

三十多年以來，世界上主流的視頻編碼標準，基本上都是它們提出來的：

1）ITU提出了H.26一、H.26二、H.26三、H.263+、H.263++，這些統稱爲H.26X系列，主要應用於實時視頻通訊領域，如會議電視、可視電話等；

2）ISO/IEC提出了MPEG一、MPEG二、MPEG四、MPEG七、MPEG21，統稱爲MPEG系列。

ITU和ISO/IEC一開始是各自搗鼓，後來，兩邊成立了一個聯合小組，名叫JVT（Joint Video Team，視頻聯合工做組）。

JVT致力於新一代視頻編碼標準的制定，後來推出了包括H.264在內的一系列標準。

▲ 壓縮率對比

▲ 視頻編碼標準的發展關係

你們特別注意一下上圖裏面的HEVC，也就是如今風頭正盛的H.265。

做爲一種新編碼標準，相比H.264有極大的性能提高，目前已經成爲最新視頻編碼系統的標配。

最後，我再說說封裝。

6.2 視頻數據的封裝

對於任何一部視頻來講，只有圖像，沒有聲音，確定是不行的。因此，視頻編碼後，加上音頻編碼，要一塊兒進行封裝。

封裝：就是封裝格式，簡單來講，就是將已經編碼壓縮好的視頻軌和音頻軌按照必定的格式放到一個文件中。再通俗點，視頻軌至關於飯，而音頻軌至關於菜，封裝格式就是一個飯盒，用來盛放飯菜的容器。

目前主要的視頻容器有以下：MPG、VOB、MP四、3GP、ASF、RMVB、WMV、MOV、Divx、MKV、FLV、TS/PS等。

封裝以後的視頻，就能夠傳輸了，你也能夠經過視頻播放器進行解碼觀看。

附錄：更多即時通信音視頻技術相關資料

[1] 實時音視頻開發的其它精華資料：
《實時語音聊天中的音頻處理與編碼壓縮技術簡述》
《網易視頻雲技術分享：音頻處理與壓縮技術快速入門》
《學習RFC3550：RTP/RTCP實時傳輸協議基礎知識》
《基於RTMP數據傳輸協議的實時流媒體技術研究（論文全文）》
《聲網架構師談實時音視頻雲的實現難點(視頻採訪)》
《淺談開發實時視頻直播平臺的技術要點》
《還在靠「喂喂喂」測試實時語音通話質量？本文教你科學的評測方法！》
《實現延遲低於500毫秒的1080P實時音視頻直播的實踐分享》
《移動端實時視頻直播技術實踐：如何作到實時秒開、流暢不卡》
《如何用最簡單的方法測試你的實時音視頻方案》
《技術揭祕：支持百萬級粉絲互動的Facebook實時視頻直播》
《簡述實時音視頻聊天中端到端加密（E2EE）的工做原理》
《移動端實時音視頻直播技術詳解（一）：開篇》
《移動端實時音視頻直播技術詳解（二）：採集》
《移動端實時音視頻直播技術詳解（三）：處理》
《移動端實時音視頻直播技術詳解（四）：編碼和封裝》
《移動端實時音視頻直播技術詳解（五）：推流和傳輸》
《移動端實時音視頻直播技術詳解（六）：延遲優化》
《理論聯繫實際：實現一個簡單地基於HTML5的實時視頻直播》
《IM實時音視頻聊天時的回聲消除技術詳解》
《淺談實時音視頻直播中直接影響用戶體驗的幾項關鍵技術指標》
《如何優化傳輸機制來實現實時音視頻的超低延遲？》
《首次披露：快手是如何作到百萬觀衆同場看直播仍能秒開且不卡頓的？》
《Android直播入門實踐：動手搭建一套簡單的直播系統》
《網易雲信實時視頻直播在TCP數據傳輸層的一些優化思路》
《實時音視頻聊天技術分享：面向不可靠網絡的抗丟包編解碼器》
《P2P技術如何將實時視頻直播帶寬下降75%？》
《專訪微信視頻技術負責人：微信實時視頻聊天技術的演進》
《騰訊音視頻實驗室：使用AI黑科技實現超低碼率的高清實時視頻聊天》
《微信團隊分享：微信每日億次實時音視頻聊天背後的技術解密》
《近期大熱的實時直播答題系統的實現思路與技術難點分享》
《福利貼：最全實時音視頻開發要用到的開源工程彙總》
《七牛雲技術分享：使用QUIC協議實現實時視頻直播0卡頓！》
《實時音視頻聊天中超低延遲架構的思考與技術實踐》
《理解實時音視頻聊天中的延時問題一篇就夠》
《實時視頻直播客戶端技術盤點：Native、HTML五、WebRTC、微信小程序》
《寫給小白的實時音視頻技術入門提綱》
《微信多媒體團隊訪談：音視頻開發的學習、微信的音視頻技術和挑戰等》
《騰訊技術分享：微信小程序音視頻技術背後的故事》
《微信多媒體團隊梁俊斌訪談：聊一聊我所瞭解的音視頻技術》
《新浪微博技術分享：微博短視頻服務的優化實踐之路》
《實時音頻的混音在視頻直播應用中的技術原理和實踐總結》
《以網遊服務端的網絡接入層設計爲例，理解實時通訊的技術挑戰》
《騰訊技術分享：微信小程序音視頻與WebRTC互通的技術思路和實踐》
《新浪微博技術分享：微博實時直播答題的百萬高併發架構實踐》
《技術乾貨：實時視頻直播首屏耗時400ms內的優化實踐》
>> 更多同類文章 ……

[2] 開源實時音視頻技術WebRTC的文章：
《開源實時音視頻技術WebRTC的現狀》
《簡述開源實時音視頻技術WebRTC的優缺點》
《訪談WebRTC標準之父：WebRTC的過去、如今和將來》
《良心分享：WebRTC 零基礎開發者教程（中文）[附件下載]》
《WebRTC實時音視頻技術的總體架構介紹》
《新手入門：到底什麼是WebRTC服務器，以及它是如何聯接通話的？》
《WebRTC實時音視頻技術基礎：基本架構和協議棧》
《淺談開發實時視頻直播平臺的技術要點》
《[觀點] WebRTC應該選擇H.264視頻編碼的四大理由》
《基於開源WebRTC開發實時音視頻靠譜嗎？第3方SDK有哪些？》
《開源實時音視頻技術WebRTC中RTP/RTCP數據傳輸協議的應用》
《簡述實時音視頻聊天中端到端加密（E2EE）的工做原理》
《實時通訊RTC技術棧之：視頻編解碼》
《開源實時音視頻技術WebRTC在Windows下的簡明編譯教程》
《網頁端實時音視頻技術WebRTC：看起來很美，但離生產應用還有多少坑要填？》
《了不得的WebRTC：生態日趨完善，或將實時音視頻技術白菜化》
《騰訊技術分享：微信小程序音視頻與WebRTC互通的技術思路和實踐》
>> 更多同類文章 ……

（本文同步發佈於：www.52im.net/thread-2840…）