阿根廷時隔 36 年再奪大力神杯，梅西問鼎球王！

牛*！牛*！牛*！

到了這個時候，還是會忍不住熱血沸騰。

幾次跌宕、多番起伏，你永遠猜不到下一秒會有什么神反轉(zhuǎn)。

這次決賽真是打破了平時大家說 “ 自古大賽無名局 ” 的說法，看點直接拉滿。

這么刺激的一場決賽踢下來，最后大家都會由衷地感謝上帝：寫劇本還是你會寫。

作為純粹的足球迷，總結(jié)起來就兩句話：

 “ 球王梅西！ ” 

“ 大馬丁牛 * ！” 

這時候回顧本屆卡塔爾世界杯，除了比賽精彩之外，不得不說，看比賽的體驗也是出奇得好。

差友們可能不知道，世超實打?qū)嵥惆雮€體育迷，平時一直也會看看球啥的，之前花錢的會員也沒少辦，讓本就不富裕的小金庫雪上加霜。

可作為各種尊貴的體育會員，往往看到的直播畫面還不如一些盜版源清楚，再加上各種亂七八糟的環(huán)節(jié)、廣告，差點就算是花錢找罪受了。

但這種體驗可不包括本屆世界杯，世超我這次破天荒頭一遭地做了白嫖黨，全程在抖音免費看完的。

除了免費 + 畫質(zhì)牛 B，最讓我記憶深刻的就是：直播延遲可以做到這么低的嗎？

之前在網(wǎng)上看直播，比文字直播或者電視慢個十幾秒都是常態(tài)，那邊慶祝絕殺、進球，我這還在看啦啦隊跳舞、中后場倒腳，這次居然都是我天天在群里劇透進球。

后來一研究才發(fā)現(xiàn)，今年抖音的世界杯直播背后，用的是火山引擎搞出來的新技術。

在網(wǎng)絡直播眾多環(huán)節(jié)中里面，主要影響直播延時的就是， “ 把數(shù)據(jù)丟到服務器 ”、“ 平臺把數(shù)據(jù)丟到你手機里 ”、“ 手機流暢播放 ” 三個環(huán)節(jié)。

因為這三個環(huán)節(jié)有一堆編解碼的操作，用到的方法還必須得匹配，不然就相當于你說英語我說中文，咱倆誰都不懂誰。

目前呢，用來解決這個匹配問題的 “ 世界語 ”，也就是流媒體協(xié)議，主要有兩種：

HLS 和 RTMP。

不巧的是這兩種技術天生就帶有高延遲。

HLS 是蘋果鼓搗出來的，它的方法簡單理解就是把一個 60 分鐘的視頻，分割成一個個短片段，然后挨個打包發(fā)送。

每個片段通常會控制在 10s 左右，而且為了保證播放的流暢性，一般都要在傳輸完 2 - 3 個片段后，才會開始播放。

這樣一來 HLS 直播的延遲都得 20 - 30s 以上了。

哪怕你強行把每個切片都切成 1s，那延遲也得 3s 以上。

而且切片不能無限縮小，因為切片小了，服務器負載就會增加。

所以，用 HLS 協(xié)議的直播，很難把延遲做到 10s 以內(nèi)。

相比之下，RTMP 就好了不少。

它的做法并不需要切片，而是分別轉(zhuǎn)發(fā)每一幀，這一來就已經(jīng)比 10s 發(fā)一次的 HLS 少了不少延遲。

但是， RTMP 傳輸時是基于 TCP 協(xié)議，這個 TCP 非常嚴謹，數(shù)據(jù)必須按順序一個不落地傳輸，一旦出現(xiàn)丟包，就會暫停，等丟掉的數(shù)據(jù)重傳完才會繼續(xù)。

平時用用么確實不錯，但直播看球時真不需要。

為了防止數(shù)據(jù)發(fā)送得太快，接收方處理不過來導致數(shù)據(jù)丟失，TCP 還會控制發(fā)送和接收雙方速度，使得數(shù)據(jù)能夠完整安全到達。

還是那句話：可靠，但影響了數(shù)據(jù)傳輸速度。

同時，為了保證 “ 在手機流暢播放 ”，一般還需要先緩存一點畫面，這又造成了大量延時。

所以，盡管目前大家對于這種標準的直播形式，已經(jīng)優(yōu)化優(yōu)化再優(yōu)化，但因為上面這些天生的限制，還是得有個 3 - 4s 的延遲。

所以啊，這次抖音的世界杯直播實現(xiàn)的 1s 延遲甚至更少延遲，靠的是另辟蹊徑。

他們用的技術叫做 “ 超低延時直播 ”。

首先，這項技術借鑒了谷歌研發(fā)的 WebRTC 通信模型，這套技術理論上可以將延時降低到 500 毫秒。

與前面的 TCP 協(xié)議不一樣，“ 超低延時直播 ” 用的是 UDP 協(xié)議。

UDP 協(xié)議不用考慮什么傳輸順序、數(shù)據(jù)有沒有丟失，它只管一股腦地把數(shù)據(jù)往接收方丟，這屬性就很適合賽事直播了。

