音視頻&流媒體

[TOC]算法

音視頻&流媒體

是什麼促使我要寫這一篇音視頻&流媒體門的初級文章?那是由於和一妹子打賭碼率的概念,結果輸了;對一個技術人員而言,碼率這個種最基本的機率都沒整明白,簡直是奇恥大辱,開個玩笑。有了這個前提以後,發現,仍是得多理解下原理和基礎入門知識。緩存

流媒體背景

當下,音視頻、流媒體已經無處不在,直播已經火了幾年,在後續的時間裏面,人們聊天已經不只僅知足與文字、而是更多的在於「類面對面」交流,可以實時感知對方的表情、動做。爲此,有必要跟緊時代潮流,好好梳理梳理流媒體這門功課。服務器

流媒體是什麼?流媒體就是指採用流式傳輸技術在網絡上連續實時播放的媒體格式,如音頻、視頻或多媒體文件。流媒體技術也稱流式媒體技術。那麼音視頻就是流媒體的核心。微信

音視頻常見術語定義規範

音視頻組成

一個完整的視頻文件,包括音頻、視頻和基礎元信息,咱們常見的視頻文件如mp四、mov、flv、avi、rmvb等視頻文件,就是一個容器的封裝,裏面包含了音頻和視頻兩部分,而且都是經過一些特定的編碼算法,進行編碼壓縮事後的。網絡

H26四、Xvid等就是視頻編碼格式,MP三、AAC等就是音頻編碼格式。例如:將一個Xvid視頻編碼文件和一個MP3音頻編碼文件按AVI封裝標準封裝之後,就獲得一個AVI後綴的視頻文件。架構

所以,視頻轉換須要設置的本質就是tcp

  • 設置須要的視頻編碼
  • 設置須要的音頻編碼
  • 選擇須要的容器封裝

一個完整的視頻轉換設置都至少包括了上面3個步驟。工具

編碼格式

音頻編碼格式

音頻編碼格式有以下性能

  • AAC
  • AMR
  • PCM
  • ogg(ogg vorbis音頻)
  • AC3(DVD 專用音頻編碼)
  • DTS(DVD 專用音頻編碼)
  • APE(monkey’s 音頻)
  • AU(sun 格式)
  • WMA

音頻編碼方案之間音質比較(AAC,MP3,WMA等)結果: AAC+ > MP3PRO > AAC> RealAudio > WMA > MP3優化

目前最多見的音頻格式有 Mp三、AC-三、ACC,MP3最普遍的支持最多,AC-3是杜比公司的技術,ACC是MPEG-4中的音頻標準,ACC是目前比較先進和具備優點的技術。對應入門,知道有這幾種最多見的音頻格式足以。

視頻編碼格式

視頻編碼標準有兩大系統: MPEG 和ITU-T,國際上制定視頻編解碼技術的組織有兩個,一個是「國際電聯(ITU-T)」,它制定的標準有H.26一、H.26三、H.263+、H.264等,另外一個是「國際標準化組織(ISO)」它制定的標準有MPEG-一、MPEG-二、MPEG-4等。

常見編碼格式有:

  • Xvid(MPEG4)
  • H264 (目前最經常使用編碼格式)
  • H263
  • MPEG1,MPEG2
  • AC-1
  • RM,RMVB
  • H.265(目前用的不夠多)

目前最多見的視頻編碼方式的大體性能排序基本是: MPEG-1/-2 < WMV/7/8 < RM/RMVB < Xvid/Divx < AVC/H.264(由低到高,可能不徹底準確)。

在H.265出來以前,H264是壓縮率最高的視頻壓縮格式,其優點有:

  • 低碼率(Low Bit Rate):和MPEG2和MPEG4 ASP等壓縮技術相比,在同等圖像質量下,採用H.264技術壓縮後的數據量只有MPEG2的1/8,MPEG4的1/3。
  • 高質量的圖象 :H.264能提供連續、流暢的高質量圖象(DVD質量)。
  • 容錯能力強 :H.264提供瞭解決在不穩定網絡環境下容易發生的丟包等錯誤的必要工具。
  • 網絡適應性強 :H.264提供了網絡抽象層(Network Abstraction Layer),使得H.264的文件能容易地在不一樣網絡上傳輸(例如互聯網,CDMA,GPRS,WCDMA,CDMA2000等)。

