技術背景

這幾年，我們對接了太多有RTSP或RTMP直播播放器訴求的開發(fā)者，他們當中除了尋求完整的解決方案的，還有些是技術探討，希望能借鑒我們播放端的開發(fā)思路或功能特性，完善自己的產品。

忙里偷閑，今天我們就再聊一聊老生常談的問題：如何實現功能完備性能優(yōu)異的RTMP、RTSP播放器？

技術剖析

這里我們說的播放器，系直播播放，確切的說，是如何在保障播放體驗的情況下，實現低延遲的RTMP或RTSP播放模塊。

(相關資料圖)

一個播放器，常規(guī)的關注點，主要有幾個方面：延遲、資源占用率（特別是性能一般的機器多路播放場景下）、多實例支持、異常網絡處理（非常穩(wěn)定的網絡環(huán)境不太現實）、實時狀態(tài)回調、長時間運行穩(wěn)定性等，下面，我就大概聊聊，我們關注的一些點：

1. 低延遲：這個功能訴求不再贅述，大多直播場景或有交互訴求的場景，對延遲的要求非常高，如果延遲過大，體驗大打折扣。無論是RTMP還是RTSP播放器，我們目前都是毫秒級的體驗。更重要的長時間運行，不會發(fā)生內存泄漏或其他異常。

2. 音視頻同步處理：在極端低延遲下，音視頻同步是可以忽略的，如果超過200ms的音視頻時間差值，感官體驗還是很差的，除此之外，還有些前端RTMP或RTSP時間戳會亂跳，這種也需要很好的兼容和矯正。

3. 支持多實例：多實例播放，這里分兩塊，一塊Windows平臺的，一塊移動端，移動端一般來說多實例，建議控制在4個以內，Windows平臺一般來說設備性能不會太差，但是隨著音視頻這塊配套設備的提升和產品訴求，越來越多的場景下，開始對高分辨率高碼率提出了要求，這對多實例的播放，就有很大挑戰(zhàn)，解一路繪一路一般機器，只要程序寫的不是太差，也不會太大性能瓶頸，但如果是同時4路8路甚至12或16路呢？我想大多自己拿開源改的播放器，都已經沒法正常使用了；

4. 支持buffer time設置：buffer time設置，這里都可以理解，說白了就是為了異常網絡環(huán)境下，盡可能緩沖點數據，提升播放流暢度，buffer time我們一般是按照毫秒設置，還有按照幀的，確切的說應該叫buffer frame，大家覺得哪種更好一些？

5. RTSP TCP/UDP模式設定、自動切換：TCP、UDP模式設定這個好理解，好多設備在特定網絡環(huán)境下，可能僅支持單模式，甚至有些服務器轉出來的RTSP流，服務端就做了限定，如果一個通用的RTSP播放器，你就需要考慮，TCP、UDP模式自動切換的問題，比如RTSP TCP模式下收不到數據，達到超時時間后，你需要能自動切到UDP。

6. 實時靜音、實時音量調節(jié)：實時靜音，特別在多實例播放下，非常重要，實時音量調節(jié)，不再贅述，依賴系統音量調節(jié)，無法針對單個實例的audio音量做調整，好多播放器不支持實時音量調節(jié)；

7. 視頻view旋轉、水平反轉、垂直反轉：好多攝像頭或一些移動單兵設備，由于安裝或場景限制，導致圖像倒置或旋轉，一個像樣的RTMP或RTSP播放器應該支持如視頻view實時旋轉(0° 90° 180° 270°)、水平反轉、垂直反轉；

8. 支持解碼后audio/video數據輸出：牛哥接觸到好多開發(fā)者，希望能在播放的同時，獲取到YUV或RGB數據，進行視覺算法的處理，這塊就顯得非常關鍵，特別是，回調需要盡量不影響性能；

9. 實時快照：實時快照的重要性不言而喻，這個我覺得應該是好多場景的標配；

10. 網絡抖動處理(如斷網重連)：我們遇到好多開發(fā)者在做播放器選型的時候，說你們的RTMP和RTSP播放器除了非常低，長時間跑不掛，也沒什么內存泄漏，資源占有低點，和我外面找的播放，其他也也測不出什么問題，那是因為大多測試是在內網穩(wěn)定的網絡環(huán)境下，網絡抖動等異常處理做不好，很難經受得住現場奇奇怪怪網絡環(huán)境的考驗；

11. 長期運行穩(wěn)定性：長時間穩(wěn)定性適用于比如一些智能設備或監(jiān)控等場景，幾乎常開的，如果資源占用持續(xù)升高、莫名crash等問題，非常惱火，問題也非常難定位；

12. log信息記錄：為什么要有日志？日志的目的，就是在發(fā)現問題的時候，不至于兩眼一抹黑，便于之前的問題還原，一般播放器，可能對這塊記錄并不成體系。

13. 實時下載速度反饋：為什么需要音視頻流實時下載回調？其實就是為了確保實時下載速度反饋，以此來監(jiān)聽網絡狀態(tài)，當然，如果不需要，我們也快設置關閉，也可以設置回調時間間隔；

14. 異常狀態(tài)處理、Event狀態(tài)回調：好的播放器，不止服務穩(wěn)定的網絡環(huán)境，一些斷網、網絡抖動、等異常場景，我們可以實時回調相關狀態(tài)，確保上層模塊感知處理；

15. 關鍵幀/全幀播放實時切換：移動端，一般對只播放關鍵幀真正場景，需求不大，但是window端，好多場景下，因為需要播放非常多路，但是又不想占用太多的系統資源，如果全幀播放，路數過多，全部解碼、繪制，系統資源占用會加大，如果能靈活的處理，可以隨時只播放關鍵幀，全幀播放切換，對系統性能要求大幅降低，想全幀播放的時候，隨時切換全幀繪制。

16. 特定機型硬解碼：無論是Windows還是Android、iOS平臺，如果需要播放高分辨率或多實例場景，硬解碼的支持非常必要，

17. 跨平臺，接口盡可能統一：跨平臺這塊，這個看開發(fā)者所服務的場景，像我們，是直接支持Windows、Linux、Android、iOS平臺，一般開發(fā)者，可能只需要支持一兩個平臺即可，如果涉及到多個平臺，盡可能的接口相對統一。

18. 可擴展：比如，我們RTMP、RTSP播放器，針對Unity平臺的配套解決方案，Unity環(huán)境下調用我們原生的RTMP、RTSP播放模塊，通過回調YUV/RGB數據，在Unity繪制，實現Unity環(huán)境下低延遲播放的友好體驗，此外，移動端，也可以用于Flutter框架下。

總結

不管是基于開源播放器二次開發(fā)，還是全自研內核，一個好的RTMP播放器或RTSP播放器，設計的時候，更多考慮的應該是如何做的更靈活、更穩(wěn)定、延遲更低、資源占用更小，單純的幾個接口，很難滿足通用化的產品訴求，啰啰嗦嗦說了這么多，權當拋磚引玉，感興趣的開發(fā)者，可以酌情參考。