目前主流的直播架構(gòu)中主要有兩種方案，即流媒體轉(zhuǎn)發(fā)、P2P。流媒體轉(zhuǎn)發(fā)，是一種在視頻直播中以流的方式將連續(xù)的音、視頻數(shù)據(jù)經(jīng)編碼壓縮后傳輸?shù)搅髅襟w服務(wù)器，用戶實時從服務(wù)器獲取流媒體資源，而不必要等待整個文件下載文件完畢的C/S架構(gòu)視頻直播方案；P2P直播，是一種建立在P2P技術(shù)基礎(chǔ)上的視頻直播方案，它規(guī)定客戶端之間使用一定協(xié)議來交換和共享直播數(shù)據(jù)，通過減少對服務(wù)器的數(shù)據(jù)請求，以降低服務(wù)端的I/O帶寬等方面壓力，從而削減服務(wù)器帶寬成本，降低客戶端卡播率。
1. 流媒體轉(zhuǎn)發(fā)
(1) YUV/RGB顏色格式
類似于RGB，YUV也是一種顏色格式，通常我們手機攝像頭采集的每一幀圖像就是YUV格式的，它分別由Y、U、V分量組成，其中“Y”表示明亮度（Luminance或Luma），也就是灰階值；而“U”和“V”表示的則是色度（Chrominance或Chroma），作用是描述影像色彩及飽和度，用于指定像素的顏色。 因此，YUV是一種亮度信號Y和色度信號U、V是分離的色彩空間，它主要用于優(yōu)化彩色視頻信號的傳輸，使其向后相容老式黑白電視，且與RGB要求三個獨立的視頻信號同時傳輸相比，它最大的優(yōu)點在于只需占用極少的頻寬，非常適用于流媒體傳輸。
YUV格式分為兩種類型，即Packet(包)和Plannar(平面)。Packet類型是將Y、U、V分量存儲在同一個數(shù)組中，每個像素點的Y、U、V是連續(xù)交錯存儲的，常見的采樣格式有NV21、NV12；Plannar類型是將Y、U、V分量分別存儲在三個獨立的數(shù)組中，且先連續(xù)存儲所有像素點的Y分量，緊接著存儲所有像素點的U分量，最后存儲所有像素點的V分量，常見的采樣格式有YV12、I420。關(guān)于YUV顏色格式深度分析，參見我這篇博文： 視頻直播YUV顏色格式完全解析 。
(2) H.264視頻編碼技術(shù)
H.264是MPEG-4的第十部分，是由VCEG和MPEG聯(lián)合提出的高度壓縮數(shù)字視頻編碼器標準，它的出現(xiàn)就是為了更大程度地對原始YUV圖像進行壓縮編碼，同時能夠保證視頻傳輸性能和畫面質(zhì)量。H.264具有低碼率、高壓縮、高質(zhì)量的圖像、容錯能力強、網(wǎng)絡(luò)適應(yīng)性強等特點，它最大的優(yōu)勢擁有很高的數(shù)據(jù)壓縮比率，在同等圖像質(zhì)量的條件下，H.264的壓縮比是MPEG-2的兩倍以上。
H.264編碼框架分為兩層：VCL、NAL。VCL(Video Coding Layer，視頻編碼層)，負責高效的視頻內(nèi)容表示；NAL(Network Abstraction Layer，網(wǎng)絡(luò)抽象層)，負責以網(wǎng)絡(luò)所要求的恰當?shù)姆绞綄?shù)據(jù)進行打包和傳送。在H.264協(xié)議里定義了三種幀，完整編碼的幀叫I幀(關(guān)鍵幀)，參考之前的I幀生成的只包含差異部分編碼的幀叫P幀，還有一種參考前后的幀編碼的幀叫B幀。H.264編碼采用的核心算法是幀內(nèi)壓縮和幀間壓縮。其中，幀內(nèi)壓縮是生成I幀的算法，它的原理是當壓縮一幀圖像時，僅考慮本幀的數(shù)據(jù)而不用考慮相鄰幀之間的冗余信息，由于幀內(nèi)壓縮是編碼一個完整的圖像，所以可以獨立的解碼顯示；幀間壓縮是生成P、B幀的算法，它的原理是通過對比相鄰兩幀之間的數(shù)據(jù)進行壓縮，進一步提高壓縮量，減少壓縮比。關(guān)于H.264深度分析，參見我這篇博文： 深度解析H.264編碼原理
(3) H.265視頻編碼技術(shù)
H.265，又稱HEVC(High Efficiency Video Coding，高效視頻編碼)，是繼H.264之后所制定的新的視頻編碼標準，它是對H.264編碼標準的改進，包括提高壓縮效率、提高魯棒性和錯誤恢復(fù)能力、減少實時的時延、降低復(fù)雜度等，其目的是旨在在有限帶寬下傳輸更高質(zhì)量的網(wǎng)絡(luò)視頻，僅需原先的一半帶寬即可播放相同質(zhì)量的視頻。比如H.263在傳輸碼率為2~4Mbps時只能傳輸標清視頻，H.264可以以低于2Mbps的傳輸碼率傳輸標清視頻，而H.264在低于1.5Mbps的傳輸碼率情況下就能傳輸1080P全高清視頻，并且同等分辨率情況下，碼率減少51-74%時H.265編碼視頻的質(zhì)量還能與H.264編碼視頻近似，甚至效果更好。不同編碼方式復(fù)雜度和所需傳輸碼率對比如下圖：
(4) AAC音頻編碼技術(shù)
高級音頻編碼(AdvancedAudio Coding，AAC)一種基于MPEG-4的音頻編碼技術(shù)，它由杜比實驗室、AT&T等公司共同研發(fā)，目的是替換MP3編碼方式。作為一種高壓縮比的音頻壓縮算法，AAC的數(shù)據(jù)壓縮比約為18:1，壓縮后的音質(zhì)可以同未壓縮的CD音質(zhì)相媲美。因此，相對于MP3、WMA等音頻編碼標準來說，在相同質(zhì)量下碼率更低，有效地節(jié)約了傳輸帶寬，被廣泛得應(yīng)用于互聯(lián)網(wǎng)流媒體、IPTV等領(lǐng)域(低碼率，高音質(zhì))。
音頻數(shù)據(jù)在壓縮編碼之前，要先進行采樣與量化，以樣值的形式存在。音頻壓縮編碼的輸出碼流，以音頻幀的形式存在。每個音頻幀包含若干個音頻采樣的壓縮數(shù)據(jù)，AAC的一個音頻幀包含960或1024個樣值，這些壓縮編碼后的音頻幀稱為原始數(shù)據(jù)塊(RawData Block)，由于原始數(shù)據(jù)塊以幀的形式存在，即簡稱為原始幀。原始幀是可變的，如果對原始幀進行ADTS的封裝，得到的原始幀為ADTS幀。 ADTS封裝格式的碼流以幀為單位，一個ADTS幀由幀頭、幀凈荷組成。其中，幀頭定義了音頻采樣率、音頻聲道數(shù)、幀長度等關(guān)鍵信息，它由兩部分組成，共占7個字節(jié)：固定頭信息adts_fixed_header、可變頭信息adts_variable_header。固定頭信息中的數(shù)據(jù)每一幀都相同，而可變頭信息則在幀與幀之間可變；幀凈荷主要由1~4個原始幀組成，它包含的數(shù)據(jù)用于解析與解碼。關(guān)于AAC格式解析，參見我這篇博文： AAC編碼格式分析與MP4文件封裝
(5) 重要參數(shù)
a) 幀率
幀率是指在每秒內(nèi)傳輸?shù)膱D像幀數(shù)量，單位為fps，它的大小影響畫面流暢度，且畫面流暢程度成正比。通常，幀率越大畫面越流暢，幀率越小畫面越有跳動感(卡頓)。
b) 分辨率
就是屏幕圖像的精密度，顯示器所能顯示的像素的多少?？梢园颜麄€圖像想象成是一個大型的棋盤，而分辨率的表示方式就是所有經(jīng)線和緯線交叉點的數(shù)目。以分辨率為1024×768的屏幕來說，（即每一條水平線上包含有1024個像素點，共有768條線，總像素1024x768個），即掃描列數(shù)為1024列，行數(shù)為768行。分辨率影響圖像大小，與圖像大小成正比：分辨率越高，圖像越大；分辨率越低，圖像越小。
c) 碼率(視頻)/比特率(音頻)
視頻中比特率又被稱為碼率，是指碼率就是數(shù)據(jù)傳輸時單位時間傳送的數(shù)據(jù)位數(shù)，單位是Kbps即千位每秒(=1000*1bps)。它表示經(jīng)過編碼(壓縮)后的音、視頻數(shù)據(jù)每秒鐘需要用多少個比特來表示。比特率越高，傳輸數(shù)據(jù)就越大，音、視頻的質(zhì)量就越好，但編碼后的文件就越大。
d) 采樣率
采樣率定義了每秒從連續(xù)信號中提取并組成離散信號的采樣個數(shù)，它用赫茲（Hz）來表示。針對于音頻而言，采樣率則為計算機每秒鐘采集聲音樣本的數(shù)量，數(shù)量越大聲音質(zhì)量就越好，體積隨之也會增大。常見的有8000HZ、22050HZ、44100HZ、16000HZ、96000Hz等。
e) 采樣精度
每一個采樣點都需要用一個數(shù)值來表示大小，這個數(shù)值的數(shù)據(jù)類型大小可以是4bit、8bit、16bit、32bit等，位數(shù)越多，表示得就越精細，聲音質(zhì)量自然就越好。由于受人的器官的機能限制，16bit(位)的聲音已經(jīng)是普通人類的極限了，更高位數(shù)就只能靠儀器才能分辨出來。
其他參數(shù)可參考我這篇博文：淺析Camera視頻實時采集中涉及的參數(shù)配置
2. P2P視頻直播
3. 兩者優(yōu)缺點對比
(1) P2P點對點
P2P視頻直播是客戶端之間使用一定協(xié)議，交換和共享直播數(shù)據(jù)，通過減少對服務(wù)器的數(shù)據(jù)請求，來降低服務(wù)端的I/O帶寬等方面壓力，從而削減服務(wù)器帶寬成本，降低客戶端卡播率。在整個網(wǎng)絡(luò)網(wǎng)框架中，每個客戶端(節(jié)點)是對等的，即同時具有Client和Server的特點。常見開源框架：WebRTC
優(yōu)點：服務(wù)器壓力小，節(jié)省帶寬成本，延時低，響應(yīng)快，秒傳，適合非實時的數(shù)據(jù)傳輸；
缺點：最多4~8個人同時在線觀看，對節(jié)點帶寬要求較高，服務(wù)器視頻錄制不好處理。IPv4網(wǎng)絡(luò)環(huán)境制約，UDP打洞穿透效率問題，打洞不通要服務(wù)器relay；
應(yīng)用場景：安防
(2) 流媒體轉(zhuǎn)發(fā)
常見流媒體直播協(xié)議都屬于C/S型，即所有客戶端通過指定協(xié)議，從服務(wù)端獲取直播數(shù)據(jù)。當客戶端數(shù)量達到一定規(guī)模后，服務(wù)端將承受巨大的I/O和帶寬壓力。若服務(wù)器無法及時處理客戶請求，客戶端卡播率急劇上升，從而影響用戶觀看體驗。常見開源框架：ffmpeg
優(yōu)點：穩(wěn)定可靠，支持量大，可以實現(xiàn)一個人播，百萬人同時在線觀看，且服務(wù)器可以進行視頻錄制存儲，用戶體驗好；
缺點：用戶數(shù)量增加后，對服務(wù)器的資源和帶寬等壓力大幅增加，服務(wù)器成本高，1~3秒延時；
應(yīng)用場景：視頻會議
二、流媒體協(xié)議架構(gòu)解析
1. RTP協(xié)議
RTP(Real-time Transport Protocol，實時傳輸協(xié)議)是一種基于UDP的網(wǎng)絡(luò)傳輸協(xié)議，它介于應(yīng)用層和傳輸層之間，負責對流媒體數(shù)據(jù)進行封包并實現(xiàn)媒體流的實時傳輸。RTP數(shù)據(jù)協(xié)議本身并不能按順序傳送數(shù)據(jù)包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些控制服務(wù)。對于那些丟失的數(shù)據(jù)包，不存在由于超時檢測而帶來的延時，而丟失的包也可以由上層根據(jù)其重要性來選擇性重傳。比如對于I幀、P幀、B幀數(shù)據(jù)，當丟失的是P幀或B幀時，可以不用選擇重傳，這樣畫面只會短暫的不清晰，但是卻保障了傳輸?shù)膶崟r性。
(1) RTP工作機制
當應(yīng)用程序與流媒體服務(wù)器建立一個RTP會話后，應(yīng)用程序會確定一對目的傳輸?shù)刂罚梢粋€網(wǎng)絡(luò)地址和一對端口組成。其中，這一對端口將分別分配給RTP包和RTCP包，通常RTP數(shù)據(jù)包發(fā)向偶數(shù)的UDP端口，而對應(yīng)的控制信號RTCP數(shù)據(jù)發(fā)向相鄰的奇數(shù)端口。RTP包發(fā)送過程：
首先，RTP協(xié)議從上層獲取編碼好的流媒體信息碼流，如H.264、AAC，封裝成RTP數(shù)據(jù)包；RTCP協(xié)議從上層接收控制信息，封裝成RTCP控制包；
然后，RTP將RTP 數(shù)據(jù)包發(fā)往UDP端口對中偶數(shù)端口；RTCP將RTCP控制包發(fā)往UDP端口對中的接收端口；
(2) RTP分組首部格式
2. RTCP協(xié)議
RTCP(Real-Time Transport Control Potocol，實時傳輸控制協(xié)議)是RTP協(xié)議的姐妹協(xié)議，它本身并不傳輸數(shù)據(jù)，而是與RTP各占一個端口，一起協(xié)作將流媒體數(shù)據(jù)進行打包發(fā)送，為RTP流媒體流提供信道外控制。由于RTP本身無法按序傳輸數(shù)據(jù)包提供可靠保證，也不提供流量控制和擁塞控制，這些都由RTCP來負責完成。通常RTCP會采用與RTP相同的分發(fā)機制，向會話中的 所有成員周期性地發(fā)送控制信息，應(yīng)用程序通過接收這些數(shù)據(jù)，從中獲取會話參與者的相關(guān)資料，以及網(wǎng)絡(luò)狀況、分組丟失概率等反饋信息，從而能夠?qū)Ψ?wù)質(zhì)量進 行控制或者對網(wǎng)絡(luò)狀況進行診斷。因此，各參與者可以利用這些信息動態(tài)地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網(wǎng)上的實時數(shù)據(jù)。總之，RTSP發(fā)起/終結(jié)流媒體、RTP傳輸流媒體數(shù)據(jù) 、RTCP對RTP進行控制，同步。
RTCP也是用UDP來傳送的，但RTCP封裝的僅僅是一些控制信息，因而分組很短，所以可以將多個RTCP分組封裝在一個UDP包中。RTCP有如下五種分組類型。
類型縮寫表示用途200SR（Sender Report）發(fā)送端報告201RR（Receiver Report）接收端報告202SDES（Source Description Items）源點描述203BYE結(jié)束傳輸204APP特定應(yīng)用
3. RTSP協(xié)議
RTSP(Real Time Stream Protocol，實時流協(xié)議)是一種基于文本的應(yīng)用層協(xié)議，主要用于C/S模型建立實時流會話。RTSP協(xié)議是一個多媒體播放控制協(xié)議，用于控制具有實時特性的數(shù)據(jù)發(fā)送，但它本身并不傳輸數(shù)據(jù)，而是對流媒體提供諸如播放、暫停、快進等操作。RTSP協(xié)議定義了一對多應(yīng)用程序如何有效地通過IP網(wǎng)絡(luò)傳送流媒體信息數(shù)據(jù)，它在TCP/IP體系中位于RTP和RTCP協(xié)議之上，主要通過TCP或RTP/RTCP完成數(shù)據(jù)傳輸，具有易解析、安全、獨立于傳輸、多服務(wù)器支持等特點。
(1) RTSP URL語法結(jié)構(gòu)
玩過VCL的朋友應(yīng)該知道，當在PC或移動端點播實時流媒體時，我們需要在VCL或點播APP中輸入URL地址才能觀看實時視頻。VCL中配置RTSP URL如下：
格式：(“rtsp:”| “rtspu:”) “//” host [“:”port”] /[abs_path]/content_name
rtsp ： 表示協(xié)議類型，類似于http
host： 表示流媒體服務(wù)器IP地址或有效的域名，如192.192.191.104;
port： 表示端口號，rtsp協(xié)議的缺省端口號為554;
abs_path ： 表示流媒體服務(wù)器中媒體流資源標識，如123456；
(2) RTSP報文結(jié)構(gòu)
與Http協(xié)議類似，RTSP也是一種基于文本的協(xié)議，它的報文類型同樣包括請求報文和響應(yīng)報文。RTSP報文由三部分組成，即開始行、首部行和實體主體，請求報文是指從客戶向服務(wù)器發(fā)送請求報文，響應(yīng)報文是指從服務(wù)器到客戶的回答。
RTSP請求報文結(jié)構(gòu)如下，RTSP請求報文的方法包括：OPTIONS、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、GET_PARAMETER和SET_PARAMETER。
響應(yīng)報文的開始行是狀態(tài)行，RTSP響應(yīng)報文的結(jié)構(gòu)如下：
(3) RTSP會話基本過程
首先，客戶端向服務(wù)器發(fā)送一個RTSP描述命令(DESCRIBE)，流媒體服務(wù)器確認收到后將向客戶端返回一個SDP描述來進行反饋，反饋的信息包括流量數(shù)、媒體類型等；
其次，客戶端接收到SDP后對其進行分析，并未會話中的每一個流發(fā)送一個RTSP建立命令，RTSP建立命令告訴服務(wù)器端用于接收流媒體數(shù)據(jù)的端口，至此RTSP會話建立完成；
第三，客戶端向流媒體服務(wù)器發(fā)送一個播放命令(PLAY)，服務(wù)器就開始在UDP上傳送媒體流(RTP包)到客戶端。在播放過程中，客戶端可以向服務(wù)器發(fā)送命令來控制快進、快退、暫停等操作；
第四，客戶端向服務(wù)器發(fā)送終止命令(TERADOWN)結(jié)束流媒體會話。
Wireshark抓包情況如下：
4. RTMP協(xié)議
RTMP(Real Time Messaging Protocol，實時消息傳輸協(xié)議)屬于五層TCP/IP體系中的應(yīng)用層，它是基于TCP傳輸?shù)牧髅襟w協(xié)議，默認端口為1935，是一個協(xié)議族，包括RTMP基本協(xié)議及RTMPT、RTMPS、REMPE等多種變種。RTMP協(xié)議是Adobe System公司為Flash播放器和FMS服務(wù)器之間音視頻和數(shù)據(jù)傳輸開發(fā)的私有協(xié)議，用來解決多媒體數(shù)據(jù)傳輸流的多路復(fù)用（Multiplexing）和分包（packetizing）的問題，基于此協(xié)議，abobe提供完善的音視頻解決方案，比如點播、直播、互動。
(1) RTMP協(xié)議傳輸原理
RTMP傳輸媒體數(shù)據(jù)的過程中，會先后經(jīng)歷"握手-建立連接-建立流-播放"步驟。發(fā)送端首先把媒體數(shù)據(jù)封裝成消息，然后把消息分割成消息塊，最后將分割后的消息塊通過TCP協(xié)議發(fā)送出去。接收端在通過TCP協(xié)議收到數(shù)據(jù)后，首先把消息塊重新組合成消息，然后通過對消息進行解封裝處理就可以恢復(fù)出媒體數(shù)據(jù)。
消息(Message)
消息是RTMP協(xié)議中基本的數(shù)據(jù)單元。不同種類的消息包含不同的Message Type ID，代表不同的功能。RTMP協(xié)議中一共規(guī)定了十多種消息類型，分別發(fā)揮著不同的作用。例如，Message Type ID在1-7的消息用于協(xié)議控制，這些消息一般是RTMP協(xié)議自身管理要使用的消息，用戶一般情況下無需操作其中的數(shù)據(jù)。Message Type ID為8，9的消息分別用于傳輸音頻和視頻數(shù)據(jù)。Message Type ID為15-20的消息用于發(fā)送AMF編碼的命令，負責用戶與服務(wù)器之間的交互，比如播放，暫停等等。消息首部（Message Header）有四部分組成：標志消息類型的Message Type ID，標志消息長度的Payload Length，標識時間戳的Timestamp，標識消息所屬媒體流的Stream ID。消息的報文結(jié)構(gòu)如下圖所示：
消息塊(Message Chunk)
在網(wǎng)絡(luò)上傳輸數(shù)據(jù)時，消息需要被拆分成較小的數(shù)據(jù)塊，才適合在相應(yīng)的網(wǎng)絡(luò)環(huán)境上傳輸。RTMP協(xié)議中規(guī)定，消息在網(wǎng)絡(luò)上傳輸時被拆分成消息塊（Chunk），默認大小為128字節(jié)。消息塊首部（Chunk Header）有三部分組成：用于標識本塊的Chunk Basic Header，用于標識本塊負載所屬消息的Chunk Message Header，以及當時間戳溢出時才出現(xiàn)的Extended Timestamp。消息塊的報文結(jié)構(gòu)如下圖所示：
(2) RTMP協(xié)議"握手"流程分析
一個RTMP連接以"握手"開始，雙方會分辨發(fā)送帶下固定的三個消息塊(數(shù)據(jù)塊)，比如客戶端會向服務(wù)器發(fā)送C0、C1、C2消息塊，服務(wù)器收到客戶端發(fā)來的消息塊后，會向客戶端發(fā)送S1、S2、S3消息塊，具體流程如下：
首先，客戶端向服務(wù)器發(fā)送C0、C1消息塊，服務(wù)器收到C0或C1后，會向客戶端發(fā)送S0和S1；
其次，當客戶端收齊S0、S1消息塊后，再向服務(wù)器發(fā)送C2消息塊。當服務(wù)器收齊C0和C1后，再向客戶端發(fā)送S2消息塊；
最后，當客戶端和服務(wù)器分別收到S2和C2后，握手完成。
5. RTMP協(xié)議、RTSP協(xié)議、HTTP協(xié)議區(qū)別
這三個協(xié)議都屬于TCP/IP五層體系中應(yīng)用層協(xié)議，通常RTMP、RTSP協(xié)議用于直播，HTTP用于點播。它們的主要區(qū)別如下：
(1) RTMP協(xié)議
a) 是流媒體協(xié)議；
b) RTMP協(xié)議是Adobe的私有協(xié)議，未完全公開；
c) RTMP協(xié)議一般傳輸flv、f4v格式的流式文件；
d) RTMP使用TCP傳輸，只需要1個通道上傳命令和數(shù)據(jù)；
(2) RTSP協(xié)議
a) 是流媒體協(xié)議，RTSP為每個會話保持狀態(tài)；
b) RTSP協(xié)議是共有協(xié)議，有專門機構(gòu)做維護；
c) RTSP協(xié)議一般傳輸ts、mp4格式的數(shù)據(jù)，但mp4不是流式文件，必須有索引才能任意seek；
d) RTSP使用UDP傳輸，需要2-3個通道來傳輸命令和數(shù)據(jù)，即數(shù)據(jù)和命令通道分離；
(3) HTTP協(xié)議
a) 不是流媒體協(xié)議，HTTP是無狀態(tài)協(xié)議；
b) HTTP協(xié)議是共有協(xié)議，有專門機構(gòu)做維護；
c) HTTP協(xié)議沒有特定的傳輸流；
d) HTTP一般在TCP一個通道上傳輸命令和數(shù)據(jù)；
參考資料
(1) 詳解P2P技術(shù)與前景展望
(2) H.265百度百科
(3) H.265深度解析
(4) 視頻直播系統(tǒng)的P2P方式
(5) RTMP、RTSP、HTTP協(xié)議區(qū)別
(6) 流媒體傳輸控制協(xié)議(RTSP RTP SDP)詳解之RTP
(7) 流媒體傳輸控制協(xié)議(RTSP RTP SDP)詳解之RTSP
(8) 帶你吃透RTMP
(9) RTMP協(xié)議學(xué)習(xí)總結(jié)
(10) rtmp 協(xié)議分析及交互過程