H.264最大的優點是具備很高的數據壓縮比率,在同等圖像質量的條件下,H.264的壓縮比是MPEG-2的2倍以上,是MPEG-4的1.5~2倍。舉個例子,原始文件的大小若是爲88GB,採用MPEG-2壓縮標準壓縮後變成3.5GB,壓縮比爲25∶1,而採用H.264壓縮標準壓縮後變爲879MB,從88GB到879MB,H.264的壓縮比達到驚人的102∶1。低碼率(Low Bit Rate)對H.264的高的壓縮比起到了重要的做用,和MPEG-2和MPEG-4 ASP等壓縮技術相比,H.264壓縮技術將大大節省用戶的下載時間和數據流量收費。尤爲值得一提的是,H.264在具備高壓縮比的同時還擁有高質量流暢的圖像,正由於如此,通過H.264壓縮的視頻數據,在網絡傳輸過程當中所須要的帶寬更少,也更加經濟。

目前這些常見的視頻編碼格式實際上都屬於有損壓縮,包括H264和H265,也是有損編碼,有損編碼才能在質量得以保證的前提下獲得更高的壓縮率和更小體積

存儲封裝格式

目前市面常見的存儲封裝格式有以下:

  • AVI (.avi)
  • ASF(.asf)
  • WMV (.wmv)
  • QuickTime ( .mov)
  • MPEG (.mpg / .mpeg)
  • MP4 (.mp4)
  • m2ts (.m2ts / .mts )
  • Matroska (.mkv / .mks / .mka )
  • RM ( .rm / .rmvb)
  • TS/PS

AVI : 可用MPEG-2, DIVX, XVID, WMV3, WMV4, AC-1, H.264 WMV : 可用WMV3, WMV4, AC-1 RM/RMVB : 可用RV40, RV50, RV60, RM8, RM9, RM10 MOV : 可用MPEG-2, MPEG4-ASP(XVID), H.264 MKV : 全部

封裝格式.png

視頻碼率、幀率、分辨率

碼率

碼流(Data Rate)是指視頻文件在單位時間內使用的數據流量,也叫碼率或碼流率,通俗一點的理解就是取樣率,是視頻編碼中畫面質量控制中最重要的部分,通常咱們用的單位是kb/s或者Mb/s。通常來講一樣分辨率下,視頻文件的碼流越大,壓縮比就越小,畫面質量就越高。碼流越大,說明單位時間內採樣率越大,數據流,精度就越高,處理出來的文件就越接近原始文件,圖像質量越好,畫質越清晰,要求播放設備的解碼能力也越高。

固然,碼率越大,文件體積也越大,其計算公式是文件體積=時間X碼率/8。例如,網絡上常見的一部90分鐘1Mbps碼率的720P RMVB文件,其體積就=5400秒×1Mbps/8=675MB。

一般來講,一個視頻文件包括了畫面(視頻)及聲音(音頻),例如一個RMVB的視頻文件,裏面包含了視頻信息和音頻信息,音頻及視頻都有各自不一樣的採樣方式和比特率,也就是說,同一個視頻文件音頻和視頻的比特率並非同樣的。而咱們所說的一個視頻文件碼流率大小,通常是指視頻文件中音頻及視頻信息碼流率的總和。

幀率

幀率也稱爲FPS(Frames Per Second)- - - 幀/秒。是指每秒鐘刷新的圖片的幀數,也能夠理解爲圖形處理器每秒鐘可以刷新幾回。越高的幀速率能夠獲得更流暢、更逼真的動畫。每秒鐘幀數(FPS)越多,所顯示的動做就會越流暢。

