(轉載請宣告出處：http://blog.csdn.net/andrexpert/article/details/76919535)

一、直播架構解析

     目前主流的直播架構中主要有兩種方案，即流媒體轉發、P2P。流媒體轉發，是一種在視訊直播中以流的方式將連續的音、視訊資料經編碼壓縮後傳輸到流媒體伺服器，使用者實時從伺服器獲取流媒體資源，而不必要等待整個檔案下載檔案完畢的C/S架構視訊直播方案；P2P直播，是一種建立在P2P技術基礎上的視訊直播方案，它規定客戶端之間使用一定協議來交換和共享直播資料，通過減少對伺服器的資料請求，以降低服務端的I/O頻寬等方面壓力，從而削減伺服器頻寬成本，降低客戶端卡播率。
1. 流媒體轉發

(1) YUV/RGB顏色格式
    類似於RGB，YUV也是一種顏色格式，通常我們手機攝像頭採集的每一幀影象就是YUV格式的，它分別由Y、U、V分量組成，其中“Y”表示明亮度（Luminance或Luma），也就是灰階值；而“U”和“V”表示的則是色度（Chrominance或Chroma），作用是描述影像色彩及飽和度，用於指定畫素的顏色。 因此，YUV是一種亮度訊號Y和色度訊號U、V是分離的色彩空間，它主要用於優化彩色視訊訊號的傳輸，使其向後相容老式黑白電視，且與RGB要求三個獨立的視訊訊號同時傳輸相比，它最大的優點在於只需佔用極少的頻寬，非常適用於流媒體傳輸。
     YUV格式分為兩種型別，即Packet(包)和Plannar(平面)。Packet型別是將Y、U、V分量儲存在同一個陣列中，每個畫素點的Y、U、V是連續交錯儲存的，常見的取樣格式有NV21、NV12；Plannar型別是將Y、U、V分量分別儲存在三個獨立的陣列中，且先連續儲存所有畫素點的Y分量，緊接著儲存所有畫素點的U分量，最後儲存所有畫素點的V分量，常見的取樣格式有YV12、I420。關於YUV顏色格式深度分析，參見我這篇博文：

視訊直播YUV顏色格式完全解析。

(2) H.264視訊編碼技術
     H.264是MPEG-4的第十部分，是由VCEG和MPEG聯合提出的高度壓縮數字視訊編碼器標準，它的出現就是為了更大程度地對原始YUV影象進行壓縮編碼，同時能夠保證視訊傳輸效能和畫面質量。H.264具有低位元速率、高壓縮、高質量的影象、容錯能力強、網路適應性強等特點，它最大的優勢擁有很高的資料壓縮比率，在同等影象質量的條件下，H.264的壓縮比是MPEG-2的兩倍以上。
     H.264編碼框架分為兩層：VCL、NAL。VCL(Video Coding Layer，視訊編碼層)，負責高效的視訊內容表示；NAL(Network Abstraction Layer，網路抽象層)，負責以網路所要求的恰當的方式對資料進行打包和傳送。在H.264協議裡定義了三種幀，完整編碼的幀叫I幀(關鍵幀)，參考之前的I幀生成的只包含差異部分編碼的幀叫P幀，還有一種參考前後的幀編碼的幀叫B幀。H.264編碼採用的核心演算法是幀內壓縮和幀間壓縮。其中，幀內壓縮是生成I幀的演算法，它的原理是當壓縮一幀影象時，僅考慮本幀的資料而不用考慮相鄰幀之間的冗餘資訊，由於幀內壓縮是編碼一個完整的影象，所以可以獨立的解碼顯示；幀間壓縮是生成P、B幀的演算法，它的原理是通過對比相鄰兩幀之間的資料進行壓縮，進一步提高壓縮量，減少壓縮比。關於H.264深度分析，參見我這篇博文：

深度解析H.264編碼原理

(3) H.265視訊編碼技術
      H.265，又稱HEVC(High Efficiency Video Coding，高效視訊編碼)，是繼H.264之後所制定的新的視訊編碼標準，它是對H.264編碼標準的改進，包括提高壓縮效率、提高魯棒性和錯誤恢復能力、減少實時的時延、降低複雜度等，其目的是旨在在有限頻寬下傳輸更高質量的網路視訊，僅需原先的一半頻寬即可播放相同質量的視訊。比如H.263在傳輸位元速率為2~4Mbps時只能傳輸標清視訊，H.264可以以低於2Mbps的傳輸位元速率傳輸標清視訊，而H.264在低於1.5Mbps的傳輸位元速率情況下就能傳輸1080P全高清視訊，並且同等解析度情況下，位元速率減少51-74%時H.265編碼視訊的質量還能與H.264編碼視訊近似，甚至效果更好。不同編碼方式複雜度和所需傳輸位元速率對比如下圖：


(4) AAC音訊編碼技術
    高階音訊編碼(AdvancedAudio Coding，AAC)一種基於MPEG-4的音訊編碼技術，它由杜比實驗室、AT&T等公司共同研發，目的是替換MP3編碼方式。作為一種高壓縮比的音訊壓縮演算法，AAC的資料壓縮比約為18:1，壓縮後的音質可以同未壓縮的CD音質相媲美。因此，相對於MP3、WMA等音訊編碼標準來說，在相同質量下位元速率更低，有效地節約了傳輸頻寬，被廣泛得應用於網際網路流媒體、IPTV等領域(低位元速率，高音質)。
     音訊資料在壓縮編碼之前，要先進行取樣與量化，以樣值的形式存在。音訊壓縮編碼的輸出碼流，以音訊幀的形式存在。每個音訊幀包含若干個音訊取樣的壓縮資料，AAC的一個音訊幀包含960或1024個樣值，這些壓縮編碼後的音訊幀稱為原始資料塊(RawData Block)，由於原始資料塊以幀的形式存在，即簡稱為原始幀。原始幀是可變的，如果對原始幀進行ADTS的封裝，得到的原始幀為ADTS幀。 ADTS封裝格式的碼流以幀為單位，一個ADTS幀由幀頭、幀淨荷組成。其中，幀頭定義了音訊取樣率、音訊聲道數、幀長度等關鍵資訊，它由兩部分組成，共佔7個位元組：固定頭資訊adts_fixed_header、可變頭資訊adts_variable_header。固定頭資訊中的資料每一幀都相同，而可變頭資訊則在幀與幀之間可變；幀淨荷主要由1~4個原始幀組成，它包含的資料用於解析與解碼。關於AAC格式解析，參見我這篇博文：AAC編碼格式分析與MP4檔案封裝

(5) 重要引數
a) 幀率
     幀率是指在每秒內傳輸的影象幀數量，單位為fps，它的大小影響畫面流暢度，且畫面流暢程度成正比。通常，幀率越大畫面越流暢，幀率越小畫面越有跳動感(卡頓)。
