歡迎大家前往 "騰訊雲+社區" ，獲取更多騰訊海量技術實踐乾貨哦~ 本文由 "goo" 發表於 "雲+社區專欄" 與生活緊密相連的音視頻，為何有那麼多格式？直播、點播以及即時視頻其中又有怎樣的機制支撐？面對紛繁複雜的音視頻知識，應該如何學起？快速探索，音視頻技術不再神秘。 前言 面對一門技術，我們熟 ...
歡迎大家前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~
與生活緊密相連的音視頻，為何有那麼多格式？直播、點播以及即時視頻其中又有怎樣的機制支撐？面對紛繁複雜的音視頻知識，應該如何學起？快速探索，音視頻技術不再神秘。
前言
面對一門技術，我們熟悉而陌生，我們能夠熟練的基於平臺的API完成各種各樣的需求，掌握平臺特性、框架與原理。但隨著技術點不斷深入，卻發現自己存在基礎性與深度性的知識盲區。
局限於平臺API開發，並不能使我們走的很遠。突破技術成長必經的瓶頸期，關鍵在於技術沉澱與對業務方向相結合，需要我們對知識積累與深入。本文分享了筆者對音視頻技術知識網路的探索路徑，希望能給大家帶來幫助。
一、採集 - 數據從哪裡來？
1.1 採樣原理
定義：對連續變化圖像在空間坐標上做離散化處理，將模擬信號轉變成數字信號的過程，即為圖像進行採樣。
通俗來說：採集就是將看到的東西轉成二進位流的過程。
1.2 基礎概念
1.2.1 圖像
「圖像」是個集合的概念，幀、頂場、底場都可以稱為圖像。
- 幀 一幀通常是一幅完整圖像，當採用逐行掃描方式掃描，每次掃描得到的信號就是一幀。
- 頂場與底場 採集視頻信號時，掃描方式分為逐行掃描與隔行掃描。如果採用逐行掃描，得到的則是一幅完整的圖像；而採用隔行掃描（奇、偶數行），則掃描下來的一幀圖像就被分為了兩個部分，這每一部分就稱為「場」，根據次序分為：「頂場」和「底場」
- 隔行掃描 每一幀被分割為兩場畫面交替顯示。每一幀被分割為頂場與底場，通常是先掃描奇數行得到第一場，然後掃描偶數行得到第二場。由於視覺暫留效應，人眼將會看到平滑的運動而不是閃動的半幀半幀的圖像。但是這時會有閃爍出現，儘管不容易被察覺，但會使得人眼容易疲勞。當屏幕的內容是橫條紋時，這種閃爍特別容易被註意到，並且會有鋸齒瑕疵。
- 逐行掃描 則是將每幀的所有畫面同時顯示。每次都顯示整個掃描幀，如果逐行掃描的幀率和隔行掃描的場率相同，人眼將看到比隔行掃描更平滑的圖像，相對於隔行掃描來說閃爍較小。每一幀圖像均是由電子束順序地一行接著一行連續掃描而成，這種掃描方式稱為逐行掃描。
- 兩者區別 舉個慄子，25fps 100行幀圖像，那麼隔行掃描需要一秒掃描50次，但每次只需要掃描50行。而逐行掃描則只需要掃描25次，但每次需要掃描100行。 結論：隔行掃描掃描頻率為逐行掃描雙倍，通道帶寬為逐行掃描的一半。在圖像體驗降低不多的情況下，通道帶寬減少了一半，使得設備成本減少，因此，早期大多數顯示器都採用隔行掃描。
- 傳送門：逐行掃描、隔行掃描詳細講解
逐行掃描與隔行掃描
頂場與底場，隔行掃描鋸齒瑕疵
1.2.2 顏色模型
RGB顏色模型
RGB模型
RGB分別代表紅綠藍，每種顏色需要用3個數字表示，一個數字占用1位元組，一種顏色則需要3位元組，24位。
更高效的顏色模型？YUV
YCbCr顏色模型
YCbCr顏色模型是YUV家族的一員，關鍵特點在於它亮度信號Y與色度信號U、V相互分離。當缺失U、V，僅有Y信號時，也能夠表示出黑白圖像。
Y = kr\*R + kg\*G + kb\*BY 即「亮度」，kr、kg、kb 即 R、G、B 的權重值。
Cr = R – Y; Cg = G – Y; Cb = B – Y;疑問：對比RGB模型，YCbCr模型每個像素也需要3個信號表示，為什麼說該模型更高效？
優化思路
人眼對亮度解析度敏感度高於色彩敏感度。
視覺特性
基於人眼視覺特性，很明顯，我們需要從顏色方面入手，於是提出“色度取樣”，使顏色存儲減半或者更多。容易實現，編碼壓力較小，收益較高。
色度取樣
優化實現
我們知道顯示器掃描原理分為逐行掃描與隔行掃描，每條掃描線被掃描時，色度數值傳送頻率會比亮度低，顏色取樣方式有多種，取樣方式通常基於亮度值，以4:X:Y的形式描述，X和Y是每兩個色度通道中的數值的相對數量：
顯示器掃描顯示原理
繼續舉個慄子：
YCbCr像素點
我們有這樣一幅圖片，上面有像素陣列：
原始像素陣列
YCbCr 4:4:4
會有以下幾種採樣優化方式：
4:2:2優化後像素陣列
4:2:2取樣方式
4:2:0優化後像素陣列
4:2:0取樣方式
上圖可以很直觀的看出：採用YCbCr顏色模型後，並不需要每個像素都存有3個分量，顏色分量通過“色度取樣”後，有效的減少了顏色分量的存儲。
1.3 圖像感知與獲取
成像感測器
- 通過電功率和對特殊類型檢測能源敏感的感測器材料組合。
- 將輸入的光照能量變為特殊的電壓波形。
- 波形的幅度和空間特性都與感知的物理現象有關。為了產生數字圖像，接下來需要進行取樣與量化處理。
1.4 取樣與量化
舉個慄子，對於黑白圖像圖(a)為連續圖像，如果需要轉換成數字形式，需要幾步主要操作：
取樣與量化
取樣：(a)圖上沿AB線段等間隔對該圖像取樣，得到灰度級曲線(b)
量化：
(c)圖右側將灰度分為8個灰度級，再橫向每一取樣的連續灰度值，量化為8個灰度之一，最終得到(d)圖，感知器輸出的量化完成流產生數字圖像的過程。
a. 圖像投影至感測器陣列 b. 圖像取樣與量化結果
二、渲染 - 數據如何展現？
2.1 播放器原理
播放器播放從互聯網上播放視頻，需要經過：解協議、解封裝、解碼、音視頻同步這幾個核心步驟。
互聯網播放視頻流程
- 解協議：將流媒體協議數據，解析為標準封裝格式數據。流媒體協議傳輸音視頻數據同時，也會傳輸一些信令數據，其中包括：播放控制、網路狀態描述等。常見流媒體協議如HTTP、RTMP或MMS等。
- 解封裝：將解協議得到的標準封裝格式數據，分離為音頻流壓縮編碼數據與視頻流壓縮編碼數據。封裝格式也稱為容器，即是將已經編碼壓縮好的視頻軌與音頻軌按照一定格式放到一個文件中。 需要註意的是：就算是同一個封裝格式，其編碼方式並不一定一樣，我們可以從尾碼名中直觀的看到視頻文件到封裝格式。常見封裝格式：avi，rmvb，mp4，flv，mkv等。
- 解碼：就是將音視頻壓縮編碼數據，解碼成為非壓縮的音視頻原始數據。音頻編碼標準有AAC，MP3，AC-3等；視頻編碼標準包含H.264，MPEG2，VC-1等。編解碼是整個流程最核心與最複雜的環節。
- 音視頻同步：根據解封裝過程獲取的參數信息，將解碼出來的音視頻數據進行同步對其，最終將數據傳送到系統，由系統調用硬體進行播放。
2.2 視頻編碼方式
視頻編解碼過程是數字視頻壓縮與解壓縮的過程。
選取音視頻編碼方案時，需要考慮：視頻的質量、碼率、編碼演算法和解碼演算法的複雜度、針對數據丟失和錯誤的魯棒性（Robustness）、編輯的方便性、隨機訪問、編碼演算法設計的完美性、端到端的延時以及其它一些因素。
2.2.1 H.26X系列概述
H.26X 系列，由國際電傳視訊聯盟遠程通信標準化組織(ITU-T)主導，包括 H.261、H.262、H.263、H.264、H.265。
- H.261，主要用於老的視頻會議和視頻電話系統。是第一個使用的數字視頻壓縮標準。實質上說，之後的所有的標準視頻編解碼器都是基於它設計的。
- H.262，等同於 MPEG-2 第二部分，使用在 DVD、SVCD 和大多數數字視頻廣播系統和有線分佈系統中。
- H.263，主要用於視頻會議、視頻電話和網路視頻相關產品。在對逐行掃描的視頻源進行壓縮的方面，H.263 比它之前的視頻編碼標準在性能上有了較大的提升。尤其是在低碼率端，它可以在保證一定質量的前提下大大的節約碼率。
- H.264，等同於 MPEG-4 第十部分，也被稱為高級視頻編碼(Advanced Video Coding，簡稱 AVC)，是一種視頻壓縮標準，一種被廣泛使用的高精度視頻的錄製、壓縮和發佈格式。該標準引入了一系列新的能夠大大提高壓縮性能的技術，並能夠同時在高碼率端和低碼率端大大超越以前的諸標準。
- H.265，被稱為高效率視頻編碼(High Efficiency Video Coding，簡稱 HEVC)是一種視頻壓縮標準，是 H.264 的繼任者。HEVC 被認為不僅提升圖像質量，同時也能達到 H.264 兩倍的壓縮率（等同於同樣畫面質量下比特率減少了 50%），可支持 4K 解析度甚至到超高畫質電視，最高解析度可達到 8192×4320（8K 解析度），這是目前發展的趨勢。
- 詳解待整理另外文章
2.2.2 MPEG系列概述
MPEG 系列，由國際標準組織機構(ISO)下屬的運動圖象專家組(MPEG)開發。
- MPEG-1 第二部分，主要使用在 VCD 上，有些線上視頻也使用這種格式。該編解碼器的質量大致上和原有的 VHS 錄像帶相當。
- MPEG-2 第二部分，等同於 H.262，使用在 DVD、SVCD 和大多數數字視頻廣播系統和有線分佈系統中。
- MPEG-4 第二部分，可以使用在網路傳輸、廣播和媒體存儲上。比起 MPEG-2 第二部分和第一版的 H.263，它的壓縮性能有所提高。
- MPEG-4 第十部分，等同於 H.264，是這兩個編碼組織合作誕生的標準。
- 詳解待整理另外文章
2.3 音頻編解碼方式
除了視頻，音頻當然也需要編碼，而音頻常用編碼格式：
- AAC，英文全稱 Advanced Audio Coding，是由 Fraunhofer IIS、杜比實驗室、AT&T、Sony等公司共同開發，在 1997 年推出的基於 MPEG-2 的音頻編碼技術。2000 年，MPEG-4 標準出現後，AAC 重新集成了其特性，加入了 SBR 技術和 PS 技術，為了區別於傳統的 MPEG-2 AAC 又稱為 MPEG-4 AAC。（AAC詳解待整理另外文章）
- MP3，英文全稱 MPEG-1 or MPEG-2 Audio Layer III，是當曾經非常流行的一種數字音頻編碼和有損壓縮格式，它被設計來大幅降低音頻數據量。它是在 1991 年，由位於德國埃爾朗根的研究組織 Fraunhofer-Gesellschaft 的一組工程師發明和標準化的。MP3 的普及，曾對音樂產業造成極大的衝擊與影響。
- WMA，英文全稱 Windows Media Audio，由微軟公司開發的一種數字音頻壓縮格式，本身包括有損和無損壓縮格式。
三、處理 - 數據怎麼加工？
音視頻加工處理，是業務的核心需求，對開發者自由度最大的一個環節，通過音視頻處理，可以實現各種各樣炫酷的特效。
圖像、視頻常見處理方式：美化、裁剪、縮放、旋轉、疊加、編解碼等。
音頻常見處理方式：重採樣、去噪，回聲消除，混音、編解碼等
常見框架：
- 圖像處理：OpenGL，OpenCV，libyuv，ffmpeg 等；
- 視頻編解碼：x264，OpenH264，ffmpeg 等；
- 音頻處理：speexdsp，ffmpeg 等；
- 音頻編解碼：libfaac，opus，speex，ffmpeg 等。
（傳送門：音視頻開發開源碼工程彙總）
四、傳輸 - 數據如何傳輸？
4.1 流媒體協議
流媒體，指通過互聯網以流式傳輸方式的媒體。流媒體協議，則是伺服器與客戶端之間通信遵循但規定。說到音視頻傳輸，我們不得不提流媒體協議，常見流媒體協議有：
| 協議 | 概述 | 特點 | 應用場景 |
|---|---|---|---|
| RTP | （Real-time Transport Protocol）一種網路傳輸協議，RTP協議詳細說明瞭在互聯網上傳遞音頻和視頻的標準數據包格式。 | 基於UDP 協議實現 | RTP協議常用於流媒體系統（配合 RTSP 協議） |
| RTCP | （Real-time Transport Control Protoco）實時傳輸協議（RTP）的一個姐妹協議。 | RTCP為RTP媒體流提供通道外（out-of-band）控制。RTCP 本身並不傳輸數據，但和 RTP 一起協作將多媒體數據打包和發送。RTCP 定期在流多媒體會話參加者之間傳輸控制數據。 | 為 RTP 所提供的服務質量（Quality of Service）提供反饋。 |
| RTSP | （Real Time Streaming Protocol）定義了一對多應用程式如何有效地通過 IP 網路傳送多媒體數據。 | RTSP 在體繫結構上位於 RTP 和 RTCP 之上，使用 TCP 或 UDP 完成數據傳輸 | 使用 RTSP 時，客戶機和伺服器都可以發出請求，即 RTSP 可以是雙向的。 |
| RTMP | （Real Time Messaging Protocol）Adobe Systems 公司為 Flash 播放器和伺服器之間音頻、視頻和數據傳輸開發的開放協議。 | 協議基於 TCP，是一個協議族，包括 RTMP 基本協議及 RTMPT/RTMPS/RTMPE 等多種變種。 | 一種設計用來進行實時數據通信的網路協議，主要用來在 Flash/AIR 平臺和支持RTMP協議的流媒體/交互伺服器之間進行音視頻和數據通信。 |
| RTMFP | （Real Time Media Flow0 Protoco）Adobe 公司開發的一套新的通信協議，全稱 Real Time Media Flow Protocol | 協議基於 UDP，支持 C/S 模式和 P2P 模式，即該協議可以讓使用 Adobe Flash Player 的終端用戶之間進行直接通信 | Adobe Flash Player 的終端用戶之間進行直接通信 |
| HTTP | （HyperText Transfer Protoco）運行在 TCP 之上 | 這個協議是大家非常熟悉的，它也可以用到視頻業務中來。 | |
| HLS | （HTTP Live Streaming）是蘋果公司實現的基於 HTTP 的流媒體傳輸協議，全稱 ，可支持流媒體的直播和點播 | 短時長的媒體文件（MPEG-TS 格式），客戶端不斷的下載並播放這些小文件。由於數據通過 HTTP 協議傳輸，所以完全不用考慮防火牆或者代理的問題，而且分段文件的時長很短，客戶端可以很快的選擇和切換碼率，以適應不同帶寬條件下的播放 HLS 的這種技術特點，決定了它的延遲一般總是會高於普通的流媒體直播協議 | 主要應用在 iOS 系統，為 iOS 設備（如 iPhone、iPad）提供音視頻直播和點播方案。 |
4.2 網路視頻點播業務
| 公司 | 協議 | 封裝 | 視頻編碼 | 音頻編碼 | 播放器 |
|---|---|---|---|---|---|
| CNTV | HTTP | MP4 | H.264 | AAC | Flash |
| CNTV（部分） | RTMP | FLV | H.264 | AAC | Flash |
| 華數 TV | HTTP | MP4 | H.264 | AAC | Flash |
| 優酷網 | HTTP | FLV | H.264 | AAC | Flash |
| 土豆網 | HTTP | F4V | H.264 | AAC | Flash |
| 56網 | HTTP | FLV | H.264 | AAC | Flash |
| 音悅台 | HTTP | MP4 | H.264 | AAC | Flash |
| 樂視網 | HTTP | FLV | H.264 | AAC | Flash |
| 新浪視頻 | HTTP | FLV | H.264 | AAC | Flash |
網路視頻點播業務採用 HTTP 有兩方面優勢：
- HTTP 是基於 TCP 協議的應用層協議，媒體傳輸過程中不會出現丟包等現象，從而保證了視頻的質量。
- HTTP 是絕大部分的 Web 伺服器支持的協議，因而流媒體服務機構不必投資購買額外的流媒體伺服器，從而節約了開支。
對於封裝格式：MP4，FLV，F4V 幾者只是容器，帶來的差異不大，而關鍵的是音視頻解碼方式：H.264與AAC，這兩種編碼標準目前仍被最廣泛的應用。
4.3 網路視頻直播業務
| 公司 | 協議 | 封裝 | 視頻編碼 | 音頻編碼 | 播放器 |
|---|---|---|---|---|---|
| 華數TV | RTMP | FLV | H.264 | AAC | Flash |
| 六間房 | RTMP | FLV | H.264 | AAC | Flash |
| 中國教育電視臺 | RTMP | FLV | H.264 | AAC | Flash |
| 北廣傳媒移動電視 | RTMP | FLV | H.264 | AAC | Flash |
| 上海IPTV | RTSP+RTP | TS | H.264 | MP2 | 機頂盒 |
網路視頻直播服務採用 RTMP 作為直播協議的好處是可以直接被 Flash 播放器支持，而 Flash 播放器在 PC 時代有著極高的普及率，並且與瀏覽器結合的很好。因此這種流媒體直播平臺基本上可以實現了「無插件直播」，極大降低了用戶使用成本。
封裝格式、視頻編碼、音頻編碼、播放器方面幾乎全部採用了 FLV、H.264、AAC、Flash。FLV、RTMP、Flash 都是 Adobe 公司的產品，天生有著良好的結合性。
4.4 總結
以上為PC時代舊數據，現移動互聯網已爆發，H5 以及客戶端應用的普及，行業中對視頻業務技術方案的選擇也逐漸在發生著變化，而我們則需要結合眼下的實際情況和技術發展的趨勢去做出合適的技術選型。
結語
音視頻技術道路很長，本文旨在搭建音視頻知識知識網，許多知識未能深入，後續仍需要我們不斷學習與實踐，抱著追求極致的精神去探索發現，加油，我們共同快速成長！
此文已由作者授權騰訊雲+社區發佈，更多原文請點擊
搜索關註公眾號「雲加社區」，第一時間獲取技術乾貨，關註後回覆1024 送你一份技術課程大禮包！
海量技術實踐經驗，盡在雲加社區！