關於幀率有以下幾個基礎數據:

  • 幀率越高,cpu消耗就高
  • 秀場視頻直播,通常幀率20fps
  • 普通視頻直播,通常幀率15fps

分辨率

視頻分辨率是指視頻成像產品所成圖像的大小或尺寸。常見的視像分辨率有352×288,176×144,640×480,1024×768。在成像的兩組數字中,前者爲圖片長度,後者爲圖片的寬度,二者相乘得出的是圖片的像素,長寬比通常爲4:3.

480P : 640 x 480 個像素點 720P : 1280 x 720 個像素點 1080P : 1920 x 1080 個像素點

而後還須要關注每一個像素點的存儲格式,每一個像素點佔用的字節大小。

圖像存儲格式yuv

一幅彩色圖像的基本要素是什麼?

一、寬:一行有多少個像素點。 二、高:一列有多少個像素點,一幀有多少行 三、YUV格式仍是RGB格式? 四、一行多少個字節?? 五、圖像大小是多少? 六、圖像的分辨率多少?

說白了,一幅圖像包括的基本東西就是二進制數據,其容量大小實質即爲二進制數據的多少。一幅1920x1080像素的YUV422的圖像,大小是1920X1080X2=4147200(十進制),也就是3.95M大小。這個大小跟多少個像素點和數據的存儲格式有關。

YUV與像素的關係:

YUV格式,與咱們熟知的RGB相似,YUV也是一種顏色編碼方法,主要用於電視系統以及模擬視頻領域,它將亮度信息(Y)與色彩信息(UV)分離,沒有UV信息同樣能夠顯示完整的圖像,只不過是黑白的,這樣的設計很好地解決了彩色電視機與黑白電視的兼容問題。而且,YUV不像RGB那樣要求三個獨立的視頻信號同時傳輸,因此用YUV方式傳送佔用極少的頻寬。

YUV格式有兩大類:planar和packed。對於planar的YUV格式,先連續存儲全部像素點的Y,緊接着存儲全部像素點的U,隨後是全部像素點的V。對於packed的YUV格式,每一個像素點的Y,U,V是連續交替存儲的。

YUV,分爲三個份量,「Y」表示明亮度(Luminance或Luma),也就是灰度值;而「U」和「V」 表示的則是色度(Chrominance或Chroma),做用是描述影像色彩及飽和度,用於指定像素的顏色。      YUV是利用一個亮度(Y)、兩個色差(U,V)來代替傳統的RGB三原色來壓縮圖像。傳統的RGB三原色使用紅綠藍三原色表示一個像素,每種原色佔用一個字節(8bit),所以一個像素用RGB表示則須要8 * 3=24bit。

若是使用YUV表示這個像素,假設YUV的採樣率爲:4:2:0,即每個像素對於亮度Y的採樣頻率爲1,對於色差U和V,則是每相鄰的兩個像素各取一個U和V。對於單個的像素來講,色差U和V的採樣頻率爲亮度的一半。若有三個相鄰的像素,若是用RGB三原色表示,則共須要佔用:8 * 3 * 3 = 72bits;若是採用YUV(4:2:0)表示,則只須要佔用:8 * 3(Y)+ 8* 3 * 0.5(U)+ 8 * 3 * 0.5(V)= 36bits。只需原來一半的空間,就能夠表示原來的圖像,數據率壓縮了一倍,而圖像的效果基本沒發生變化。

那麼,具體yuv格式所佔用的字節數要怎麼算呢 ?

YUV圖像格式的內存大小

  • 4:4:4 表示色度值(UV)沒有減小採樣。即Y,U,V各佔一個字節,加上Alpha通道一個字節,總共佔4字節.這個格式其實就是24bpp的RGB格式了。

  • 4:2:2 表示UV份量採樣減半,好比第一個像素採樣Y,U,第二個像素採樣Y,V,依次類推,這樣每一個點佔用2個字節.二個像素組成一個宏像素.

    • 須要佔用的內存:w * h * 2
  • 4:2:0 這種採樣並不意味着只有Y,Cb而沒有Cr份量,這裏的0說的U,V份量隔行才採樣一次。好比第一行採樣 4:2:0 ,第二行採樣 4:0:2 ,依次類推...在這種採樣方式下,每個像素佔用16bits或10bits空間.

    • 內存則是:yyyyyyyyuuvv
    • 須要佔用的內存:w * h * 3 / 2
  • 4:1:1 能夠參考4:2:2份量,是進一步壓縮,每隔四個點才採一次U和V份量。通常是第1點採Y,U,第2點採Y,第3點採YV,第4點採Y,依次類推。

