宅時光之 Refresh 新知系列 2
申明本站點所有文章,僅代表個人想法,不代表任何公司立場,所有數據都來自公開資料--轉載請註明出處--
本篇,我們一起來聊聊直播技術,剛開始接觸這塊發現有很多的「行話」和術語,對於一個架構師而言,無法統一語言的高效溝通是最痛苦的事情,意味著,你根本無法理解客戶的語言,今天先自我掃盲一些關鍵知識點和基本場景理解。
直播和點播有什麼不一樣?點播,是視頻文件已經存儲在那裡,用戶可以隨時隨地進行播放,播放器進度可以由客戶控制,比如從頭,從上次觀看的時間點,快進播放等等;點播的平臺很多,比如國內的愛奇藝,騰訊視頻,國外的 Youtube,Netflix 等等;
直播,視頻源是通常由一方比如主播實時發起,由於是實時進行,播放器是沒有進度條的,直播流到最終客戶側傳輸可以是推流方式播放,也可以是拉流模式播放;我們接下來看看有哪些直播場景。
整個直播主要環節包括 採集,編碼,推流,轉碼,分發,拉流,解碼和渲染 這幾塊;
直播有哪些場景?直播在今年突如其來的疫情期間,得到非常廣泛的傳播,無論是在家辦公還是停課不停學都少不了直播技術;
你聽過或參與過哪些直播形式?
直播賣貨:比如口紅一哥李佳琪的抖音直播
遊戲直播:比如國內的鬥魚、虎牙,海外的 Twitch
賽事直播:比如 企鵝直播,愛奇藝的西甲、WTA 網球賽直播
泛娛樂直播:比如 B站的二次元,直播答題,YY
教育直播:最近大火的,老師變主播在線給孩子們直播上課,比如滬江的 CCTalk平臺
在線會議:比如 騰訊會議,Zoom,Amazon Chime 等等
直播從最終用戶體驗來說,要做到觀看流暢,無卡頓,如果有互動,則互動更要儘可能「實時」。
千頭萬緒,到底要權衡哪些方面?根據 Twitch 首席研發工程師沈悅時老師的一篇公開演講,所有的直播場景,主要權衡三方面內容:
任何直播場景都需要在三者之間找到一個最恰當的平衡,最終會影響直播平臺的技術實現和運營維護成本。
比如遊戲直播的場景,一個直播間同時參與在線的人數往往很多,一般比較火的網紅同時觀看人數會在 10萬左右(Twitch 的數據),單位觀眾的接入成本不能太高(成本包括伺服器資源消耗,流量,客戶的帶寬要求等等)這就要求可擴展性要很好;類似,教育直播,比如上海市教委最新通知的,中小學統一同時在線學習,一堂課容納的在線學生也是跟網紅聚集的在線人流差不多,三個指標中,首先要滿足的就是可擴展性,否則,同學們都不一定能進的了在線課堂教室;同時,這類場景的服務質量還要求很高,不能總是低清和卡頓,而高服務質量會犧牲一定的延遲。
再比如在線視頻會議,要滿足對話級的自然互動程度,通常端到端的延遲要控制在 200 ~ 400毫秒以內,所以,三個指標上,服務質量上會有所犧牲,比如畫質和卡頓率要求就沒有那麼高,而且常見的會議系統通常能容納的同時在線人數也只能在 20 ~ 100人左右,犧牲可擴展性,給低延遲讓路。
推流是什麼鬼?直播中的視頻源需要從 PC 電腦或移動端發布到直播平臺,就稱為「推流」,也稱為「發布」。
技術面來講,目前基本上都是利用 RTMP(實時消息傳輸協議)進行「主播」端推流,RTMP 最初是由 Macromedia 為通過網際網路在 Flash播放器與一個伺服器之間傳輸流媒體音頻、視頻和數據而開發的協議。隨著視頻直播領域的興起,也成為業內廣泛使用的協議。
RTMP 推流有個顯著的特點就是低延時且低擴展性;
推流工具:PC 上有開源的 OBS (Open Broadcaster Software)軟體,或商業版的 xsplit;移動端通常每家直播平臺都會提供相應的開發 SDK;
被直播平臺廣泛採用:比如 B 站,鬥魚,Twitch, Youtube 等等
RTMP 有幾個變種:
標準協議工作在 TCP 之上,使用默認埠 1935
RTMPT 封裝在 HTTP 請求之中,可穿越防火牆
RTMPS 類似 RTMPT,增加了 TLS/SSL 的安全功能,使用 HTTPS 連接
近幾年由於基於 UDP 的協議比如 QUIC 或者 SRT 的發展,也有很多玩家嘗試自主研發 RTPM over UDP 的方案,比如國內的 B站團隊,就在研發和灰度上線基於 QUIC 的 RTMP 直播方案。
QUIC(Quick UDP Internet Connection)是谷歌制定的一種基於 UDP 的低時延的網際網路傳輸層協議,QUIC 可以兼容 HTTP 1.1或HTTP / 2,基於 UDP 的 QUIC 協議相對比 TCP/IP 來說,由於不需要握手機制,延遲大大降低(包括建立連接和丟包重傳都有優化)。
SRT (安全可靠傳輸)協議,開源且基於 UDP,同時專為高效安全視頻流而設計;目前無論是 QUIC 還是 SRT 協議規範都在進一步演進中,自主研發需要比較高的研發成本,且有一定的不確定性,比如 QUIC 在行動裝置的支持不夠好,等等。
直播流播放這方面的技術選型最豐富,為了實現比較好的用戶體驗,有非常多的優化技術細節,不過目前主流玩家主要兩個方向:
國際上主流方向是基於 HTTP 動態自適應流技術(HTTP Adaptive Streaming - HAS),HAS 是一種流化和 HTTP 漸進式下載混合的媒體內容分發方法;
代表廠商有 Youtube/Twitch/Hulu/Amazon 等。
海外廠商採用的主流方案包括 Apple 的 HTTP Living Streaming(HLS) 和 國際標準 MPEG-DASH(Dynamic Adaptive Streaming over HTTP)簡稱 DASH;
無論 HLS 還是 DASH,都會將內容分解成一系列小型的基於 HTTP 的文件片段,每個片段包含很短的可播放內容,再提供一個 播放清單(playlist)給到播放器,播放器收到播放清單才會一層一層向源站請求;
除此之外,市場上還有一些 HAS 方案,比如企業出品的 Microsoft Smooth Streaming(MSS),Adobe 的 HTTP Dynamic Streaming(HDS),以及OPEN IPTV Forum 定義的 OIPF 規範;
優勢:
高可擴展性,但高延遲
客戶端通過 HTTP 短連接不斷請求內容片段實現了直播流的播放
CDN 友好,部署方便、快捷,具有良好的防火牆穿透能力; 由於可以通過內容分發網絡進行緩存分發,極大降低直播平臺的流量成本;
可以直接在 HTML 5中播放;HLS 在蘋果生態完全支持,大部分 Android手機瀏覽器也非常給力;
核心指標
延遲:通常 10秒左右,可優化;Twitch 基於 HLS 的低延時互動直播技術可以將延遲中位數控制在 4.5 秒;
服務質量(QoS):由於是小的切片,可以通過碼率自適應播放(ABR)技術優化弱網下的觀眾體驗,即客戶端可以根據網絡狀況,設備能力和用戶偏好,實現自適應的碼率和QoE;有非常多的伺服器端和客戶端碼率自適應的算法;
切片大小:Twitch 通常是兩秒一個片段,Facebook 和 YouTube是一秒鐘一片;
國內客戶典型代表 B站,快手,愛奇藝,虎牙等等,主要採用的實現方案包括 RTMP、HTTP-FLV、HLS/DASH 或者 自研基於 UDP 實現。通常一個平臺有可能會支持多種直播播放方案,比如同時支持 RTMP 和 HLS 等等。
RTMP & HTTP-FLV 直播流播放為什麼把這兩個放在一起來講呢,因為他們都是 Adobe 公司的解決方案:
國內非常多的直播平臺採用該這兩種協議作為直播流播放解決方案;
都是低延遲,通常 2 ~ 5 秒,所以都是直播首選方案
視頻封裝的格式都是 FLV,傳輸的數據也都一樣,都是 FLV 文件的 Tag
FLV(Flash Video) 由 Adobe 公司主推的一種視頻格式,優化在網絡上傳輸流媒體數據的一種容器,格式簡單,整個 FLV 由 The FLV Header, The FLV Body 以及其它 Tag 組成,不需要很大的媒體頭部信息;在延遲表現和大規模並發方面都很成熟;
RTMP 在推流章節介紹過,該協議比較全面,也可以用來用在接受和播放直播流,採用 RTMP 的直播播放一個典型的特徵是 絕大多數使用 Flash 作為播放器!
HTTP-FLV,即將音視頻數據封裝成 FLV,然後通過 HTTP 協議傳輸給客戶端;HTTP-FLV 的原理是伺服器在響應客戶端 HTTP 請求時候,不返回 Content-length 欄位給客戶端,這樣瀏覽器就會不會認為數據已經傳完了,一直會接受數據,直到伺服器和客戶端斷開;
相較於 RTMP 協議,HTTP-FLV 能夠好的穿透防火牆,它是基於 HTTP/80 傳輸,有效避免被防火牆攔截;並且首開和延遲略低於 RTMP;
採用 RTMP/HTTP-FLV 作為直播流播放方案的話,從採集推流到源站再到用戶側的播放器是一條完整的主動式數據流,相對於國m際通用的 HAS 解決方案,有明顯的優勢:
低延遲
基於長連接,RTMP 基於 TCP 長連接;HTTP-FLV 基於 HTTP 長連接;
HTTP-FLV 支持大並發,也就是可擴展性比較好;同時支持 302 跳轉,便於靈活調度;
但,也不是沒有缺點:
伺服器端資源消耗高;HAS 方案是客戶端主動拉進行播放,而且 CDN 友好,單伺服器的用戶密度高,也就是整體成本要低很多;據沈悅時老師的分享,RTMP 推流播放對於伺服器端的資源消耗要遠大於 HLS 的拉流方式,Twitch 的經驗,單臺同樣配置的伺服器用戶密度是 1:5,Twitch 一開始也是採用 RTMP 推流播放,不過成本太高,因此改成了 HLS。
播放器方面,RTMP 支持 VLC/FlashPlayer 等,不支持 HTML5 直接播放,iOS 需要第三方解碼器;HTTP-FLV 需要集成 SDK 比如 flv.js 才能實現 HTML 5的播放;
這兩種方式在 碼率自適應播放調優方面能做的有限,後來 Adobe 出品了 HTTP Dynamic Streaming(HDS)來適應 HAS 的技術潮流;
HTTP-FLV 會在本地緩存流媒體資源,保密性不夠好
自研私有解決方案很多客戶會針對性自研適合自身直播特點的解決方案,比如 Twitch 的直播,自建了全球適合直播的 CDN 網絡,並優化了 HLS 協議實現中位 3-4秒的端到端延遲,由於優化了協議,因此播放器必須嵌入自研的 SDK 方能播放直播流。詳情參考沈悅時老師的《基於HLS格式的低延時互動直播技術》
國內了解到的快手基於 UDP 自研了一套 KTP(Kuaishou Transmission Protocol) 協議,但由於自研協議 CDN 不支持,所以,KTP 目前根據公開資料只是加速推流以及連麥場景,直接跟快手機房 IDC 超低延遲通信;詳情可參考快手多媒體傳輸算法優化實踐
國內外 CDN 直播支持差異國內廣泛採用的 RTMP 和 HTTP-FLV 兩種直播播放協議,大部分海外 CDN 廠商都不支持,本質上 不過由於 RTMP 和 HTTP-FLV 是基於 TCP或 HTTP的長連接,CDN 的內容緩存效果有限,對於這類直播流分發,最需要的是一個穩定的、大帶寬以及 BGP 線路的全球客戶觸達的網絡基礎設施。
以 AWS Cloudfront 為例,該 CDN 本身支持 HLS/MSS/DASH/HDS/CMAF 直播分發,都是 HAS 技術;那對於 RTMP 和 HTTP-FLV 可以利用 AWS Global Accelerator來進行加速,該服務也是利用龐大、無擁塞的 AWS 全球的網絡,支持 TCP 和 UDP 流量的應用,加速延遲敏感的直播應用;
再比如獨立的國外 CDN 廠商,Akamai 也只支持基於 HTTP 的流媒體 (HLS/HDS/MSS/DASH/CMAF)解決方案;
當然海外很多客戶也有選擇自建 CDN 網絡來支撐點直播業務,比如 Netflix 私有的 OpenConnect網絡;比如 Twitch 自建的遊戲直播 CDN 等等;
在回到國內,主流廠商的 CDN 拉流都支持 RTMP、HTTP-FLV 以及 HLS 協議;關於推流協議,基本都是 RTMP 推流外,部分還支持自研的 RTMP over QUIC 推流 SDK,比如騰訊雲直播服務,七牛雲等;
其他一些黑話什麼是連麥?連麥其實就是原來主播的直播流中,同時加上多路粉絲的語音視頻流,本質上已經脫離了我們通常所說的廣播式短時延直播,而是類似視頻會議這樣的一種實時音視頻通信;所以,連麥對擴展性要求不高,也就是同時連麥在線的人數不會太多,比如騰訊雲直播 SDK 連麥人數就控制在 10人以內,但對延遲會更加敏感;
對話級語音視頻互動,端到端的延遲上面章節提到過,最好在 200 ~ 400毫秒之間;由於要求超低延遲,常規可以利用 RTMP 流媒體協議來實現,或者通過優化的基於 UDP 的協議,因為具備更好的擁塞處理,以及快速建立連接的優勢,比如 WebRTC,該協議是 Google的開源技術,降低了實時音視頻開發的門檻;
什麼是彈幕?彈幕功能是 B站以及很多視頻網站非常受歡迎的一種互動功能,用戶的評論像子彈一樣從屏幕中穿過,英文稱為「Bullet screen」 或 」bullet comments「,技術人一般用 」danmaku「 表示,實現可以參考 B站的GOIM架構,通常用 Web Socket 來實現相對低延遲的消息推送 (1s內):
觀看體驗 QoE 主要影響因素?QoE 就是觀眾看得爽,主要影響因素:
碼率 Data Rate:通俗一點的理解就是取樣率,影響視頻體積大小,碼率越大,文件體積也越大,其計算公式是文件體積=時間X碼率/8,而且一般文件包含視頻和音頻,各自會採用不同的碼率,文件的大小包含視頻和音頻的大小;
幀率 FPS(Frames Per Second):每秒鐘幀數(FPS)越多,所顯示的動作就會越流暢,幀率越大,畫面越流暢;幀率越小,畫面越有跳動感。如果碼率為變量,則幀率也會影響體積,幀率越高,每秒鐘經過的畫面越多,需要的碼率也越高,體積也越大;普通視頻直播幀率在 15fps ~ 25fps;
解析度:影響圖像大小,與圖像大小成正比,比如 480p就是指 640 x 480 個像素點,720p指 1280x720解析度;1080P 指1920x1080解析度;
後記直播越來越火,隨著 5G 的到來,我相信語音視頻應用場景會更多融入我們的生活,去年底跟公司媒體專家在客戶現場旁聽了2個小時轉碼探討,才發現以前太高估自己了,隔行如隔山,先總結一篇,把看到的資料理一理,期望也能你有所幫助。
誕生於 2019,遇見 2020。
感謝關注,歡迎動動手指標星和置頂;
這樣就不會錯過少但精彩的技術探討、團隊建設、案例分享!
每周至少一更,轉發是對我的最大鼓勵!
學習之路漫漫,走走停停,
偶有所感,隨心所記,
言由心聲,問心無愧!
從客戶中來,到客戶中去!