2020年註定是魔幻的一年，疫情讓我們更熱愛生命，也讓我們更珍視工作。今年的五一假期比往年多了兩天，但在這個特殊的年份的特殊的勞動節中，工作和這個假期更配哦！小編在這個假期就玩了玩直播，解釋一下，是騰訊雲平臺提供的關於一系列的視頻應用場景的一些服務，很榮幸能夠提前體驗一把，順便簡單的做一些評測，主要從產品易用性和性能體驗這兩個角度做了些測試，在此記錄一下。同時也感謝騰訊直播雲平臺的哥哥姐姐們提供寶貴機會！
接下來，我們書歸正傳，開始我們的評測之路。
1.推拉流地址易用性測試
對於直播場景而言，開發過程中首先關注比較多的是推拉流地址，一般而言我們推流的地址即是拉流的地址。騰訊雲的直播服務通過兩個不同的域名將推流和拉流地址從邏輯上分割開來。這樣的設計有利有弊：好處是可以推拉流的名稱個性化自定義，且推流和拉流地址解耦；不好的是需要開發者或者使用騰訊雲產品的人員擁有兩個經過備案的域名，可能會影響到一部分人，不過也不是什麼大事。
生成推拉流地址可以通過騰訊雲控制檯域名管理和輔助工具中的地址生成器來實現。對於推流地址，支持自定義推流應用程序名稱，自定義推流視頻流的名稱，拉流地址支持自定義拉流應用程序名稱。生成地址後，可以通過複製按鈕和掃描二維碼的方式獲取推拉流地址，這一點對於開發人員來講很適用，否則推拉流的url手敲起來，或者再人手動來一次ctrl+c和ctrl+v着實有些肝疼。
筆者填入的流名稱是test，推流應用程序採用默認值，生成的推流地址如下：
rtmp://94626.livepush.myqcloud.com/live/test?txSecret=4b8fafc769f0f88df99ec9d8b35131d9&txTime=5EB03BFF
2.推流協議及推流方式支持測試
一看生成的推流地址，我們便知騰訊雲的推流地址採用的是rtmp協議，這也是直播場景裏當前依然繞不過的一個協議。普通意義上的直播，當下對於rtmp可能足以。不過對於一些安防監控的場景，rtsp協議的支持也是很有必要的，他們也有直播（實時查看監控數據）的需求，這一點，筆者覺得騰訊雲不應該不考慮。
對於推流端，主要的場景分爲移動端和傳統PC端以及包含攝像頭的嵌入式互聯設備，分別嘗試做了測試。
移動端就是兩大主流陣營，Android和IOS，騰訊雲直播提供了推流的sdk，同時也提供了推流的Demo，美顏，動圖，特效，這些主播端需要的常用功能有都支持。不過目前提供的特效效果感覺相對較少，可能後續還會陸續增加吧，希望早日推出。整體而言，移動端的推流支持基本滿足需求，可以快速上手。
PC端的推流，騰訊雲直播平臺提供了基於Obs的推流，obs的操作相對來講有一些專業性，遊戲場景使用的比較多。這一功能做的也相對比較完善，控制檯還有針對obs推流的指引和說明，這一點做的很貼心。有的時候，開發時候找不到幫助文檔也很抓狂。
對於PC端而言，由於廣大音視頻開發者廣泛使用FFmpeg，且FFmpeg也支持rtmp推流。但是測試了騰訊雲的直播，一直未成功，筆者覺得，PC端基於FFmpeg的推流，還是需要支持的。另外，很多嵌入式設備的音視頻開發也是基於FFmpeg去做開發，否則一大批基於FFmpeg做開發的朋友們將被拒之門外或者不得不更換方案（有時候更換技術方案的成本會很高）。
3.拉流方式支持測試
拉流，也就是播放端，通過播放地址，我們可以看到騰訊雲的支持算是比較全面。生成的播放地址中可以看到支持http+flv，支持hls，支持rtmp，支持webrtc，筆者使用騰訊雲直播的demo,ffplay,vlc，蘋果手機對各種協議進行測試，整體上都比較完整的支持,由於不具備webrtc的測試條件，未做測評。在iphone上播放的時候，筆者通過支付寶掃描二維碼也成功實現了播放。商業有壁壘，技術無邊界啊！
4.各種直播場景常見關注點測試
說到直播，我們一般比較關注的幾個點是秒開，播放的流暢度，以及延時這幾個維度。各種場景玩了騰訊雲的直播服務，秒開基本沒問題，視頻播放的流暢度也基本沒有問題，幾乎沒有出現花屏、卡頓等問題，當然，筆者的網絡是正常的家用網絡，極弱網絡環境，比如偏遠山區，衛星等網絡並未做測試，這裏不敢瞎說哈！對於延時這個問題，倒是想到了一個比較直觀的可視化的測試方式，那就是通過秒錶來測試延時，按這種方式測試了不同直播場景下的直播的延時，我們一一來看。
（1） obs直播（PC）
obs在前面的搭建簡單直播平臺的問文章中介紹過，感興趣可以戳下面文章回顧一下：
obs推流PC端用的比較多，而對於直播的場景，可能一般遊戲的場景比較多，像國內的鬥魚是支持obs推流的，而騰訊雲的直播平臺也支持obs推流，且給出了obs的推流步驟，畢竟，騰訊和鬥魚之間還是有千絲萬縷的聯繫的嗎！因爲使用了rtmp鑑權，所以，在obs推流的時候要注意填寫串流密鑰的信息。
通過輔助工具生成的推流地址中，obs推流地址對應obs中的服務器，obs推流名稱對應obs中的串流密鑰，配置起來還是略微繁瑣了一些。
配置完畢之後，在瀏覽器中打開一個在線秒錶的窗口，然後在obs中添加一個窗口捕獲，之後點擊開始推流：
播放端，使用ffplay進行播放，進行截屏，我們觀看一下延時效果：
第一張截圖的網絡環境是家用，100M帶寬方正，截圖時間是obs推流已經進行一段時間，延時有可能會有累積現象。
第二張截圖的環境是公司級別用，網絡狀況好一些，截圖時間是obs推流剛開始。
第一張截圖，obs推流部分的秒錶時間爲01：45：092，ffplay播放的秒錶的時間爲01：39：678，此時rtmp推流的延時爲5秒770毫秒，略微高一些；
第二章截圖，obs推流部分的秒錶時間爲06：31：344，ffplay播放的秒錶的時間爲06：28：678，此時rtmp推流的延時爲2秒334毫秒，這個還不錯，rtmp應該是這個表現。
（2）手機推流（ffplay播放）
手機使用騰訊雲提供的騰訊雲工具包進行推流。pc端使用ffplay進行播放測試。
此時的延時，通過一個小視頻來感受一下：
這個是秒級別的，延時大概5秒，可能精度會差一些，筆者又錄製了一個使用秒錶的測試延時的小視頻，精度更高一些：
通過秒錶觀看，可以查看延時不足3秒，2秒多一點，這個程度可以說已經很可觀了。
第一個視頻是在直播推流進行一段時間以後錄製，第二個秒錶的視頻是在直播剛開始的時候錄製，經過測試，基本可以確信的是，隨着推流的不斷進行，直播的也會進一步的累加。筆者的網絡環境中，最差的時候能達到5秒延時。
（3）Android推流蘋果播放（hls）
對於流媒體，Apple天然不支持rtmp，有自己獨特的hls，所以，關於hls也不得不測試一下。筆者還是使用騰訊雲直播工具包發佈直播（在Android手機端），然後在iphone上掃描hls播放地址進行播放。
我們還是看看hls播放的延時。
看過視頻之後，不是一般的高啊，高達10秒之多，甚至更高，確實有些過分，這也是對於直播而言，爲什麼rtmp雖一直被詬病，卻也一直是直播界的主流。不過呢，蘋果的生態如此強大，又不得不支持hls（它本身也是有優點的嗎）！
（4）http+flv
騰訊雲直播還提供了flv格式的播放支持，這個筆者測試中，大部分瀏覽器和工具對於該鏈接都是做默認下載處理（下載flv格式的視頻）。折騰了許久，最終藉助vlc播放器，簡單做了一下延遲的測試，效果如下：
可以看到，延時大概5秒左右，與正常的rtmp流程基本相仿。
（5）總結
整體而言，直播場景中比較核心的幾個點，秒開，流暢播放，騰訊雲的直播服務基本可以滿足需求。對於延時，除hls外，最壞情況延時在5-6秒左右，最好的情況2-3秒，直播的時間加長延時會有所累加，網絡環境對直播延時有較明顯的影響。
5. Web推流
騰訊雲的直播服務也推出了基於web的推流，搞音視頻的都知道webRtc近幾年火的一塌糊塗。去面個試，十個有八個都問會不會，搞沒搞過webRtc。本以爲騰訊雲的web推流也是基於webRtc的，體驗了一把發現並不是，原來是基於flash的。算是有一點小小的失望吧！
在雲直播的控制檯，輔助工具選項卡中提供了web推流的選項。使用web推流，比較簡單，填入流的名稱，點擊開始推流即可，要結束推流的時候，點擊斷開推流即可。
不過斷開推流做的比較粗糙，沒有提示，並不能確切的知道是否成功斷開了推流，有時又好像沒有響應的樣子，這一功能有待提升！另外，在web推流的時候還需要打開flash，不過Chrome宣佈不久的將來將不再支持flash了，不知道騰訊雲直播對於這一點是如何考慮的。下圖是web推流的效果。
從圖中可以看出，web推流使用的分辨率相對較小，默認480p，且沒有提供修改推流分辨率的選項，這一部分的功能理論上應該需要繼續完善。點擊開始推流後，下方提供了rtmp，hls，flv的播放地址，說明只是通過web推送到了流媒體服務器，並沒有從瀏覽器直接到瀏覽器，實現真正的基於web的點對點視頻通信。筆者使用ffplay播放了rtmp流，延時大概約5秒左右，這一功能很可能會變成雞肋，食之無味，棄之可惜，這部分完全換作基於webRtc的通信纔是王道。
6. 流管理
雲直播平臺同時也支持對推送的視頻流進行管理。主要分爲在線流，歷史流，禁用流。在線流是指當前正在推送的視頻流，歷史流是指曾經推送的視頻流。在歷史流和在線流的選項卡中，可以選擇對流進行禁用，這個筆者考慮可能是用於對一些非法，比如涉暴等敏感的推流進行禁用。
整體而言，個人覺得對於流管理的功能做的相對單一了些。對於每一路流，應該可以再加一些控制，比如質量優先，速度優先諸如此類的選項，以供開發者選擇。
5.功能模板（水印、鑑黃、錄製、轉碼）
對於直播場景中，常見的功能，如水印，鑑黃，錄製，轉碼等功能，騰訊雲直播平臺通過將不同的功能抽象爲模板，對於每一個模板進行配置。然後在推流域名中添加各種模板配置進而實現功能。這個設計筆者覺得比較巧妙，點個贊。對於每一個模板使用不同的參數，這樣滿足多樣性的需求。通過推流域名設置增加模板，如此保證了可擴展性。
6.統計分析
騰訊雲直播平臺同時也提供了統計分析功能。該功能主要用於統計推流的數據，以及推流產生的流量情況，併發情況。並以折線圖的形式展現，比較直觀。貼一張圖，大家感受一下。
這樣的功能其實很有必要，隨着數據量的不斷產生，通過人工智能和大數據的方式，可以提取很多有效有用的信息。當前還沒有看到這部分內容，不過筆者相信，這部分功能，騰訊雲直播平臺也不會放過的，應該就是時間問題。如果能夠在統計分析圖標中直接將產生的費用顯示，就更直觀更完美了！
總結
好了，整個五一假期，就和騰訊雲直播平臺爲伴。熟悉了整體流程，日後如有機會使用騰訊雲直播的產品，相信會有一定的先發優勢。簡單對雲直播的測評總結如下：
-
推拉流地址支持自定義生成比較靈活，但需要域名支持可能會限制部分開發者的使用；
-
推流流媒體服務器只支持rtmp流媒體協議比較單一，對於基於rtsp的安防等領域不友好；
-
支持不同平臺的直播推流，效果基本滿足需求，美中不足的是，對基於FFmpeg的推流支持不完善；
-
各類直播場景中可以實現秒開，播放流暢，延時平均5-6秒，與網絡環境相關，hls播放的延時可達10秒，基本達到行業平均水平。隨着直播時間的增長，延時會產生累加，應該有進一步優化空間；
-
基於flash的web推流感覺沒有存在的必要，更好的聚焦webRtc的開發可能纔是王道；
-
流管理的部分增加諸如質量優先，速度優先等其他選項會更加飽滿；
-
鑑黃、錄製、轉碼等按照模板的方式存在，與推流域名的管理相結合設計比較巧妙，兼顧了多樣性和可擴展性；
-
統計分析統計了推拉流產生流量以及併發數等情況，如能一併顯示計費信息會更加完美！
以上是筆者對於騰訊雲直播產品體驗的一些簡單評測和記錄。歡迎交流！
