超低延时直播技术演进之路-进化篇

news2024/11/17 8:28:26

一、概述

网络基础设施升级、音视频传输技术迭代、WebRTC 开源等因素，驱动音视频服务时延逐渐降低，使超低延时直播技术成为炙手可热的研究方向。实时音视频业务在消费互联网领域蓬勃发展，并逐渐向产业互联网领域加速渗透。经历了行业第一轮的红利爆发期，我国实时音视频行业的场景效能逐渐深化，步入到理性增长阶段。

延时的指标选择很大程度上取决于用户与内容制作方的交互耦合程度，场景丰富多样。

image.png

在这些极端场景下，延时在用户侧希望越小越好，接近于实时通信的低延迟模式可以最大化地激发用户的参与感，无缝地与内容生产方产生互动效应，调动用户所见即所得的积极性。比如在主播秀场的 PK 、送礼、工会冲榜、打赏的活动关键环节，竞争双方的储值大户都希望实时地观察到自身主播在礼物刷榜后的反应，为后台运营决策团队或者后续活动策略提供第一时间的信息反馈。

下图体现了从技术/产品/运营的三方角度来综合思考低延时直播技术的作用；从外部-内部综合因素考虑技术的变迁对整个生态正向循环的影响。

image.png

二、传统标准直播技术的局限性

2.1 RTMP 协议的延迟问题

RTMP 协议是最传统的直播协议，主播端采用 RTMP 协议推送 H.264/5 和 AAC 编码的视音频数据到云厂商 CDN 服务器进行转封装分发，端到端延迟一般控制在 3 到 7 秒。问题是 RTMP 的可扩展性存在缺陷，同时对于延迟的进一步下探存在一定的技术困难。RTMP 协议情况下：为了满足延时降低必然压缩播放器的下载缓冲区，这样会引发显著的卡顿问题，使得播放的观感产生不舒适的感受（延时下探至 2 秒以下）。

image.png

2.2 传统直播技术在实时互动场景中的不足

比较典型的有以下一些不足：

  1. 视频延时和弹幕交互的延时存在显著差异，问题聊天内容互动与视频传输图像节奏不匹配。

image.png

  1. 观众与主播互动形式单一，是单向内容传导无法做到双向（在 RTC 技术引入之前无法显著解决）。
  2. 单向传导的局限第一个方面表现在：观众端拉流传输无法做到根据网络情况自适应调节。用户只能以固定的码率进行流媒体传输无法做到动态感知，在网络情况实时变化的场景（比如弱网，移动基站切换等）固定单向码率传输有较大概率造成丢帧卡顿等因素影响观播体验；另一方面在网络条件更好时，固定码率传输无法动态提升视频传输码率（更高的画质带来更加舒适的体验）。
  3. 在直播和连麦场景共存的互动直播场景下，主播采用传统 RTMP 推流在遇到连麦 PK 场景时，会产生推流/本地连麦合流/服务器连麦合流的切换问题，这种场景变换的切换会使得观众端产生瞬间的卡顿问题；如果采用基于 webRTC 直播技术的超低延时直播方案，这种推流–连麦逻辑的合流切换问题可以得到比较友好的解决（只需要改变服务器转发-订阅流通道的分发逻辑，不涉及推流媒体数据流的旁路调度切换）。

2.3 超低延时直播与标准直播的区别

  1. 超低延时直播是近年来新兴起的一类应用。如电商直播、赛事直播等场景，兼具高并发与低延时的特性，传统直播 3-20s 的时延难以满足其需求，但对实时互动的要求又不及视频会议等典型的实时音视频应用，无需将时延降低至 400ms 以下。 为此，超低延时直播融合了传统直播与实时音视频的技术架构，通过取长补短的方式实现了介于二者之间的端到端时延。 尽管针对超低延时直播厂商尚无一套标准的技术路径，但大体可以归纳为拉流协议、网络架构和推流协议三个方面的改造， 在实际应用过程中，厂商会平衡成本及性能指标等因素，在不同的协议和网络架构之间进行选择。
  2. 传输层协议的差异 （基于 UDP 协议的可靠性优化，为弱网对抗策略提供依据）。

