热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

详解音视频直播平台搭建中的低延时

详解音视频直播平台搭建中的低延时音视频实时通讯的应用场景已经随处可见,从“吃鸡”的语音对讲、直播连麦、直播答题组队开黑,再到银行视频开户等。对于开发者来讲,除了关注如何能快速实现不

详解音视频直播平台搭建中的低延时

音视频实时通讯的应用场景已经随处可见,从“吃鸡”的语音对讲、直播连麦、直播答题组队开黑,再到银行视频开户等。对于开发者来讲,除了关注如何能快速实现不同应用场景重点额音视频通讯,另一个更需要关注的可能就是“低延时”。但是,到底实时音视频传输延时应该如何“低”,才能满足你的应用场景呢?

延时的产生与优化

在聊低延时之前,我们先要讲清延时是如何产生的。由于音视频的传输路径一样,我们可以通过一张图来说明延时的产生:

 

 

 

在音视频传输过程中,在不同阶段都会产生延时。总体可以分为三类:

 

 

 

T1:设备端上的延时

音视频数据在设备端上产生延时还可以细分。设备端上的延时主要与硬件性能、采用的编解码算法、音视频数据量相关,设备端上的延时可达到 30~200ms,甚至更高。如上表所示,音频与视频分别在采集端或播放端产生延时的过程基本相同,但产生延时的原因不同。

音频在设备端上的延时:

  • 音频采集延时:采集后的音频首先会经过声卡进行信号转换,声卡本身会产生延时,比如 M-Audio 声卡设备延迟 1ms,艾肯声卡设备延迟约为 37ms;

  • 编解码延时:随后音频进入前处理、编码的阶段,如果采用 OPUS 标准编码,最低算法延时大约需要 2.5~60ms;

  • 音频播放延时:这部分延时与播放端硬件性能相关。

  • 音频处理延时:前后处理,包括 AEC,ANS,AGC 等前后处理算法都会带来算法延时,通常这里的延时就是滤波器阶数。在 10ms 以内。

  • 端网络延时:这部分延时主要出现在解码之前的 jitter buffer 内,如果在抗丢包处理中,增加了重传算法和前向纠错算法,这里的延时一般在 20ms 到 200ms 左右。但是受到 jitter buffer 影响,可能会更高。


视频在设备端上的延时:

  • 采集延时:采集时会遇到成像延迟,主要由 CCD 相关硬件产生,市面上较好的 CCD 一秒可达 50 帧,成像延时约为 20ms,如果是一秒 20~25 帧的 CCD,会产生 40~50ms 的延时;

  • 编解码延时:以 H.264 为例,它包含 I、P、B 三种帧(下文会详细分析),如果是每秒 30 帧相连帧,且不包括 B 帧(由于 B 帧的解码依赖前后视频帧会增加延迟),采集的一帧数据可能直接进入编码器,没有 B 帧时,编码的帧延时可以忽略不计,但如果有 B 帧,会带来算法延时。

  • 视频渲染延时:一般情况下渲染延时非常小,但是它也会受到系统性能、音画同步的影响而增大。

  • 端网络延时:与音频一样,视频也会遇到端网络延时。


另外,在设备端,CPU、缓存通常会同时处理来自多个应用、外接设备的请求,如果某个问题设备的请求占用了 CPU,会导致音视频的处理请求出现延时。以音频为例,当出现该状况时,CPU 可能无法及时填充音频缓冲区,音频会出现卡顿。所以设备整体的性能,也会影响音视频采集、编解码与播放的延时。

T2:端与服务器间的延时

影响采集端与服务器、服务器与播放端的延时的有以下主几个因素:客户端同服务间的物理距离、客户端和服务器的网络运营商、终端网络的网速、负载和网络类型等。如果服务器就近部署在服务区域、服务器与客户端的网络运营商一致时,影响上下行网络延时的主要因素就是终端网络的负载和网络类型。一般来说,无线网络环境下的传输延时波动较大,传输延时通常在 10~100ms 不定。而有线宽带网络下,同城的传输延时能较稳定的低至 5ms~10ms。但是在国内有很多中小运营商,以及一些交叉的网络环境、跨国传输,那么延时会更高。

T3:服务器间的延时

在此我们要要考虑两种情况,第一种,两端都连接着同一个边缘节点,那么作为最优路径,数据直接通过边缘节点进行转发至播放端;第二种,采集端与播放端并不在同一个边缘节点覆盖范围内,那么数据会经由“靠近”采集端的边缘节点传输至主干网络,然后再发送至“靠近”播放端的边缘节点,但这时服务器之间的传输、排队还会产生延时。仅以骨干网络来讲,数据传输从黑龙江到广州大约需要 30ms,从上海到洛杉矶大约需要 110ms~130ms。

