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

为什么在直播系统源码的流媒体直播的延迟很高

通信技术的发展促进了视频点播和直播业务的兴起,4G和5G网络技术的进步也使得流媒体技术变得越来越重要,但是网络技术并不能解决流媒体直播的高延迟问题&#x

通信技术的发展促进了视频点播和直播业务的兴起,4G 和 5G 网络技术的进步也使得流媒体技术变得越来越重要,但是网络技术并不能解决流媒体直播的高延迟问题,本文不会介绍网络对直播业务的影响,而是会分析直播中常见的现象 — 主播和观众之间能够感觉到的明显网络延迟。除了业务上要求的延迟直播之外,有哪些因素会导致视频直播的延迟这么高呢?

live-streaming

图 1 - 流媒体直播

当观众通过弹幕与主播进行互动时,从我们看到弹幕到得到主播的响应可能要经过 5s 甚至更长的时间,虽然主播看到弹幕的时间与观众看到弹幕的时间不会有太大的差别,但是直播系统将主播的音视频数据传输到客户端或者浏览器需要较长的时间,这个从主播端到观众端传输数据的时间一般被称作端到端的音视频延迟。

流媒体直播从音视频的采集和编码到音视频的解码和播放涉及了非常长的链路,需要途径主播端、流媒体服务器以及观众端,这三方分别提供了不同的功能:

  • 主播端:音视频采集、音视频编码、推流;
  • 流媒体服务器:直播流收集、音视频转码、直播流分发;
  • 观众端:拉流、音视频解码、音视频播放;

在这个冗长的采集和分发流程中,不同过程中都会通过一些技术保证直播的质量,这些为了保证可靠性、降低系统带宽而使用的手段共同造成了直播高延迟的问题。本文会从以下三个方面分析为什么流媒体直播的端到端延迟很高:

  • 音视频使用的编码格式决定了客户端只能从特定帧开始解码;
  • 音视频传输使用的网络协议切片大小决定了客户端接收数据的间隔;
  • 服务器和客户端为了保证用户体验和直播质量预留缓存;

数据编码

视频直播一定会使用音视频的编码技术,目前主流的音频和视频编码方式是高级音频编码(Advanced Audio Coding,AAC)1 和高级视频编码(Advanced Video Coding,AVC)2,AVC 常被称作 H.264。这一节不讨论音频数据的编解码算法,我们来详细分析一下为什么需要 H.264 编码,它又如何影响直播延迟。假设我们需要看一部时长为 2 小时的 1080p、60FPS 的电影,如果每个像素需要 2 字节的存储,那么整部电影需要占用如下所示的资源:

3600∗2∗1920∗1080∗60∗2bytes=1668.54GB

然而在实际情况下,每一部电影占用的磁盘空间只有几百 MB 或者几 GB,这与我们计算出来的结果相差好几个数量级,音视频编码就是起到用于压缩音视频数据,减少占用磁盘和网络带宽的关键技术。

H.264 是用于视频压缩的业界标准,因为视频是由一帧一帧的图片组成的,而不同的图片之间有较强的连续性,H.264 使用关键帧(Intra-coded picture,I 帧)作为视频的全量数据,不断使用向前参考帧(Predicted picture,P 帧)和双向参考帧(Bidirectional predicted picture,B 帧)对全量的数据进行增量式的修改以达到压缩的目的。

h264-frames

图 2 - H.264 压缩视频数据

H.264 会使用 I 帧、P 帧和 B 帧将视频数据压缩成如上图所示的图片序列,这三种不同的视频帧分别起到不同的作用3:

视频帧作用
I 帧类似 JPG 或者 BMP 格式的完整的图片
P 帧可以使用前一个视频帧的数据压缩数据
B 帧可以使用前一个和后一个视频帧压缩数据

压缩后的视频数据是一系列连续的视频帧,客户端在解码视频数据时会先找到视频数据的第一个关键帧,然后增量对关键帧进行修改。如果客户端接收到的第一个视频帧就是关键帧,那么客户端就可以直接播放视频,但是如果客户端错过了关键帧,那么就需要等待下一个关键帧才可以播放视频。

group-of-pictures

图 3 - 视频编码 GOP

图像组(Group of pictures,GOP)指定了视频帧的组织方式,编码的视频流就由连续的 GOP 组成,因为每个 GOP 都会以关键帧开头,所以 GOP 的大小会影响播放端的延迟。视频占用的网络带宽也与 GOP 息息相关,在通常情况下,移动端直播的 GOP 都会被设置成 1 ~ 4 秒,当然我们也可以使用更长的 GOP 降低占用的带宽4。

视频编码中的 GOP 决定了关键帧的间隔,也决定了客户端在找到第一个可以播放的关键帧的时间,进而影响流媒体直播的延迟,这种秒级别的延迟对于视频直播业务来说影响还是比较明显的,GOP 的设置是对视频质量、带宽和延迟权衡的结果。

