直播軟件開發編解碼
硬編解碼
通過硬件實現編解碼，減輕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
出現馬賽克現象？
是否類似花屏 ？