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

一、概述

网络基础设施升级、音视频传输技术迭代、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.mzph.cn/news/100346.shtml

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

相关文章

Doris 2.0.1 DockerFile版 升级实战

Doris 2.0.1 DockerFile版 升级实战

1、Doris 2.0.1 DockerFile 的制作 参考 Doris 2.0.1 Dockerfile制作-CSDN博客 2、之前的Doris 集群通过 Docker容器进行的部署，需提前准备好Doris2.0.1的镜像包 参考： 集群升级 - Apache Doris Doris 升级请遵守不要跨两个及以上关键节点版本升级的…
阅读更多...
Unix Network Programming Episode 78

Unix Network Programming Episode 78

‘getaddrinfo’ Function The gethostbyname and gethostbyaddr functions only support IPv4. The API for resolving IPv6 addresses went through several iterations, as will be described in Section 11.20(See 8.9.20); the final result is the getaddrinfo function…
阅读更多...
ansible部署二进制k8s

ansible部署二进制k8s

简介 GitHub地址： https://github.com/chunxingque/ansible_install_k8s 本脚本通过ansible来快速安装和管理二进制k8s集群；支持高可用k8s集群和单机k8s集群地部署；支持不同版本k8s集群部署，一般小版本的部署脚本基本是通用的。 …
阅读更多...
js文件的入口代码及需要入口代码的原因

js文件的入口代码及需要入口代码的原因

1 在js解释器解释代码时，是从上往下逐条执行的，但是在js文件中，存在许多进行页面交互的代码，它们需要获取到当前按钮元素，比如：var btn document.querySelector(button), 如果将js文件写在了页面结…
阅读更多...
java项目实现不停服更新的4种方案（InsCode AI 创作助手）

java项目实现不停服更新的4种方案（InsCode AI 创作助手）

文章目录 1. Blue-Green 部署2. 滚动更新3. 使用负载均衡器4. 灰度发布 在软件开发和维护中，不停机更新是确保应用程序持续可用的关键任务之一。以下是四种常见的不停机更新策略及其示例： 1. Blue-Green 部署 概念： Blue-Green 部署是一种部…
阅读更多...
Jenkins 构建时动态获取参数

Jenkins 构建时动态获取参数

文章目录 问题简介Groovy 脚本配置进阶 问题 在做jenkins项目时，有些参数不是固定写死的，而是动态变化的，这时我们可以用 Active Choices 插件来远程调用参数 问题解决方案：执行构建前使用Groovy Scrip调用本地脚本，…
阅读更多...
点云处理开发测试题目 完整解决方案

点云处理开发测试题目 完整解决方案

点云处理开发测试题目 文件夹中有一个场景的三块点云数据，单位mm。是一个桌子上放了一个纸箱，纸箱上有四个圆孔。需要做的内容是： 1. 绘制出最小外接立方体，得到纸箱的长宽高值。注意高度计算是纸箱平面到桌子平面的距离。 2. 计算出纸箱上的四个圆的圆心坐标和半径，对圆…
阅读更多...
flutter StreamSubscription 订阅者 stream

flutter StreamSubscription 订阅者 stream