传统直播 FLV/RTMP 等采用的是 TCP 协议（或者 QUIC 协议）TCP 是牺牲传输实时性来换取数据完整性的可靠传输协议。弱网环境下，其在数据传输前的“三次 握手”连接会带来较大延时。而 UDP 作为不可靠的传输协议，其最大的优点为高实时性，但不保证数据的到达和排序。 实时音视频产品（如 RTM 超低延时直播）往往采用 UDP 协议，并在此之上进行协议层与算法层的优化，来提高传输的可靠性与逻辑性。

  1. UDP 协议的优化

UDP 协议往往和 RTP/RTCP 协议一起在实际应用中出现。RTP 负责数据传输，其协议头中的序列号、 端口类型、时间戳等字段，可为数据包的分组、组装、排序提供逻辑依据；RTCP 作为 RTP 的控制协议，负责对 RTP 的传输质量进行统计反馈，并为弱网对抗策略提供控制参数。

image.png

三、超低延时直播技术的演进历程

（1）基于业务场景发展的直播技术演进过程（延迟主线）

（2）RTM 协议本身的演进历程

  • miniSDP 信令标准实现部分（抖音)
  • CDN 信令异步回源
  • RTP 携带扩展头组成部分
 a=extmap:18 "http://www.webrtc.org/experiments/rtp-hdrext/decoding-timestamp"
a=extmap:19 "uri:webrtc:rtc:rtp-hdrext:video:CompositionTime"
a=extmap:21 "uri:webrtc:rtc:rtp-hdrext:video:frame-seq-range"
a=extmap:22 "uri:webrtc:rtc:rtp-hdrext:video:frame-type"
a=extmap:23 "uri:webrtc:rtc:rtp-hdrext:video:reference-frame-timestamp"
a=extmap:27 "uri:webrtc:rtc:rtp-hdrext:audio:aac-config"
  • a=extmap:18 “http://www.webrtc.org/experiments/rtp-hdrext/decoding-timestamp”
  • a=extmap:19 “uri:webrtc:rtc:rtp-hdrext:video:CompositionTime”

RTP 使用 RTP 私有扩展头携带 DTS/CTS 值，每一帧 RTP 数据包通过 RFC5285-Header-Extension 扩展头携带该帧的 DTS 值，每一帧首个 RTP 包和 VPS/SPS/PPS 包通过 RFC5285-Header-Extension 扩展头携带该帧的 CTS 值，通过 PTS = DTS + CTS 计算当前帧的时间戳。用于启播快速音画同步和播放器播控逻辑精准音画同步。

  • a=extmap:21 uri:webrtc:rtc:rtp-hdrext:video:frame-seq-range

扩展头携带帧的起始/结束序号：如果首帧的前几个包丢失，那么可根据起始序号快速发起重传加快首帧；如果当前帧的后几个包丢失，那么可根据该帧的结束序号快速发起重传，降低延时，减少卡顿。

  • a=extmap:22 uri:webrtc:rtc:rtp-hdrext:video:frame-type

扩展头携带帧的类型：如果携带并解析了正确的帧类型，客户端可以不用解析 metadata ；同时在弱网情形，客户端可以跳过 B 帧直接解码 P 帧，加速出帧并减少潜在卡顿。

  • a=extmap:23 uri:webrtc:rtc:rtp-hdrext:video:reference-frame-timestamp

扩展头携带 P 帧的参考帧信息：如果发生弱网情形，那么客户端可以依照扩展头指定的参考帧关系及其对应时间戳，跳过 B 帧解码，减少卡顿发生。

  • a=extmap:27 uri:webrtc:rtc:rtp-hdrext:audio:aac-config

为了加速信令交互的速度，CDN 可以在某些条件下不去查询媒体信息，直接向客户端返回支持的音视频能力；此时 SDP 的媒体描述中将不包含有具体的音视频配置详细信息。在音频层面，此时 AnswerSDP 中不包含 aac 解码所需的头信息；此时我们需要采取 RTP 扩展头模式携带 AAC-Config 供客户端在 RTP 收包时刻自行解析处理完成解码动作，作用是减少信令交互时间，提升拉流成功率。

