ffmpeg開發之旅(7):Android視頻直播核心技術(架構)詳解

ffmpeg開發之旅(7):Android視頻直播核心技術(架構)詳解

一、直播架構解析

目前主流的直播架構中主要有兩種方案,即流媒體轉發、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顏色格式深度分析。
(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深度分析。
(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格式解析。
a) 幀率
幀率是指在每秒內傳輸的圖像幀數量,單位為fps,它的大小影響畫面流暢度,且畫面流暢程度成正比。通常,幀率越大畫面越流暢,幀率越小畫面越有跳動感(卡頓)。
b) 分辨率
就是屏幕圖像的精密度,顯示器所能顯示的像素的多少。可以把整個圖像想象成是一個大型的棋盤,而分辨率的表示方式就是所有經線和緯線交叉點的數目。以分辨率為1024×768的屏幕來說,(即每一條水平線上包含有1024個像素點,共有768條線,總像素1024×768個),即掃描列數為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一個通道上傳輸命令和數據;

You May Also Like