「ApsaraVideo for Live技術詳解」系列之三：編碼和封裝，

「ApsaraVideo for Live技術詳解」系列之三：編碼和封裝，

關於直播的技術文章不少，成體系的不多。我們將用七篇文章，更系統化地介紹當下大熱的ApsaraVideo for Live各環節的關鍵技術，協助ApsaraVideo for Live創業者們更全面、深入地瞭解ApsaraVideo for Live技術，更好地技術選型。

視頻編碼是ApsaraVideo for Live技術系列文章的第三篇，是本系列一個非常重要的部分，是移動開發必修的基礎課程，本篇文章從理論到實踐一網打盡主流編碼器。

如果把整個流媒體比喻成一個物流系統，那麼編解碼就是其中配貨和裝貨的過程，這個過程非常重要，它的速度和壓縮比對物流系統的意義非常大，影響物流系統的整體速度和成本。同樣，對流媒體傳輸來說，編碼也非常重要，它的編碼效能、編碼速度和編碼壓縮比會直接影響整個流媒體傳輸的使用者體驗和傳輸成本。

本系列文章大綱如下，想複習之前文章的直接點擊直達連結：

（一）採集

（二）處理

（三）編碼和封裝

（四）推流和傳輸

（五）延遲最佳化

（六）現代播放器原理

（七）SDK 效能測試模型

 

視頻編碼的意義

• 原始視頻資料存放區空間大，一個 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.mp4

 

ffmpeg -i tutudebug2.mp4 'tutunormal-%03d.bmp'

　　　

除了空間冗餘和時間冗餘的壓縮，主要還有編碼壓縮和視覺壓縮，下面是一個編碼器主要的流程圖：

圖 3

圖 4

圖 3、圖 4 兩個流程，圖 3 是幀內編碼，圖 4 是幀間編碼，從圖上看到的主要區別就是第一步不相同，其實這兩個流程也是結合在一起的，我們通常說的 I 幀和 P 幀就是分別採用了幀內編碼和幀間編碼。

 

編碼器的選擇

前面梳理了一下編碼器的原理和基本流程，編碼器經曆了數十年的發展，已經從開始的只支援幀內編碼演化到現如今的 H.265 和 VP9 為代表的新一代編碼器，就目前一些常見的編碼器進行分析，帶大家探索一下編碼器的世界。

1) 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 需要交納不菲的專利費用。

專利許可

和 MPEG-2 第一部分、第二部分，MPEG-4第二部分一樣，使用 H.264/AVC 的產品製造商和服務提供者需要向他們的產品所使用的專利的持有人支付專利許可費用。這些專利許可的主要來源是一家稱為 MPEG-LA LLC 的私人組織，該組織和 MPEG 標準化組織沒有任何關係，但是該組織也管理著 MPEG-2 第一部分系統、第二部分視頻、MPEG-4 第二部分視頻和其它一些技術的專利許可。

其他的專利許可則需要向另一家稱為 VIA Licensing 的私人組織申請，這家公司另外也管理偏向音頻壓縮的標準如 MPEG-2 AAC 及 MPEG-4 Audio 的專利許可。

H.264 的開源實現

• openh264
• x264

openh264 是思科實現的開源 H.264 編碼，雖然 H.264 需要交納不菲的專利費用，但是專利費有一個年度上限，思科把 OpenH264 實現的年度專利費交滿後，OpenH264 事實上就可以免費自由的使用了。

x264 x264是一個採用GPL授權的視頻編碼自由軟體。x264 的主要功能在於進行 H.264/MPEG-4 AVC 的視頻編碼，而不是作為解碼器（decoder）之用。

除去費用問題比較來看：

• openh264 CPU 的佔用相對 x264低很多
• openh264 只支援 baseline profile，x264 支援更多 profile

2) HEVC/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/IEC 23008-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 的開源實現

• libde265
• x265

libde265 HEVC 由 struktur 公司以開源許可證 GNU LesserGeneral Public License (LGPL) 提供，觀眾可以較慢的網速下欣賞到最高品質的影像。跟以前基於H.264標準的解碼器相比，libde265 HEVC 解碼器可以將您的全高清內容帶給多達兩倍的受眾，或者，減少 50% 流媒體播放所需要的頻寬。高清或者 4K/8K 超高清流媒體播放，低延遲/低頻寬視頻會議，以及完整的行動裝置覆蓋。具有「擁塞感知」視頻編碼的穩定性，十分適合應用在 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 協議下使用這個軟體。