yuv格式.png

幀率、碼率與分辨率之間關係

碼率和幀率沒有半毛錢關係

碼率關係着帶寬、文件體積

幀率關係着畫面流暢度和cpu消耗

分辨率關係着圖像尺寸和清晰度

一個視頻文件的大小爲5.86M,播放時長爲3分7秒

  • 1,該文件對應的碼率就是

    • 5.86 * 1024 * 1024 * 8 / (3 * 60 + 7) = 262872.95657754bps
  • 2,10M獨享帶寬能支撐的同時在線人數

    • 10 * 1024 * 1024 / 262872.95657754 = 39.889078498294
  • 3, 支撐1000人同時在線的系統最少須要的帶寬數爲

    • 262872 * 1000 / (1024 * 1024) = 250.69427490234M

10min,流量消耗41587KB

41587/10*60 = 69KB/s = 69 * 8 Kb/s = 532Kb/s

那麼獲得碼率就是 532Kb/s

輸出文件大小公式

一個音頻編碼率爲128Kbps,視頻編碼率爲800Kbps的文件,其總編碼率爲928Kbps,意思是通過編碼後的數據每秒鐘須要用928K比特來表示。

文件大小公式: (音頻編碼率(KBit爲單位)/8 + 視頻編碼率(KBit爲單位)/8)× 影片總長度(秒爲單位)= 文件大小(MB爲單位)

一幀圖像大小

一幀圖像原始大小 = 寬像素 * 長像素 ,固然要考慮數據格式,由於數據格式不同,大小寫也不相同,通常數據採用rgb、yuv格式,如rgb3二、yuv420、yuv422等。最經常使用的應當屬於yuv420。 所以,計算公式爲:

文件的字節數 = 圖像分辨率 * 圖像量化位數/8 圖像分辨率 = X方向的像素數 * Y方向的像素數 圖像量化數 = 二進制顏色位數

  • RGB24每幀的大小是

    • size=width×heigth×3 Bit
  • RGB32每幀的大小是

    • size=width×heigth×4
  • YUV420每幀的大小是

    • size=width×heigth×1.5 Bit

舉例說明,對於一個1024*768的圖像實際的YUV422數據流大小就爲:1024 *768 * 2 = 1572864bit

音頻採樣率、位數

一、聲道數:聲道數是音頻傳輸的重要指標,如今主要有單聲道和雙聲道之分。雙聲道又稱爲立體聲,在硬件中要佔兩條線路,音質、音色好, 但立體聲數字化後所佔空間比單聲道多一倍。

  二、量化位數: 量化位是對模擬音頻信號的幅度軸進行數字化,它決定了模擬信號數字化之後的動態範圍。因爲計算機按字節運算,通常的量化位數爲 8位和16位。量化位越高,信號的動態範圍越大,數字化後的音頻信號就越可能接近原始信號,但所須要的存儲空間也越大。

   三、採樣率:也稱爲採樣速度或者採樣頻率,定義了每秒從連續信號中提取並組成離散信號的採樣個數,它用赫茲(Hz)來表示。採樣率是指將模擬信號轉換成數字信號時的採樣頻率,也就是單位時間內採樣多少點。一個採樣點數據有多少個比特。比特率是指每秒傳送的比特(bit)數。單位爲 bps(Bit Per Second),比特率越高,傳送的數據越大,音質越好.

