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