3) 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 的開源實現

• libvpx

libvpx 是 VP8 的唯一開源實現，由 On2 Technologies 開發，Google 收購後將其開放源碼，License 非常寬鬆可以自由使用。

4) 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 日，Google發布了 libvpx1.4.0 增加了對 10 位和 12 位的位元深度支援、4:2:2 和 4:4:4 色度抽樣，並 VP9 多核心編/解碼。

專利許可

VP9 是一個開放格式、無權利金的視頻編碼格式。

VP9 的開源實現

• libvpx

libvpx 是 VP9 的唯一開源實現，由 Google 開發維護，裡面有部分代碼是 VP8 和 VP9 公用的，其餘分別是 VP8 和 VP9 的編解碼實現。

VP9 和 H.264 和 HEVC 比較

CodecHEVCx264vp9HEVC-42.2%32.6%x26475.8%18.5%vp948.3%-14.6%CodecHEVC vs. VP9(in %)VP9 vs. x264 (in %)Total Average61239399

引用 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 的平均位元速率減低值為：

解析度480P720P1080P4K UHDHEVC52%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 倍

5) FFmpeg

談到視頻編碼相關內容就不得不提一個偉大的軟體包 -- FFmpeg。

FFmpeg 是一個自由軟體，可以運行音頻和視頻多種格式的錄影、轉換、流功能，包含了 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 Fast Forward...」

這個項目最初是由 Fabrice Bellard 發起的，而現在是由 Michael Niedermayer 在進行維護。許多FFmpeg的開發人員同時也是 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 上幀率只能達到 2

or

ffmpeg -r 30 -f avfoundation -i 1 -vcodec h264 screen.mp4

然後用 ffplay 播放就可以了

ffplay screen.mp4

or

ffplay screen2.webp

FFmpeg 視頻轉換成 gif

有一個特別有用的需求，在網上發現了一個特別有趣的視頻想把它轉換成一個動態表情，作為一個 IT 從業者，我第一個想到的不是下載一個轉碼器，也不是去找一個線上轉換網站，直接利用手邊的工具 FFmpeg，瞬間就完成了轉碼：

ffmpeg -ss 10 -t 10  -i tutu.mp4  -s 80x60  tutu.gif## -ss 指從 10s 開始轉碼,-t 指轉換 10s 的視頻 -s

FFmpeg 錄製螢幕並直播

可以繼續擴充例子1，直播當前螢幕的內容，向大家介紹一下怎麼通過幾行命令搭建一個測試用的直播服務：

Step 1：首先安裝 docker：
訪問 Docker Download ，按作業系統下載安裝。

Step 2：下載 nginx-rtmp 鏡像：

docker pull chakkritte/docker-nginx-rtmp

Step 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-rtmp

Step 4：推送螢幕錄製到 nignx-rtmp

ffmpeg -y -loglevel warning -f avfoundation -i 2 -r 30 -s 480x320 -threads 2 -vcodec libx264  -f flv rtmp://127.0.0.1/live/test

Step 5：用 ffplay 播放

ffplay rtmp://127.0.0.1/live/test

總結一下，FFmpeg 是個優秀的工具，可以通過它完成很多日常的工作和實驗，但是距離提供真正可用的流媒體服務、直播服務還有非常多的工作要做，這方面可以參考七牛雲發布的 七牛直播雲端服務 。

 

封裝

介紹完了視頻編碼後，再來介紹一些封裝。沿用前面的比喻，封裝可以理解為採用哪種貨車去運輸，也就是媒體的容器。

所謂容器，就是把編碼器產生的多媒體內容（視頻，音頻，字幕，章節資訊等）混合封裝在一起的標準。容器使得不同多媒體內容同步播放變得很簡單，而容器的另一個作用就是為多媒體內容提供索引，也就是說如果沒有容器存在的話一部影片你只能從一開始看到最後，不能拖動進度條（當然這種情況下有的播放器會話比較長的時間臨時建立索引），而且如果你不自己去手動另外載入音頻就沒有聲音，下面介紹幾種常見的封裝格式和優缺點：

目前，我們在流媒體傳輸，尤其是直播中主要採用的就是 FLV 和 MPEG2-TS 格式，分別用於 RTMP/HTTP-FLV 和 HLS 協議。

下一期我們將系統講解ApsaraVideo for Live的推流和傳輸，敬請期待~

 

 本文作者： 蔔赫@七牛雲佈道師，更多雲行業技術洞見請訪問七牛雲部落格。