b) 解析度
     就是螢幕影象的精密度，顯示器所能顯示的畫素的多少。可以把整個影象想象成是一個大型的棋盤，而解析度的表示方式就是所有經線和緯線交叉點的數目。以解析度為1024×768的螢幕來說，（即每一條水平線上包含有1024個畫素點，共有768條線，總畫素1024x768個），即掃描列數為1024列，行數為768行。解析度影響影象大小，與影象大小成正比：解析度越高，影象越大；解析度越低，影象越小。
c) 位元速率(視訊)/位元率(音訊)
     視訊中位元率又被稱為位元速率，是指位元速率就是資料傳輸時單位時間傳送的資料位數，單位是Kbps即千位每秒(=1000*1bps)。它表示經過編碼(壓縮)後的音、視訊資料每秒鐘需要用多少個位元來表示。位元率越高，傳輸資料就越大，音、視訊的質量就越好，但編碼後的檔案就越大。
d) 取樣率
     取樣率定義了每秒從連續訊號中提取並組成離散訊號的取樣個數，它用赫茲（Hz）來表示。針對於音訊而言，取樣率則為計算機每秒鐘採集聲音樣本的數量，數量越大聲音質量就越好，體積隨之也會增大。常見的有8000HZ、22050HZ、44100HZ、16000HZ、96000Hz等。
