一. 直播流程總覽

目前主流的直播架構(gòu)中主要有兩種方案原在，即流媒體轉(zhuǎn)發(fā)、P2P批糟。流媒體轉(zhuǎn)發(fā)，是一種在視頻直播中以流的方式將連續(xù)的音看铆、視頻數(shù)據(jù)經(jīng)編碼壓縮后傳輸?shù)搅髅襟w服務(wù)器徽鼎，用戶實(shí)時(shí)從服務(wù)器獲取流媒體資源。而不必要等待整個(gè)文件下載文件完畢的C/S架構(gòu)視頻直播方案弹惦；P2P直播否淤，是一種建立在P2P技術(shù)基礎(chǔ)上的視頻直播方案，它規(guī)定客戶端之間使用一定協(xié)議來交換和共享直播數(shù)據(jù)肤频，通過減少對服務(wù)器的數(shù)據(jù)請求叹括，以降低服務(wù)端的I/O帶寬等方面壓力，從而削減服務(wù)器帶寬成本宵荒，降低客戶端卡播率。

一個(gè)直播功能通用的基礎(chǔ)架構(gòu)涉及三個(gè)部分净嘀，即音視頻采集端报咳、云服務(wù)端和音視頻播放端。

直播app架構(gòu)圖

image.png

如下圖挖藏，是一個(gè)APP直播功能的架構(gòu)：

img

從上圖中我們可以看到暑刃，每一個(gè)部分都有各自要處理的一些工作。

總體來說膜眠，視頻直播類功能的整體流程包括以下內(nèi)容：

1. 音視頻采集
2. 音視頻處理
3. 音視頻編碼和封裝
4. 推流
5. 流媒體服務(wù)器處理
6. 拉流
7. 音視頻解碼
8. 音視頻播放

二. 音視頻采集

在音視頻采集階段會(huì)包括：音頻采集和圖像采集岩臣。

在音頻采集時(shí)溜嗜，除了上面我們說到的采樣率、量化級數(shù)和聲道數(shù)參數(shù)外架谎，還需要音頻幀炸宵。

音頻跟視頻很不一樣，視頻每一幀就是一張圖像谷扣，而從聲音的正玄波可以看出：音頻數(shù)據(jù)是流式的土全，沒有明確的一幀幀的概念。在實(shí)際的應(yīng)用中会涎，為了音頻算法處理/傳輸?shù)姆奖愎祝话慵s定俗成取 2.5ms~60ms 為單位的數(shù)據(jù)量為一幀音頻。

這個(gè)時(shí)間被稱之為“采樣時(shí)間”末秃，其長度沒有特別的標(biāo)準(zhǔn)概页，它是根據(jù)編解碼器和具體應(yīng)用的需求來決定的。

如果某音頻信號(hào)是采樣率為 8kHz练慕、雙通道惰匙、量化級數(shù)是16bit，采樣時(shí)間是20ms贺待，則一幀音頻數(shù)據(jù)的大小為：8000 * 2 * 16bit * 0.02s = 5120 bit = 640 byte

在圖像采集中徽曲，采集的圖片結(jié)果會(huì)組合成一組連續(xù)播放的動(dòng)畫，即構(gòu)成視頻中可肉眼觀看的內(nèi)容麸塞。

圖像的采集過程主要由攝像頭等設(shè)備拍攝成 YUV 編碼的原始數(shù)據(jù)秃臣，然后經(jīng)過編碼壓縮成 H.264 等格式的數(shù)據(jù)分發(fā)出去。在圖像采集階段哪工，涉及的主要技術(shù)參數(shù)包括：圖像傳輸格式奥此、圖像格式、傳輸通道雁比、分辨率以及采樣率稚虎。

在音視頻的采集階段，常用的采集源包括攝像頭偎捎，比如手機(jī)的前后置攝像頭蠢终；游戲直播中使用的屏幕錄制；和電視節(jié)目中視頻文件的直接推流茴她。

采集是整個(gè)視頻推流過程中的第一個(gè)環(huán)節(jié)寻拂，它從系統(tǒng)的采集設(shè)備中獲取原始視頻數(shù)據(jù)，將其輸出到下一個(gè)環(huán)節(jié)丈牢。視頻的采集涉及兩方面數(shù)據(jù)的采集：音頻采集和圖像采集祭钉，它們分別對應(yīng)兩種完全不同的輸入源和數(shù)據(jù)格式。