不過呢， WebRTC 模型本身有非常復雜的步驟，進行建立連接。

這個建立連接過程就像是發(fā)短信：

“ 在嗎？” 

“ 我在，有事兒嗎？” 

“ 有事兒。” 

“ ... ” 

非要這么幾輪 “ 對話拉扯 ”，雙方都確認對上號了，才會開始傳輸數(shù)據(jù)，所以我們在看一些直播的時候常遇到，點進直播間，畫面卻一直在轉(zhuǎn)圈圈，就是這個原因。

還有個問題就是，WebRTC 這套玩意兒之前都是用在視頻會議等場景，在傳輸數(shù)據(jù)中會出現(xiàn)一些音畫對不上的情況。

這本來不算什么大毛病，WebRTC 一般就直接讓落后的那個加速一下就能對齊了。

但是這種原生的倍速播放，在大家看體育賽事或者其他的直播里，會顯得非常難受。

所以在抖音用的這套超低延時直播播放模型里，火山引擎團隊經(jīng)過了大量實驗，找到了倍速和體驗之間的平衡點，反正這次世界杯我是一點沒感覺出來這些問題。

再一個，前面也說了，WebRTC 本來大部分用在視頻會議等場景，這兩年雖然逐漸被采用到了直播場景，可是它本身是不定義信令交互流程的。

信令交互意思就相當于甲方告訴乙方需求，乙方向甲方展示能力，雙方通過這么一來回，大致就能摸清合作方向了。

既然牽扯到雙方交流，就得有套固定的流程，比如是寫文字稿件、寫 PPT 還是做方案，怎么把控時間節(jié)點等等。

這些在合作前最好都規(guī)范化流程，雙方都遵守，做起事來就輕松。

可現(xiàn)狀是，WebRTC 就沒個統(tǒng)一的流程，很容易變成大家各干各的，耽誤時間。

為了解決這個問題，在今年 2 月 25 日，火山引擎與阿里云、騰訊云聯(lián)合發(fā)布了一項 “ 超低延時直播協(xié)議信令標準（ 以下簡稱標準 ） ” 。

有了這套統(tǒng)一標準，讓大家知道該怎么辦事兒了，速度也就快了不少。

不光如此，這套標準里還簡化了信令交互流程: 

好比原來甲乙方談合作，要酒過三巡菜過五味，幾輪會談下來才能搞定，現(xiàn)在直接是預算需求一發(fā)，能不能做？能做就做，不能做就拜拜，簡潔明了。

最終一統(tǒng)優(yōu)化下來，這次抖音世界杯直播延時被卷進了 1 秒內(nèi)，最快可達到 500 毫秒。

搞定了延時，還有一個很重要的問題擺在眼前：音視頻原始數(shù)據(jù)是要壓縮才能在互聯(lián)網(wǎng)上流暢傳輸?shù)?，壓縮可是相當耗時間的。

特別是這次世界杯用的都是特高清攝像頭，畫面是好了，但數(shù)據(jù)量也就更多了，壓縮起來更費時間了。

世界杯比賽的標準攝像機計劃是由 42 臺攝像機組成的 ▼

所以，為了解決這個壓力，本次抖音的世界杯直播，用上了火山引擎視頻云團隊自研的 BVC 編碼器，它針對體育賽事場景進行了深度優(yōu)化。

能夠在梅西助跑打門的時候，快速編碼比賽的超清畫面，保證大家直播里看到的梅球王每一步都縱享絲滑，而且還不會影響延遲等問題。

此外，這屆世界杯主辦方為了進一步提升觀賽體驗，大面積使用了 HDR 拍攝。

HDR 畫面細節(jié)拉滿，顏色更豐富，是個好東西。

可問題是很多人電腦、電視等設備并不完全支持 HDR 信號播放，所以還得將 HDR 信號轉(zhuǎn)成普通信號，可這個過程中就會損失掉很多內(nèi)容。

為了讓沒有 HDR 播放設備觀眾能享受到近乎 HDR 的體驗，火山引擎視頻云團隊設計了一套自適應 ToneMapping 算法。

以往簡單用個算法來改善 SDR 畫質(zhì)，都是死板的，比如黑色亮度統(tǒng)一增強 5，純白亮度統(tǒng)一降 3，顯然不能讓大家滿意。

有了自適應 ToneMapping 算法，它會根據(jù)不同幀畫面的不同情況，有腦子地進行畫質(zhì)增強，這就很舒服。

左 : hable 算法   右 :內(nèi)容自適應 ToneMapping

當然了，除了這些，這次畫面能看得這么舒服，還用上了色彩增強、時空域降噪、超分等畫質(zhì)增強技術等等。

反正這么看下來，這次世界杯直播，四舍五入，約等于換了一整套直播技術。

最后還有個小小的疑惑，這整套技術是有一點點貴還是億點點貴？

將來有沒有可能，直接搬到其他賽事或者領域用用呢？

純粹是好奇，真不是看慣了世界杯直播，眼界變刁了。