抖音在今年世界杯上下的功夫，远不止撒币10亿买版权这么简单

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