採樣率的選擇應該遵循奈奎斯特(Harry Nyquist)採樣理論( 若是對某一模擬信號進行採樣,則採樣後可還原的最高信號頻率只有採樣頻率的一半,或者說只要採樣頻率高於輸入信號最高頻率的兩倍,就能從採樣信號系列重構原始信號 )。根據該採樣理論, CD激光唱盤採樣頻率爲 44kHz,可記錄的最高音頻爲 22kHz,這樣的音質與原始聲音相差無幾,也就是咱們常說的超級高保真音質。通訊系統中數字電話的採用頻率一般爲 8kHz,與原 4k帶寬聲音一致的。

比特率(音頻) = 採樣率 x 採用位數 x 聲道數.

以電話爲例,每秒3000次取樣,每一個取樣是7比特,那麼電話的比特率是21000。 而CD是每秒 44100次取樣,兩個聲道,每一個取樣是13位PCM編碼,因此CD的比特率是44100213=1146600,也就是說CD每秒的數據量大約是 144KB,而一張CD的容量是74分等於4440秒,就是639360KB=640MB。

I幀、P幀、B幀、IDR幀

I幀:幀內編碼幀

I幀特色:

  1. 它是一個全幀壓縮編碼幀。它將全幀圖像信息進行JPEG壓縮編碼及傳輸;
  2. 解碼時僅用I幀的數據就可重構完整圖像;
  3. I幀描述了圖像背景和運動主體的詳情;
  4. I幀不須要參考其餘畫面而生成;
  5. I幀是P幀和B幀的參考幀(其質量直接影響到同組中之後各幀的質量);
  6. I幀是幀組GOP的基礎幀(第一幀),在一組中只有一個I幀;
  7. I幀不須要考慮運動矢量;
  8. I幀所佔數據的信息量比較大。

P幀:前向預測編碼幀

P幀的預測與重構:P幀是以I幀爲參考幀,在I幀中找出P幀「某點」的預測值和運動矢量,取預測差值和運動矢量一塊兒傳送。在接收端根據運動矢量從I幀中找出P幀「某點」的預測值並與差值相加以獲得P幀「某點」樣值,從而可獲得完整的P幀。又稱predictive-frame,經過充分將低於圖像序列中前面已編碼幀的時間冗餘信息來壓縮傳輸數據量的編碼圖像,也叫預測幀

P幀特色:

  1. P幀是I幀後面相隔1~2幀的編碼幀;
  2. P幀採用運動補償的方法傳送它與前面的I或P幀的差值及運動矢量(預測偏差);
  3. 解碼時必須將I幀中的預測值與預測偏差求和後才能重構完整的P幀圖像;
  4. P幀屬於前向預測的幀間編碼。它只參考前面最靠近它的I幀或P幀;
  5. P幀能夠是其後面P幀的參考幀,也能夠是其先後的B幀的參考幀;
  6. 因爲P幀是參考幀,它可能形成解碼錯誤的擴散;
  7. 因爲是差值傳送,P幀的壓縮比較高。

B幀:雙向預測內插編碼幀。

B幀的預測與重構:B幀之前面的I或P幀和後面的P幀爲參考幀,「找出」B幀「某點」的預測值和兩個運動矢量,並取預測差值和運動矢量傳送。接收端根據運動矢量在兩個參考幀中「找出(算出)」預測值並與差值求和,獲得B幀「某點」樣值,從而可獲得完整的B幀。 又稱bi-directional interpolated prediction frame,既考慮與源圖像序列前面已編碼幀,也顧及源圖像序列後面已編碼幀之間的時間冗餘信息來壓縮傳輸數據量的編碼圖像,也叫雙向預測幀

B幀特色:

  1. B幀是由前面的I或P幀和後面的P幀來進行預測的;
  2. B幀傳送的是它與前面的I或P幀和後面的P幀之間的預測偏差及運動矢量;
  3. B幀是雙向預測編碼幀;
  4. B幀壓縮比最高,由於它只反映丙參考幀間運動主體的變化狀況,預測比較準確;
  5. B幀不是參考幀,不會形成解碼錯誤的擴散。

IDR 幀

