直播流媒體協(xié)議中RTMP和HLS協(xié)議是我們比較熟悉的。RTMP（real-time message protocol）實(shí)時(shí)消息協(xié)議，上層基于TCP協(xié)議，因此具有穩(wěn)定，可控等特性。在播放端時(shí)延上一般為3-5s。HLS（HTTP Live Stream）是Apple公司的動(dòng)態(tài)碼率自適應(yīng)技術(shù)，支持點(diǎn)播和直播功能。以HTTP為基礎(chǔ)，因此其穿透能力強(qiáng)、無(wú)論是點(diǎn)播還是直播，都是通過(guò)HTTP進(jìn)行媒體流數(shù)據(jù)請(qǐng)求，但正是因?yàn)榛贖TTP協(xié)議，我們知道，HTTP是用于文本請(qǐng)求的，所以無(wú)論是在點(diǎn)播還是在直播，都會(huì)對(duì)流進(jìn)行切片，切成一個(gè)個(gè)適合的小分片，而這造成了在直播中，主播端播放的時(shí)候會(huì)有15s左右的延遲。這在直播體驗(yàn)上會(huì)有點(diǎn)差強(qiáng)人意?；贖LS的整體功能框架如下圖2：

RTMP在直播中用的比較多，然而，在弱網(wǎng)環(huán)境下，上層基于TCP協(xié)議的缺點(diǎn)也暴露的比較明顯。在弱網(wǎng)環(huán)境下，丟包的概率大大增加，基于TCP協(xié)議的丟包重傳給帶寬造成了更大的壓力，加劇了網(wǎng)絡(luò)擁塞。再者，直播的多樣化需求、如連麥，如多人討論等需求的提出，RTP（real-time transport protocol）協(xié)議族成了多樣化直播的有利協(xié)議。若如果只是單純使用RTP協(xié)議，還無(wú)法做到直播多樣化的功能，RTP協(xié)議只是攜帶流媒體數(shù)據(jù)，而做到流媒體控制，當(dāng)然還需要RTCP（real-time transport control protocol）協(xié)助。因此，現(xiàn)在多樣化要求下的直播，大多基于WebRTC進(jìn)行二次開(kāi)發(fā)，或進(jìn)行裁剪，或進(jìn)行優(yōu)化，或加入相關(guān)自定義插件。關(guān)于流媒體協(xié)議，會(huì)在流媒體協(xié)議系列中講到。

WebRTC（Web Real-Time Communication）是一個(gè)基于網(wǎng)頁(yè)瀏覽器進(jìn)行實(shí)時(shí)語(yǔ)音對(duì)話或者視頻對(duì)話的API。谷歌于2011年6月對(duì)WebRTC進(jìn)行了開(kāi)源。WebRTC提供了實(shí)時(shí)視頻會(huì)議的核心技術(shù)。WebRTC架構(gòu)如圖3所示：WebRTC完成了從音視頻采集到音視頻播放的全過(guò)程。最重要的還完成了NAT穿越功能，為點(diǎn)對(duì)點(diǎn)音視頻通信提供了基礎(chǔ)。對(duì)于WebRTC這塊，在WebRTC技術(shù)系列中會(huì)詳細(xì)講到。

WebRTC既然是點(diǎn)對(duì)點(diǎn)的，那么如果單純的直播功能，能用WebRTC嗎？答案是肯定的，從圖3 WebRTC的框架圖可以看到，WebRTC具備了音視頻引擎，同時(shí)提供了網(wǎng)絡(luò)傳輸方案，而直播無(wú)非就是音視頻流數(shù)據(jù)傳輸，因此WebRTC是完全能做到的。搭建MCU（Multi-point Control Unit）或者SFU（Selective forward Unit）網(wǎng)絡(luò)結(jié)構(gòu)來(lái)解決一端客戶端進(jìn)行網(wǎng)絡(luò)音視頻傳輸?shù)組CU或者SFU服務(wù)，繼而由MCU或者SFU服務(wù)轉(zhuǎn)發(fā)到用戶端（直播中，用戶一般稱為粉絲端）。

