也不知什麼時候，直播行業異軍突起，周邊的小夥伴們都開始玩直播了。對於鋤頭哥這種老碼農來說，與其說願意關注直播帶來的娛樂快感，還不如說更願意花時間去研究直播背後的技術實現。去年下半年，鋤頭哥也是出於好奇，對直播的技術做了一番研究，略有斬獲。最近趁着手頭項目稍微空閒，把鋤頭哥所瞭解的直播技術內容做了一個整理，分享給各位讀者朋友。
爲了便於理解，先放上一張直播的整體框架：
可以看到，當主播在進行直播的時候，視頻內容在主播客戶端進行採集，然後進行一定的視頻處理後，推流到雲端，觀衆客戶端進行視頻拉流、解碼後，再進行觀看。當然在採集、推流、拉流的過程中涉及到很多的技術內容，鋤頭哥會針對性的作出解釋。
本篇是基礎普及篇，直播的名詞是最基礎的內容：
1.推流
將直播內容推送至服務器的過程。2.拉流
服務器已有直播內容，用指定地址進行拉取的過程。3.RTMP協議
Real Time Messaging Protocol（實時消息傳輸協議）的首字母縮寫。該協議基於TCP，是一個協議族，包括RTMP基本協議及RTMPT/RTMPS/RTMPE等多種變種。RTMP是一種設計用來進行實時數據通信的網絡協議，主要用來在Flash/AIR平臺和支持RTMP協議的流媒體/交互服務器之間進行音視頻和數據通信。4.編碼：
H.264編碼 是 高性能的視頻編碼技術，最大的優勢是具有很高的數據壓縮比率，能以較低的數據速率傳送基於聯網協議（IP）的視頻流.5.碼率：
碼率就是數據傳輸時單位時間傳送的數據位數,一般我們用的單位是kbps即千位每秒。6.FPS：
幀率（Frame rate）是用於測量顯示幀數的量度。所謂的測量單位爲每秒顯示幀數(Frames per Second，簡稱：FPS）或“赫茲”（Hz）
小結：
鋤頭哥調研了目前市面上主流的兩款直播平臺：雲豹直播平臺和方維直播平臺，經過了多次的嘗試和優化，在原來的源碼基礎上進行了bug改良，使得系統更加穩定，卡頓現象得到了較好的解決。
現在想來，要把直播系統做穩定，其實最難的難點是提高首播時間、服務質量即Qos。要想在技術上把別的直播站PK下去，提供幾種方案：
1. gop緩存，爲加快首播時間
2. gop丟幀，爲解決延時，爲什麼會有延時，網絡抖動、網絡擁塞導致的數據發送不出去，丟完之後所有的時間戳都要修改，切記要不客戶端就會卡一個 gop的時間，是由於 dts 和 pts 的原因，或者播放器修正 dts 和 pts 也行（推流端丟gop更復雜，丟 p 幀之前的 p 幀會花屏）
3. 純音頻丟幀，要解決音視頻不同步的問題，要讓視頻的 delta增量到你丟掉音頻的delta之後，再發音頻，要不就會音視頻不同步
4. 源站主備切換和斷線重連。
5. 根據TCP擁塞窗口做智能調度，當擁塞窗口過大說明節點服務質量不佳，需要切換節點和故障排查。
6. 增加上行、下行帶寬探測接口，當帶寬不滿足時降低視頻質量，即降低碼率。
7. 定時獲取最優的推流、拉流鏈路IP，儘可能保證提供最好的服務。
8. 監控必須要，監控各個節點的Qos狀態，來做整個平臺的資源配置優化和調度。
9. 如果你家產品從推流端、CDN、播放器都是自家的，保障 Qos 優勢非常大.
10. 當直播量非常大時，要加入集羣管理和調度，保障 Qos。
2. gop丟幀，爲解決延時，爲什麼會有延時，網絡抖動、網絡擁塞導致的數據發送不出去，丟完之後所有的時間戳都要修改，切記要不客戶端就會卡一個 gop的時間，是由於 dts 和 pts 的原因，或者播放器修正 dts 和 pts 也行（推流端丟gop更復雜，丟 p 幀之前的 p 幀會花屏）
3. 純音頻丟幀，要解決音視頻不同步的問題，要讓視頻的 delta增量到你丟掉音頻的delta之後，再發音頻，要不就會音視頻不同步
4. 源站主備切換和斷線重連。
5. 根據TCP擁塞窗口做智能調度，當擁塞窗口過大說明節點服務質量不佳，需要切換節點和故障排查。
6. 增加上行、下行帶寬探測接口，當帶寬不滿足時降低視頻質量，即降低碼率。
7. 定時獲取最優的推流、拉流鏈路IP，儘可能保證提供最好的服務。
8. 監控必須要，監控各個節點的Qos狀態，來做整個平臺的資源配置優化和調度。
9. 如果你家產品從推流端、CDN、播放器都是自家的，保障 Qos 優勢非常大.
10. 當直播量非常大時，要加入集羣管理和調度，保障 Qos。
本篇的基礎普及篇到此擱筆，後續的詳細分析也會盡快更新，歡迎大家指正。
如果有直播相關探討，歡迎關注鋤頭哥的官微進行交流。
![]()