IDR(Instantaneous Decoding Refresh)--即時解碼刷新。

I和IDR幀都是使用幀內預測的。它們都是同一個東西而已,在編碼和解碼中爲了方便,要首個I幀和其餘I幀區別開,因此才把第一個首個I幀叫IDR,這樣就方便控制編碼和解碼流程。IDR幀的做用是馬上刷新,使錯誤不致傳播,從IDR幀開始,從新算一個新的序列開始編碼。而I幀不具備隨機訪問的能力,這個功能是由IDR承擔。IDR會致使DPB(DecodedPictureBuffer參考幀列表——這是關鍵所在)清空,而I不會。IDR圖像必定是I圖像,但I圖像不必定是IDR圖像。一個序列中能夠有不少的I圖像,I圖像以後的圖像能夠引用I圖像之間的圖像作運動參考。一個序列中能夠有不少的I圖像,I圖像以後的圖象能夠引用I圖像之間的圖像作運動參考。

對於IDR幀來講,在IDR幀以後的全部幀都不能引用任何IDR幀以前的幀的內容,與此相反,對於普通的I-幀來講,位於其以後的B-和P-幀能夠引用位於普通I-幀以前的I-幀。從隨機存取的視頻流中,播放器永遠能夠從一個IDR幀播放,由於在它以後沒有任何幀引用以前的幀。可是,不能在一個沒有IDR幀的視頻中從任意點開始播放,由於後面的幀老是會引用前面的幀。

小結

I幀表示關鍵幀,你能夠理解爲這一幀畫面的完整保留;解碼時只須要本幀數據就能夠完成(由於包含完整畫面).

P幀表示的是這一幀跟以前的一個關鍵幀(或P幀)的差異,解碼時須要用以前緩存的畫面疊加上本幀定義的差異,生成最終畫面。(也就是差異幀,P幀沒有完整畫面數據,只有與前一幀的畫面差異的數據).

B幀是雙向差異幀,也就是B幀記錄的是本幀與先後幀的差異,換言之,要解碼B幀,不只要取得以前的緩存畫面,還要解碼以後的畫面,經過先後畫面的與本幀數據的疊加取得最終的畫面。B幀壓縮率高,可是解碼時CPU會比較累~。

PTS:Presentation Time Stamp。PTS主要用於度量解碼後的視頻幀何時被顯示出來

DTS:Decode Time Stamp。DTS主要是標識讀入內存中的bit流在何時開始送入解碼器中進行解碼。

DTS主要用於視頻的解碼,在解碼階段使用.PTS主要用於視頻的同步和輸出.在display的時候使用.在沒有B frame的狀況下.DTS和PTS的輸出順序是同樣的.

GOP

GOP.png

兩個I frame之間造成一個GOP,在x264中同時能夠經過參數來設定bf的大小,即:I 和p或者兩個P之間B的數量。若是有B frame 存在的狀況下一個GOP的最後一個frame必定是P.

通常平均來講,I的壓縮率是7(跟JPG差很少),P是20,B能夠達到50,可見使用B幀能節省大量空間,節省出來的空間能夠用來保存多一些I幀,這樣在相同碼率下,能夠提供更好的畫質。在碼率不變的前提下,GOP值越大,P、B幀的數量會越多,平均每一個I、P、B幀所佔用的字節數就越多,也就更容易獲取較好的圖像質量;Reference越大,B幀的數量越多,同理也更容易得到較好的圖像質量。

若是一個GOP裏面丟了I幀,那麼後面的P幀、B幀也將會無用武之地,所以必須丟掉,可是通常策略會保證I幀不丟(如經過tcp協議保證) ,若是採用UDP,那麼也會有更多的策略來保證I幀正確傳輸。

編解碼

硬編解碼

經過硬件實現編解碼,減輕CPU計算的負擔,如GPU等

軟編解碼

如 H26四、H26五、MPEG-4等編解碼算法,更消耗CPU

數據優化

數據優化和編解碼算法息息相關,通常而言