在实际情况下,我们为了解决网络不佳、网络抖动,会在采集设备端、服务器、播放端增设缓冲策略。一旦触发缓冲策略就会产生延时。如果卡顿情况多,延时会慢慢积累。要解决卡顿、积累延时,就需要优化整个网络状况。

综上所述,由于音视频在采集与播放端上的延时取决于硬件性能、编解码内核的优化,不同设备,表现不同。所以通常市面上常见的“端到端延时”指的是 T2+T3。

延时低≠通话质量可靠

不论是教育、社交、金融,还是其它场景下,大家在开发产品时可能会认为“低延时”一定就是最好的选择。但有时,这种“追求极致”也是陷入误区的表现,低延时不一定意味着通讯质量可靠。由于音频与视频本质上的差异,我们需要分别来讲实时音频、视频的通讯质量与延时之间的关系。

音频质量与延时

 

音频采样示意图

 

 

影响实时音频通讯质量的因素包括:音频采样率、码率、延时。音频信息其实就是一段以时间为横轴的正弦波,它是一段连续的信号(如上图)。

采样率:是每秒从连续信号中提取并组成离散信号的采样个数。采样率越高,音频听起来越接近真实声音。

码率:它描述了单位时间长度的媒体内容需要空间。码率越高,意味着每个采样的信息量就越大,对这个采样的描述就越精确,音质越好。

假设网络状态稳定不变,那么采样率越高、码率越高,音质就越好,但是相应单个采样信息量就越大,那么传输时间可能会相对更长。

对照我们之前的公式,如果想要达到低延时,那么可以提高网络传输效率,比如提高带宽、网络速度,这在实验室环境下可以轻易实现。但放到生活环境中,弱网、中小运营商等不可控的问题必定会影响网络传输效率,最后结果就是通讯质量没有保障。还有一种方法,就是降低码率,那么会损失音质。

视频质量与延时

影响实时视频质量的因素包括:码率、帧率、分辨率、延时。其中视频的码率与音频码率相似,是指单位时间传输的数据位数。码率越大,画面细节信息越丰富,视频文件体积越大。

 

 

 

**帧:**正如大家所知,视频由一帧帧图像组成,如上图所示为 H.264 标准下的视频帧。它以 I 帧、P 帧、B 帧组成的 GOP 分组来表示图像画面(如下图):I 帧是关键帧,带有图像全部信息;P 帧是预测编码帧,表示与当前与前一帧(I 或 P 帧)之间的差别;B 帧是双向预测编码帧,记录本帧与前后帧的差别。

**帧率:**它是指每秒钟刷新的图像帧数。它直接影响视频的流畅度,帧率越大,视频越流畅。由于人类眼睛与大脑处理图像信息非常快,当帧率高于 24fps 时,画面看起来是连贯的,但这只是一个起步值。在游戏场景下,帧率小于 30fps 就会让人感到画面不流畅,当提升到 60fps 时会带来更实时的交互感,但超过 75fps 后一般很难让人感到有什么区别了。

**分辨率:**是指单位英寸中所包含的像素点数,直接影响图像的清晰度。如果将一张 640 x 480 与 1024 x 768 的视频在同一设备上全屏播放,你会感到清晰度明显不同。

在分辨率一定的情况下,码率与清晰度成正比关系,码率越高,图像越清晰;码率越低,图像越不清晰。

在实时视频通话情况下,会出现多种质量问题,比如:与编解码相关的画面糊、不清晰、画面跳跃等现象,因网络传输问题带来的延时、卡顿等。所以解决了低延时,只是解决了实时音频通讯的一小部分问题而已。

综上来看,如果在网络传输稳定的情况下,想获得越低的延时,就需要在流畅度、视频清晰度、音频质量等方面进行权衡。

不同场景下的延时

我们通过下表看到每个行业对实时音视频部分特性的大致需求。但是每个行业,不仅对低延时的要求不同,对延时、音质、画质,甚至功耗之间的平衡也有要求。在有些行业中,低延时并非永远排在首位。

 

 

 

游戏场景

在手游场景下,不同游戏类型对实时音视频的要求不同,比如狼人杀这样的桌游,语音沟通是否顺畅,对游戏体验影响很大,所以对延时要求较高。其它类型游戏具体如下方表格所示。

 

 

 

但满足低延时,并不意味着能满足手游开发的要求。因为手游开发本身存在很多痛点,比如功耗、安装包体积、安全性等。从技术层面讲,将实时音视频与手游结合时,手游开发关注的问题有两类:性能类与体验类。

 

 

 

在将实时音视频与手游结合时,除了延时,更注重包的大小、功耗等。安装包的大小直接影响用户是否安装,而功耗则直接影响游戏体验。

社交直播场景

