球王梅西，还需要一座金杯来证明吗？

Posted 2022-12-21 码农翻身

转眼间，世界杯又快要结束了！

阿根廷又一次杀入决赛，无限接近大力神杯了。

作为梅西的球迷，从2006年梅西第一次登上世界杯舞台，一直看到了2022年，虽然希望梅西这次能够圆梦，但是我也很清楚，在足球的世界里什么都可能发生。

即使这次没有金杯加持，在我心中，他早已经是球王了。

这次世界杯让我特别伤感，因为无论结果如何，这肯定是梅西的最后一届世界杯，看了十几年的梅西，梅西老了，我也老了。

如果从98年算起，我已经看了七届世界杯，曾经一起为足球呐喊的小伙伴们一个个地远离了世界杯，还在坚守的不多了。

这二十多年，看球体验可以说是天差地别。

98年的时候，家里只有一台老式彩电，画质不咋地，但是依然看得津津有味，印象深刻。

互联网早期，出现了简陋的文字滚动直播，然后是图文直播，后来网络速度不断提升，终于可以看视频了，但是画质惨不忍睹。 

也就是这几年，随着光纤入户，网速有了飞跃，球赛终于脱离了电视机的束缚，随时随地都可以看高清网络直播。

像我在厨房做饭的时候，会支起一个平板，时不时搂一眼，客厅电视上有个第三方的app也在同步播放，这样我来回走动的时候就不会错过任何精彩镜头。

有一次小组赛正在看日本 vs 德国，无意中刷了一下朋友圈，赫然发现朋友圈都在发图庆祝日本队打入一球反超了，这是怎么回事，我的电视中日本队怎么还在进攻呢？

我立刻明白了：不同的直播观看平台延时不一样！直播技术相对落后的平台延时可以高达十几秒～

作为计算机行业人士，我知道本地网络是有延时，但是延时这么大是我不能忍的。

好奇心瞬间被激发出来，于是我开始研究直播背后的技术流程到底是怎么回事。

1

球赛直播流从赛场传递到手机/平板/电视上，大概需要经历这么一个过程：

1. 采集

这是第一个环节，它从系统的采集设备中获取原始视频数据，包括音频和视频。这一步耗时很小，十几毫秒就搞定。

2. 编码

音频和视频都需要进行编码压缩，常用的音频压缩编码算法有AAC、MP3、WMA等，视频压缩编码算法有H.264，H.265等。

通过调优，这一步也能降到几十毫秒。

3. 推流

将数据从推到云端直播中心，一般使用RTMP协议推流，基本耗时在十几毫秒到几十毫秒。

5. 转码

大家观看视频时一般都会有超清、高清、流畅等不同选择，一般需要在服务器端进行转码处理，形成不同的清晰度。如果采取高速转码，耗时也不高。

6. 分发

为了支持高并发，一般需要CDN来进行内容分发加速，这一步是耗时的，如果用户网络条件差，丢包多，延时就要达到几秒甚至几十秒！

7. 客户端播放

我们的客户端进行解码，渲染，最终呈现出来。目前像Flash播放器、hls、rtmp播放器缓存需要6-10秒，播放器的缓存是产生延时的关键原因。那为什么不在当前直播条件下把缓存调到0呢？这是由于调到0之后延时虽然小了，但卡顿会很高。

其实本质的原因就在于传统直播模型中，传输和播放是完全割裂的，没有对变化的网络进行适配，基于TCP的可靠传输也无法区分视频帧的优先级，而且其窗口确认机制在弱网下会导致较大的延时积累，就没法满足延时优先的需求。

其实流媒体技术经过了漫长的发展和迭代，早在2005年，Macromedia（后来被Adobe收购）就研发了RTMP协议，用于在RTMP服务器和Flash播放器之间传输数据，RTMP协议中的基本数据单元是消息（Message），传输的过程中消息会被拆分为更小的消息块（Chunk）单元。最后将分割后的消息块通过 TCP 协议传输，接收端再反解接收的消息块恢复成流媒体数据。

由于RTMP基于TCP传输，非公共端口，可能会被防火墙阻拦。后来Adobe又提出了HTTP-FLV，将流媒体数据封装成 FLV 格式，然后通过 HTTP 协议传输给客户端。

2009年，苹果公司提出了一个HTTP Live Streaming(HLS)协议，相比常见的流媒体协议，HLS会在服务器端将流媒体数据切割成短时长的ts小文件，并通过m3u8索引文件来按序访问ts文件，客户端只需要不停地按序播放就可以了。

HLS对html5非常友好，但是延时却比较大，2019年苹果推出LL-HLS(Low-Latency HLS)，采用chunk编码，将延时降低到3秒左右。

但是无论怎么折腾，这些基于TCP方案的协议，都难以突破2~3秒的延时极限。

而基于UDP的WebRTC的出现，终于让大家看到了把延时降到1秒以内的曙光。