3.1 WebRTC 协议在直播播放器的移植

RTM 低延时直播基于 WebRTC 技术衍生，基于 WebRTC 标准构建点到点传输一般有如下几个步骤：

（1）通信双方要进行媒体协商，会话详细规范即 SDP(Session Description Protocol) 交互；

（2）随后进行交互式网络地址协商（查询对端真实 IP 地址）准备构建媒体传输通道；

（3）当上述条件准备完毕即进入最终的 Peer to Peer 点对点媒体数据传输。

image.png

信令部分客户端-服务器单独开发，利用了 SDP 标准报文模式；媒体传输部分采用开源的 WebRTC 框架和自截自研的实时音视频媒体引擎进行媒体传输。

3.2 RTC 信令协议的改造升级（ MiniSDP 压缩协议）

参考链接：https://github.com/zhzane/mini_sdp

image.png

经过升级后的miniSDP协议具有如下优势：

  • 标准 SDP 比较冗长（ 5-10KB 左右），不利于快速高效传输。在直播场景下，会尤其影响首帧时间。MiniSDP 对标准 SDP 文本协议进行高效能压缩，将原生 SDP 转换成更小的二进制格式，使其能够通过一个 UDP 包来传输。
  • 降低信令交互时间，提高网络传输效能，降低直播拉流首帧渲染时间，提高拉流秒开率/成功率等 QoS 统计指标。

数据参考下表：

播放协议RTM-HTTP信令RTM-MiniSDP信令FLV
首帧时间（预览）600ms510ms350ms
拉流成功率（预览）97.50%98.00%98.70%

3.3 CDN 对 RTM 信令的异步回源优化

  • 降低 RTM 信令交互时间，降低 RTM 拉流首帧渲染时间。
  • 原来的流程在服务端缓存不命中时需要等待回源拿到数据，才能返回带有 AacConfig 信息的 AnswerSDP。客户端收到 AnswerSDP 后发送 STUN，而服务端只能在收到 STUN 才能开始下发数据。（如下图左）；当异步回源情况下：服务端不再等待回源结果直接返回 AnswerSDP，之后回源和 WebRTC 建连流程同步进行。等到 WebRTC 建连成功且回源拿到数据立即下发 RTP 数据。（如下图右）

image.png

3.4 视频渲染卡顿的优化（百秒卡顿平均降低 4 秒）

改善人均看播时长，改变 RTC 引擎的组帧/解码策略；禁止 RTC 在低延时模式下的丢帧，改善直播的视频渲染卡顿。

实验组视频渲染百秒卡顿（直播间场景）
RTM默认JitterBuffer策略8.3s
RTM改进的JitterBuffer非丢帧策略3.6s

传统的 RTC 场景优先保时延，全链路会触发各种丢帧（包括但不限于解码模块，网络模块），FLV 直播场景会优先保证观播体验（不丢帧，良好的音画同步效果）。RTM 要想减少卡顿，取得 qoe 的收益，播控策略需进行定制化 , 定制逻辑修改点：

  • 确保不会由于软解的解码耗时或者硬解的 dequeuinputbuffer 等其它 api 操作阻塞 jitterbuffer ，内核层有一层强制的音画同步逻辑，可以确保音视频的播放体验；
  • 同时上层在监控网络模块和解码模块的缓存长度，有相应的兜底逻辑：a，判断硬解确实解不过来，dec_cache_frames 过多，上报错误，会降级到软解；b，jitterbuffer 异常，缓存的 frame_list 过多，触发播放器异常逻辑，上报错误，重新拉流。

image.png

3.5 RTM 播控逻辑的优化

  • 改善移动端看播渗透，RTC 统一内核方案天生存在缺陷（ MediaCodec 硬件解码器初始化耗时久）；将 RTM 视频解码模块从 RTC 内核中迁移至 TTMP 播放内核，复用了 FLV 的视频解码模块（ MediaCodec 避免重新初始化）；显著的降低了安卓平台的首帧渲染时间，提升了拉流的成功率。
  • RTC 内核通用逻辑

image.png

  • 改进的 RTM 内核播控逻辑