目前的社交直播产品按照功能类型分有仅支持纯音频社交的,比如荔枝 FM;还有音视频社交的,比如陌陌。这两类场景对实时音视频的要求包括:

 

 

 

直播答题场景

在直播答题场景中,对实时音视频的要求主要有如下两点:

 

 

 

我们以前经常能看到主持人说完一道题,题目却还没发到手机上,最后只剩 3 秒的答题时间,甚至没看到题就已出局。该场景的痛点不是低延时,而是直播音视频与题目的同步,保证所有人公平,有钱分。

K 歌合唱场景

天天 K 歌、唱吧等 K 歌类应用中,都有合唱功能,主流形式是 A 用户上传完整录音,B 用户再进行合唱。实现实时合唱的主要需求有如下几点:

 

 

 

在这个场景中,两人的歌声与音乐三者之间的同步给低延时提出了很高的要求。同时,音质也是关键,如果为了延时而大幅降低音质,就偏离了 K 歌应用的初衷。

金融场景

对于核保、银行开户来讲,需要一对一音视频通话。由于金融业特殊性,该类应用对实时音视频的需求,按照重要性来排序如下:

 

 

 

在这个场景中,低延时不是关键。重要的是,要保证安全性、双录功能和系统平台的兼容。

在线教育

在线教育主要分为两类:非 K12 在线教育,比如技术开发类教学,该场景对实时音视频的要求主要有:

 

 

 

很多非 K12 教学发生在单向直播场景下,所以延时要求并不高。

另一类是 K12 在线教育,比如英语外教、部分兴趣教学,通常会有一对一或一对多的师生连麦功能,它对直播场景的要求包括:

 

 

 

在 K12 的在线教育中,师生的连麦在低延时方面有较高的要求。如果会涉及跨国的英语教学,或需要面向偏远地区学生,那还要考虑海外节点部署、中小运营商网络的支持等。

在线抓娃娃

在线抓娃娃是近期新兴热点,主要依靠实时音视频与线下娃娃机来实现。它对实时音视频的要求包括:

 

 

 

瓶颈与权衡

 

 

 

产品的开发追求极致,需要让延时低到极限。但理想丰满,现实骨感。我们曾在上文提到,延时是因多个阶段的数据处理、传输而产生的。那么就肯定有它触及天花板的时候。

我们大胆假设,要从北京机场传输一路音视频留到上海虹桥机场。我们突破一切物理环境、财力、人力限制,在两地之间搭设了一条笔直的光纤,且保证真空传输(实际上根本不可能)。两地之间距离约为 1061 km。通过计算可知,传输需要约 3.5ms。数据在采集设备与播放设备端需要的采集、编解码处理与播放缓冲延时计为较高的值,30ms。那么端到端的延时大概需要 33.5ms。请注意,我们在这里还忽略了音视频文件本身、系统、光的衰减等因素带来的影响。

所以,所谓“超低延时”也会遇到瓶颈。在任何实验环境下都可以达到很低的延时,但是到实际环境中,要考虑边缘节点的部署、主干网络拥塞、弱网环境、设备性能、系统性能等问题,实际延时会更大。在一定的网络条件限制下,针对不同场景选择低延时方案或技术选型时,就需要围绕延时、卡顿、音频质量、视频清晰度等指标进行权衡与判断。



作者:声网Agora

链接:https://juejin.im/post/6844903601043669000

来源:掘金

著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。


