首页 > 科技未来 > 内容

对于互动直播，直播技术如何实现低延迟？

发布于：2024-06-17 编辑：匿名来源：网络

雷锋网出版社：本文作者：作者冼牛，总监，技术市场的市场运营者，香港大学MBA，十年研发经验，音视频云服务技术王牌，重点关注连麦互动直播技术的应用研究。

本文为雷锋网独家文章。

让我们从姜文《让子弹飞》的名言开始：让子弹飞一会儿。

某名人抱怨：飞多久？这子弹的延迟也太大了。

这是名人。

为什么低延迟很重要？低延时的子弹可以秒杀千里之外的敌人，低延时的直播技术可以秒杀千里之外的粉丝。

互动直播技术已经成为直播平台的标配。

没有互动直播技术的直播平台不可能跻身直播行业的第一梯队。

要获得互动直播技术，低延迟是必须的。

所以低延迟很重要。

那么，直播技术是如何实现低延迟的呢？请允许我根据我在极狗科技直播技术方面的经验，给大家分享一下如何实现低延迟。

采用极狗科技的连麦互动直播技术，连麦端延迟为毫秒级，观看端延迟在1秒左右。

目前，映客直播、花椒直播、一博、栗子直播均采用极狗科技的连麦互动直播技术。

因此，这种直播技术经验是经过市场验证、从实际操作中获得的，而不是仅仅基于理论分析。

一般来说，只有在延迟小于毫秒的情况下，才能在直播过程中连接麦克风，进行一些相对高频的互动，例如相声或脱口秀。

如果延迟高于毫秒，直播时连续麦克风连接的效果将无法被观众接受。

因此，毫秒级延迟的直播技术有足够的空间来实现连麦互动直播业务。

要实现直播技术的低延迟，有一个简单而务实的理念：1）选择最优路径； 2）在这条路径上是最优的； 3）在所有路径上保持高质量。

下面我就按照这个思路来讨论如何实现低延迟。

选择最佳路径选择最佳路径的方法有很多种。

目前，常用的网络路径选择方法有网速测试、用户个人连接数据分析、用户组连接数据分析等。

在推流之前，网速测试仪会向每条路径发送简单的数据包，然后根据数据包的响应时间猜测哪条路径最快。

这种方法比较简单、有效，但有局限性：所选择的路径只是测试时间点最快的，网络状况随时间变化；另外，实测简单数据包的速度比较快，并不代表流媒体传输。

数据速度也更快。

因此，该方法得到的结果只能作为参考指标。

大数据分析为了避免单个采样时间点测速带来的偏差，可以通过分析历史大数据来预测哪条网络路径是最佳的。

历史大数据的分析分为两个维度：用户个人连接数据分析和用户群体连接数据分析。

1、用户个人连接数据分析每个主播用户的使用历史数据是有规律的、可追踪的。

通过分析这些历史数据，我们可以发现主播用户从哪里访问、访问的时间、访问的服务器以及采取的路径来达到最佳效果。

这些历史数据积累得越丰富，历史数据分析得出的结论就越可靠。

该方法可以发现个体锚定用户的周期性网络连接状态，找到大多数时候连接效率最好的网络路径。

但该方法的缺点是数据采样仅基于单个用户，采样点过少，没有统筹考虑用户所在区域的整体网络连接情况。

2、用户群体连接数据分析为了弥补用户个人连接数据分析的不足，这里引入数据分析的另一个维度：对某一区域的用户群体连接数据的分析。

通过分析某个用户所在区域的用户组历史数据，我们可以发现该区域网络连接随时间变化的规律，找出不同时间点不同接入点连接到哪台服务器效果最好。

单点网络测速、用户个人连接数据分析、用户组连接数据分析相结合得出结论，可以更有效地预测哪条路径最好。

这部分路由需要不断优化，以积累丰富的用户数据，适应网络的变化。

在这条路径上实现最优路径之后，剩下的就是在这条路径上实现最优路径了。

该路径包括以下几个环节：采集、编码、推流、转码、分发、推流、解码、渲染。

在实时音视频系统架构中，每个环节都会有一定的优化空间。

业内朋友在这条路上已经进行了很多探索。

我不想在这里重复别人已经探讨过的问题，只关注以下要点。

协议的选择传输协议的选择非常重要。

传输协议在一定程度上决定了延迟的范围。

选择传输协议时，应考虑是推端还是拉端。

流媒体端的协议包括RTMP、WebRTC以及基于UDP的私有协议。

1、RTMP是基于TCP的标准协议，一般CDN网络都支持，可以实现比较低的延迟。

极狗科技的互动直播技术在推送端采用RTMP协议，拉取端兼容RTMP、HLS、FLV三种协议。

HLS协议的延迟比较大，需要持续小麦交互的场景不宜使用HLS协议。

2、WebRTC的优点是用户体验好。

无需安装任何东西。

您只需分享一个链接即可查看。

但它有一个缺点，那就是WebRTC是Google推广的技术。

除了Google Chrome和Opera支持WebRTC外，其他大多数浏览器都不支持WebRTC。