e) 取樣精度
     每一個取樣點都需要用一個數值來表示大小，這個數值的資料型別大小可以是4bit、8bit、16bit、32bit等，位數越多，表示得就越精細，聲音質量自然就越好。由於受人的器官的機能限制，16bit(位)的聲音已經是普通人類的極限了，更高位數就只能靠儀器才能分辨出來。

2. P2P視訊直播

3. 兩者優缺點對比
(1) P2P點對點
      P2P視訊直播是客戶端之間使用一定協議，交換和共享直播資料，通過減少對伺服器的資料請求，來降低服務端的I/O頻寬等方面壓力，從而削減伺服器頻寬成本，降低客戶端卡播率。在整個網路網框架中，每個客戶端(節點)是對等的，即同時具有Client和Server的特點。常見開源框架：WebRTC
優點：伺服器壓力小，節省頻寬成本，延時低，響應快，秒傳，適合非實時的資料傳輸；
缺點：最多4~8個人同時線上觀看，對節點頻寬要求較高，伺服器視訊錄製不好處理。IPv4網路環境制約，UDP打洞穿透效率問題，打洞不通要伺服器relay；
應用場景：安防
(2) 流媒體轉發
     常見流媒體直播協議都屬於C/S型，即所有客戶端通過指定協議，從服務端獲取直播資料。當客戶端數量達到一定規模後，服務端將承受巨大的I/O和頻寬壓力。若伺服器無法及時處理客戶請求，客戶端卡播率急劇上升，從而影響使用者觀看體驗。常見開源框架：ffmpeg
優點：穩定可靠，支援量大，可以實現一個人播，百萬人同時線上觀看，且伺服器可以進行視訊錄製儲存，使用者體驗好；
缺點：使用者數量增加後，對伺服器的資源和頻寬等壓力大幅增加，伺服器成本高，1~3秒延時；
應用場景：視訊會議

二、流媒體協議架構解析


1. RTP協議
      RTP(Real-time Transport Protocol，實時傳輸協議)是一種基於UDP的網路傳輸協議，它介於應用層和傳輸層之間，負責對流媒體資料進行封包並實現媒體流的實時傳輸。RTP資料協議本身並不能按順序傳送資料包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些控制服務。對於那些丟失的資料包，不存在由於超時檢測而帶來的延時，而丟失的包也可以由上層根據其重要性來選擇性重傳。比如對於I幀、P幀、B幀資料，當丟失的是P幀或B幀時，可以不用選擇重傳，這樣畫面只會短暫的不清晰，但是卻保障了傳輸的實時性。
(1) RTP工作機制
     當應用程式與流媒體伺服器建立一個RTP會話後，應用程式會確定一對目的傳輸地址，它由一個網路地址和一對埠組成。其中，這一對埠將分別分配給RTP包和RTCP包，通常RTP資料包發向偶數的UDP埠，而對應的控制訊號RTCP資料發向相鄰的奇數埠。RTP包傳送過程：
      首先，RTP協議從上層獲取編碼好的流媒體資訊碼流，如H.264、AAC，封裝成RTP資料包；RTCP協議從上層接收控制資訊，封裝成RTCP控制包；
      然後，RTP將RTP 資料包發往UDP埠對中偶數埠；RTCP將RTCP控制包發往UDP埠對中的接收埠；
(2) RTP分組首部格式

2. RTCP協議
      RTCP(Real-Time Transport Control Potocol，實時傳輸控制協議)是RTP協議的姐妹協議，它本身並不傳輸資料，而是與RTP各佔一個埠，一起協作將流媒體資料進行打包傳送，為RTP流媒體流提供通道外控制。由於RTP本身無法按序傳輸資料包提供可靠保證，也不提供流量控制和擁塞控制，這些都由RTCP來負責完成。通常RTCP會採用與RTP相同的分發機制，向會話中的 所有成員週期性地傳送控制資訊，應用程式通過接收這些資料，從中獲取會話參與者的相關資料，以及網路狀況、分組丟失概率等反饋資訊，從而能夠對服務質量進 行控制或者對網路狀況進行診斷。因此，各參與者可以利用這些資訊動態地改變傳輸速率，甚至改變有效載荷型別。RTP和RTCP配合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網上的實時資料。總之，RTSP發起/終結流媒體、RTP傳輸流媒體資料 、RTCP對RTP進行控制，同步。