数据传输

音视频数据传输可以选择使用不同的应用层协议,最常见的两种网络协议是实时消息传输协议(Real Time Messaging Protocol,RTMP)和 HTTP 实时流式传输协议(HTTP Live Streaming,HLS),这两种网络协议分别使用不同的方式传输音视频流,我们可以认为 RTMP 协议基于音视频流分发数据,而 HLS 协议基于文件分发音视频数据。

live-streaming-protoco

图 4 - 流媒体数据传输协议

RTMP 协议是基于 TCP 的应用层协议,它将音视频流切分成片段进行传输,在默认情况下音频数据段的大小为 64 字节,视频数据段的大小是 128 字节5。使用 RTMP 协议时,所有的数据都会块(Chunk)的形式传输:

rtmp-payload

图 5 - RTMP 协议数据块

每个 RTMP 的数据块都包含 1 ~ 18 字节的协议头,协议头由基本协议头(Basic Header)、消息头(Message Header)和扩展时间戳(Extended Timestamp)三个部分组成,除了包含块 ID 和类型的基本协议头之外,其他的两个部分都是可以省略的,进入传输阶段的 RTMP 协议只需要 1 字节的协议头,这也意味着极低的额外开销6。

HLS 协议是苹果在 2009 年发布的基于 HTTP 协议的码率自适应的流媒体网络传输协议7。当播放器获得使用 HLS 协议的拉流地址时,播放器会从拉流地址中获得如下所示的 m3u8 文件:

#EXTM3U
#EXT-X-TARGETDURATION:10#EXTINF:9.009,
http://media.example.com/first.ts
#EXTINF:9.009,
http://media.example.com/second.ts
#EXTINF:3.003,
http://media.example.com/third.ts

m3u8 是一种播放多媒体列表的文件格式8,该文件中包含了一系列的视频流切片,播放器可以根据文件中的描述依次播放各个视频流。HLS 协议将直播流拆分成一个个小的文件并使用 m3u8 组织这些直播片段,当播放器播放直播流时会根据 m3u8 的描述依次播放拆分后的 ts 文件。

m3u8-ts

图 6 - m3u8 和 ts 文件

HLS 协议切分的 ts 文件大小会影响端到端的直播延迟,苹果官方文档推荐使用 6 秒的 ts 切片,这也就意味着从主播到观众的延迟至少会增加 6 秒,使用更短的切分方式并不是不可行,只是会带来巨大的额外开销和存储压力。

虽然所有应用层协议受限于物理设备的 MTU9 都只能分段传输音视频数据,但是不同应用层协议对音视频数据的切分粒度决定了端到端的网络延迟。RTMP 以及 HTTP-FLV 等基于流分发的协议切片粒度很小,延迟在 3s 以下,可以看做实时的传输协议;而 HLS 协议是基于文件分发的协议,它的切片粒度很大,在实际使用中可能会带来 20 ~ 30s 的延迟。

需要注意的是基于文件分发不等价于高延迟,分片的大小才是决定延迟的关键因素,在保证分片小的同时降低额外开销是实时流媒体传输协议需要考虑的问题。

多端缓存

视频直播架构的链路往往都很长,我们不能保证整条链路的稳定性,想要提供流畅的数据传输和用户体验,服务端和和客户端都会增加缓存以应对直播的音视频卡顿。

服务器一般会先缓存一部分直播数据,然后将数据传输至客户端,在网络突然抖动时,服务端可以使用缓存中的数据保证直播流的流畅。当网络状况恢复时,又会重新缓存数据;客户端也会使用预读缓冲区来提高直播的质量。我们可以调小缓冲区增加实时性,但是在网络状况抖动较多时会严重影响客户端的用户体验10。

总结

流媒体直播的高延迟是一个系统性的工程问题,与微信视频等 1 对 1 的实时通信相比,视频流的生产方和消费方之间的链路极长,很多因素都会影响主播和观众的感受,因为带宽的成本、历史的惯性以及网络的不确定,我们只能通过不同的技术解决遇到的问题,而不得不牺牲的就是用户的体验:

  1. 全量的音视频数据过多 — 使用音视频编码会使用关键帧以及增量修改的方式压缩数据,关键帧的间隔 GOP 决定了客户端在播放第一个画面时需要等待的最长时间;
  2. 浏览器对实时流的协议支持不够 — 使用 HLS 协议基于 HTTP 对直播的切片进行分发,这会为主播和观众带来 20 ~ 30s 的直播延迟;
  3. 链路过长带来的不确定性 — 服务器和客户端使用缓存减少网络抖动对直播质量造成的显著影响;

上述的这些因素都会影响直播系统的端到端延迟,在一个正常的直播系统中使用 RTMP 和 HTTP-FLV 可以达到 3s 以下的延迟,不过 GOP 以及多端缓存都会影响这一指标,延迟在 10s 以内都是很正常的。