image.png

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/1077749.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

并发、并行、同步、异步、阻塞、非阻塞

并发、并行、同步、异步、阻塞、非阻塞

一、多核、多cpu （一）多核 Multicore 核是CPU最重要的部分。负责运算。核包括控制单元、运算单元、寄存器等单元。 多核就是指单个CPU中有多个核。 （二）多cpu Multiprocessor 多cpu就是一个系统拥有多个CPU。每个CPU可能有单个核…
阅读更多...
JSON数据处理工具-在线工具箱网站tool.qqmu.com的使用指南

JSON数据处理工具-在线工具箱网站tool.qqmu.com的使用指南

导语：无论是处理JSON数据、进行文本数字处理、解码加密还是使用站长工具，我们都希望能够找到一个功能强大、简便易用的在线平台。tool.qqmu.com作为一款瑞士军刀般的在线工具箱网站，满足了众多用户的需求。本文将介绍tool.qqmu.com的多项功能…
阅读更多...
Infinity同步

Infinity同步

阅读更多...
短视频矩阵系统seo源码saas开发---一手源头

短视频矩阵系统seo源码saas开发---一手源头

一套优秀的短视频全链条获客系统，支持抖音获客seo排名、抖音SEO优化的系统应该如何开发，应该具备哪些功能？今天小编就跟大家分享一下我们的开发思路。 首先，目前公认的、抖音短视频seo优化方向，SaaS源码，系…
阅读更多...
VIT(Vision Transformer)学习-模型理解（一）

VIT(Vision Transformer)学习-模型理解（一）

VIT (Vision Transformer) 模型论文代码(源码)从零详细解读，看不懂来打我_哔哩哔哩_bilibili VIT模型架构图 1.图片切分为patch 2. patch转化为embedding 1）将patch展平为一维长度 2）token embedding：将拉平之后的序列映射…
阅读更多...
初识 C语言文件操作

初识 C语言文件操作

目录 前言： 为什么我们要使用文件？ 什么是文件？ 程序文件： 数据文件： 文件名： 文件的打开和关闭 文件指针： 流程： 文件路径： 文件的顺序读写： …
阅读更多...
我用PYQT5做的第一个实用的上位机项目（六）

我用PYQT5做的第一个实用的上位机项目（六）

将之前的画面和代码用复制粘贴的方法复制四份，就完成了整个主画面和主程序的基本构建。 下面的工作是关于PLC和通信。 上位机项目，其与PLC通信的模式很多都是这样的：在没有操作和设置的平常显示界面，按照预定周期从PLC读取当前页…
阅读更多...
一个命令让redis服务端所有信息无所遁形~(收藏吃灰系列)

一个命令让redis服务端所有信息无所遁形~(收藏吃灰系列)

Redis服务器是一个事件驱动程序，它主要处理两类事件：文件事件和时间事件。这些事件的处理和Redis命令的执行密切相关。下面我将以Redis服务端命令为切入点，深入解析其工作原理和重要性。 首先，我们先了解Redis服务端有哪些命令。…
阅读更多...
linux 安装下载conda并创建虚拟环境

linux 安装下载conda并创建虚拟环境

目录 1. 下载安装2. 创建虚拟环境1. 下载安装 在window操作系统中下载anconda包，并通过scp传输到ubuntu操作系统 具体anconda包在如下界面： anconda包 目录 博主选择了最新的包：Anaconda3-2023.09-0-Linux-x86_64.sh 通过scp传输到ubuntu操作系统中： 并在ubuntu操作系…
阅读更多...
共模电感有什么作用与选型技巧？|深圳比创达EMC

共模电感有什么作用与选型技巧？|深圳比创达EMC

共模电感(Common mode Choke)，也叫共模扼流圈，常用于电脑的开关电源中过滤共模的电磁干扰信号。在板卡设计中，共模电感也是起EMI滤波的作用，用于抑制高速信号线产生的电磁波向外辐射发射。 如图1，共模电感的简化模型&…
阅读更多...
【每日一记】OSPF区域划分详讲、划分区域的优点好处

【每日一记】OSPF区域划分详讲、划分区域的优点好处