視頻幀大小

  • 通常I 幀的壓縮率是7,P 幀是20,B 幀能夠達到50 (數據不精確)
  • P幀大概是3~4KB (480P, 1200k碼率, baseline profile)

音頻幀大小

  • (採樣頻率(Hz)* 採樣位數(bit)* 聲道數)/ 8
  • 48000hz大概通過AAC壓縮後,應該是12KB/s左右

流媒體傳輸協議

經常使用的流媒體協議主要有 HTTP 漸進下載和基於 RTSP/RTP 的實時流媒體協議,這二種基本是徹底不一樣的東西

CDN直播中經常使用的流媒體協議包括RTMP,HLS,HTTP FLV

RTP,RTCP

實時傳輸協議(Real-time Transport Protocol),RTP協議經常使用於流媒體系統(配合RTCP協議),視頻會議和一鍵通系統(配合H.323或SIP),使它成爲IP電話產業的技術基礎。RTP協議和RTP控制協議RTCP一塊兒使用,並且它是創建在UDP協議上的。

實時傳輸控制協議(Real-time Transport Control Protocol或RTP Control Protocol或簡寫RTCP)是實時傳輸協議的一個姐妹協議。RTCP爲RTP媒體流提供信道外控制。RTCP自己並不傳輸數據,但和RTP一塊兒協做將多媒體數據打包和發送。RTCP按期在流多媒體會話參加者之間傳輸控制數據。RTCP的主要功能是爲RTP所提供的服務質量提供反饋。

RTP.png

RTSP+RTP常常用於IPTV領域。由於其採用UDP傳輸視音頻,支持組播,效率較高。但其缺點是網絡很差的狀況下可能會丟包,影響視頻觀看質量。

小結

TCP_UDP_RTCP.png

RTMP

RTMP(Real Time Messaging Protocol)實時消息傳送協議是Adobe Systems公司爲Flash播放器和服務器之間音頻、視頻和數據傳輸 開發的開放協議。

它有三種變種:

  • 工做在TCP之上的明文協議,使用端口1935;
  • RTMPT封裝在HTTP請求之中,可穿越防火牆;
  • RTMPS相似RTMPT,但使用的是HTTPS鏈接;

總結: RTMP協議基於TCP來實現,每一個時刻的數據,收到後馬上轉發,通常延遲在1-3s左右

HLS

HTTP Live Streaming(HLS)是蘋果公司(Apple Inc.)實現的基於HTTP的流媒體傳輸協議,可實現流媒體的直播和點播。HLS點播,基本上就是常見的分段HTTP點播,不一樣在於,它的分段很是小。基本原理就是將視頻或流切分紅小片(TS), 並創建索引(M3U8).

相對於常見的流媒體直播協議,例如RTMP協議、RTSP協議、MMS協議等,HLS直播最大的不一樣在於,直播客戶端獲取到的,並非一個完整的數據流。HLS協議在服務器端將直播數據流存儲爲連續的、很短時長的媒體文件(MPEG-TS格式),而客戶端則不斷的下載並播放這些小文件,由於服務器端老是會將最新的直播數據生成新的小文件,這樣客戶端只要不停的按順序播放從服務器獲取到的文件,就實現了直播。因而可知,基本上能夠認爲,HLS是以點播的技術方式來實現直播。因爲數據經過HTTP協議傳輸,因此徹底不用考慮防火牆或者代理的問題,並且分段文件的時長很短,客戶端能夠很快的選擇和切換碼率,以適應不一樣帶寬條件下的播放。不過HLS的這種技術特色,決定了它的延遲通常老是會高於普通的流媒體直播協議。

總結: HLS協議基於HTTP短鏈接來實現,集合一段時間數據,生成ts切片文件,而後更新m3u8(HTTP Live Streaming直播的索引文件),通常延遲會大於10s

HTTP-FLV

HTTP-FLV基於HTTP長鏈接,通RTMP同樣,每一個時刻的數據,收到後馬上轉發,只不過使用的是HTTP協議,通常延遲在1-3s

CDN

