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

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

反正世超這么看下來，這次世界杯直播，四舍五入，約等于換了一整套直播技術，真是活該被網上各種夸。

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

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

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

直播吧10月28日訊 U20亞洲杯分組抽簽儀式結束之后，中國隊與日本隊、沙特隊以及吉爾吉斯斯坦隊同分在D組。據《體壇周報》記者馬德興消息，目前小組賽的賽程已經敲定，國青隊將在明年3月3日北京時間下午18點首戰日本。

2023年U20亞洲杯將于2023年3月1日至18日在烏茲別克斯坦進行。小組賽為2023年3月1日至3月9日，淘汰賽為3月11日至18日。中國隊所在小組的比賽將被安排在塔什干進行。首戰日本和末戰吉爾吉斯斯坦的比賽將在JAR體育場進行，次輪對陣沙特的比賽在塔什干國家體育場進行。

中國U20國足小組賽賽程如下（北京時間）：

2023年3月3日18:00 中國vs日本 JAR體育場

2023年3月6日20:00 中國vs沙特 國家體育場

2023年3月9日20:00 中國vs吉爾吉斯斯坦 JAR體育場

（涼笙墨塵）