實(shí)際上，目前好多公司即使是單純的直播功能點(diǎn)也用到了WebRTC?？赡苡腥藭?huì)有疑問(wèn)，單純的直播為啥不直接使用RTMP。這其中主要有幾個(gè)原因，一是WebRTC基于RTP協(xié)議，RTP上層基于UDP協(xié)議，這在弱網(wǎng)條件下，不會(huì)像RTMP一樣，進(jìn)行重復(fù)重傳，加劇網(wǎng)絡(luò)擁塞，而WebRTC通過(guò)各種技術(shù)來(lái)解決丟包問(wèn)題。二是在后續(xù)直播功能擴(kuò)展下更加方便快捷，如加入多人連麥功能等。當(dāng)然，在擴(kuò)展性上如連麥，rtmp也可以完成，但因?yàn)榛赥CP需要進(jìn)行三次握手，每次連接都產(chǎn)生了額外的RTT，存在高延遲的問(wèn)題，因此rtmp方案是不太可取的。當(dāng)然，一開(kāi)始項(xiàng)目就使用了RTMP協(xié)議，并且也搭建了RTMP服務(wù)器，特別是整個(gè)大集團(tuán)都在使用RTMP的時(shí)候，是不可能一刀切的從RTMP轉(zhuǎn)到RTP的，因此就會(huì)有如下的RTP推流之后經(jīng)過(guò)MCU再轉(zhuǎn)RTMP的方案存在。

圖 rtmp方案

圖 rtp方案

一個(gè)完整的直播功能，一般包括主播端、粉絲端（播放端）、以及服務(wù)端。服務(wù)端涉及的功能很多，可能會(huì)分成不同功能的服務(wù)，但這里我們把這些功能統(tǒng)一為服務(wù)端。主播端，顧名思義，就是信息內(nèi)容分享者，對(duì)話議題發(fā)起者，是音視頻流發(fā)起的一端。粉絲端：既是觀看主播信息的用戶，是獲取音視頻流的一端。服務(wù)端：既充當(dāng)接收流，保存流中間方，而且也是各種信號(hào)命令的控制者，如主播在直播過(guò)程中想發(fā)送優(yōu)惠券，那么命令就通過(guò)服務(wù)器，繼而發(fā)送給用戶。三者的關(guān)系如下圖4：這里主播推流的操作涉及的協(xié)議可以是RTMP（以RTMP為協(xié)議的流媒體傳輸）、HLS、或者RTP/RTCP等，也可以是先RTP，再轉(zhuǎn)RTMP。根據(jù)業(yè)務(wù)情況進(jìn)行，推流涉及的一些開(kāi)源庫(kù)可以是FFmpeg、WebRTC。

圖 完整直播架構(gòu)

前面說(shuō)到，多樣化直播功能需求下，主播側(cè)基于RTP/RTCP協(xié)議進(jìn)行流媒體傳輸。而粉絲側(cè)是基于RTP或RTMP協(xié)議進(jìn)行的流媒體傳輸。下圖中是一個(gè)完整音視頻拉流播放流程，根據(jù)開(kāi)源庫(kù)FFmpeg的執(zhí)行流程來(lái)分析的，至于WebRTC的音視頻播放則是直接通過(guò)RTP進(jìn)行的，并沒(méi)有像FFmpeg那樣，根據(jù)不同的流媒體協(xié)議來(lái)進(jìn)行。一般情況下，在多樣化直播中，播放端一般都是在FFmpeg開(kāi)源庫(kù)進(jìn)行開(kāi)發(fā)。實(shí)際上，F(xiàn)Fmpeg也具備推流能力，只不過(guò)因?yàn)閃ebRTC天然的視頻通話能力，在多樣化直播需求中顯然更具備優(yōu)勢(shì)。因此，一般情況下，推流直接基于WebRTC、拉流基于FFmpeg。FFmpeg的拉流流程如下圖所示，如根據(jù)RTMP協(xié)議進(jìn)行流傳輸，確定流文件為何種格式，由特定的格式進(jìn)行相關(guān)的處理、進(jìn)行音頻視頻解碼、渲染播放。關(guān)于FFmpeg這塊，將在FFmpeg進(jìn)行詳細(xì)分析。

多樣化直播涉及的內(nèi)容鏈路主要包括流媒體協(xié)議, 協(xié)議選擇，根據(jù)媒體信息選擇封裝格式、根據(jù)音頻和視頻數(shù)據(jù)，分解出編解碼格式、得出編解碼數(shù)據(jù)之后，推流的進(jìn)行發(fā)送，拉流進(jìn)行渲染播放。關(guān)于音頻處理中，發(fā)送端，涉及采集----> 3A處理 ——>發(fā)送 ， 接送方，接收丟包恢復(fù) ——> NetEQ緩存解碼——> 混音播放，這其中，涉及各種算法，包括卡爾曼濾波算法、3A、NetEQ等。 關(guān)于視頻處理，發(fā)送端，涉及攝像頭采集——> 編碼（v8，h264）——>發(fā)送，接收方，接收丟包恢復(fù)——> jitterbuffer——>解碼——>屏幕顯示。在音視頻的傳輸過(guò)程中，涉及到FEC、延遲丟包重傳等算法。?