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