也就是说，40%的浏览器支持WebRTC，剩下的60%不支持，所以应用范围相对有限。

那么，在中国，WebRTC在Google Chrome上的性能也大打折扣。

最后，由于浏览器不具备开放核心的能力，浏览器??上运行的协议很难实现更低的延迟。

3、基于UDP的私有协议，非常适合实时音视频系统。

它是无连接的，避免了TCP用于网络质量控制所需的开销，并且可以实现相对较低的延迟。

但它也有一个缺点，那就是私有协议的兼容性不好。

CDN支持标准的RTMP协议，但不支持基于UDP的私有协议。

为了吸收UDP的优点，避免UDP的缺点，狗科技的互动直播技术采用了基于UDP的私有协议作为补充，在必要时弥补了RTMP协议的缺点。

例如，基于UDP的私有协议仅在网络环境比较恶劣或者跨境通信的情况下使用；例如，从流媒体端到媒体服务器仅使用基于UDP的私有协议，而从媒体服务器转发流到CDN网络则使用RTMP协议。

通过将UDP私有协议转换为RTMP协议，实现两段之间的适配和连接。

这样，极狗科技的直播解决方案不仅具有超低延迟的优势，还保留了CDN网络普遍支持的标准协议的优势。

前向纠错和丢包重传前向纠错，简称FEC，英文全称Forward Error Correction，是通过提前采取措施来对抗网络损害。

丢包重传主要是为了在丢包的情况下，有针对性、高效地重传丢失的数据包。

准确地说，它们的直接目的不是减少延迟，而是对抗网络损伤。

在不可预测的网络环境中，能够很好地应对网络抖动的负面影响，间接降低延迟的同时保证稳定性和流畅性。

一般来说，前向纠错和丢包重传是互补使用的。

前者是先验方法，节省时间，但占用多余带宽；后者是后验方法，可以节省带宽，但消耗更多的钱。

时间。

当网络状况比较差、丢包率比较高时，可以采用前向纠错的方法来保证信息的完整传递。

例如，发送冗余信息可以保证在一定的丢包率下，接收方能够准确、完整地恢复发送方想要发送的信息。

当网络比较好的情况下，丢包率比较低的时候，可以采用丢包重传的方式来保证信息的完整传递。

例如，通过有效的机制重传丢失的数据包，以确保接收方能够完整接收发送方想要发送的消息。

缓冲区适配由于网络抖动的存在，导致数据包的到达不均匀。

减少延迟最直接的方法就是将缓冲队列的长度设置为零，直接渲染接收到的数据包。

但这样做的后果就是播放不流畅，出现卡顿。

因此，延迟和平滑本身就是矛盾的因素。

我们要做的就是找到低延迟和流畅之间的平衡点。

寻找平衡点的有效方法是建立缓冲队列。

推流端和混流服务器都需要建立缓冲队列。

对于实时系统来说，缓冲队列的长度一定不是固定的，而是自适应的：当网络好的时候，缓冲队列的长度会变短，接近于零，甚至为零；当网络好的时候，缓冲队列的长度会变短，接近于零，甚至为零；当网络不好时，缓冲队列的长度会变短。

好的情况下，缓冲队列的长度会变长，但不能超过可接受的上限。

毕竟，缓冲队列的长度本质上就是延迟时间。

此外，缓冲区自适应技术还可以与快播或慢速广播技术结合使用。

当网络由坏变好时，可以尽快使广播速度更快，并缩短缓冲队列的长度。

当网络由好变差时，可以适当减慢广播速度，从而适当加长缓冲队列，以保持流畅。

快放和慢放是根据观众的心理模型，在适合快放和慢放的条件下使用，使观众察觉不到播放速度的变化，整体感觉流畅、低沉。

潜伏。

码率适配由于网络环境的复杂性和多变性，码率必须能够自动适应网络条件的变化，即所谓的码率适配。

当网络比较差时，必须降低码率才能保持直播低延迟、流畅；当网络比较好的时候，必须提高码率才能保持直播的高清质量。

为了实现码率适配，协议选择也很有讲究。

RTMP对于码率适配能做的事情比较有限，因为它是基于TCP的，而TCP的下层已经做了网络质量控制。

当网络拥塞时，无法及时通知上层应用。

基于UDP的私有协议更适合码率适配，因为它是基于UDP的，而UDP只负责发送和接收数据包，将网络质量控制留给应用层，这样应用层就有足够的能力了。

空间实现码率自适应。

保持所有路径的高质量因此，为了实现直播技术的低延迟，必须选择一条最优路径，并在该路径上做到最优。

故事讲完了吗？不，我们忘记了一个前提：整体路网必须足够好。

路网不好。

无论你如何选择，总会有腐烂的土路。

如果你选择烂土路，你怎么跑得快？因此，要实现低延迟，网络基础设施必须足够好。

网络基础设施质量可从以下三个方面提升：网络全覆盖。

一般来说，音视频云服务的机房会分布在几个核心枢纽城市，偏远地区用户的访问质量无法得到保证。