当您使用[Stream.listen]收听[Stream]时 则返回[StreamSubscription]对象 List<StreamSubscription?> subscriptions []; overridevoid initState() {super.initState();//subscriptions列表添加两个StreamSubscription。Stream.listen返回StreamSubscription对象subs…
阅读更多...
论文解析——AMD EPYC和Ryzen处理器系列的开创性的chiplet技术和设计

论文解析——AMD EPYC和Ryzen处理器系列的开创性的chiplet技术和设计

ISCA 2021 摘要 本文详细解释了推动AMD使用chiplet技术的挑战&#xff0c;产品开发的技术方案&#xff0c;以及如何将chiplet技术从单处理器扩展到多个产品系列。 正文 这些年在将SoC划分成多个die方面有一系列研究&#xff0c;MCM的概念也在不断更新&#xff0c;AMD吸收了…
阅读更多...
Git基础使用

Git基础使用

Git基础使用 1、git的本质2 Gitlab账号申请、免密设置2.1 申请Gitlab账号2.2 免密设置2.2.1 公钥及私钥路径2.2.2 免密设置 3、常用命令3.1 git全局配置信息3.2 初始化项目3.3 拉取项目 将日常笔记记录上传&#xff0c;方便日常使用翻阅。 1、git的本质 git对待数据更像是一个快…
阅读更多...
【jvm--堆】

【jvm--堆】

文章目录 1. 堆&#xff08;Heap&#xff09;的核心概述2. 图解对象分配过程2.1 Minor GC&#xff0c;MajorGC、Full GC2.1 堆空间分代思想2.3 内存分配策略2.4 TLAB&#xff08;Thread Local Allocation Buffer&#xff09;2.5 堆空间的参数设置2.6 逃逸分析2.7 逃逸分析&…
阅读更多...
MODBUS-RTU通信协议功能码+数据帧解读(博途PLC梯形图代码)

MODBUS-RTU通信协议功能码+数据帧解读(博途PLC梯形图代码)

MODBUS通信详细代码编写，请查看下面相关链接，这篇博客主要和大家介绍MODBUS协议的一些常用功能码和具体数据帧解析，以便大家更好的理解MODBUS通信和解决现场实际问题。 S7-1200PLC MODBUS-RTU通信 博途PLC 1200/1500PLC MODBUS-RTU通讯_博图modbus rtu通讯实例-CSDN博客1、…
阅读更多...
【centos7安装ElasticSearch】

【centos7安装ElasticSearch】

概述 最近工作中有用到ES &#xff0c;当然少不了自己装一个服务器捣鼓。本文的ElasticSearch 的版本&#xff1a; 7.17.3 一、下载 ElasticSearch 点此下载 下载完成后上传至 Linux 服务器&#xff0c;本文演示放在&#xff1a; /root/ 下&#xff0c;进行解压&#xff1…
阅读更多...
Go 复合类型之字典类型介绍

Go 复合类型之字典类型介绍

Go 复合类型之字典类型介绍 文章目录 Go 复合类型之字典类型介绍一、map类型介绍1.1 什么是 map 类型&#xff1f;1.2 map 类型特性 二.map 变量的声明和初始化2.1 方法一&#xff1a;使用 make 函数声明和初始化&#xff08;推荐&#xff09;2.2 方法二&#xff1a;使用复合字…
阅读更多...
边坡安全监测系统的功能优势

边坡安全监测系统的功能优势

随着科技的进步&#xff0c;边坡安全监测系统在各种工程项目中发挥着越来越重要的作用。这款系统通过实时监测垂直、水平位移数据&#xff0c;以折线图的方式显示在监控平台中&#xff0c;为工程人员提供了直观、便捷的监控工具&#xff0c;从而能够及时掌握边坡稳定状况&#…
阅读更多...
Gin 文件上传操作（单/多文件操作）

Gin 文件上传操作（单/多文件操作）

参考地址： 单文件 | Gin Web Framework (gin-gonic.com)https://gin-gonic.com/zh-cn/docs/examples/upload-file/single-file/ 单文件 官方案例： func main() {router := gin.Default()// 为 multipart forms 设置较低的内存限制 (默认是 32 MiB)router.MaxMultipartMem…
阅读更多...
【软件测试】JUnit详解

【软件测试】JUnit详解

文章目录 一. Junit是什么?二.Junit中常见的注解1. Test2. BeforeAll & AfterAll3. BeforeEach & AfterEach4. ParameterizedTest参数化5. Disabled6. Order 三. 测试套件1. 通过class运行测试用例2. 通过包运行测试用例 四. 断言 一. Junit是什么? JUnit是一个用于…
阅读更多...
mac使用python递归删除文件夹下所有的.DS_Store文件

mac使用python递归删除文件夹下所有的.DS_Store文件

import osfolder_path "yourself file path"for root, dirs, files in os.walk(folder_path):for filename in files:if filename .DS_Store:file_path os.path.join(root, filename)os.remove(file_path)print("delete ok")
阅读更多...
通用任务批次程序模板

通用任务批次程序模板

通用批次任务模板 我们总会遇到需要使用批次任务处理问题的场景&#xff0c;任务有很多不同类型的任务&#xff0c;同时这些任务可能都有大致相同&#xff0c;甚至抽象出来共同的执行阶段状态。 任务的执行肯定无法保证一帆风顺&#xff0c;总会在某个时间阶段被打断&#xff…
阅读更多...
Spring Cloud--@RefreshScope动态刷新的注意事项

Spring Cloud--@RefreshScope动态刷新的注意事项

原文网址&#xff1a;Spring Cloud--RefreshScope动态刷新的注意事项_IT利刃出鞘的博客-CSDN博客 简介 本文介绍Spring Cloud的RefreshScope动态刷新的注意事项。 不用RefreshScope也能动态刷新 Spring Cloud的默认实现了动态刷新&#xff0c;不加RefreshScope就能实现动态…
阅读更多...
最新文章

Copyright @ 2022~2023