RTCP也是用UDP來傳送的，但RTCP封裝的僅僅是一些控制資訊，因而分組很短，所以可以將多個RTCP分組封裝在一個UDP包中。RTCP有如下五種分組型別。
型別縮寫表示用途200SR（Sender Report）傳送端報告201RR（Receiver Report）接收端報告202SDES（Source Description Items）源點描述203BYE結束傳輸204APP特定應用
3. RTSP協議
     RTSP(Real Time Stream Protocol，實時流協議)是一種基於文字的應用層協議，主要用於C/S模型建立實時流會話。RTSP協議是一個多媒體播放控制協議，用於控制具有實時特性的資料傳送，但它本身並不傳輸資料，而是對流媒體提供諸如播放、暫停、快進等操作。RTSP協議定義了一對多應用程式如何有效地通過IP網路傳送流媒體資訊資料，它在TCP/IP體系中位於RTP和RTCP協議之上，主要通過TCP或RTP/RTCP完成資料傳輸，具有易解析、安全、獨立於傳輸、多伺服器支援等特點。
(1) RTSP URL語法結構
     玩過VCL的朋友應該知道，當在PC或移動端點播實時流媒體時，我們需要在VCL或點播APP中輸入URL地址才能觀看實時視訊。VCL中配置RTSP URL如下：

格式：(“rtsp:”| “rtspu:”) “//” host [“:”port”] /[abs_path]/content_name
       rtsp  ： 表示協議型別，類似於http
       host： 表示流媒體伺服器IP地址或有效的域名，如192.192.191.104;
       port： 表示埠號，rtsp協議的預設埠號為554;
       abs_path  ： 表示流媒體伺服器中媒體流資源標識，如123456；
(2) RTSP報文結構
      與Http協議類似，RTSP也是一種基於文字的協議，它的報文型別同樣包括請求報文和響應報文。RTSP報文由三部分組成，即開始行、首部行和實體主體，請求報文是指從客戶向伺服器傳送請求報文，響應報文是指從伺服器到客戶的回答。 
     RTSP請求報文結構如下，RTSP請求報文的方法包括：OPTIONS、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、GET_PARAMETER和SET_PARAMETER。
    
    響應報文的開始行是狀態行，RTSP響應報文的結構如下：
   
(3)  RTSP會話基本過程
    首先，客戶端向伺服器傳送一個RTSP描述命令(DESCRIBE)，流媒體伺服器確認收到後將向客戶端返回一個SDP描述來進行反饋，反饋的資訊包括流量數、媒體型別等；
    其次，客戶端接收到SDP後對其進行分析，並未會話中的每一個流傳送一個RTSP建立命令，RTSP建立命令告訴伺服器端用於接收流媒體資料的埠，至此RTSP會話建立完成；
    第三，客戶端向流媒體伺服器傳送一個播放命令(PLAY)，伺服器就開始在UDP上傳送媒體流(RTP包)到客戶端。在播放過程中，客戶端可以向伺服器傳送命令來控制快進、快退、暫停等操作；
    第四，客戶端向伺服器傳送終止命令(TERADOWN)結束流媒體會話。
Wireshark抓包情況如下：

4. RTMP協議
     RTMP(Real Time Messaging Protocol，實時訊息傳輸協議)屬於五層TCP/IP體系中的應用層，它是基於TCP傳輸的流媒體協議，預設埠為1935，是一個協議族，包括RTMP基本協議及RTMPT、RTMPS、REMPE等多種變種。RTMP協議是Adobe System公司為Flash播放器和FMS伺服器之間音視訊和資料傳輸開發的私有協議，用來解決多媒體資料傳輸流的多路複用（Multiplexing）和分包（packetizing）的問題，基於此協議，abobe提供完善的音視訊解決方案，比如點播、直播、互動。