音頻采集

音頻數(shù)據(jù)既能與圖像結(jié)合組合成視頻數(shù)據(jù)己沛，也能以純音頻的方式采集播放慌核，后者在很多成熟的應(yīng)用場景如在線電臺(tái)和語音電臺(tái)等起著非常重要的作用距境。音頻的采集過程主要通過設(shè)備將環(huán)境中的模擬信號(hào)采集成 PCM 編碼的原始數(shù)據(jù)，然后編碼壓縮成 MP3 等格式的數(shù)據(jù)分發(fā)出去垮卓。常見的音頻壓縮格式有：MP3垫桂，AAC，HE-AAC扒接，Opus伪货，F(xiàn)LAC，Vorbis (Ogg)钾怔，Speex 和 AMR等碱呼。
音頻采集和編碼主要面臨的挑戰(zhàn)在于：延時(shí)敏感、卡頓敏感宗侦、噪聲消除（Denoise）愚臀、回聲消除（AEC）、靜音檢測（VAD）和各種混音算法等矾利。

圖像采集

將圖像采集的圖片結(jié)果組合成一組連續(xù)播放的動(dòng)畫姑裂，即構(gòu)成視頻中可肉眼觀看的內(nèi)容。圖像的采集過程主要由攝像頭等設(shè)備拍攝成 YUV 編碼的原始數(shù)據(jù)男旗，然后經(jīng)過編碼壓縮成 H.264 等格式的數(shù)據(jù)分發(fā)出去舶斧。常見的視頻封裝格式有：MP4、3GP察皇、AVI茴厉、MKV、WMV什荣、MPG矾缓、VOB、FLV稻爬、SWF嗜闻、MOV、RMVB 和 WebM 等桅锄。
圖像由于其直觀感受最強(qiáng)并且體積也比較大琉雳，構(gòu)成了一個(gè)視頻內(nèi)容的主要部分。圖像采集和編碼面臨的主要挑戰(zhàn)在于：設(shè)備兼容性差友瘤、延時(shí)敏感咐吼、卡頓敏感以及各種對圖像的處理操作如美顏和水印等。

視頻采集的采集源主要有 攝像頭采集商佑、屏幕錄制和從視頻文件推流。

三. 音視頻處理

音視頻處理會(huì)分為：視頻處理和音頻處理厢塘。

視頻處理包括：美顏茶没、濾鏡肌幽、面部識(shí)別、水印抓半、剪輯拼接等喂急。音頻處理包括：混音、降噪笛求、聲音特效等廊移。

下面我們簡要描述一下美顏和視頻水印的基本原理：

美顏的主要原理是通過【磨皮】+【美白】來達(dá)到整體美顏效果的。磨皮的技術(shù)術(shù)語是去噪探入，也就是對圖像中的噪點(diǎn)進(jìn)行去除或者模糊化處理狡孔，常見的去噪算法有均值模糊、高斯模糊和中值濾波等蜂嗽。這個(gè)環(huán)節(jié)中也涉及到人臉和皮膚檢測技術(shù)苗膝。

視頻水印包括播放器水印和視頻內(nèi)嵌水印兩種方式。對于播放器水印來說植旧，如果沒有有效的防盜措施辱揭，對于沒有播放鑒權(quán)的推流，客戶端拿到直播流之后可以在任何一個(gè)不帶水印的播放器里面播放病附，因此也就失去了視頻保護(hù)的能力问窃。所以，一般來說會(huì)選擇視頻內(nèi)嵌水印的方式打水印完沪，這樣域庇，水印就會(huì)內(nèi)嵌到視頻之內(nèi)，在視頻播放的過程中持續(xù)顯示丽焊。

再多聊一些较剃，視頻內(nèi)嵌水印也會(huì)應(yīng)用在軟件中，軟件中播出企業(yè)內(nèi)部版權(quán)保護(hù)的動(dòng)畫段視頻時(shí)技健，會(huì)應(yīng)用到內(nèi)嵌水印的技術(shù)写穴。

