直播軟體開發科普之流媒體介紹

直播軟體開發編解碼

硬編解碼

通過硬體實作編解碼，減輕CPU計算的負擔，如GPU等

軟編解碼

如 H264、H265、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

出現馬賽克現象？

是否類似花屏 ？