本文引用了微信公眾號“鮮棗課堂”的《視頻編碼零基礎入門》文章內容。為了更好的內容呈現，引用和收錄時內容有改動，轉載時請注明原文來源信息，尊重原作者的勞動。
1、引言
如今我們所處的時代，是移動互聯網時代，也可以說是視頻時代。從快播到抖音，從“三生三世”到“延禧攻略”，我們的生活，被越來越多的視頻元素所影響。
而這一切，離不開視頻拍攝技術的不斷升級，還有視頻制作產業的日益強大。
此外，也離不開通信技術的飛速進步。試想一下，如果還是當年的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）
2、系列文章
本文是系列文章中的第19篇，本系列文章的大綱如下：
《即時通訊音視頻開發（一）：視頻編解碼之理論概述》
《即時通訊音視頻開發（二）：視頻編解碼之數字視頻介紹》
《即時通訊音視頻開發（三）：視頻編解碼之編碼基礎》
《即時通訊音視頻開發（四）：視頻編解碼之預測技術介紹》
《即時通訊音視頻開發（五）：認識主流視頻編碼技術H.264》
《即時通訊音視頻開發（六）：如何開始音頻編解碼技術的學習》
《即時通訊音視頻開發（七）：音頻基礎及編碼原理入門》
《即時通訊音視頻開發（八）：常見的實時語音通訊編碼標準》
《即時通訊音視頻開發（九）：實時語音通訊的回音及回音消除概述》
《即時通訊音視頻開發（十）：實時語音通訊的回音消除技術詳解》
《即時通訊音視頻開發（十一）：實時語音通訊丟包補償技術詳解》
《即時通訊音視頻開發（十二）：多人實時音視頻聊天架構探討》
《即時通訊音視頻開發（十三）：實時視頻編碼H.264的特點與優勢》
《即時通訊音視頻開發（十四）：實時音視頻數據傳輸協議介紹》
《即時通訊音視頻開發（十五）：聊聊P2P與實時音視頻的應用情況》
《即時通訊音視頻開發（十六）：移動端實時音視頻開發的幾個建議》
《即時通訊音視頻開發（十七）：視頻編碼H.264、V8的前世今生》
《即時通訊音視頻開發（十八）：詳解音頻編解碼的原理、演進和應用選型》
《即時通訊音視頻開發（十九）：零基礎，史上最通俗視頻編碼技術入門》（本文）
3、圖像基礎知識
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、視頻編碼基礎知識
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、視頻編碼的實現原理
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、視頻編碼的國際標準
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.261、H.262、H.263、H.263+、H.263++，這些統稱為H.26X系列，主要應用于實時視頻通信領域，如會議電視、可視電話等；
2）ISO/IEC提出了MPEG1、MPEG2、MPEG4、MPEG7、MPEG21，統稱為MPEG系列。
ITU和ISO/IEC一開始是各自搗鼓，后來，兩邊成立了一個聯合小組，名叫JVT（Joint Video Team，視頻聯合工作組）。
JVT致力于新一代視頻編碼標準的制定，后來推出了包括H.264在內的一系列標準。
▲ 壓縮率對比
▲ 視頻編碼標準的發展關系
大家特別注意一下上圖里面的HEVC，也就是現在風頭正盛的H.265。
作為一種新編碼標準，相比H.264有極大的性能提升，目前已經成為最新視頻編碼系統的標配。
最后，我再說說封裝。
6.2 視頻數據的封裝
對于任何一部視頻來說，只有圖像，沒有聲音，肯定是不行的。所以，視頻編碼后，加上音頻編碼，要一起進行封裝。
封裝：就是封裝格式，簡單來說，就是將已經編碼壓縮好的視頻軌和音頻軌按照一定的格式放到一個文件中。再通俗點，視頻軌相當于飯，而音頻軌相當于菜，封裝格式就是一個飯盒，用來盛放飯菜的容器。
目前主要的視頻容器有如下：MPG、VOB、MP4、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、HTML5、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互通的技術思路和實踐》
>> 更多同類文章 ……
（本文同步發布于：http://www.52im.net/thread-2840-1-1.html）