視頻或者音頻完成采集之后得到原始數(shù)據(jù)，為了增強(qiáng)一些現(xiàn)場效果或者加上一些額外的效果雌贱，我們一般會(huì)在將其編碼壓縮前進(jìn)行處理啊送，比如打上時(shí)間戳或者公司 Logo 的水印，祛斑美顏和聲音混淆等處理欣孤。在主播和觀眾連麥場景中馋没，主播需要和某個(gè)或者多個(gè)觀眾進(jìn)行對話，并將對話結(jié)果實(shí)時(shí)分享給其他所有觀眾降传，連麥的處理也有部分工作在推流端完成篷朵。

這里寫圖片描述

如上圖所示，處理環(huán)節(jié)中分為音頻和視頻處理，音頻處理中具體包含混音声旺、降噪和聲音特效等處理笔链，視頻處理中包含美顏、水印腮猖、以及各種自定義濾鏡等處理鉴扫。

四. 音視頻編碼和封裝

音視頻的編碼以及視頻的封裝在上述基礎(chǔ)知識(shí)部分已經(jīng)介紹過了，這里不再贅述澈缺。

在這里說一下編碼器的知識(shí)坪创。上文中我們了解了H.264的編碼技術(shù)，編碼流程是要基于編碼器進(jìn)行的姐赡。

編碼器的主要流程是：幀內(nèi)預(yù)測（去除空間冗余）/幀間預(yù)測（去除時(shí)間冗余）——變換（去除空間冗余）——量化（去除視覺冗余）——熵編碼（去除編碼冗余）莱预。通過該流程，即可完成音視頻的編碼步驟雏吭。

（1）編碼

如果把整個(gè)流媒體比喻成一個(gè)物流系統(tǒng)锁施，那么編解碼就是其中配貨和裝貨的過程，這個(gè)過程非常重要杖们，它的速度和壓縮比對物流系統(tǒng)的意義非常大悉抵，影響物流系統(tǒng)的整體速度和成本。同樣摘完，對流媒體傳輸來說姥饰，編碼也非常重要，它的編碼性能孝治、編碼速度和編碼壓縮比會(huì)直接影響整個(gè)流媒體傳輸?shù)挠脩趔w驗(yàn)和傳輸成本列粪。

視頻編碼的意義
原始視頻數(shù)據(jù)存儲(chǔ)空間大，一個(gè) 1080P 的 7 s 視頻需要 817 MB
原始視頻數(shù)據(jù)傳輸占用帶寬大谈飒，10 Mbps 的帶寬傳輸上述 7 s 視頻需要 11 分鐘
而經(jīng)過 H.264 編碼壓縮之后岂座，視頻大小只有 708 k ，10 Mbps 的帶寬僅僅需要 500 ms 杭措，可以滿足實(shí)時(shí)傳輸?shù)男枨蠓咽玻詮囊曨l采集傳感器采集來的原始視頻勢必要經(jīng)過視頻編碼。

基本原理
為什么巨大的原始視頻可以編碼成很小的視頻呢?這其中的技術(shù)是什么呢?核心思想就是去除冗余信息：
1）空間冗余：圖像相鄰像素之間有較強(qiáng)的相關(guān)性
2）時(shí)間冗余：視頻序列的相鄰圖像之間內(nèi)容相似
3）編碼冗余：不同像素值出現(xiàn)的概率不同
4）視覺冗余：人的視覺系統(tǒng)對某些細(xì)節(jié)不敏感
5）知識(shí)冗余：規(guī)律性的結(jié)構(gòu)可由先驗(yàn)知識(shí)和背景知識(shí)得到

編碼器的選擇
視頻編碼器經(jīng)歷了數(shù)十年的發(fā)展手素，已經(jīng)從開始的只支持幀內(nèi)編碼演進(jìn)到現(xiàn)如今的 H.265 和 VP9 為代表的新一代編碼器鸳址，下面是一些常見的視頻編碼器：
1）H.264/AVC
2）HEVC/H.265
3）VP8
4）VP9
5）FFmpeg
注：音頻編碼器有Mp3, AAC等。

