文/胡小清
作者簡介：
個人直播
個人直播從 2014 年起步，到 2016 年發展到異常火爆，從遊戲直播、秀場直播到移動直播，和我們以前說的娛樂視頻直播有很大不同，主要體現在直播源端、CDN、互動性等方面，具體如下：
個人直播現在非常火熱，美國的 Periscope（Twitter收購）、Facebook Live、Meerkat、韓國的 AfreecaTV 都在全球範圍內掀起了熱潮，國內有近 200 款終端 App，2 億用戶同時在線超過 400 萬用戶，按照分類：
-
遊戲直播：虎牙（原 YY ）、鬥魚、戰旗、熊貓、龍珠、TGA、全民 TV；
-
秀場直播：映客、花椒、美拍、一直播；
-
行業直播：電商、教育、O2O、新聞、賽事等各個領域。
目前幾乎所有的視頻雲廠商均提供了個人直播服務：
-
騰訊雲：基於騰訊的私有協議（TX 加速媒體協議）提供互動直播服務，包括推流和拉流，騰訊是將互動直播和普通單向直播的方案區分開來，採用了不同的技術，在普通直播中提供 RTMP 推流/HLS 拉流的直播信號注入方式；
-
百度雲：音視頻直播 LSS 服務，提供基於 RTMP 的直播服務，支持實時轉碼和錄製，提供模板配置；
-
阿里雲：提供 Live Video 服務，基於 RTMP 推流，支持窄帶高清轉碼技術；
國外的視頻雲服務目前主要針對娛樂視頻點播和直播，提供基礎能力，並沒有提供互動直播的能力：
-
AWS：沒有專門的媒體服務，只有一個 Transcoder 和 Elemental 轉碼服務；
-
Azure Media Service：微軟雲針對 Media 的服務，內容非常豐富，可以提供直播服務，基於 RTMP、RTP (TS)、Framented MP4 多種輸入提供直播服務，直播時延在 2s 左右，但沒有針對互動直播視頻的應用場景。
本文針對個人直播的流程和技術進行分析，下圖展示了從視頻生產、視頻源處理、視頻遞送、視頻消費的四個環節的交互流程：
關鍵技術
1、RTMP（Real Time Messaging Protocol）
個人直播中大家瞭解到最多的技術是 RTMP，基於實時的媒體流傳送技術；但傳統 RTMP 基於 TCP，需要 TCP 三次握手、慢啓動等擁塞控制算法導致啓動速度慢，對網絡容忍度低；RMTP 支持推流和拉流兩種方式；
基於 RTMP 的變種協議包括：
-
RTMPT：將 RTMP 打包在 HTTP 中，實現防火牆穿越，默認端口80；
-
RTMPS：通過 SSL 加密傳送 RTMP，默認端口 443；
-
RTMPE：加密傳送 RTMP，但不是採用 SSL，默認端口 1935；
-
RTMPTE：通過加密通道連接的 RTMPE。
Adobe 針對實時音視頻傳輸又推出了 RTMFP，請注意 RTMFP (Real-Time Media Flow Protocol)，這個協議和 RTMP 沒有什麼關係，採用 UDP 傳送，是 Adobe 針對音視頻實時傳送而設計的，支持網絡丟包和快速重建連接，並且支持 P2P 點對點傳送；但 RTMFP 目前應用度並不如 RTMP 高，在直播場景下 RTMP 的開源終端軟件和服務端軟件商用程度極高。
將 RTMP 改造通過 Reliable UDP 的思路是爲了解決 TCP 的傳輸效率問題，可以實現快速建鏈、快速重傳支持傳輸速度提升 5-10 倍；
RTMP Specification 在這裏可以獲取到：
http://wwwimages.adobe.com/content/dam/Adobe/en/devnet/rtmp/pdf/rtmp_specification_1.0.pdf
2、直播源視頻生產關鍵技術
源端處理技術：水印技術、Logo、字幕、美顏濾鏡、人臉檢測、直播道具、PC 桌面共享；
高性能低功耗編碼：通過 GPU 加速、降低編碼性能消耗，在移動端考慮降低功耗；採用硬件 H.264 編碼/H.265 編碼，如何解決異構終端的適配難題，目前大部分應用傾向於軟解。
3、300 ms 快速啓播/快速切換
直播啓動的時間在什麼水平是客戶可以接受的，下面是用戶調查的數據，300 ms 以下的直播體驗是非常好的，目前互聯網個人直播平臺的普遍的時間在 2000 ms 以上，花椒直播的啓播速度相對快一些，在 1000 ms-2000 ms：
直播頻道啓動或者切換的技術實際上在娛樂直播中沒有任何區別，直播切換啓動慢的主要原因，主要來源於 CDN 和直播客戶端，主要的解決辦法：
-
CDN 預緩存 GOP，以高倍速推送，縮短I幀等待時間；
-
播放端識別首個關鍵幀即啓動播放；
-
視頻優先模式，音視頻同步後處理。
4、降低卡頓
在個人直播中最常見的是卡頓，直播卡頓主要來自於三個原因：
-
直播源的處理和編碼性能不足，出現丟幀和卡頓；
-
直播源到 CDN 的丟包；
-
CDN 到終端側的丟包。
據統計直播卡頓中 80% 來自於直播源上行環節的卡頓。
針對這三個問題的解決辦法分別是：
-
面向個人直播的 CDN 網絡：將單向分發型 CDN 改造成雙向分發型 CDN、支持上行智能調度、提供低時延高效傳輸、提供網絡質量上行 QoE 質量保障；
-
高效的傳輸協議：基於 UDP 構建高效、可靠的視頻傳送通道，支持在高丟包、高時延抖動的網絡下保障視頻的實時性和防卡頓；
-
JITT 的實時轉碼：將高效轉碼、水印服務、視頻處理等技術融合提供實時的媒體處理服務，邊緣節點需要具備這些能力；
-
直播源碼率自適應：根據直播源的媒體處理和編碼能力調整碼率，在直播設備性能不能滿足要求的情況下，主動降低幀率和碼率，降低直播源視頻處理、視頻編碼、打包帶來的卡頓，通常是由於 CPU/GPU 處理性能不足帶來的卡頓。
（更多華爲資訊請關注華爲開發者社區，華爲自己的對外開放門戶:http://developer.huawei.com/ict/cn/ ,不要問我叫啥，別人都叫我雷鋒）
