ut視訊聊天大廳…關於直播的技術文章不少，成體系的不多。我們將用一系列文章，更系統化地介紹當下大熱的視頻直播各環節的關鍵技術，幫助視頻直播創業者們更全面、深入地了解視頻直播技術，更好地技術選型。
視頻編碼是視頻直播技術系列文章的第三篇，是本系列一個非常重要的部分，是移動開發必修的基礎課程，本篇文章從理論到實踐一網打盡主流編碼器。
如果把整個流媒體比喻成一個物流系統，那麼編解碼就是其中配貨和裝貨的過程，這個過程非常重要，它的速度和壓縮比對物流系統的意義非常大，影響物流系統的整體速度和成本。同樣，對流媒體傳輸來說，編碼也非常重要，它的編碼性能、編碼速度和編碼壓縮比會直接影響整個流媒體傳輸的用戶體驗和傳輸成本。
視頻編碼的意義
原始視頻數據存儲空間大，一個 1080P 的 7 s 視頻需要 817 MB原始視頻數據傳輸占用帶寬大，10 Mbps 的帶寬傳輸上述 7 s 視頻需要 11 分鐘而經過 H.264 編碼壓縮之後，視頻大小只有 708 k ,10 Mbps 的帶寬僅僅需要 500 ms ，可以滿足實時傳輸的需求，所以從視頻採集傳感器採集來的原始視頻勢必要經過視頻編碼。
基本原理
那為什麼巨大的原始視頻可以編碼成很小的視頻呢？這其中的技術是什麼呢？
核心思想就是去除冗餘信息：
空間冗餘：圖像相鄰像素之間有較強的相關性時間冗餘：視頻序列的相鄰圖像之間內容相似編碼冗餘：不同像素值出現的機率不同視覺冗餘：人的視覺系統對某些細節不敏感知識冗餘：規律性的結構可由先驗知識和背景知識得到視頻本質上講是一系列圖片連續快速的播放，最簡單的壓縮方式就是對每一幀圖片進行壓縮，例如比較古老的 MJPEG 編碼就是這種編碼方式，這種編碼方式只有幀內編碼，利用空間上的取樣預測來編碼。形象的比喻就是把每幀都作為一張圖片，採用 JPEG 的編碼格式對圖片進行壓縮，這種編碼只考慮了一張圖片內的冗餘信息壓縮，如圖1，綠色的部分就是當前待編碼的區域，灰色就是尚未編碼的區域，綠色區域可以根據已經編碼的部分進行預測（綠色的左邊，下邊，左下等）。
…圖1
但是幀和幀之間因為時間的相關性，後續開發出了一些比較高級的編碼器可以採用幀間編碼，簡單點說就是通過搜索算法選定了幀上的某些區域，然後通過計算當前幀和前後參考幀的向量差進行編碼的一種形式，通過下面兩個圖 2 連續幀我們可以看到，滑雪的同學是向前位移的，但實際上是雪景在向後位移，P 幀通過參考幀（I 或其他 P 幀）就可以進行編碼了，編碼之後的大小非常小，壓縮比非常高。
…圖 2
可能有同學對這兩張圖片怎麼來的感興趣，這裡用了 FFmpeg 的兩行命令來實現，具體 FFmpeg 的更多內容請看後續章節：
第一行生成帶有移動矢量的視頻第二行把每一幀都輸出成圖片ffmpeg -flags2 +export_mvs -i tutu.mp4 -vf codecview=mv=pf+bf+bb tutudebug2.mp4ffmpeg -i tutudebug2.mp4 ‘tutunormal-%03d.bmp’除了空間冗餘和時間冗餘的壓縮，主要還有編碼壓縮和視覺壓縮，下面是一個編碼器主要的流程圖：
…圖 3
…圖 4
圖 3、圖 4 兩個流程，圖 3 是幀內編碼，圖 4 是幀間編碼，從圖上看到的主要區別就是第一步不相同，其實這兩個流程也是結合在一起的，我們通常說的 I 幀和 P 幀就是分別採用了幀內編碼和幀間編碼。
編碼器的選擇
前面梳理了一下編碼器的原理和基本流程，編碼器經歷了數十年的發展，已經從開始的只支持幀內編碼演進到現如今的 H.265 和 VP9 為代表的新一代編碼器，就目前一些常見的編碼器進行分析，帶大家探索一下編碼器的世界。
H.264
簡介
H.264/AVC 項目意圖創建一種視頻標準。與舊標準相比，它能夠在更低帶寬下提供優質視頻（換言之，只有 MPEG-2，H.263 或 MPEG-4 第 2 部分的一半帶寬或更少），也不增加太多設計複雜度使得無法實現或實現成本過高。另一目的是提供足夠的靈活性以在各種應用、網絡及系統中使用，包括高、低帶寬，高、低視頻解析度，廣播，DVD 存儲，RTP/IP 網絡，以及 ITU-T多媒體電話系統。
H.264/AVC 包含了一系列新的特徵，使得它比起以前的編解碼器不但能夠更有效的進行編碼，還能在各種網絡環境下的應用中使用。這樣的技術基礎讓 H.264 成為包括 YouTube 在內的在線視頻公司採用它作為主要的編解碼器，但是使用它並不是一件很輕鬆的事情，理論上講使用 H.264 需要交納不菲的專利費用。
專利野i
和 MPEG-2 第一部分、第二部分，MPEG-4第二部分一樣，使用 H.264/AVC 的產品製造商和服務提供商需要向他們的產品所使用的專利的持有者支付專利野i費用。這些專利野i的主要來源是一家稱為 MPEG-LA LLC 的私有組織，該組織和 MPEG 標準化組織沒有任何關係，但是該組織也管理著 MPEG-2 第一部分系統、第二部分視頻、MPEG-4第二部分視頻和其它一些技術的專利野i。
其他的專利野i則需要向另一家稱為 VIA Licensing 的私有組織申請，這家公司另外也管理偏向音頻壓縮的標準如 MPEG-2 AAC 及 MPEG-4 Audio 的專利野i。
H.264 的開源實現
openh264x264openh264 是思科實現的開源 H.264 編碼，雖然 H.264 需要交納不菲的專利費用，但是專利費有一個年度上限，思科把 OpenH264 實現的年度專利費交滿後，OpenH264 事實上就可以免費自由的使用了。
x264 x264是一個採用GPL授權的視頻編碼自由軟體。x264 的主要弁鄏b於進行 H.264/MPEG-4 AVC 的視頻編碼，而不是作為解碼器（decoder）之用。
除去費用問題比較來看：
openh264 CPU 的占用相對 x264低很多openh264 只支持 baseline profile，x264 支持更多 profileHEVC/H.265
高效率視頻編碼（High Efficiency Video Coding，簡稱HEVC）是一種視頻壓縮標準，被視為是 ITU-T H.264/MPEG-4 AVC 標準的繼任者。2004 年開始由 ISO/IEC Moving Picture Experts Group（MPEG）和 ITU-T Video Coding Experts Group（VCEG）作為 ISO/IEC23008-2 MPEG-H Part 2 或稱作 ITU-T H.265 開始制定。第一版的 HEVC/H.265 視頻壓縮標準在 2013 年 4 月 13 日被接受為國際電信聯盟（ITU-T）的正式標準。HEVC 被認為不僅提升視頻質量，同時也能達到 H.264/MPEG-4 AVC 兩倍之壓縮率（等同於同樣畫面質量下比特率減少了 50%），可支持 4K解析度甚至到超高畫質電視（UHDTV），最高解析度可達到 8192×4320（8K解析度）。
H.265 的開源實現
libde265x265libde265 HEVC 由 struktur 公司以開源野i證 GNU LesserGeneral Public License (LGPL) 提供，觀眾可以較慢的網速下欣賞到最高品質的影像。跟以前基於H.264標準的解碼器相比，libde265 HEVC 解碼器可以將您的全高清內容帶給多達兩倍的受眾，或者，減少 50% 流媒體播放所需要的帶寬。高清或者 4K/8K超高清流媒體播放，低延遲/低帶寬視頻會議，以及完整的移動設備覆說C具有「擁塞感知」視頻編碼的穩定性，十分適合應用在 3/4G 和 LTE 網絡。
HEVC Advance 要求所有包括蘋果、YouTube、Netflix、Facebook、亞馬遜等使用 H.265 技術的內容製造商上繳內容收入的 0.5%作為技術使用費，而整個流媒體市場每年達到約 1000 億美元的規模，且不斷增長中，徵收 0.5%絕對是一筆龐大的費用。而且他們還沒有放過設備製造商，其中電視廠商需要支付每台 1.5 美元、移動設備廠商每台 0.8美元的專利費。他們甚至沒有放過藍光設備播放器、遊戲機、錄像機這樣的廠商，這些廠商必須支付每台 1.1 美元的費用。最無法令人接受的是，HEVC Advance 的專利使用權追溯到了廠商的「」」，意思是之前已經發售的產品依然要追繳費用。
x265 是由 MulticoreWare 開發，並開源。採用 GPL 協議，但是資助這個項目的幾個公司組成了聯盟可以在非 GPL 協議下使用這個軟體。
VP8
VP8 是一個開放的視頻壓縮格式，最早由 On2 Technologies 開發，隨後由 Google 發布。同時 Google 也發布了 VP8 編碼的實做庫：libvpx，以 BSD 授權條款的方式發行，隨後也附加了專利使用權。而在經過一些爭論之後，最終 VP8 的授權確認為一個開放原始碼授權。
目前支持 VP8 的網頁瀏覽器有 Opera、Firefox 和 Chrome。
2013 年三月，Google 與 MPEG LA 及 11 個專利持有者達成協議，讓Google 獲取 VP8 以及其之前的 VPx 等編碼所可能侵犯的專利授權，同時 Google 也可以無償再次授權相關專利給 VP8 的用戶，此協議同時適用於下一代 VPx 編碼。至此 MPEG LA 放棄成立 VP8 專利集中授權聯盟，VP8的用戶將可確定無償使用此編碼而無須擔心可能的專利侵權授權金的問題。
VP8 的開源實現
libvpxlibvpx 是 VP8 的唯一開源實現，由 On2 Technologies 開發，Google 收購後將其開放源碼，License 非常寬鬆可以自由使用。
VP9
VP9 的開發從 2011 年第三季開始，目標是在同畫質下，比 VP8 編碼減少 50%的文件大小，另一個目標則是要在編碼效率上超越 HEVC 編碼。
2012 年 12 月 13 日，Chromium 瀏覽器加入了 VP9 編碼的支持。Chrome 瀏覽器則是在 2013 年 2 月 21 日開始支持 VP9 編碼的視頻播放。
Google 宣布會在 2013 年 6 月 17 日完成 VP9 編碼的制定工作，屆時Chrome 瀏覽器將會把 VP9 編碼默認引導。2014 年 3 月 18 日，Mozilla 在 Firefox 瀏覽器中加入了 VP9 的支持。
2015 年 4 月 3 日，谷歌發布了 libvpx1.4.0 增加了對 10 位和 12 位的比特深度支持、4:2:2 和 4:4:4 色度抽樣，並 VP9 多核心編/解碼。
VP9 是一個開放格式、無權利金的視頻編碼格式。
VP9 的開源實現
libvpxlibvpx 是 VP9 的唯一開源實現，由 Google 開發維護，裡面有部分代碼是 VP8 和 VP9 公用的，其餘分別是 VP8 和 VP9 的編解碼實現。
VP9 和 H.264 和 HEVC 比較
Codec HEVC x264 vp9 HEVC -42.2% 32.6% x264 75.8% 18.5% vp9 48.3% -14.6% Codec HEVC vs. VP9(in %) VP9 vs. x264 (in %) Total Average 612 39399 引用 Comparative Assessment of H.265/MPEG-HEVC, VP9,and
H.264/MPEG-AVC Encoders for Low-Delay Video Applications 這篇比較新的論文對，低延遲視頻進行編碼的測試結果。
HEVC 和 H.264 在不同解析度下的比較
跟 H.264/MPEG-4 相比，HEVC 的平均比特率減低值為：
解析度 480P 720P 1080P 4K UHD HEVC 52% 56% 62% 64% 可見碼率下降了 60% 以上。
HEVC (H.265) 對 VP9 和 H.264 在碼率節省上有較大的優勢，在相同 PSNR 下分別節省了 48.3% 和 75.8%。H.264 在編碼時間上有巨大優勢，對比 VP9 和 HEVC(H.265) ，HEVC 是 VP9 的6倍，VP9 是 H.264 的將近 40 倍FFmpeg
談到視頻編碼相關內容就不得不提一個偉大的軟體包 — FFmpeg。
FFmpeg 是一個自由軟體，可以運行音頻和視頻多種格式的錄影、轉換、流弁遄A包含了 libavcodec ——這是一個用於多個項目中音頻和視頻的解碼器庫，以及 libavformat ——一個音頻與視頻格式轉換庫。
FFmpeg 這個單詞中的 FF 指的是 Fast Forward。有些新手寫信給 FFmpeg 的項目負責人，詢問 FF 是不是代表 Fast Free 或者 Fast Fourier 等意思，FFmpeg 的項目負責人回信說：「Just for the record, the original meaning of FF in FFmpeg is FastForward…」
這個項目最初是由 Fabrice Bellard 發起的，而現在是由 Michael Niedermayer 在進行維護。釵hFFmpeg的開發者同時也是 MPlayer 項目的成員，FFmpeg 在 MPlayer 項目中是被設計為伺服器版本進行開發。
FFmpeg 下載地址是 : FFmpeg Download
可以瀏覽器輸入下載，目前支持 Linux ,Mac OS,Windows 三個主流的平台，也可以自己編譯到 Android 或者 iOS 平台。如果是 Mac OS ，可以通過 brew 安裝 brew install ffmpeg –with-libvpx –with-libvorbis –with-ffplay我們可以用 FFmpeg 來做哪些有用有好玩的事情呢？通過一系列小實驗來帶大家領略 FFmpeg 的神奇和強大。
FFmpeg 錄屏
通過一個小例子看一下怎麼在 Mac OS 下面使用 FFmpeg 進行錄屏:
輸入：
ffmpeg -f avfoundation -list_devices true -i ""輸出：
[AVFoundation input device @ 0x7fbec0c10940] AVFoundation video devices:[AVFoundation input device @ 0x7fbec0c10940] [0] FaceTime HD Camera[AVFoundation input device @ 0x7fbec0c10940] [1] Capture screen 0[AVFoundation input device @ 0x7fbec0c10940] [2] Capture screen 1[AVFoundation input device @ 0x7fbec0c10940] AVFoundation audio devices:[AVFoundation input device @ 0x7fbec0c10940] [0] Built-in Microphone給出了當前設備支持的所有輸入設備的列表和編號，我本地有兩塊顯示器，所以 1 和 2 都是我螢幕，可以選擇一塊進行錄屏。
查看當前的 H.264 編解碼器：
ffmpeg -codecs grep 264輸出：
DEV.LS h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_vda ) (encoders: libx264 libx264rgb )查看當前的 VP8 編解碼器：
ffmpeg -codecs grep vp8輸出：
DEV.L. vp8 On2 VP8 (decoders: vp8 libvpx ) (encoders: libvpx )可以選擇用 vp8 或者 h264 做編碼器
ffmpeg -r 30 -f avfoundation -i 1 -vcodec vp8 -quality realtime screen2.webm# -quality realtime 用來優化編碼器，如果不加在我的 Air 上幀率只能達到 2or
ffmpeg -r 30 -f avfoundation -i 1 -vcodec h264 screen.mp4然後用 ffplay 播放就可以了
ffplay screen.mp4or
ffplay screen2.webpFFmpeg 視頻轉換成 gif
有一個特別有用的需求，在網上發現了一個特別有趣的視頻想把它轉換成一個動態表情，作為一個 IT 從業者，我第一個想到的不是下載一個轉碼器，也不是去找一個在線轉換網站，直接利用手邊的工具 FFmpeg，瞬間就完成了轉碼：
ffmpeg -ss 10 -t 10 -i tutu.mp4 -s 80×60 tutu.gif## -ss 指從 10s 開始轉碼,-t 指轉換 10s 的視頻 -sFFmpeg 錄製螢幕並直播
可以繼續擴展例子1，直播當前螢幕的內容，向大家介紹一下怎麼通過幾行命令搭建一個測試用的直播服務：
Step 1：首先安裝 docker：
訪問 Docker Download ，按作業系統下載安裝。
Step 2：下載 nginx-rtmp 鏡像：
docker pull chakkritte/docker-nginx-rtmpStep 3：創建 nginx html 路徑，啟動 docker-nginx-rtmp
mkdir ~/rtmpdocker run -d -p 80:80 -p 1935:1935 -v ~/rtmp:/usr/local/nginx/html chakkritte/docker-nginx-rtmpStep 4：推送螢幕錄製到 nignx-rtmp
ffmpeg -y -loglevel warning -f avfoundation -i 2 -r 30 -s 480×320 -threads 2 -vcodec libx264 -f flv rtmp://127.0.0.1/live/testStep 5：用 ffplay 播放
ffplay rtmp://127.0.0.1/live/test總結一下，FFmpeg 是個優秀的工具，可以通過它完成很多日常的工作和實驗，但是距離提供真正可用的流媒體服務、直播服務還有非常多的工作要做，這方面可以參考七牛雲發布的 七牛直播雲服務 。
封裝
介紹完了視頻編碼後，再來介紹一些封裝。沿用前面的比喻，封裝可以理解為採用哪種貨車去運輸，也就是媒體的容器。
所謂容器，就是把編碼器生成的多媒體內容（視頻，音頻，字幕，章節信息等）混合封裝在一起的標準。容器使得不同多媒體內容同步播放變得很簡單，而容器的另一個作用就是為多媒體內容提供索引，也就是說如果沒有容器存在的話一部影片你只能從一開始看到最後，不能拖動進度條（當然這種情況下有的播放器會話比較長的時間臨時創建索引），而且如果你不自己去手動另外載入音頻就沒有聲音，下面介紹幾種常見的封裝格式和優缺點：
AVI 格式（後綴為 .AVI）: 它的英文全稱為 Audio Video Interleaved ，即音頻視頻交錯格式。它於 1992 年被 Microsoft 公司推出。這種視頻格式的優點是圖像質量好。由於無損AVI可以保存 alpha 通道，經常被我們使用。缺點太多，體積過於龐大，而且更加糟糕的是壓縮標準不統一，最普遍的現象就是高版本 Windows 媒體播放器播放不了採用早期編碼編輯的AVI格式視頻，而低版本 Windows媒體播放器又播放不了採用最新編碼編輯的AVI格式視頻，所以我們在進行一些AVI格式的視頻播放時常會出現由於視頻編碼問題而造成的視頻不能播放或即使能夠播放，但存在不能調節播放進度和播放時只有聲音沒有圖像等一些莫名其妙的問題。DV-AVI 格式（後綴為 .AVI）: DV的英文全稱是 Digital Video Format ，是由索尼、松下、JVC 等多家廠商聯合提出的一種家用數字視頻格式。數字攝像機就是使用這種格式記錄視頻數據的。它可以通過電腦的 IEEE 1394 埠傳輸視頻數據到電腦，也可以將電腦中編輯好的的視頻數據回錄到數碼攝像機中。這種視頻格式的文件擴展名也是 avi。電視台採用錄像帶記錄模擬信號，通過 EDIUS 由IEEE 1394埠採集卡從錄像帶中採集出來的視頻就是這種格式。QuickTime File Format 格式（後綴為 .MOV）: 美國Apple公司開發的一種視頻格式，默認的播放器是蘋果的QuickTime。具有較高的壓縮比率和較完美的視頻清晰度等特點，並可以保存alpha通道。MPEG 格式（文件後綴可以是 .MPG .MPEG .MPE .DAT .VOB .ASF .3GP .MP4等) : 它的英文全稱為 Moving Picture Experts Group，即運動圖像專家組格式，該專家組建於1988年，專門負責為 CD 建立視頻和音頻標準，而成員都是為視頻、音頻及系統領域的技術專家。MPEG 文件格式是運動圖像壓縮算法的國際標準。MPEG 格式目前有三個壓縮標準，分別是 MPEG－1、MPEG－2、和MPEG－4 。MPEG－1、MPEG－2 目前已經使用較少，著重介紹 MPEG－4，其制定於1998年，MPEG－4 是為了播放流式媒體的高質量視頻而專門設計的，以求使用最少的數據獲得最佳的圖像質量。目前 MPEG-4最有吸引力的地方在於它能夠保存接近於DVD畫質的小體積視頻文件。WMV 格式（後綴為.WMV .ASF）: 它的英文全稱為Windows Media Video，也是微軟推出的一種採用獨立編碼方式並且可以直接在網上實時觀看視頻節目的文件壓縮格式。WMV格式的主要優點包括：本地或網絡回放,豐富的流間關係以及擴展性等。WMV 格式需要在網站上播放，需要安裝 Windows Media Player（ 簡稱 WMP ），很不方便，現在已經幾乎沒有網站採用了。Real Video 格式（後綴為 .RM .RMVB）: Real Networks 公司所制定的音頻視頻壓縮規範稱為Real Media。用戶可以使用 RealPlayer 根據不同的網絡傳輸速率制定出不同的壓縮比率，從而實現在低速率的網絡上進行影像數據實時傳送和播放。RMVB 格式：這是一種由RM視頻格式升級延伸出的新視頻格式，當然性能上有很大的提升。RMVB 視頻也是有著較明顯的優勢，一部大小為700MB左右的 DVD 影片，如果將其轉錄成同樣品質的 RMVB 格式，其個頭最多也就 400MB左右。大家可能注意到了，以前在網絡上下載電影和視頻的時候，經常接觸到 RMVB 格式，但是隨著時代的發展這種格式被越來越多的更優秀的格式替代，著名的人人影視字幕組在2013年已經宣布不再壓制 RMVB 格式視頻。Flash Video 格式（後綴為 .FLV）:由 Adobe Flash 延伸出來的的一種流行網絡視頻封裝格式。隨著視頻網站的豐富，這個格式已經非常普及。Matroska 格式（後綴為 .MKV）:是一種新的多媒體封裝格式，這個封裝格式可把多種不同編碼的視頻及16條或以上不同格式的音頻和語言不同的字幕封裝到一個 Matroska Media 檔內。它也是其中一種開放原始碼的多媒體封裝格式。Matroska 同時還可以提供非常好的交互弁遄A而且比 MPEG 的方便、強大。MPEG2-TS 格式 (後綴為 .ts)（Transport Stream「傳輸流」；又稱MTS、TS）是一種傳輸和存儲包含音效、視頻與通信協議各種數據的標準格式，用於數位電視廣播系統，如DVB、ATSC、IPTV等等。MPEG2-TS 定義於 MPEG-2 第一部分，系統（即原來之ISO/IEC標準13818-1或ITU-T Rec. H.222.0）。Media Player Classic、VLC 多媒體播放器等軟體可以直接播放MPEG-TS文件。目前，我們在流媒體傳輸，尤其是直播中主要採用的就是 FLV 和 MPEG2-TS 格式，分別用於 RTMP/HTTP-FLV 和 HLS 協議。
下一期我們將系統講解視頻直播的推流和傳輸，盡請期待~
ut視訊聊天大廳-「移動開發」關於一對一視頻聊天直播系統技術（三）編碼和封裝
ut視訊聊天大廳…關於直播的技術文章不少，成體系的不多。我們將用一系列文章，更系統化地介紹當下大熱的視頻直播各環節的關鍵技術，幫助視頻直播創業者們更全面、深入地了解視頻直播技術，更好地技術選型。
視頻編碼是視頻直播技術系列文章的第三篇，是本系列一個非常重要的部分，是移動開發必修的基礎課程，本篇文章從理論到實踐一網打盡主流編碼器。
如果把整個流媒體比喻成一個物流系統，那麼編解碼就是其中配貨和裝貨的過程，這個過程非常重要，它的速度和壓縮比對物流系統的意義非常大，影響物流系統的整體速度和成本。同樣，對流媒體傳輸來說，編碼也非常重要，它的編碼性能、編碼速度和編碼壓縮比會直接影響整個流媒體傳輸的用戶體驗和傳輸成本。
視頻編碼的意義
原始視頻數據存儲空間大，一個 1080P 的 7 s 視頻需要 817 MB原始視頻數據傳輸占用帶寬大，10 Mbps 的帶寬傳輸上述 7 s 視頻需要 11 分鐘而經過 H.264 編碼壓縮之後，視頻大小只有 708 k ,10 Mbps 的帶寬僅僅需要 500 ms ，可以滿足實時傳輸的需求，所以從視頻採集傳感器採集來的原始視頻勢必要經過視頻編碼。
基本原理
那為什麼巨大的原始視頻可以編碼成很小的視頻呢？這其中的技術是什麼呢？
核心思想就是去除冗餘信息：
空間冗餘：圖像相鄰像素之間有較強的相關性時間冗餘：視頻序列的相鄰圖像之間內容相似編碼冗餘：不同像素值出現的機率不同視覺冗餘：人的視覺系統對某些細節不敏感知識冗餘：規律性的結構可由先驗知識和背景知識得到視頻本質上講是一系列圖片連續快速的播放，最簡單的壓縮方式就是對每一幀圖片進行壓縮，例如比較古老的 MJPEG 編碼就是這種編碼方式，這種編碼方式只有幀內編碼，利用空間上的取樣預測來編碼。形象的比喻就是把每幀都作為一張圖片，採用 JPEG 的編碼格式對圖片進行壓縮，這種編碼只考慮了一張圖片內的冗餘信息壓縮，如圖1，綠色的部分就是當前待編碼的區域，灰色就是尚未編碼的區域，綠色區域可以根據已經編碼的部分進行預測（綠色的左邊，下邊，左下等）。
…圖1
但是幀和幀之間因為時間的相關性，後續開發出了一些比較高級的編碼器可以採用幀間編碼，簡單點說就是通過搜索算法選定了幀上的某些區域，然後通過計算當前幀和前後參考幀的向量差進行編碼的一種形式，通過下面兩個圖 2 連續幀我們可以看到，滑雪的同學是向前位移的，但實際上是雪景在向後位移，P 幀通過參考幀（I 或其他 P 幀）就可以進行編碼了，編碼之後的大小非常小，壓縮比非常高。
…圖 2
可能有同學對這兩張圖片怎麼來的感興趣，這裡用了 FFmpeg 的兩行命令來實現，具體 FFmpeg 的更多內容請看後續章節：
第一行生成帶有移動矢量的視頻第二行把每一幀都輸出成圖片ffmpeg -flags2 +export_mvs -i tutu.mp4 -vf codecview=mv=pf+bf+bb tutudebug2.mp4ffmpeg -i tutudebug2.mp4 ‘tutunormal-%03d.bmp’除了空間冗餘和時間冗餘的壓縮，主要還有編碼壓縮和視覺壓縮，下面是一個編碼器主要的流程圖：
…圖 3
…圖 4
圖 3、圖 4 兩個流程，圖 3 是幀內編碼，圖 4 是幀間編碼，從圖上看到的主要區別就是第一步不相同，其實這兩個流程也是結合在一起的，我們通常說的 I 幀和 P 幀就是分別採用了幀內編碼和幀間編碼。
編碼器的選擇
前面梳理了一下編碼器的原理和基本流程，編碼器經歷了數十年的發展，已經從開始的只支持幀內編碼演進到現如今的 H.265 和 VP9 為代表的新一代編碼器，就目前一些常見的編碼器進行分析，帶大家探索一下編碼器的世界。
H.264
簡介
H.264/AVC 項目意圖創建一種視頻標準。與舊標準相比，它能夠在更低帶寬下提供優質視頻（換言之，只有 MPEG-2，H.263 或 MPEG-4 第 2 部分的一半帶寬或更少），也不增加太多設計複雜度使得無法實現或實現成本過高。另一目的是提供足夠的靈活性以在各種應用、網絡及系統中使用，包括高、低帶寬，高、低視頻解析度，廣播，DVD 存儲，RTP/IP 網絡，以及 ITU-T多媒體電話系統。
H.264/AVC 包含了一系列新的特徵，使得它比起以前的編解碼器不但能夠更有效的進行編碼，還能在各種網絡環境下的應用中使用。這樣的技術基礎讓 H.264 成為包括 YouTube 在內的在線視頻公司採用它作為主要的編解碼器，但是使用它並不是一件很輕鬆的事情，理論上講使用 H.264 需要交納不菲的專利費用。
專利野i
和 MPEG-2 第一部分、第二部分，MPEG-4第二部分一樣，使用 H.264/AVC 的產品製造商和服務提供商需要向他們的產品所使用的專利的持有者支付專利野i費用。這些專利野i的主要來源是一家稱為 MPEG-LA LLC 的私有組織，該組織和 MPEG 標準化組織沒有任何關係，但是該組織也管理著 MPEG-2 第一部分系統、第二部分視頻、MPEG-4第二部分視頻和其它一些技術的專利野i。
其他的專利野i則需要向另一家稱為 VIA Licensing 的私有組織申請，這家公司另外也管理偏向音頻壓縮的標準如 MPEG-2 AAC 及 MPEG-4 Audio 的專利野i。
H.264 的開源實現
openh264x264openh264 是思科實現的開源 H.264 編碼，雖然 H.264 需要交納不菲的專利費用，但是專利費有一個年度上限，思科把 OpenH264 實現的年度專利費交滿後，OpenH264 事實上就可以免費自由的使用了。
x264 x264是一個採用GPL授權的視頻編碼自由軟體。x264 的主要弁鄏b於進行 H.264/MPEG-4 AVC 的視頻編碼，而不是作為解碼器（decoder）之用。
除去費用問題比較來看：
openh264 CPU 的占用相對 x264低很多openh264 只支持 baseline profile，x264 支持更多 profileHEVC/H.265
簡介
高效率視頻編碼（High Efficiency Video Coding，簡稱HEVC）是一種視頻壓縮標準，被視為是 ITU-T H.264/MPEG-4 AVC 標準的繼任者。2004 年開始由 ISO/IEC Moving Picture Experts Group（MPEG）和 ITU-T Video Coding Experts Group（VCEG）作為 ISO/IEC23008-2 MPEG-H Part 2 或稱作 ITU-T H.265 開始制定。第一版的 HEVC/H.265 視頻壓縮標準在 2013 年 4 月 13 日被接受為國際電信聯盟（ITU-T）的正式標準。HEVC 被認為不僅提升視頻質量，同時也能達到 H.264/MPEG-4 AVC 兩倍之壓縮率（等同於同樣畫面質量下比特率減少了 50%），可支持 4K解析度甚至到超高畫質電視（UHDTV），最高解析度可達到 8192×4320（8K解析度）。
H.265 的開源實現
libde265x265libde265 HEVC 由 struktur 公司以開源野i證 GNU LesserGeneral Public License (LGPL) 提供，觀眾可以較慢的網速下欣賞到最高品質的影像。跟以前基於H.264標準的解碼器相比，libde265 HEVC 解碼器可以將您的全高清內容帶給多達兩倍的受眾，或者，減少 50% 流媒體播放所需要的帶寬。高清或者 4K/8K超高清流媒體播放，低延遲/低帶寬視頻會議，以及完整的移動設備覆說C具有「擁塞感知」視頻編碼的穩定性，十分適合應用在 3/4G 和 LTE 網絡。
專利野i
HEVC Advance 要求所有包括蘋果、YouTube、Netflix、Facebook、亞馬遜等使用 H.265 技術的內容製造商上繳內容收入的 0.5%作為技術使用費，而整個流媒體市場每年達到約 1000 億美元的規模，且不斷增長中，徵收 0.5%絕對是一筆龐大的費用。而且他們還沒有放過設備製造商，其中電視廠商需要支付每台 1.5 美元、移動設備廠商每台 0.8美元的專利費。他們甚至沒有放過藍光設備播放器、遊戲機、錄像機這樣的廠商，這些廠商必須支付每台 1.1 美元的費用。最無法令人接受的是，HEVC Advance 的專利使用權追溯到了廠商的「」」，意思是之前已經發售的產品依然要追繳費用。
x265 是由 MulticoreWare 開發，並開源。採用 GPL 協議，但是資助這個項目的幾個公司組成了聯盟可以在非 GPL 協議下使用這個軟體。
VP8
簡介
VP8 是一個開放的視頻壓縮格式，最早由 On2 Technologies 開發，隨後由 Google 發布。同時 Google 也發布了 VP8 編碼的實做庫：libvpx，以 BSD 授權條款的方式發行，隨後也附加了專利使用權。而在經過一些爭論之後，最終 VP8 的授權確認為一個開放原始碼授權。
目前支持 VP8 的網頁瀏覽器有 Opera、Firefox 和 Chrome。
專利野i
2013 年三月，Google 與 MPEG LA 及 11 個專利持有者達成協議，讓Google 獲取 VP8 以及其之前的 VPx 等編碼所可能侵犯的專利授權，同時 Google 也可以無償再次授權相關專利給 VP8 的用戶，此協議同時適用於下一代 VPx 編碼。至此 MPEG LA 放棄成立 VP8 專利集中授權聯盟，VP8的用戶將可確定無償使用此編碼而無須擔心可能的專利侵權授權金的問題。
VP8 的開源實現
libvpxlibvpx 是 VP8 的唯一開源實現，由 On2 Technologies 開發，Google 收購後將其開放源碼，License 非常寬鬆可以自由使用。
VP9
簡介
VP9 的開發從 2011 年第三季開始，目標是在同畫質下，比 VP8 編碼減少 50%的文件大小，另一個目標則是要在編碼效率上超越 HEVC 編碼。
2012 年 12 月 13 日，Chromium 瀏覽器加入了 VP9 編碼的支持。Chrome 瀏覽器則是在 2013 年 2 月 21 日開始支持 VP9 編碼的視頻播放。
Google 宣布會在 2013 年 6 月 17 日完成 VP9 編碼的制定工作，屆時Chrome 瀏覽器將會把 VP9 編碼默認引導。2014 年 3 月 18 日，Mozilla 在 Firefox 瀏覽器中加入了 VP9 的支持。
2015 年 4 月 3 日，谷歌發布了 libvpx1.4.0 增加了對 10 位和 12 位的比特深度支持、4:2:2 和 4:4:4 色度抽樣，並 VP9 多核心編/解碼。
專利野i
VP9 是一個開放格式、無權利金的視頻編碼格式。
VP9 的開源實現
libvpxlibvpx 是 VP9 的唯一開源實現，由 Google 開發維護，裡面有部分代碼是 VP8 和 VP9 公用的，其餘分別是 VP8 和 VP9 的編解碼實現。
VP9 和 H.264 和 HEVC 比較
Codec HEVC x264 vp9 HEVC -42.2% 32.6% x264 75.8% 18.5% vp9 48.3% -14.6% Codec HEVC vs. VP9(in %) VP9 vs. x264 (in %) Total Average 612 39399 引用 Comparative Assessment of H.265/MPEG-HEVC, VP9,and
H.264/MPEG-AVC Encoders for Low-Delay Video Applications 這篇比較新的論文對，低延遲視頻進行編碼的測試結果。
HEVC 和 H.264 在不同解析度下的比較
跟 H.264/MPEG-4 相比，HEVC 的平均比特率減低值為：
解析度 480P 720P 1080P 4K UHD HEVC 52% 56% 62% 64% 可見碼率下降了 60% 以上。
HEVC (H.265) 對 VP9 和 H.264 在碼率節省上有較大的優勢，在相同 PSNR 下分別節省了 48.3% 和 75.8%。H.264 在編碼時間上有巨大優勢，對比 VP9 和 HEVC(H.265) ，HEVC 是 VP9 的6倍，VP9 是 H.264 的將近 40 倍FFmpeg
談到視頻編碼相關內容就不得不提一個偉大的軟體包 — FFmpeg。
FFmpeg 是一個自由軟體，可以運行音頻和視頻多種格式的錄影、轉換、流弁遄A包含了 libavcodec ——這是一個用於多個項目中音頻和視頻的解碼器庫，以及 libavformat ——一個音頻與視頻格式轉換庫。
FFmpeg 這個單詞中的 FF 指的是 Fast Forward。有些新手寫信給 FFmpeg 的項目負責人，詢問 FF 是不是代表 Fast Free 或者 Fast Fourier 等意思，FFmpeg 的項目負責人回信說：「Just for the record, the original meaning of FF in FFmpeg is FastForward…」
這個項目最初是由 Fabrice Bellard 發起的，而現在是由 Michael Niedermayer 在進行維護。釵hFFmpeg的開發者同時也是 MPlayer 項目的成員，FFmpeg 在 MPlayer 項目中是被設計為伺服器版本進行開發。
FFmpeg 下載地址是 : FFmpeg Download
可以瀏覽器輸入下載，目前支持 Linux ,Mac OS,Windows 三個主流的平台，也可以自己編譯到 Android 或者 iOS 平台。如果是 Mac OS ，可以通過 brew 安裝 brew install ffmpeg –with-libvpx –with-libvorbis –with-ffplay我們可以用 FFmpeg 來做哪些有用有好玩的事情呢？通過一系列小實驗來帶大家領略 FFmpeg 的神奇和強大。
FFmpeg 錄屏
通過一個小例子看一下怎麼在 Mac OS 下面使用 FFmpeg 進行錄屏:
輸入：
ffmpeg -f avfoundation -list_devices true -i ""輸出：
[AVFoundation input device @ 0x7fbec0c10940] AVFoundation video devices:[AVFoundation input device @ 0x7fbec0c10940] [0] FaceTime HD Camera[AVFoundation input device @ 0x7fbec0c10940] [1] Capture screen 0[AVFoundation input device @ 0x7fbec0c10940] [2] Capture screen 1[AVFoundation input device @ 0x7fbec0c10940] AVFoundation audio devices:[AVFoundation input device @ 0x7fbec0c10940] [0] Built-in Microphone給出了當前設備支持的所有輸入設備的列表和編號，我本地有兩塊顯示器，所以 1 和 2 都是我螢幕，可以選擇一塊進行錄屏。
查看當前的 H.264 編解碼器：
輸入：
ffmpeg -codecs grep 264輸出：
DEV.LS h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_vda ) (encoders: libx264 libx264rgb )查看當前的 VP8 編解碼器：
輸入：
ffmpeg -codecs grep vp8輸出：
DEV.L. vp8 On2 VP8 (decoders: vp8 libvpx ) (encoders: libvpx )可以選擇用 vp8 或者 h264 做編碼器
ffmpeg -r 30 -f avfoundation -i 1 -vcodec vp8 -quality realtime screen2.webm# -quality realtime 用來優化編碼器，如果不加在我的 Air 上幀率只能達到 2or
ffmpeg -r 30 -f avfoundation -i 1 -vcodec h264 screen.mp4然後用 ffplay 播放就可以了
ffplay screen.mp4or
ffplay screen2.webpFFmpeg 視頻轉換成 gif
有一個特別有用的需求，在網上發現了一個特別有趣的視頻想把它轉換成一個動態表情，作為一個 IT 從業者，我第一個想到的不是下載一個轉碼器，也不是去找一個在線轉換網站，直接利用手邊的工具 FFmpeg，瞬間就完成了轉碼：
ffmpeg -ss 10 -t 10 -i tutu.mp4 -s 80×60 tutu.gif## -ss 指從 10s 開始轉碼,-t 指轉換 10s 的視頻 -sFFmpeg 錄製螢幕並直播
可以繼續擴展例子1，直播當前螢幕的內容，向大家介紹一下怎麼通過幾行命令搭建一個測試用的直播服務：
Step 1：首先安裝 docker：
訪問 Docker Download ，按作業系統下載安裝。
Step 2：下載 nginx-rtmp 鏡像：
docker pull chakkritte/docker-nginx-rtmpStep 3：創建 nginx html 路徑，啟動 docker-nginx-rtmp
mkdir ~/rtmpdocker run -d -p 80:80 -p 1935:1935 -v ~/rtmp:/usr/local/nginx/html chakkritte/docker-nginx-rtmpStep 4：推送螢幕錄製到 nignx-rtmp
ffmpeg -y -loglevel warning -f avfoundation -i 2 -r 30 -s 480×320 -threads 2 -vcodec libx264 -f flv rtmp://127.0.0.1/live/testStep 5：用 ffplay 播放
ffplay rtmp://127.0.0.1/live/test總結一下，FFmpeg 是個優秀的工具，可以通過它完成很多日常的工作和實驗，但是距離提供真正可用的流媒體服務、直播服務還有非常多的工作要做，這方面可以參考七牛雲發布的 七牛直播雲服務 。
封裝
介紹完了視頻編碼後，再來介紹一些封裝。沿用前面的比喻，封裝可以理解為採用哪種貨車去運輸，也就是媒體的容器。
所謂容器，就是把編碼器生成的多媒體內容（視頻，音頻，字幕，章節信息等）混合封裝在一起的標準。容器使得不同多媒體內容同步播放變得很簡單，而容器的另一個作用就是為多媒體內容提供索引，也就是說如果沒有容器存在的話一部影片你只能從一開始看到最後，不能拖動進度條（當然這種情況下有的播放器會話比較長的時間臨時創建索引），而且如果你不自己去手動另外載入音頻就沒有聲音，下面介紹幾種常見的封裝格式和優缺點：
AVI 格式（後綴為 .AVI）: 它的英文全稱為 Audio Video Interleaved ，即音頻視頻交錯格式。它於 1992 年被 Microsoft 公司推出。這種視頻格式的優點是圖像質量好。由於無損AVI可以保存 alpha 通道，經常被我們使用。缺點太多，體積過於龐大，而且更加糟糕的是壓縮標準不統一，最普遍的現象就是高版本 Windows 媒體播放器播放不了採用早期編碼編輯的AVI格式視頻，而低版本 Windows媒體播放器又播放不了採用最新編碼編輯的AVI格式視頻，所以我們在進行一些AVI格式的視頻播放時常會出現由於視頻編碼問題而造成的視頻不能播放或即使能夠播放，但存在不能調節播放進度和播放時只有聲音沒有圖像等一些莫名其妙的問題。DV-AVI 格式（後綴為 .AVI）: DV的英文全稱是 Digital Video Format ，是由索尼、松下、JVC 等多家廠商聯合提出的一種家用數字視頻格式。數字攝像機就是使用這種格式記錄視頻數據的。它可以通過電腦的 IEEE 1394 埠傳輸視頻數據到電腦，也可以將電腦中編輯好的的視頻數據回錄到數碼攝像機中。這種視頻格式的文件擴展名也是 avi。電視台採用錄像帶記錄模擬信號，通過 EDIUS 由IEEE 1394埠採集卡從錄像帶中採集出來的視頻就是這種格式。QuickTime File Format 格式（後綴為 .MOV）: 美國Apple公司開發的一種視頻格式，默認的播放器是蘋果的QuickTime。具有較高的壓縮比率和較完美的視頻清晰度等特點，並可以保存alpha通道。MPEG 格式（文件後綴可以是 .MPG .MPEG .MPE .DAT .VOB .ASF .3GP .MP4等) : 它的英文全稱為 Moving Picture Experts Group，即運動圖像專家組格式，該專家組建於1988年，專門負責為 CD 建立視頻和音頻標準，而成員都是為視頻、音頻及系統領域的技術專家。MPEG 文件格式是運動圖像壓縮算法的國際標準。MPEG 格式目前有三個壓縮標準，分別是 MPEG－1、MPEG－2、和MPEG－4 。MPEG－1、MPEG－2 目前已經使用較少，著重介紹 MPEG－4，其制定於1998年，MPEG－4 是為了播放流式媒體的高質量視頻而專門設計的，以求使用最少的數據獲得最佳的圖像質量。目前 MPEG-4最有吸引力的地方在於它能夠保存接近於DVD畫質的小體積視頻文件。WMV 格式（後綴為.WMV .ASF）: 它的英文全稱為Windows Media Video，也是微軟推出的一種採用獨立編碼方式並且可以直接在網上實時觀看視頻節目的文件壓縮格式。WMV格式的主要優點包括：本地或網絡回放,豐富的流間關係以及擴展性等。WMV 格式需要在網站上播放，需要安裝 Windows Media Player（ 簡稱 WMP ），很不方便，現在已經幾乎沒有網站採用了。Real Video 格式（後綴為 .RM .RMVB）: Real Networks 公司所制定的音頻視頻壓縮規範稱為Real Media。用戶可以使用 RealPlayer 根據不同的網絡傳輸速率制定出不同的壓縮比率，從而實現在低速率的網絡上進行影像數據實時傳送和播放。RMVB 格式：這是一種由RM視頻格式升級延伸出的新視頻格式，當然性能上有很大的提升。RMVB 視頻也是有著較明顯的優勢，一部大小為700MB左右的 DVD 影片，如果將其轉錄成同樣品質的 RMVB 格式，其個頭最多也就 400MB左右。大家可能注意到了，以前在網絡上下載電影和視頻的時候，經常接觸到 RMVB 格式，但是隨著時代的發展這種格式被越來越多的更優秀的格式替代，著名的人人影視字幕組在2013年已經宣布不再壓制 RMVB 格式視頻。Flash Video 格式（後綴為 .FLV）:由 Adobe Flash 延伸出來的的一種流行網絡視頻封裝格式。隨著視頻網站的豐富，這個格式已經非常普及。Matroska 格式（後綴為 .MKV）:是一種新的多媒體封裝格式，這個封裝格式可把多種不同編碼的視頻及16條或以上不同格式的音頻和語言不同的字幕封裝到一個 Matroska Media 檔內。它也是其中一種開放原始碼的多媒體封裝格式。Matroska 同時還可以提供非常好的交互弁遄A而且比 MPEG 的方便、強大。MPEG2-TS 格式 (後綴為 .ts)（Transport Stream「傳輸流」；又稱MTS、TS）是一種傳輸和存儲包含音效、視頻與通信協議各種數據的標準格式，用於數位電視廣播系統，如DVB、ATSC、IPTV等等。MPEG2-TS 定義於 MPEG-2 第一部分，系統（即原來之ISO/IEC標準13818-1或ITU-T Rec. H.222.0）。Media Player Classic、VLC 多媒體播放器等軟體可以直接播放MPEG-TS文件。目前，我們在流媒體傳輸，尤其是直播中主要採用的就是 FLV 和 MPEG2-TS 格式，分別用於 RTMP/HTTP-FLV 和 HLS 協議。
下一期我們將系統講解視頻直播的推流和傳輸，盡請期待~