（2）封裝
沿用前面的比喻泉懦，封裝可以理解為采用哪種貨車去運(yùn)輸稿黍，也就是媒體的容器。
所謂容器崩哩，就是把編碼器生成的多媒體內(nèi)容(視頻巡球，音頻，字幕，章節(jié)信息等)混合封裝在一起的標(biāo)準(zhǔn)辕漂。容器使得不同多媒體內(nèi)容同步播放變得很簡單呢灶，而容器的另一個(gè)作用就是為多媒體內(nèi)容提供索引，也就是說如果沒有容器存在的話一部影片你只能從一開始看到最后钉嘹，不能拖動(dòng)進(jìn)度條，而且如果你不自己去手動(dòng)另外載入音頻就沒有聲音鲸阻。下面是幾種常見的封裝格式：
1）AVI 格式(后綴為 .avi)
2）DV-AVI 格式(后綴為 .avi)
3）QuickTime File Format 格式(后綴為 .mov)
4）MPEG 格式(文件后綴可以是 .mpg .mpeg .mpe .dat .vob .asf .3gp .mp4等)
5）WMV 格式(后綴為.wmv .asf)
6）Real Video 格式(后綴為 .rm .rmvb)
7）Flash Video 格式(后綴為 .flv)
8）Matroska 格式(后綴為 .mkv)
9）MPEG2-TS 格式 (后綴為 .ts)
目前跋涣，我們在流媒體傳輸，尤其是直播中主要采用的就是 FLV 和 MPEG2-TS 格式鸟悴，分別用于 RTMP/HTTP-FLV 和 HLS 協(xié)議陈辱。

四.音視頻推流

推流就是將處理過的音頻和視頻數(shù)據(jù)通過流媒體協(xié)議發(fā)送到流媒體服務(wù)器。
直播的推流對這個(gè)直播鏈路影響非常大细诸，如果推流的網(wǎng)絡(luò)不穩(wěn)定沛贪，無論如何做優(yōu)化，觀眾的體驗(yàn)都會(huì)很糟糕震贵。推送協(xié)議主要有三種：

• 1. RTSP（Real Time Streaming Protocol）：實(shí)時(shí)流傳送協(xié)議利赋，是用來控制聲音或影像的多媒體串流協(xié)議, 由Real Networks和Netscape共同提出的；
• 2. RTMP(Real Time Messaging Protocol)：實(shí)時(shí)消息傳送協(xié)議猩系，是Adobe公司為Flash播放器和服務(wù)器之間音頻媚送、視頻和數(shù)據(jù)傳輸 開發(fā)的開放協(xié)議；
• 3. HLS(HTTP Live Streaming)：是蘋果公司(Apple Inc.)實(shí)現(xiàn)的基于HTTP的流媒體傳輸協(xié)議寇甸；

1：RTSP RTMP HTTP都是在應(yīng)用應(yīng)用層塘偎。

2： 理論上RTSP RTMPHTTP都可以做直播和點(diǎn)播，但一般做直播用RTSP RTMP拿霉，做點(diǎn)播用HTTP吟秩。做視頻會(huì)議的時(shí)候原來用SIP協(xié)議，現(xiàn)在基本上被RTMP協(xié)議取代了绽淘。

推流所遵循的協(xié)議有RTMP涵防、WebRTC和基于UDP的私有協(xié)議。

• RTMP協(xié)議是基于TCP協(xié)議的收恢，RTMP 是目前主流的流媒體傳輸協(xié)議武学，廣泛用于直播領(lǐng)域，市面上絕大多數(shù)的直播產(chǎn)品都采用了這個(gè)協(xié)議伦意。但是火窒，由于基于TCP協(xié)議，傳輸成本高驮肉，在弱網(wǎng)環(huán)境下丟包率高熏矿，不支持瀏覽器推送。
• WebRTC是一個(gè)支持網(wǎng)頁瀏覽器進(jìn)行實(shí)時(shí)語音對話或視頻對話的 API，主要應(yīng)用于視頻會(huì)議票编。它的主流瀏覽器支持度高褪储，并且底層基于SRTP和UDP，弱網(wǎng)情況優(yōu)化空間大慧域。
• 基于UDP的私有協(xié)議鲤竹。有些直播應(yīng)用會(huì)使用 UDP 做為底層協(xié)議開發(fā)自己的私有協(xié)議，因?yàn)?UDP在弱網(wǎng)環(huán)境下的優(yōu)勢通過一些定制化的調(diào)優(yōu)可以達(dá)到比較好的弱網(wǎng)優(yōu)化效果昔榴，但是開發(fā)成過高辛藻。