推荐阅读
  • FastDFS Nginx 扩展模块的源代码解析与技术剖析
    FastDFS Nginx 扩展模块的源代码解析与技术剖析 ... [详细]
  • 为了评估精心优化的模型与策略在实际环境中的表现,Google对其实验框架进行了全面升级,旨在实现更高效、更精准和更快速的在线测试。新的框架支持更多的实验场景,提供更好的数据洞察,并显著缩短了实验周期,从而加速产品迭代和优化过程。 ... [详细]
  • TypeScript 实战分享:Google 工程师深度解析 TypeScript 开发经验与心得
    TypeScript 实战分享:Google 工程师深度解析 TypeScript 开发经验与心得 ... [详细]
  • 利用CSV Data Set Config实现JMeter参数化测试的详细指南
    本文详细介绍了如何使用JMeter中的CSV Data Set Config元素来实现参数化测试。通过该配置元件,用户可以轻松地从外部CSV文件中读取数据,从而提高测试的灵活性和可扩展性。文章不仅提供了具体的配置步骤,还结合实际案例,展示了如何在不同的测试场景中应用这一功能,帮助读者更好地理解和掌握JMeter参数化测试的技巧。 ... [详细]
  • 经过半年的精心整理,我们汇总了当前市场上最全面的Android面试题解析,为移动开发人员的晋升和加薪提供了宝贵的参考资料。本书详细涵盖了从基础到高级的各类面试题,帮助读者全面提升技术实力和面试表现。章节目录包括:- 第一章:Android基础面试题- 第二章:... ... [详细]
  • 利用树莓派畅享落网电台音乐体验
    最近重新拾起了闲置已久的树莓派,这台小巧的开发板已经沉寂了半年多。上个月闲暇时间较多,我决定将其重新启用。恰逢落网电台进行了改版,回忆起之前在树莓派论坛上看到有人用它来播放豆瓣音乐,便萌生了同样的想法。通过一番调试,终于实现了在树莓派上流畅播放落网电台音乐的功能,带来了全新的音乐享受体验。 ... [详细]
  • Zookeeper作为Apache Hadoop生态系统中的一个重要组件,主要致力于解决分布式应用中的常见数据管理难题。它提供了统一的命名服务、状态同步服务以及集群管理功能,有效提升了分布式系统的可靠性和可维护性。此外,Zookeeper还支持配置管理和临时节点管理,进一步增强了其在复杂分布式环境中的应用价值。 ... [详细]
  • 【Linux进阶指南】第一阶段第三课:体验与部署Ubuntu系统
    在正式踏上Linux学习之旅之前,本课程将引导你深入体验和部署Ubuntu系统。通过详细的操作步骤和实践演练,你将掌握Ubuntu的基本安装、配置及常用命令,为后续的进阶学习打下坚实的基础。此外,课程还将介绍如何解决常见问题和优化系统性能,帮助你更加高效地使用Ubuntu。 ... [详细]
  • 本文源自极分享,详细内容请参阅原文。技术债务如同信用卡负债,随着时间推移,修复成本会越来越高,因此程序员必须对此有深刻认识。此外,团队应致力于培养一种持续维护和优化代码的文化,以减少技术债务的累积。 ... [详细]
  • JBPM 6.5 环境配置深入解析(下篇)
    本文深入探讨了JBPM 6.5 的环境配置细节,从零开始详细介绍了下载、解压后的文件结构,并结合实际操作步骤,为初学者提供了全面的配置指南。通过具体的示例和详细的解释,帮助读者快速掌握 JBPM 6.5 的安装与配置过程。 ... [详细]
  • 揭秘腾讯云CynosDB计算层设计优化背后的不为人知的故事与技术细节
    揭秘腾讯云CynosDB计算层设计优化背后的不为人知的故事与技术细节 ... [详细]
  • Go 项目中数据库配置文件的优化与应用 ... [详细]
  • 如果程序使用Go语言编写并涉及单向或双向TLS认证,可能会遭受CPU拒绝服务攻击(DoS)。本文深入分析了CVE-2018-16875漏洞,探讨其成因、影响及防范措施,为开发者提供全面的安全指导。 ... [详细]
  • 深入解析Spring Boot启动过程中Netty异步架构的工作原理与应用
    深入解析Spring Boot启动过程中Netty异步架构的工作原理与应用 ... [详细]
  • Android 网络请求中的下载断点续传技术解析与实现
    本文详细解析了 Android 平台下网络请求中下载断点续传的技术原理与实现方法。断点续传技术在下载过程中尤为重要,当下载因网络中断或其他原因暂停时,该技术允许从上次中断的位置继续下载,而无需重新开始。文章重点介绍了断点续传的逻辑思路和关键实现步骤,包括如何记录下载进度、处理 HTTP 请求头以及优化下载性能。通过具体示例代码,读者可以更好地理解和应用这一技术,提高应用程序的用户体验和可靠性。 ... [详细]
author-avatar
洪凤兴惠婷
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有