（音視頻領域博大精深,，本文僅從一個PM的角度出發(fā)，總結一些最基本的內容） 一,、直播的基礎架構一個直播功能通用的基礎架構涉及三個部分,，即音視頻采集端、云服務端和音視頻播放端,。 如下圖,，是一個APP直播功能的架構：
從上圖中我們可以看到，每一個部分都有各自要處理的一些工作,。 總體來說,，視頻直播類功能的整體流程包括以下內容：
在具體了解每個流程之前，我們先從音視頻的基本知識入手,。 二,、音視頻技術基礎1. 音頻聲音： 我們平時在手機或電腦里聽到的音頻，是已經(jīng)數(shù)字化了的音頻模擬信號,。最初,，這些音頻都是始于物理的聲音,。 中學物理都學過，聲音是波,，是通過物體的振動產(chǎn)生的,。 聲波具有三要素：
模擬信號的數(shù)字化過程： 模擬信號的數(shù)字化過程，就是將模擬信號轉換為數(shù)字信號的過程,，包括采樣,、量化和編碼。 我們可以通過下圖理解這一過程：
通過上述的流程,，就實現(xiàn)了音頻信號的數(shù)字化過程,。轉為數(shù)字信號之后，就可以對這些數(shù)據(jù)進行存儲,、播放,、復制獲取等其他操作了。 音頻編碼： 上面我們說到了,，編碼就是按照一定的格式記錄采樣和量化后的數(shù)據(jù),，那么到底為什么需要編碼呢？ 采集和量化后的數(shù)據(jù)是非常大的,，從存儲或者網(wǎng)絡實時傳播的角度來說,，這個數(shù)據(jù)量都太大了。對于存儲和傳輸都是非常具有挑戰(zhàn)的,，所以我們需要通過編碼來進行壓縮,。 壓縮編碼的指標是壓縮比，壓縮比通常是小于1的,。 壓縮編碼算法分為2種：有損壓縮和無損壓縮,。
壓縮編碼的實質就是壓縮冗余的信號,，冗余信號就是指不能被人耳感知的信號，包括：人耳聽覺范圍之外的音頻信號以及被掩蓋掉的音頻信號,。信號的掩蔽可以分為頻域掩蔽和時域掩蔽,，關于信號的掩蔽大家可以自行百度一下，這里就不做過多闡述了,。 那么,，音頻壓縮編碼的常用格式都有哪些呢？ 主要包括：WMA編碼,；MP3編碼,；AAC編碼,，這個是現(xiàn)在比較熱門的有損壓縮編碼技術，也是目前在直播或小視頻中常用的編碼格式,；OGG編碼等,。 2. 視頻數(shù)字視頻： 我們平時在手機或PC上看到的視頻，是由內容元素,、編碼格式和封裝容器構成的,。
圖像： 圖像是人對視覺感知的物質重現(xiàn),。三維圖像的對象包括：深度,、紋理和亮度信息，二維圖像包括紋理和亮度信息,，我們可以簡單的把紋理就理解為圖像,。 說了圖像的概念，現(xiàn)在來說下視頻：視頻是由多幅圖像構成的,，是一組連續(xù)的圖像。一個基本的數(shù)字視頻,，基本是通過“采集——處理——顯示”形成的,。 編碼格式： 上面我們說到了音頻的編碼，視頻同樣是存在編碼的過程的,。視頻編解碼的過程是指對數(shù)字視頻進行壓縮或解壓縮的過程,。 在進行視頻的編解碼時，需要考慮以下因素的平衡：視頻的質量,、用來表示視頻所需要的數(shù)據(jù)量（通常稱之為碼率）,、編碼算法和解碼算法的復雜度、針對數(shù)據(jù)丟失和錯誤的魯棒性,、編輯的方便性,、隨機訪問、編碼算法設計的完美性,、端到端的延時以及其它一些因素,。 常用的視頻編解碼方式有H.26X系列和MPEG系列，而目前最常用的視頻編碼格式是H.264,，它的優(yōu)點是低碼率,、圖像質量高、容錯能力強,、網(wǎng)絡適應性更強,，并且已被廣泛應用于實時視頻應用中。 再介紹一些關于H.264的知識： 在H.264中,，圖像是包括幀、頂場和底場的,，一副完整的圖像就是一幀,。 當采集視頻信號時，如果采用逐行掃描,，則每次掃描得到的信號就是一副圖像,，也就是一幀。如果采用隔行掃描（奇,、偶數(shù)行）,，則掃描下來的一幀圖像就被分為了兩個部分，這每一部分就稱為場,，根據(jù)次序分為：頂場（也成為偶數(shù)場）和底場（也成為奇數(shù)場）,。 幀和場的概念又帶來了不同的編碼方式：幀編碼和場編碼。逐行掃描適合于運動圖像,，所以對于運動圖像采用幀編碼更好,；而隔行掃描適合于非運動圖像，所以對于非運動圖像采用場編碼更理想,。 此外,，每一幀圖像可以分為多個片，每一個片由宏塊構成,，而每個宏塊又是由子塊所構成的,。 封裝格式： 視頻的封裝格式可以看成是一個裝載著視頻、音頻,、視頻編解碼方式等信息的容器,。一種視頻封裝格式可以支持多種的視頻編解碼方式，比如：QuickTime（.MOV）支持幾乎所有的編解碼方式,，MPEG（.MP4）也支持大部分的編解碼方式,。 在PC上，我們經(jīng)常會使用.MOV的視頻文件。通過以上的介紹,，我們就知道了,，這個視頻的文件格式是.MOV，封裝格式是QuickTime File Format,，但是我們無法知道它的視頻編解碼方式,。如果我們想要專業(yè)的去描述一個視頻，可以描述成：H.264/MOV的視頻文件,，這就是說它的封裝方式是QuickTime File Format,，文件格式是.MOV，編碼方式是H.264,。 H.264： H.264是一種高性能的視頻編解碼技術,，是由“國際電聯(lián)”和“國際標準化組織ISO”聯(lián)合組建的聯(lián)合視頻組共同制定的新的數(shù)字視頻編碼標準。 我們在上面已經(jīng)說到了H.264編碼技術的優(yōu)勢,，我們接下來看一下H.264所涉及的關鍵技術： 我們首先要知道,，無論是視頻或音頻編碼，其目的都是壓縮,。視頻編碼的目的,，是抽取出冗余信息，這些冗余信息包括：空間冗余,、時間冗余,、編碼冗余,、視覺冗余和知識冗余。 基于此,，H.264的壓縮技術涉及： a）幀內預測壓縮,，解決的就是空間數(shù)據(jù)冗余問題,。空間冗余數(shù)據(jù)就是圖里數(shù)據(jù)在寬高空間內包含了很多顏色和光亮,，人的肉眼很難察覺的數(shù)據(jù)。對于這些數(shù)據(jù),，我們是可以直接壓縮掉的,。 幀內壓縮對應的是I幀——即關鍵幀,。那么什么是I幀呢,？網(wǎng)上教程中有一個經(jīng)典的例子，如果攝像頭對著你拍攝,，1秒之內實際你發(fā)生的變化是非常少的,。攝像機一般1秒鐘會抓取幾十幀的數(shù)據(jù)，比如像動畫,，就是25幀/s,，一般視頻文件都是在30幀/s左右,。那些對于一組幀來說變化很小的,，為了便于壓縮數(shù)據(jù)，就將第一幀完整的保存下來,。如果沒有這個關鍵幀后面解碼數(shù)據(jù)是完成不了的,，所以I幀是特別關鍵的。 b）幀間預測壓縮,，解決的是時間數(shù)據(jù)冗余問題,。在上面的例子中，攝像頭在一段時間內所捕捉的數(shù)據(jù)沒有較大的變化,，我們針對這一時間內的相同的數(shù)據(jù)壓縮掉,，這就是時間數(shù)據(jù)壓縮。 幀間壓縮對應的是P幀和B幀,。P幀是向前參考幀，壓縮時只參考前一個幀,。而B幀是雙向參考幀,，壓縮時即參考前一幀也參考后一幀。 c）整數(shù)離散余弦變換（DCT）,，將空間上的相關性變?yōu)轭l域上無關的數(shù)據(jù)然后進行量化。 d）CABAC壓縮：無損壓縮,。 H.264除了上述的關鍵技術,，還有幾個重要的概念需要了解：
在進行視頻解碼的時候,，接收到一組幀GOF之前，我們首先收到的是SPS/PPS數(shù)據(jù),，如果沒有這組參數(shù)的話,，是無法進行解碼的。 因此,，如果在解碼時發(fā)生錯誤，首先要檢查是否有SPS/PPS,。如果沒有,，就要檢查是因為對端沒有發(fā)送過來還是因為對端在發(fā)送過程中丟失了,。 更加詳細的H.264編碼原理這里就不做介紹了，大家感興趣的可以上網(wǎng)查閱一下資料,，比如：宏塊分組劃分,、宏塊查找,、幀內預測、DCT壓縮以及H.264的碼流結構等知識,。 三,、直播流程詳述通過上面的介紹，我們已經(jīng)了解音視頻一些基本的知識,。接下來，我們一起再描述一遍直播類應用的整體流程,。 1. 音視頻采集在音視頻采集階段會包括：音頻采集和圖像采集。 在音頻采集時，除了上面我們說到的采樣率,、量化級數(shù)和聲道數(shù)參數(shù)外，還需要音頻幀,。 音頻跟視頻很不一樣,，視頻每一幀就是一張圖像，而從聲音的正玄波可以看出：音頻數(shù)據(jù)是流式的,，沒有明確的一幀幀的概念。在實際的應用中,，為了音頻算法處理/傳輸?shù)姆奖?，一般約定俗成取 2.5ms~60ms 為單位的數(shù)據(jù)量為一幀音頻,。 這個時間被稱之為“采樣時間”,，其長度沒有特別的標準，它是根據(jù)編解碼器和具體應用的需求來決定的,。 如果某音頻信號是采樣率為 8kHz,、雙通道、量化級數(shù)是16bit,，采樣時間是20ms，則一幀音頻數(shù)據(jù)的大小為：8000 * 2 * 16bit * 0.02s = 5120 bit = 640 byte 在圖像采集中,，采集的圖片結果會組合成一組連續(xù)播放的動畫,，即構成視頻中可肉眼觀看的內容。 圖像的采集過程主要由攝像頭等設備拍攝成 YUV 編碼的原始數(shù)據(jù),，然后經(jīng)過編碼壓縮成 H.264 等格式的數(shù)據(jù)分發(fā)出去,。在圖像采集階段，涉及的主要技術參數(shù)包括：圖像傳輸格式,、圖像格式,、傳輸通道、分辨率以及采樣率,。 在音視頻的采集階段,，常用的采集源包括攝像頭，比如手機的前后置攝像頭,；游戲直播中使用的屏幕錄制,；和電視節(jié)目中視頻文件的直接推流。 2. 音視頻處理音視頻處理會分為：視頻處理和音頻處理,。 視頻處理包括：美顏,、濾鏡,、面部識別、水印,、剪輯拼接等,。音頻處理包括：混音、降噪,、聲音特效等。 下面我們簡要描述一下美顏和視頻水印的基本原理： 美顏的主要原理是通過【磨皮】+【美白】來達到整體美顏效果的,。磨皮的技術術語是去噪,，也就是對圖像中的噪點進行去除或者模糊化處理,，常見的去噪算法有均值模糊、高斯模糊和中值濾波等,。這個環(huán)節(jié)中也涉及到人臉和皮膚檢測技術,。 視頻水印包括播放器水印和視頻內嵌水印兩種方式。對于播放器水印來說,，如果沒有有效的防盜措施，對于沒有播放鑒權的推流,，客戶端拿到直播流之后可以在任何一個不帶水印的播放器里面播放,，因此也就失去了視頻保護的能力,。所以，一般來說會選擇視頻內嵌水印的方式打水印,，這樣,，水印就會內嵌到視頻之內,，在視頻播放的過程中持續(xù)顯示。 再多聊一些,，視頻內嵌水印也會應用在軟件中,，軟件中播出企業(yè)內部版權保護的動畫段視頻時,，會應用到內嵌水印的技術。 3. 音視頻編碼和封裝音視頻的編碼以及視頻的封裝在上述基礎知識部分已經(jīng)介紹過了,，這里不再贅述,。 在這里說一下編碼器的知識,。上文中我們了解了H.264的編碼技術,，編碼流程是要基于編碼器進行的。 編碼器的主要流程是：幀內預測（去除空間冗余）/幀間預測（去除時間冗余）——變換（去除空間冗余）——量化（去除視覺冗余）——熵編碼（去除編碼冗余）,。通過該流程,，即可完成音視頻的編碼步驟。 4. 推流推流就是將處理過的音頻和視頻數(shù)據(jù)通過流媒體協(xié)議發(fā)送到流媒體服務器,。 推流協(xié)議： 推流所遵循的協(xié)議有RTMP,、WebRTC和基于UDP的私有協(xié)議。
CDN： 推出去的流媒體要給各個地理位置的觀眾看，那么這里就需要CDN網(wǎng)絡了,。CDN就是為了解決用戶訪問網(wǎng)絡資源慢而產(chǎn)生的技術,。 CDN包括邊緣節(jié)點、二級節(jié)點和源站,。內容提供方可以將內容放到源站上,，用戶從邊緣節(jié)點獲取數(shù)據(jù)，而CDN的二級節(jié)點則用于緩存,，減輕源站壓力。 在直播領域中,，CDN要支持的服務如下：
5. 流媒體服務器處理流媒體服務器要做的事情包括：數(shù)據(jù)分發(fā)（CDN）,、支持上述CDN的一些服務,、實時轉碼以及內容的檢測（鑒黃）等。 6. 拉流拉流就是客戶端從流媒體服務器上拉取獲得上述步驟中的音視頻數(shù)據(jù),。同理,，這個過程也是要基于上述的協(xié)議和CDN。 7. 音視頻解碼在上述H.264編碼的介紹中,，說到了SPS/PPS是解碼必備的數(shù)據(jù),。此步驟就是需要對拉流下來已編碼的音視頻數(shù)據(jù)進行解碼,。 解碼過程就是編碼的逆過程,，這個過程包括：熵解碼、變換解碼,、預測解碼,。 H.264規(guī)范規(guī)定了解碼器的結構,，解碼的過程大體如下：以宏塊為單位，依次進行熵解碼,、反量化,、反變換，得到殘差數(shù)據(jù),。再結合宏塊里面的預測信息,，找到已解碼的被參考塊，進而結合已解碼被參考塊和本塊殘差數(shù)據(jù),，得到本塊的實際數(shù)據(jù)。宏塊解碼后,，組合出片，片再進而組合出圖像,。 這里要說明的是：如果H264碼流中I幀錯誤或丟失，就會導致錯誤傳遞,，單獨的P幀或B幀是完成不了解碼工作的,。I幀所保留的是一張完整的視頻幀，是解碼的關鍵所在,。 8. 音視頻播放在完成了音視頻數(shù)據(jù)的解碼后，就可以通過硬件設備（手機或PC）上的播放器對音視頻文件進行渲染播放了,。 那么,，上述架構圖中的信令服務器是干什么的呢,？ ——信令服務器是用來處理主播端和用戶端的一些信令指令的。 在網(wǎng)絡中傳輸著各種信號,，其中一部分是我們需要的（例如：打電話的語音,，上網(wǎng)的數(shù)據(jù)包等等）,，而另外一部分是我們不需要的（只能說不是直接需要）它用來專門控制電路的,，這一類型的信號我們就稱之為信令（摘自百度百科）,。也就是說，信令是指通信系統(tǒng)中的控制指令,。 我們基于此,，再來描述一下這整個的流程：
好了,，以上就是直播類應用的一個最基本的架構和流程了,。 四、總結本文通過直播類應用的架構,，介紹了一些音視頻技術方面的知識,，并且詳述了直播類功能的整體流程,。 音視頻技術是一個高深的領域,，本文只是做了一些基礎知識的總結,，如果大家想要深入了解更多的音視頻技術,，我推薦大家可以學習一下雷神（雷霄驊）的博客。 #專欄作家#流年,，人人都是產(chǎn)品經(jīng)理專欄作家,。互聯(lián)網(wǎng)產(chǎn)品設計師,，4年互聯(lián)網(wǎng)產(chǎn)品設計經(jīng)驗,。擅長用戶體驗設計，喜歡鉆研需求功能背后的技術實現(xiàn)方式,；在成為綜合型產(chǎn)品設計師的道路上不斷努力前進！ |
|
|
來自： 昵稱11458597 > 《視頻技術》