區(qū)別：

1：HTTP: 即超文本傳送協(xié)議(ftp即文件傳輸協(xié)議)。

2：HTTP將所有的數(shù)據(jù)作為文件做處理互订。http協(xié)議不是流媒體協(xié)議吱肌。
3：RTMP協(xié)議是Adobe的私有協(xié)議,未完全公開，RTSP協(xié)議和HTTP協(xié)議是共有協(xié)議仰禽，并有專門機(jī)構(gòu)做維護(hù)氮墨。

4：RTMP協(xié)議一般傳輸?shù)氖莊lv，f4v格式流吐葵，RTSP協(xié)議一般傳輸?shù)氖莟s,mp4格式的流规揪。HTTP沒有特定的流。

5：RTSP傳輸一般需要2-3個(gè)通道折联，命令和數(shù)據(jù)通道分離粒褒，HTTP和RTMP一般在TCP一個(gè)通道上傳輸命令和數(shù)據(jù)。

RTMP 是目前主流的流媒體傳輸協(xié)議诚镰，廣泛用于直播領(lǐng)域奕坟，可以說市面上絕大多數(shù)的直播產(chǎn)品都采用了這個(gè)協(xié)議，也有部分使用HLS協(xié)議清笨。

推流可選方案：

利用FFmpeg進(jìn)行直播推流（優(yōu)點(diǎn)：對技術(shù)開發(fā)者來說过蹂，會(huì)有在不斷的填坑過程中涮毫，提升自我；缺點(diǎn)：產(chǎn)品穩(wěn)定性差，延遲大）娜亿；

利用第三方SDK（優(yōu)點(diǎn)：延遲小稽犁，非常穩(wěn)定熔号，適用于產(chǎn)品快速上線依痊，有專人維護(hù)；缺點(diǎn)：商業(yè)授權(quán)需要一定費(fèi)用）齐苛。

五.服務(wù)器流分發(fā)

流媒體服務(wù)器的作用是負(fù)責(zé)直播流的發(fā)布和轉(zhuǎn)播分發(fā)功能翘盖。

常用服務(wù)器

• SRS: 一款國人開發(fā)的優(yōu)秀開源流媒體服務(wù)器系統(tǒng)
• BMS: 也是一款流媒體服務(wù)器系統(tǒng)，但不開源凹蜂，是SRS的商業(yè)版馍驯，比SRS功能更多
• nginx: 免費(fèi)開源Web服務(wù)器阁危，常用來配置流媒體服務(wù)器

自建流媒體服務(wù)器局限性很大，費(fèi)用也比較高昂汰瘫，建議交給CDN服務(wù)商狂打。

CDN：

推出去的流媒體要給各個(gè)地理位置的觀眾看，那么這里就需要CDN網(wǎng)絡(luò)了混弥。CDN就是為了解決用戶訪問網(wǎng)絡(luò)資源慢而產(chǎn)生的技術(shù)趴乡。

CDN包括邊緣節(jié)點(diǎn)、二級節(jié)點(diǎn)和源站剑逃。內(nèi)容提供方可以將內(nèi)容放到源站上浙宜，用戶從邊緣節(jié)點(diǎn)獲取數(shù)據(jù)，而CDN的二級節(jié)點(diǎn)則用于緩存蛹磺，減輕源站壓力。

在直播領(lǐng)域中同仆，CDN要支持的服務(wù)如下：

• 流媒體協(xié)議的支持萤捆。比如RTMP等；
• 首屏秒開俗批。從用戶點(diǎn)擊到播放控制在秒級以內(nèi)俗或；
• 1~3 延遲控制。從推流端到播放端岁忘，延遲控制在 1~3 秒之間辛慰；
• 全球全網(wǎng)智能路由「上瘢可以利用整個(gè)CDN網(wǎng)絡(luò)內(nèi)的所有節(jié)點(diǎn)為某一單一用戶服務(wù)帅腌，不受地域限制。