CDN架構設計比較複雜。不一樣的CDN廠商,也在對其架構進行不斷的優化,因此架構不能統一而論。這裏只是對一些基本的架構進行簡單的剖析。

CDN主要包含:源站、緩存服務器、智能DNS、客戶端等幾個主要組成部分。

源站:是指發佈內容的原始站點。添加、刪除和更改網站的文件,都是在源站上進行的;另外緩存服務器所抓取的對象也所有來自於源站。對於直播來講,源站爲主播客戶端。

緩存服務器:是直接提供給用戶訪問的站點資源,由一臺或數臺服務器組成;當用戶發起訪問時,他的訪問請求被智能DNS定位到離他較近的緩存服務器。若是用戶所請求的內容恰好在緩存裏面,則直接把內容返還給用戶;若是訪問所需的內容沒有被緩存,則緩存服務器向鄰近的緩存服務器或直接向源站抓取內容,而後再返還給用戶。

智能DNS:是整個CDN技術的核心,它主要根據用戶的來源,以及當前緩存服務器的負載狀況等,將其訪問請求指向離用戶比較近且負載較小的緩存服務器。經過智能DNS解析,讓用戶訪問同服務商下、負載較小的服務器,能夠消除網絡訪問慢的問題,達到加速做用。

客戶端:即發起訪問的普通用戶。對於直播來講,就是觀衆客戶端。

弱網優化

弱網優化的策略包括以下:

  • 播放器Buffer

  • 丟幀策略 (優先丟P幀,其次I幀,最後音頻)

  • 自適應碼率算法

  • 雙向鏈路優化

  • 音頻FEC冗餘算法(20%丟包率)

丟幀

在弱網狀況下,爲了達到更好的體驗,可能會採起丟幀的策略,可是丟幀,怎麼丟呢?丟音頻幀仍是視頻幀呢 ? 由於視頻幀比較大,而且視頻幀先後是有關聯的;音頻幀很小,關鍵是音頻幀是連續採樣的,丟了音頻幀,那聲音就會明顯出現瑕疵。爲此,通常的丟幀策略是丟視頻幀

自適應碼率

在弱網狀況下,另一種靠譜的策略是自適應碼率算法,經過設置碼率降級爲多個檔次,這樣,當網絡很差的狀況下,經過下降碼率進行預測,若是碼率下降後,還不夠buffer緩衝,那麼繼續下降一個檔次,是一個循環探測的過程,若是再次降級一個檔次後,發現buffer緩衝足夠了,那麼說明當前網絡可以適應這個碼率,所以就會採起當前碼率。同理,升檔也是同樣的。可是這個屬於廠商的核心算法,

實時聊天的挑戰

簡單估算一下大概的網絡延時。衆所周知,光在真空中的速度約爲300,000km/s,而在其餘介質中光 速會大大下降,因此在普通光纖中,工程上通常認爲傳輸速度是200,000km/s。從現實上來講,能夠參考以下:

距離光纖延遲.png

距離往返延遲.png

實時聊天的挑戰主要在於如下幾點:

  • 實時性: 600ms之內

  • 網絡的不對稱性

  • 距離

常見問題和解決方案

  • 出現花屏、綠屏問題

    • 採集問題、編解碼問題、聲網傳輸丟幀問題
  • 聲畫不一樣步

    • 採集問題,或者公有云SDK問題
  • 畫面有時候有點糊

    • 弱網,碼率的自適應
  • 有聲音沒有畫面

    • 弱網,觸發了丟幀策略
  • 畫面播放有時候卡頓

    • CPU消耗太高致使卡頓,好比AR模塊
    • 弱網
  • 網絡鏈接不上

    • 弱網
    • 或者代碼有Bug,或者公有云SDK有Bug
  • 出現馬賽克現象?

    • 是否相似花屏 ?

TODO

其餘常見指標 和 問題解決方案

【"歡迎關注個人微信公衆號:Linux 服務端系統研發,後面會大力經過微信公衆號發送優質文章"】

個人微信公衆號
相關文章
相關標籤/搜索