(1) RTMP協議傳輸原理
     RTMP傳輸媒體資料的過程中，會先後經歷"握手-建立連線-建立流-播放"步驟。傳送端首先把媒體資料封裝成訊息，然後把訊息分割成訊息塊，最後將分割後的訊息塊通過TCP協議傳送出去。接收端在通過TCP協議收到資料後，首先把訊息塊重新組合成訊息，然後通過對訊息進行解封裝處理就可以恢復出媒體資料。
訊息(Message)
      訊息是RTMP協議中基本的資料單元。不同種類的訊息包含不同的Message Type ID，代表不同的功能。RTMP協議中一共規定了十多種訊息型別，分別發揮著不同的作用。例如，Message Type ID在1-7的訊息用於協議控制，這些訊息一般是RTMP協議自身管理要使用的訊息，使用者一般情況下無需操作其中的資料。Message Type ID為8，9的訊息分別用於傳輸音訊和視訊資料。Message Type ID為15-20的訊息用於傳送AMF編碼的命令，負責使用者與伺服器之間的互動，比如播放，暫停等等。訊息首部（Message Header）有四部分組成：標誌訊息型別的Message Type ID，標誌訊息長度的Payload Length，標識時間戳的Timestamp，標識訊息所屬媒體流的Stream ID。訊息的報文結構如下圖所示：

訊息塊(Message Chunk)
     在網路上傳輸資料時，訊息需要被拆分成較小的資料塊，才適合在相應的網路環境上傳輸。RTMP協議中規定，訊息在網路上傳輸時被拆分成訊息塊（Chunk），預設大小為128位元組。訊息塊首部（Chunk Header）有三部分組成：用於標識本塊的Chunk Basic Header，用於標識本塊負載所屬訊息的Chunk Message Header，以及當時間戳溢位時才出現的Extended Timestamp。訊息塊的報文結構如下圖所示：

(2) RTMP協議"握手"流程分析
      一個RTMP連線以"握手"開始，雙方會分辨傳送帶下固定的三個訊息塊(資料塊)，比如客戶端會向伺服器傳送C0、C1、C2訊息塊，伺服器收到客戶端發來的訊息塊後，會向客戶端傳送S1、S2、S3訊息塊，具體流程如下：
    首先，客戶端向伺服器傳送C0、C1訊息塊，伺服器收到C0或C1後，會向客戶端傳送S0和S1；
    其次，當客戶端收齊S0、S1訊息塊後，再向伺服器傳送C2訊息塊。當伺服器收齊C0和C1後，再向客戶端傳送S2訊息塊；
    最後，當客戶端和伺服器分別收到S2和C2後，握手完成。
    
5. RTMP協議、RTSP協議、HTTP協議區別
     這三個協議都屬於TCP/IP五層體系中應用層協議，通常RTMP、RTSP協議用於直播，HTTP用於點播。它們的主要區別如下：
(1) RTMP協議
    a) 是流媒體協議；
    b) RTMP協議是Adobe的私有協議，未完全公開；
    c) RTMP協議一般傳輸flv、f4v格式的流式檔案；
    d) RTMP使用TCP傳輸，只需要1個通道上傳命令和資料；
(2) RTSP協議
    a) 是流媒體協議，RTSP為每個會話保持狀態；
    b) RTSP協議是共有協議，有專門機構做維護；
    c) RTSP協議一般傳輸ts、mp4格式的資料，但mp4不是流式檔案，必須有索引才能任意seek；
    d) RTSP使用UDP傳輸，需要2-3個通道來傳輸命令和資料，即資料和命令通道分離；
(3) HTTP協議
    a) 不是流媒體協議，HTTP是無狀態協議；
    b) HTTP協議是共有協議，有專門機構做維護；
    c) HTTP協議沒有特定的傳輸流；
    d) HTTP一般在TCP一個通道上傳輸命令和資料；

參考資料
(1) 詳解P2P技術與前景展望
(2) H.265百度百科
(3) H.265深度解析
(4) 視訊直播系統的P2P方式
(5) RTMP、RTSP、HTTP協議區別
(6) 流媒體傳輸控制協議(RTSP RTP SDP)詳解之RTP
(7) 流媒體傳輸控制協議(RTSP RTP SDP)詳解之RTSP
(8) 帶你吃透RTMP
(9) RTMP協議學習總結
(10) rtmp 協議分析及互動過程