一對一交友app原始碼實現平臺搭建時會遇到的那些“坑”

使用一對一交友 app原始碼實現平臺搭建的過程中，經常會遇到很多坑。主要可以總結為兩個方面：裝置差異及網路環境等場景下帶來的技術考驗。在推流端可以檢測網路狀態或動態切換位元速率，以保障網路切換時的推流流暢。其次，編碼、推流和封包這一部分的邏輯也可以進行微調，可以嘗試選擇性丟幀（比如優先丟影片參考幀），這樣也可以減少要傳輸的資料內容，同時又達到了不影響直播畫質和視聽流暢的目的。

1.  一對一直播技術延遲最佳化原理

（1） 影響影片清晰度的指標：幀率 、 位元速率 、 解析度 、 量化引數（壓縮比） 。

（2） 影響影片流暢度的指標：位元速率 、 幀率 。

其他指標：直播是耗費流量和效能較大的一類行業， 耗電量 和 發熱 都算作其他指標之一， 大部分情況 下 發熱和耗電量正比，可以使用耗電量暫時替代 。

2.  直播卡頓和首幀最佳化

大部分直播 app都會出現網路不穩定的情況，有可能是CDN節點不足，也有可能是主播端自身和程式碼的各種問題。通常出現卡頓的直接原因是本地buffer為空導致播放停止，但是從主播端到觀看端整個流程看，網路狀況和伺服器效能都可能會導致問題加劇。影片中的原始影像資料會採用H.264編碼格式進行壓縮，音訊取樣資料會採用AAC編碼格式進行壓縮。

3.  服務端的最佳化

在直播伺服器中，支援設定一個 cache用於存放GOP客戶端播放。當直播伺服器快取了當前的GOP序列，然後播放端請求資料的時候，CDN會從I幀返回給客戶端，從而保證客戶端能夠快速獲取I幀進行顯示。當然，由於快取的是之前的影片資訊，當音訊資料達到播放端之後，為了音影片同步，播放器會進行影片的快進處理。（這種情況的影響很小）

4.  播放端的最佳化

DNS解析意味著要將一個域名為xxx.com解析成為ip的過程。修改播放器邏輯，基於FFmpeg二次開發，FFmpeg啟播影片都是拿到影片完整資訊才能啟播。如果只拿到部分資訊就啟播，那麼就需要修改程式碼了。

5.  影片的最佳化

如果僅僅只是最佳化首開延遲，可以在影片幀之間插入較多的關鍵幀，這樣一來，客戶端收到影片流之後可以儘快解碼。但是如果需要最佳化傳輸過程中的累積延遲，就會盡可能減少使用關鍵幀，在保證同等影片質量的情況下， I幀越多位元速率越大，傳輸所需要的網路頻寬也就越多。這意味著什麼？意味著累積延遲可能越大。當然，這個最佳化效果可能在秒級延遲的系統中並不是很明顯，但是在100ms甚至更低延遲的系統中就會非常明顯。此時，儘量使用 ACC-LC Codec 來編碼音訊 。雖然 HE-ACC 和 HE-ACC 2 編碼效率高，但是編碼所需時間 相對 更長，而產生更大體積的音訊 所 造成的傳輸延遲對於影片流的傳輸來說影響更小。

以上就是一對一交友 app原始碼實現平臺搭建時經常會遇到的坑，雖然都是一些小的細節部分，俗話說“細節決定成敗”，但是如果在開發過程中不把細節工作做好，那麼也是沒有辦法在直播行業中長期發展下去的。

本文宣告原創，轉載請註明出處。