推荐阅读
  • 这是原文链接:sendingformdata许多情况下,我们使用表单发送数据到服务器。服务器处理数据并返回响应给用户。这看起来很简单,但是 ... [详细]
  • 图解redis的持久化存储机制RDB和AOF的原理和优缺点
    本文通过图解的方式介绍了redis的持久化存储机制RDB和AOF的原理和优缺点。RDB是将redis内存中的数据保存为快照文件,恢复速度较快但不支持拉链式快照。AOF是将操作日志保存到磁盘,实时存储数据但恢复速度较慢。文章详细分析了两种机制的优缺点,帮助读者更好地理解redis的持久化存储策略。 ... [详细]
  • 本文介绍了Web学习历程记录中关于Tomcat的基本概念和配置。首先解释了Web静态Web资源和动态Web资源的概念,以及C/S架构和B/S架构的区别。然后介绍了常见的Web服务器,包括Weblogic、WebSphere和Tomcat。接着详细讲解了Tomcat的虚拟主机、web应用和虚拟路径映射的概念和配置过程。最后简要介绍了http协议的作用。本文内容详实,适合初学者了解Tomcat的基础知识。 ... [详细]
  • 本文介绍了南邮ctf-web的writeup,包括签到题和md5 collision。在CTF比赛和渗透测试中,可以通过查看源代码、代码注释、页面隐藏元素、超链接和HTTP响应头部来寻找flag或提示信息。利用PHP弱类型,可以发现md5('QNKCDZO')='0e830400451993494058024219903391'和md5('240610708')='0e462097431906509019562988736854'。 ... [详细]
  • macOS Big Sur全新设计大版本更新,10+个值得关注的新功能
    本文介绍了Apple发布的新一代操作系统macOS Big Sur,该系统采用全新的界面设计,包括图标、应用界面、程序坞和菜单栏等方面的变化。新系统还增加了通知中心、桌面小组件、强化的Safari浏览器以及隐私保护等多项功能。文章指出,macOS Big Sur的设计与iPadOS越来越接近,结合了去年iPadOS对鼠标的完善等功能。 ... [详细]
  • 恶意软件分析的最佳编程语言及其应用
    本文介绍了学习恶意软件分析和逆向工程领域时最适合的编程语言,并重点讨论了Python的优点。Python是一种解释型、多用途的语言,具有可读性高、可快速开发、易于学习的特点。作者分享了在本地恶意软件分析中使用Python的经验,包括快速复制恶意软件组件以更好地理解其工作。此外,作者还提到了Python的跨平台优势,使得在不同操作系统上运行代码变得更加方便。 ... [详细]
  • 本文介绍了C#中生成随机数的三种方法,并分析了其中存在的问题。首先介绍了使用Random类生成随机数的默认方法,但在高并发情况下可能会出现重复的情况。接着通过循环生成了一系列随机数,进一步突显了这个问题。文章指出,随机数生成在任何编程语言中都是必备的功能,但Random类生成的随机数并不可靠。最后,提出了需要寻找其他可靠的随机数生成方法的建议。 ... [详细]
  • [译]技术公司十年经验的职场生涯回顾
    本文是一位在技术公司工作十年的职场人士对自己职业生涯的总结回顾。她的职业规划与众不同,令人深思又有趣。其中涉及到的内容有机器学习、创新创业以及引用了女性主义者在TED演讲中的部分讲义。文章表达了对职业生涯的愿望和希望,认为人类有能力不断改善自己。 ... [详细]
  • 解决Cydia数据库错误:could not open file /var/lib/dpkg/status 的方法
    本文介绍了解决iOS系统中Cydia数据库错误的方法。通过使用苹果电脑上的Impactor工具和NewTerm软件,以及ifunbox工具和终端命令,可以解决该问题。具体步骤包括下载所需工具、连接手机到电脑、安装NewTerm、下载ifunbox并注册Dropbox账号、下载并解压lib.zip文件、将lib文件夹拖入Books文件夹中,并将lib文件夹拷贝到/var/目录下。以上方法适用于已经越狱且出现Cydia数据库错误的iPhone手机。 ... [详细]
  • 本文介绍了高校天文共享平台的开发过程中的思考和规划。该平台旨在为高校学生提供天象预报、科普知识、观测活动、图片分享等功能。文章分析了项目的技术栈选择、网站前端布局、业务流程、数据库结构等方面,并总结了项目存在的问题,如前后端未分离、代码混乱等。作者表示希望通过记录和规划,能够理清思路,进一步完善该平台。 ... [详细]
  • 如何在服务器主机上实现文件共享的方法和工具
    本文介绍了在服务器主机上实现文件共享的方法和工具,包括Linux主机和Windows主机的文件传输方式,Web运维和FTP/SFTP客户端运维两种方式,以及使用WinSCP工具将文件上传至Linux云服务器的操作方法。此外,还介绍了在迁移过程中需要安装迁移Agent并输入目的端服务器所在华为云的AK/SK,以及主机迁移服务会收集的源端服务器信息。 ... [详细]
  • Android工程师面试准备及设计模式使用场景
    本文介绍了Android工程师面试准备的经验,包括面试流程和重点准备内容。同时,还介绍了建造者模式的使用场景,以及在Android开发中的具体应用。 ... [详细]
  • 基于Socket的多个客户端之间的聊天功能实现方法
    本文介绍了基于Socket的多个客户端之间实现聊天功能的方法,包括服务器端的实现和客户端的实现。服务器端通过每个用户的输出流向特定用户发送消息,而客户端通过输入流接收消息。同时,还介绍了相关的实体类和Socket的基本概念。 ... [详细]
  • 上图是InnoDB存储引擎的结构。1、缓冲池InnoDB存储引擎是基于磁盘存储的,并将其中的记录按照页的方式进行管理。因此可以看作是基于磁盘的数据库系统。在数据库系统中,由于CPU速度 ... [详细]
  • 本文介绍了使用数据库管理员用户执行onstat -l命令来监控GBase8s数据库的物理日志和逻辑日志的使用情况,并强调了对已使用的逻辑日志是否及时备份的重要性。同时提供了监控方法和注意事项。 ... [详细]
author-avatar
年轮033
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有