昨晚阿根廷時隔 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 ▼

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

反正世超這麼看下來，這次世界盃直播，四捨五入，約等於換了一整套直播技術，真是活該被網上各種誇。

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

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

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

撰文：八戒 編輯：莽山烙鐵頭 & 面線