阿根廷时隔 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
当然了，除了这些，这次画面能看得这么舒服，还用上了色彩增强、时空域降噪、超分等画质增强技术等等。
反正这么看下来，这次世界杯直播，四舍五入，约等于换了一整套直播技术。
最后还有个小小的疑惑，这整套技术是有一点点贵还是亿点点贵？
将来有没有可能，直接搬到其他赛事或者领域用用呢？
纯粹是好奇，真不是看惯了世界杯直播，眼界变刁了。
