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

牛*！牛*！牛*！

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

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

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

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

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

 “ 球王梅西！ ” 

“ 大馬丁牛 * ！” 

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

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

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

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

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

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

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

在網絡直播眾多環節中里面，主要影響直播延時的就是， “ 把數據丟到服務器 ”、“ 平臺把數據丟到你手機里 ”、“ 手機流暢播放 ” 三個環節。

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

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

HLS 和 RTMP。

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

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

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

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

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

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

所以，用 HLS 協議的直播，很難把延遲做到 10s 以內。

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

它的做法并不需要切片，而是分別轉發每一幀，這一來就已經比 10s 發一次的 HLS 少了不少延遲。

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

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

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

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

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

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

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

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

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

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

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

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

這個建立連接過程就像是發短信：

“ 在嗎？” 

“ 我在，有事兒嗎？” 

“ 有事兒。” 

“ ... ” 

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

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

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

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

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

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

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

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

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

可現狀是，WebRTC 就沒個統一的流程，很容易變成大家各干各的，耽誤時間。

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

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

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

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

最終一統優化下來，這次抖音世界杯直播延時被卷進了 1 秒內，最快可達到 500 毫秒。

搞定了延時，還有一個很重要的問題擺在眼前：音視頻原始數據是要壓縮才能在互聯網上流暢傳輸的，壓縮可是相當耗時間的。

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

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

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

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

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

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

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

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

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

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

左 : hable 算法   右 :內容自適應 ToneMapping

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

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

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

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

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