但是WebRTC的初衷是用于低延时P2P(Peer-to-Peer)通信，如果应用在直播场景下它表现如何呢？

我上网搜了一下，发现腾讯云快直播是业内首创将WebRTC技术引入直播领域，最早对外发布超低延时直播产品，目前，快直播的延时可降低到800ms以内，并同时兼顾延时、卡顿和首帧耗时，综合QoS远超传统直播。

毫秒级延时！这样的技术如果看球赛直播岂不很爽， 但是它真能达到这个效果吗？ 

2

我决定亲自体验一下，用腾讯云快直播（https://console.cloud.tencent.com/live/leb）搭建了一个快直播环境，然后找了几个1080P的足球视频片段，循环播放，用OBS做推流直播，然后对比快直播和普通直播的观看效果。

直播测试开始，效果果然很惊艳！

快直播（下方视频中右下角的WebRTC）几乎和原视频画面几乎保持一致，甚至感受不到差异。

标准直播FLV的画面要慢一些，延时在3秒左右。HLS就更慢了，延时高达10秒以上，别人都开始第二轮循环播放了，它在第一轮中还没出来。

（快直播 vs 普通直播）

不过这是正常网络下的表现，如果是网络很差，出现了丢包的问题，快直播表现如何呢？

想要模拟丢包，得弄个工具才行，有个叫Clumsy的软件可以专门干这件事，可以通过“Drop”的方式随机丢弃某些数据包。

可以看出，手工模拟丢包，形成弱网，快直播依然可以流畅的播放，相比标准直播，弱网丢包抗性提升50%：

（模拟弱网丢包测试）

快直播这种超低延时抗弱网的效果是怎么实现的呢？ 

原来，快直播虽然是基于WebRTC的，但是对WebRTC做了很多创新性的改造：

信令改造，利用miniSDP和0-RTT的结合，大幅减少信令耗时、提升信令交互成功，进而降低首帧耗时和提升开播成功率。 

音视频改造，让WebRTC支持AAC，H.265，附加前向纠错，抗50%以上丢包。还引入了B帧，增强了画质，同时大幅减少了码率。

传输改造，采样柔性分级丢帧的传输策略来渐进式降低码率，以适应弱网情况。支持P2P分发网络，能够将看同一视频流的用户群就近地组织成网络，相互分享传输。

......

技术术语很多，简而言之，腾讯云快直播就是针对CDN传输和播放这两个痛点问题，将传输和播放控制实时反馈联动，形成闭环，通过感知网络状态来调整缓存和传输策略，根据实时网络进行最优匹配，这样用户在变动的网络中依然能获得非常低的平均延时（800毫秒左右）。

除了超低延时和抗弱网特性，腾讯云快直播还有两个业界领先的特性：自适应码率和AV1编码。

自适应码率：它可以根据播放端带宽自适应下发合适码率的视频，提升播放体验。这就厉害了，它不是我们在客户端手工去切换码率的，而是服务器端通过渐进式的超发来探测网络的承载能力，主动帮我们切换的。

下方的视频就展示出了随着网络情况的变化，当前视频的分辨率，码率都随之而变，视频依然非常流畅。

（自适应码率测试）

AV1视频编码：编码格式开源、免版权费，相比上一代H.265[HEVC]编码，在相同画质下可以再降低30%+码率，帮助企业节约带宽成本。

从我的测试中可以看出，AV1编码仅用1.5Mbps（仅为原始流的一半）就实现了同样的画质，这样不仅可以节省视频的存储空间，还能节省至少50%的传输带宽成本。

（AV1编码测试）

据我所知，超低延时直播产品领域，市面上也只有腾讯云、A厂商和Z厂商做了商用，相比而言，腾讯云快直播从各方面的指标测试表现来看，是处于市场领先地位的。

据了解今年2月份腾讯云音视频联合信通院对外独家发布了《超低延时直播（快直播）白皮书》，并首次对外公布超低延时直播技术标准，为直播技术发展提供了新思路，突破性的改善了直播观看体验。

3

说了这么多的直播技术，最终还是想看一场流畅、“实时”、高清的球赛直播，今年2022世界杯有转播权的平台好像是央视、咪咕、抖音这几家吧，我都去下载感受了一下，也和一些朋友聊了聊，普遍感觉抖音似乎延时最低而且画面体验最好，不知道是不是用了快直播技术？（个人猜测）

世界杯决赛虽然马上快要结束了，但是各类体育赛事直播一直都在进行中，并且已经融入到我们的生活和娱乐中。

同时，在电商带货、会展直播、娱乐秀场、在线教育、体育赛事等领域，超低延时直播技术的应用也将最大程度还原真实的直播互动场景，让作为观众的我们感受到更低延时更强互动的直播体验。

最后，我还是强烈推荐大家关注下腾讯云的快直播，亲身体验一下这款产品的唯”快“不破：

想了解快直播底层技术的同学，可以下载《超低延时直播白皮书》看一看，有不少干货。