个人名片： 🐼作者简介：一名大二在校生，喜欢编程🎋 🐻‍❄️个人主页🥇：小新爱学习. 🐼个人WeChat：hmmwx53 🕊️系列专栏：&#x1f5bc…
阅读更多...
springboot项目中后台文件上传处理

springboot项目中后台文件上传处理

参考地址：http://www.gxcode.top/code 文件上次核心处理代码： @Autowired private FileUpload fileUpload; //获取资源对象：file-upload-prod.properties@ApiOperation(value = "用户头像修改", notes = "用户头像修改", httpMethod =
阅读更多...
IDEA的使用（三）Debug（断点调试）（IntelliJ IDEA 2022.1.3版本）

IDEA的使用（三）Debug（断点调试）（IntelliJ IDEA 2022.1.3版本）

编程过程中如果出现错误，需要查找和定位错误时，借助程序调试可以快速查找错误。 编写好程序后，可能出现的情况： 1.没有bug。 使用Debug的情况： 2.运行后，出现错误或者异常信息，但是通过日志文件…
阅读更多...
【置顶】关于博客的一些公告

【置顶】关于博客的一些公告

所谓 万事开头难，最开始的两个专栏 《微机》 和 《骨骼动作识别》 定价 29.9 ，因为： 刚开始确实比较困难，要把自己学的知识彻底搞懂讲给别人，还要 码字排版，从 Markdown 语法开始学起（这都是 花…
阅读更多...
林沛满-TCP 是如何避免被发送方分片的？

林沛满-TCP 是如何避免被发送方分片的？

TCP 可以避免被发送方分片，是因为它主动把数据分成小段再交给网络层。最大的分段大小称为 MSS（Maximum Segment Size），它相当于把 MTU 刨去 IP头和 TCP 头之后的大小，所以一个 MSS 恰好能装进一个 MTU 中。 图4 图 4 …
阅读更多...
『Linux项目自动化构建工具』make/Makefile

『Linux项目自动化构建工具』make/Makefile

前言 如题可知,make/Makefile为在Linux下的项目自动化构建工具; 在上一篇文章『Linux - gcc / g』c程序翻译过程 中讲解了C/C程序的翻译过程; 而make/Makefile即可以看成,是Makefile在使用gcc/g使在Linux环境下能够更好的高效率的进行项目构建; 在此之前首先要对make/Makefile…
阅读更多...
Http请求响应 Ajax 过滤器

Http请求响应 Ajax 过滤器

10/10/2023 近期总结： 最近学的后端部署，web服务器运行，各种请求响应，内容很多，学的很乱，还是需要好好整理，前面JavaSE内容还没有完全掌握，再加上一边刷题，感觉压力很大哈…
阅读更多...
归纳所猜半结论推出完整结论：CF1592F1

归纳所猜半结论推出完整结论：CF1592F1

https://www.luogu.com.cn/problem/CF1592F1 场上猜了个结论，感觉只会操作1。然后被样例1hack了。然后就猜如果 ( n , m ) (n,m) (n,m) 为1则翻转4操作，被#14hack了。然后就猜4操作只会进行一次，然后就不知道怎么做下去了。 上面猜的结论都…
阅读更多...
Multi-Grade Deep Learning for Partial Differential Equations

Multi-Grade Deep Learning for Partial Differential Equations

论文阅读：Multi-Grade Deep Learning for Partial Differential Equations with Applications to the Burgers Equation Multi-Grade Deep Learning for Partial Differential Equations with Applications to the Burgers Equation符号定义偏微分方程定义FNN定义PI…
阅读更多...
iceberg简介004_iceberg和其他数据湖框架的对比---​​数据湖Apache Iceberg工作笔记0004

iceberg简介004_iceberg和其他数据湖框架的对比---​​数据湖Apache Iceberg工作笔记0004

然后来看一下iceberg和其他数据湖框架的对比这里可以看到hudi支持的多一点对吧,但是 iceberg有自己的优势,并且他们都支持timeline 也就是时间旅行对吧. 然后这个图是显示了,数据湖三剑客的开源时间,以及火热程度,可以对比一下看看.
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023