流媒體服務(wù)器處理

流媒體服務(wù)器要做的事情包括：數(shù)據(jù)分發(fā)（CDN）麻汰、支持上述CDN的一些服務(wù)速客、實(shí)時(shí)轉(zhuǎn)碼以及內(nèi)容的檢測（鑒黃）等。

轉(zhuǎn)碼

即構(gòu)提供了實(shí)時(shí)轉(zhuǎn)碼技術(shù)五鲫，將用戶推流碼率較高（比如720P）實(shí)時(shí)轉(zhuǎn)成較低清晰度（比如360P）的流以適應(yīng)播放端的需求溺职。

如果要自己搭建實(shí)時(shí)轉(zhuǎn)碼系統(tǒng)，這個(gè)成本是極高的位喂，一臺(tái)8核設(shè)備只能實(shí)時(shí)轉(zhuǎn)10路流浪耘，一個(gè)規(guī)模中等的直播平臺(tái)假設(shè)有1000路流，就需要100臺(tái)設(shè)備塑崖，加上后期的運(yùn)維成本七冲，一般的公司是難以負(fù)擔(dān)的。

鑒黃

目前市面上提供鑒黃服務(wù)的方案主要有兩種弃舒，第一種是對視頻進(jìn)行截圖癞埠，然后對圖片進(jìn)行鑒黃状原，返回鑒黃結(jié)果和分值，相關(guān)企業(yè)有阿里（綠網(wǎng)）苗踪、圖普科技等颠区。

第二種是和CDN結(jié)合，直接對直播流進(jìn)行分析通铲，識(shí)別結(jié)果分為色情毕莱、疑似色情、性感和正常颅夺，業(yè)務(wù)系統(tǒng)根據(jù)識(shí)別結(jié)果直接控制直播流朋截，代表企業(yè)有Viscovery等。

六. 拉流播放

拉流就是客戶端從流媒體服務(wù)器上拉取獲得上述步驟中的音視頻數(shù)據(jù)吧黄。同理部服，這個(gè)過程也是要基于上述的協(xié)議和CDN。
指服務(wù)器已有直播內(nèi)容拗慨，用指定地址進(jìn)行拉取的過程廓八。根據(jù)協(xié)議類型（如RTMP、RTP赵抢、RTSP剧蹂、HTTP等），與服務(wù)器建立連接并接收數(shù)據(jù)
流程如下：

解析二進(jìn)制數(shù)據(jù)烦却，從中找到相關(guān)流信息宠叼；

根據(jù)不同的封裝格式（如FLV、TS）解復(fù)用（demux）其爵；

分別得到已編碼的H.264視頻數(shù)據(jù)和AAC音頻數(shù)據(jù)冒冬；

使用硬解碼（對應(yīng)系統(tǒng)的API）或軟解碼（FFMpeg）來解壓音視頻數(shù)據(jù)；

經(jīng)過解碼后得到原始的視頻數(shù)據(jù)（YUV）和音頻數(shù)據(jù)（AAC）醋闭；

因?yàn)橐纛l和視頻解碼是分開的窄驹，所以我們得把它們同步起來，否則會(huì)出現(xiàn)音視頻不同步的現(xiàn)象证逻，比如別人說話會(huì)跟口型對不上乐埠；

最后把同步的音頻數(shù)據(jù)送到耳機(jī)或外放，視頻數(shù)據(jù)送到屏幕上顯示囚企。

主要是實(shí)現(xiàn)直播節(jié)目在終端上的展現(xiàn)丈咐。因?yàn)槲疫@里使用的傳輸協(xié)議是RTMP， 所以只要支持 RTMP 流協(xié)議的播放器都可以使用

主要是實(shí)現(xiàn)直播節(jié)目在終端上的展現(xiàn)龙宏。因?yàn)槲疫@里使用的傳輸協(xié)議是RTMP棵逊， 所以只要支持 RTMP 流協(xié)議的播放器都可以使用，譬如：

