快速探索，音視訊技術不再神祕
歡迎大家前往騰訊雲+社群，獲取更多騰訊海量技術實踐乾貨哦~
本文由goo發表於雲+社群專欄
與生活緊密相連的音視訊，為何有那麼多格式？直播、點播以及即時視訊其中又有怎樣的機制支撐？面對紛繁複雜的音視訊知識，應該如何學起？快速探索，音視訊技術不再神祕。
前言
面對一門技術，我們熟悉而陌生，我們能夠熟練的基於平臺的API完成各種各樣的需求，掌握平臺特性、框架與原理。但隨著技術點不斷深入，卻發現自己存在基礎性與深度性的知識盲區。
侷限於平臺API開發，並不能使我們走的很遠。突破技術成長必經的瓶頸期，關鍵在於技術沉澱與對業務方向相結合，需要我們對知識積累與深入。本文分享了筆者對音視訊技術知識網路的探索路徑，希望能給大家帶來幫助。
一、採集 - 資料從哪裡來？
1.1 取樣原理
定義： 對連續變化影象在空間座標上做離散化處理，將 模擬訊號轉變成數字訊號 的過程，即為影象進行取樣。
通俗來說： 採集就是將看到的東西轉成二進位制流的過程。
1.2 基礎概念
1.2.1 影象
「影象」是個集合的概念，幀、頂場、底場都可以稱為影象。
- 幀 一幀通常是一幅完整影象，當採用逐行掃描方式掃描，每次掃描得到的訊號就是一幀。
- 頂場與底場 採集視訊訊號時，掃描方式分為逐行掃描與隔行掃描。如果採用逐行掃描，得到的則是一幅完整的影象；而採用隔行掃描（奇、偶數行），則掃描下來的一幀影象就被分為了兩個部分，這每一部分就稱為「場」，根據次序分為：「頂場」和「底場」
- 隔行掃描 每一幀被分割為兩場畫面交替顯示。每一幀被分割為頂場與底場，通常是先掃描奇數行得到第一場，然後掃描偶數行得到第二場。由於視覺暫留效應，人眼將會看到平滑的運動而不是閃動的半幀半幀的影象。但是這時會有閃爍出現，儘管不容易被察覺，但會使得人眼容易疲勞。當螢幕的內容是橫條紋時，這種閃爍特別容易被注意到，並且會有鋸齒瑕疵。
- 逐行掃描 則是將每幀的所有畫面同時顯示。每次都顯示整個掃描幀，如果逐行掃描的幀率和隔行掃描的場率相同，人眼將看到比隔行掃描更平滑的影象，相對於隔行掃描來說閃爍較小。每一幀影象均是由電子束順序地一行接著一行連續掃描而成，這種掃描方式稱為逐行掃描。
- 兩者區別 舉個栗子，25fps 100行幀影象，那麼隔行掃描需要一秒掃描50次，但每次只需要掃描50行。而逐行掃描則只需要掃描25次，但每次需要掃描100行。 結論：隔行掃描掃描頻率為逐行掃描雙倍，通道頻寬為逐行掃描的一半。在影象體驗降低不多的情況下，通道頻寬減少了一半，使得裝置成本減少，因此，早期大多數顯示器都採用隔行掃描。
- 傳送門： ofollow,noindex">逐行掃描、隔行掃描詳細講解
逐行掃描與隔行掃描
頂場與底場，隔行掃描鋸齒瑕疵
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\*B
Y 即「亮度」，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 影象感知與獲取
<img src=" https:// ask.qcloudimg.com/draft /2557878/yjqoq9qlhg.png "
width="70%" />
成像感測器
</center>
- 通過電功率和對特殊型別檢測能源敏感的感測器材料組合。
- 將輸入的光照能量變為特殊的電壓波形。
- 波形的幅度和空間特性都與感知的物理現象有關。為了產生數字影象，接下來需要進行 取樣與量化 處理。
1.4 取樣與量化
舉個栗子，對於黑白影象圖(a)為連續影象，如果需要轉換成數字形式，需要幾步主要操作：
取樣與量化
- 取樣： (a)圖上沿AB線段等間隔對該影象取樣，得到灰度級曲線(b)
- 量化：
(c)圖右側將灰度分為8個灰度級，再橫向每一取樣的連續灰度值，量化為8個灰度之一，最終得到(d)圖，感知器輸出的量化完成流產生數字影象的過程。
a. 影象投影至感測器陣列 b. 影象取樣與量化結果
二、渲染 - 資料如何展現？
2.1 播放器原理
播放器播放從網際網路上播放視訊，需要經過：解協議、解封裝、解碼、音視訊同步這幾個核心步驟。<center>
網際網路播放視訊流程
- 解協議： 將流媒體協議資料，解析為標準封裝格式資料。流媒體協議傳輸音視訊資料同時，也會傳輸一些信令資料，其中包括：播放控制、網路狀態描述等。常見流媒體協議如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 網路視訊點播業務
網路視訊點播業務採用 HTTP 有兩方面優勢：
- HTTP 是基於 TCP 協議的應用層協議，媒體傳輸過程中不會出現丟包等現象，從而保證了視訊的質量。
- HTTP 是絕大部分的 Web 伺服器支援的協議，因而流媒體服務機構不必投資購買額外的流媒體伺服器，從而節約了開支。
對於封裝格式：MP4，FLV，F4V 幾者只是容器，帶來的差異不大，而關鍵的是音視訊解碼方式：H.264與AAC，這兩種編碼標準目前仍被最廣泛的應用。
4.3 網路視訊直播業務
網路視訊直播服務採用 RTMP 作為直播協議的好處是可以直接被 Flash 播放器支援，而 Flash 播放器在 PC 時代有著極高的普及率，並且與瀏覽器結合的很好。因此這種流媒體直播平臺基本上可以實現了「無外掛直播」，極大降低了使用者使用成本。
封裝格式、視訊編碼、音訊編碼、播放器方面幾乎全部採用了 FLV、H.264、AAC、Flash。FLV、RTMP、Flash 都是 Adobe 公司的產品，天生有著良好的結合性。
4.4 總結
以上為PC時代舊資料，現移動網際網路已爆發，H5 以及客戶端應用的普及，行業中對視訊業務技術方案的選擇也逐漸在發生著變化，而我們則需要結合眼下的實際情況和技術發展的趨勢去做出合適的技術選型。
結語
音視訊技術道路很長，本文旨在搭建音視訊知識知識網，許多知識未能深入，後續仍需要我們不斷學習與實踐，抱著追求極致的精神去探索發現，加油，我們共同快速成長！
相關閱讀 【每日課程推薦】機器學習實戰！快速入門線上廣告業務及CTR相應知識
此文已由作者授權騰訊雲+社群釋出，更多原文請點選
搜尋關注公眾號「雲加社群」，第一時間獲取技術乾貨，關注後回覆1024 送你一份技術課程大禮包！
海量技術實踐經驗，盡在雲加社群！