電腦端：VLC等
手機(jī)端：Vitamio以及ijkplayer等
一般情況下我們把上面流程的前四步稱為第一部分银酗，即視頻主播端的操作辆影。視頻采集處理后推流到流媒體服務(wù)器徒像，第一部分功能完成。第二部分就是流媒體服務(wù)器蛙讥，負(fù)責(zé)把從第一部分接收到的流進(jìn)行處理并分發(fā)給觀眾锯蛀。第三部分就是觀眾啦，只需要擁有支持流傳輸協(xié)議的播放器即可次慢。

在上述H.264編碼的介紹中旁涤，說到了SPS/PPS是解碼必備的數(shù)據(jù)。此步驟就是需要對拉流下來已編碼的音視頻數(shù)據(jù)進(jìn)行解碼迫像。

解碼過程就是編碼的逆過程劈愚，這個(gè)過程包括：熵解碼、變換解碼闻妓、預(yù)測解碼菌羽。

H.264規(guī)范規(guī)定了解碼器的結(jié)構(gòu)，解碼的過程大體如下：以宏塊為單位由缆，依次進(jìn)行熵解碼算凿、反量化、反變換犁功，得到殘差數(shù)據(jù)。再結(jié)合宏塊里面的預(yù)測信息婚夫，找到已解碼的被參考塊浸卦，進(jìn)而結(jié)合已解碼被參考塊和本塊殘差數(shù)據(jù)，得到本塊的實(shí)際數(shù)據(jù)案糙。宏塊解碼后限嫌，組合出片，片再進(jìn)而組合出圖像时捌。

這里要說明的是：如果H264碼流中I幀錯(cuò)誤或丟失怒医，就會(huì)導(dǎo)致錯(cuò)誤傳遞，單獨(dú)的P幀或B幀是完成不了解碼工作的奢讨。I幀所保留的是一張完整的視頻幀稚叹，是解碼的關(guān)鍵所在。

8. 音視頻播放

在完成了音視頻數(shù)據(jù)的解碼后拿诸，就可以通過硬件設(shè)備（手機(jī)或PC）上的播放器對音視頻文件進(jìn)行渲染播放了扒袖。

那么，上述架構(gòu)圖中的信令服務(wù)器是干什么的呢亩码？

——信令服務(wù)器是用來處理主播端和用戶端的一些信令指令的季率。

在網(wǎng)絡(luò)中傳輸著各種信號(hào)，其中一部分是我們需要的（例如：打電話的語音描沟，上網(wǎng)的數(shù)據(jù)包等等）飒泻，而另外一部分是我們不需要的（只能說不是直接需要）它用來專門控制電路的鞭光，這一類型的信號(hào)我們就稱之為信令（摘自百度百科）。也就是說泞遗，信令是指通信系統(tǒng)中的控制指令惰许。

我們基于此，再來描述一下這整個(gè)的流程：

1. 主播共享端發(fā)起一個(gè)信令刹孔，比如：創(chuàng)建房間（或聊天啡省、發(fā)送禮物等），到達(dá)信令服務(wù)器髓霞；信令服務(wù)器處理并且創(chuàng)建一個(gè)房間卦睹，同時(shí)返回給主播共享端一個(gè)流媒體云的地址。
2. 接下來方库，主播共享端采集數(shù)據(jù)（音視頻的采集结序、處理以及編碼封裝流程）形成RTMP流推送到CDN網(wǎng)絡(luò)（推流）。
3. 觀眾要進(jìn)行觀看時(shí)纵潦，客戶端會(huì)發(fā)送信令到信令服務(wù)器徐鹤，信令服務(wù)器將該觀眾加入到主播的房間中，同時(shí)也會(huì)返回一個(gè)流媒體云的地址（該地址就是之前主播端的流媒體云地址）邀层。
4. 客戶端拿到此流媒體云地址后返敬，就會(huì)到流媒體云服務(wù)器拉取到該媒體流（拉流和解碼），從而看到要觀看的直播節(jié)目（播放器播放）寥院。

七. P2P視頻

(1) P2P點(diǎn)對點(diǎn)
P2P視頻直播是客戶端之間使用一定協(xié)議劲赠，交換和共享直播數(shù)據(jù)，通過減少對服務(wù)器的數(shù)據(jù)請求秸谢，來降低服務(wù)端的I/O帶寬等方面壓力凛澎，從而削減服務(wù)器帶寬成本，降低客戶端卡播率估蹄。在整個(gè)網(wǎng)絡(luò)網(wǎng)框架中塑煎，每個(gè)客戶端(節(jié)點(diǎn))是對等的，即同時(shí)具有Client和Server的特點(diǎn)臭蚁。常見開源框架：WebRTC
優(yōu)點(diǎn)：服務(wù)器壓力小最铁，節(jié)省帶寬成本，延時(shí)低刊棕，響應(yīng)快炭晒，秒傳，適合非實(shí)時(shí)的數(shù)據(jù)傳輸甥角；
缺點(diǎn)：最多4~8個(gè)人同時(shí)在線觀看网严，對節(jié)點(diǎn)帶寬要求較高，服務(wù)器視頻錄制不好處理嗤无。IPv4網(wǎng)絡(luò)環(huán)境制約震束，UDP打洞穿透效率問題怜庸，打洞不通要服務(wù)器relay；
應(yīng)用場景：安防
(2) 流媒體轉(zhuǎn)發(fā)
常見流媒體直播協(xié)議都屬于C/S型垢村，即所有客戶端通過指定協(xié)議割疾，從服務(wù)端獲取直播數(shù)據(jù)。當(dāng)客戶端數(shù)量達(dá)到一定規(guī)模后嘉栓，服務(wù)端將承受巨大的I/O和帶寬壓力宏榕。若服務(wù)器無法及時(shí)處理客戶請求，客戶端卡播率急劇上升侵佃，從而影響用戶觀看體驗(yàn)麻昼。常見開源框架：ffmpeg
優(yōu)點(diǎn)：穩(wěn)定可靠，支持量大馋辈，可以實(shí)現(xiàn)一個(gè)人播抚芦，百萬人同時(shí)在線觀看，且服務(wù)器可以進(jìn)行視頻錄制存儲(chǔ)迈螟，用戶體驗(yàn)好叉抡；
缺點(diǎn)：用戶數(shù)量增加后，對服務(wù)器的資源和帶寬等壓力大幅增加答毫，服務(wù)器成本高褥民，1~3秒延時(shí)；
應(yīng)用場景：視頻會(huì)議

八. 總結(jié)

本文通過直播類應(yīng)用的架構(gòu)洗搂，介紹了一些音視頻技術(shù)方面的知識(shí)轴捎，并且詳述了直播類功能的整體流程。
音視頻技術(shù)是一個(gè)高深的領(lǐng)域蚕脏，本文只是做了一些基礎(chǔ)知識(shí)的總結(jié)，如果大家想要深入了解更多的音視頻技術(shù)侦锯，我推薦大家可以學(xué)習(xí)一下雷神（雷霄驊）的博客驼鞭。

參考資料：
Android直播解決方案
關(guān)于音視頻直播技術(shù)的總結(jié)
視頻直播的技術(shù)原理和實(shí)現(xiàn)思路方案整理
Android直播解決方案
關(guān)于音視頻直播技術(shù)的總結(jié)
視頻直播的技術(shù)原理和實(shí)現(xiàn)思路方案整理
webrtc可以做直播嗎
webrtc進(jìn)階-信令篇-之三：信令、stun尺碰、turn挣棕、ice
WebRTC學(xué)習(xí)總結(jié)
因直播了解webRTC
Android WebRTC簡介
Android 直播 直播架構(gòu)技術(shù)淺析
像花椒，映客亲桥，來瘋這種直播app洛心，技術(shù)實(shí)現(xiàn)難度在哪？需要什么樣技術(shù)人才题篷，還有就是服務(wù)器帶寬要求及成本词身？
RTMP、WebRTC番枚、UDP 三種互動(dòng)直播方案的優(yōu)劣比較
WebRTC 研究系列 二法严、打通webrtc與rtmp
音視頻篇 - Android 圖像處理技術(shù)簡介
老司機(jī)帶你深入了解移動(dòng)直播技術(shù)基礎(chǔ)知識(shí)
Android視頻直播的實(shí)現(xiàn)
Android視頻直播的實(shí)現(xiàn)
Android直播開發(fā)之旅(7)：Android視頻直播核心技術(shù)(架構(gòu))詳解