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

一、概述

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

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

相关文章

```，```中间添加 # + 空格 + 空行后遇到的底部空行出错，书接上回，处理空行

```，```中间添加 # + 空格 + 空行后遇到的底部空行出错，书接上回，处理空行

【python查找替换：查找空行，空行前后添加，中间添加 # 空格 空行后遇到的第1行文字？ - CSDN App】http://t.csdnimg.cn/QiKCV def is_blank(line):return len(line.strip()) 0txt 时间戳： ("%Y-%m-%d %H:%M:…
阅读更多...
【排序算法】插入排序

【排序算法】插入排序

文章目录 一：基本概念1.1 介绍1.2 原理1.3 插入排序法思想 二：代码实现2.1 源码2.2 执行结果2.3 测试八万条数据 三：算法分析3.1 时间复杂度3.2 空间复杂度3.3 稳定性 一：基本概念 1.1 介绍 插入式排序属于内部排序法&#xff0…
阅读更多...
Xcode 15下，包含个推的项目运行时崩溃的处理办法

Xcode 15下，包含个推的项目运行时崩溃的处理办法

升级到Xcode15后，部分包含个推的项目在iOS17以下的系统版本运行时，会出现崩溃，由于崩溃在个推Framework内部，无法定位到具体代码，经过和个推官方沟通，确认问题是项目支持的最低版本问题。 需要将项目的最低…
阅读更多...
K8S：K8S对外服务之Ingress

K8S：K8S对外服务之Ingress

文章目录 一.Ingress基础介绍1.Ingress概念2.K8S对外暴露服务（service）主要方式（1）NodePort（2）LoadBalancer（3）externalIPs（4）Ingress 3.Ingress 组成&#x…
阅读更多...
计算机网络 | OSI 参考模型

计算机网络 | OSI 参考模型

计算机网络 | OSI 参考模型 计算机网络 | OSI 参考模型应用层表示层会话层传输层网络层数据链路层物理层 参考视频：王道计算机考研 计算机网络 参考书：《2022年计算机网络考研复习指导》 计算机网络 | OSI 参考模型 OSI 参考模型自下而上分为7层&…
阅读更多...
Redis 学习笔记

Redis 学习笔记

文章目录 一、基础命令1.1 通用命令1.2 String1.3 Hash1.4 List1.5 Set1.6 SortedSet 二、Redis 和数据库的数据一致性三、缓存穿透四、缓存雪崩五、缓存击穿 一、基础命令 1.1 通用命令 KEYS pattern 查找所有符合给定模式 pattern 的 key，其中 * 匹配零个或多个…
阅读更多...
【Golang】gin框架入门

【Golang】gin框架入门

文章目录 gin框架入门认识gingo流行的web框架gin介绍快速入门 路由RESTful API规范请求方法URI处理函数分组路由 请求参数GET请求参数POST请求参数路径参数文件参数 响应字符串方式JSON方式XML方式文件格式设置HTTP响应头重定向YAML方式 模板渲染基本使用多个模板渲染自定义模板…
阅读更多...
Qt中QTimer定时器的用法

Qt中QTimer定时器的用法

Qt中提供了两种定时器的方式一种是使用Qt中的事件处理函数，另一种就是Qt中的定时器类QTimer。 使用QTimer类，需要创建一个QTimer类对象，然后调用其start()方法开启定时器，此后QTimer对象就会周期性的发出timeout()信号。 1.QTimer…
阅读更多...
VMware centos7虚拟机修改静态IP

VMware centos7虚拟机修改静态IP

一、修改网络适配器 1、打开 2、使用管理员权限修改 3、按照图中步骤修改为 4、设置网关为10.0.0.2后保存即可 二、修改配置文件 1、输入下面代码进入修改（网卡这里网卡名字为ens33，可使用ifcfig或ip a查看） vi /etc/sysconfig/netwo…
阅读更多...
使用vlc获取海康威视视频流

使用vlc获取海康威视视频流

1.下载相关软件 1.1海康威视官网-服务支持-工具软件-设备网络搜索 下载地址： https://www.hikvision.com/cn/support/tools/hitools/注意：必须跟摄像头在同一个局域网下才可以使用设备网络搜索工具，才能使用vlc获取到视频流。 1.2下载VLC …
阅读更多...
Hadoop----Azkaban的使用与一些报错问题的解决

Hadoop----Azkaban的使用与一些报错问题的解决

1.因为官方只放出源码，并没有放出其tar包，所以需要我们自己编译，通过查阅资料我们可以使用gradlew对其进行编译，还是比较简单，然后将里面需要用到的服务文件夹进行拷贝，完善其文件夹结构，通常会…
阅读更多...
leetcode 每日一题复盘(10.9~10.15)

leetcode 每日一题复盘(10.9~10.15)

leetcode 101 对称二叉树 这道题一开始想是用层序遍历,看每一层是否都对称,遇到一个问题就是空指针(子树为空)无法记录下来,同时会导致操作空指针的问题,因此需要修改入队条件,并用一个标志去表示空指针 vector<int>numv;for(int i0;i<size;i){TreeNode*frontque.fro…
阅读更多...
SpringCloudGateway网关整合swagger3+Knife4j3，basePath丢失请求404问题

SpringCloudGateway网关整合swagger3+Knife4j3，basePath丢失请求404问题

很多人都是照着别人的文章粘代码&#xff0c;我也是粘的&#xff0c;但是这样粘也会有问题&#xff0c;我搞这个Knife4j3的时候遇到两个问题&#xff0c;这里记录一下&#xff1a; 第一个是basePath丢失&#xff0c;第二个解决basePath丢失完又引发了会引起application/json数据…
阅读更多...
React +ts + babel+webpack

React +ts + babel+webpack

babel babel/preset-typescript 专门处理ts "babel/cli": "^7.17.6", "babel/core": "^7.17.8", "babel/preset-env": "^7.16.11", "babel/preset-react": "^7.16.7", "babel/preset…
阅读更多...
第4章 决策树

第4章 决策树

文章目录 4.1 基本流程4.2 划分选择4.2.1 信息增益4.2.2 增益率4.2.3 基尼指数 4.3 剪枝处理4.3.1 预剪枝4.3.2 后剪枝 4.4 连续与缺失值4.4.1 连续值处理4.4.2 缺失值处理 4.5 多变量决策树4.6 阅读材料 4.1 基本流程 决策树也称判定树&#xff0c;是一类常见的机器学习方法。…
阅读更多...
35 WEB漏洞-逻辑越权之找回机制及接口安全

35 WEB漏洞-逻辑越权之找回机制及接口安全

目录 找回重置机制接口调用乱用演示案例绑定手机验证码逻辑-Rep状态值篡改-实例某APP短信轰炸接口乱用-实例接口调用发包 文章分享&#xff1a;https://www.cnblogs.com/zhengna/p/15655691.html 有支付接口、短信发送接口&#xff0c;邮箱的发送接口等等&#xff0c;在接口这…
阅读更多...
论文研读｜Protecting Intellectual Property of Deep Neural Networks with Watermarking

论文研读｜Protecting Intellectual Property of Deep Neural Networks with Watermarking

目录 论文信息文章简介研究动机研究方法水印生成水印嵌入版权验证 实验结果有效性&#xff08;Effectiveness&#xff09;高效性&#xff08;Converge Speed&#xff09;保真度&#xff08;Functionality&#xff09;鲁棒性&#xff08;Robustness&#xff09;Anti-剪枝攻击&am…
阅读更多...
镜像仓库harbor安装部署

镜像仓库harbor安装部署

基础配置 systemctl stop firewalld && systemctl disable firewalld setenforce 0 sed -i s/SELINUXenforcing/SELINUXdisabled/ /etc/selinux/configharbor wget http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo yum install -y docker-ce docke…
阅读更多...
Python中套接字实现服务端和客户端3-2

Python中套接字实现服务端和客户端3-2

2.3 监听套接字 通过listen()方法监听套接字。该方法的格式如下所示。 socket.listen([backlog]) 其中&#xff0c;参数backlog是一个可选项&#xff0c;表示等待服务器接收连接的客户端的数量。使用listen()方法监听套接字的代码如下所示。 s.listen(1) 当没有客户端连接…
阅读更多...
OJ练习第183题——移动机器人

OJ练习第183题——移动机器人

移动机器人 力扣链接&#xff1a;2731. 移动机器人 题目描述 示例 官解思路 当两个机器人相撞时&#xff0c;它们会沿着原本相反的方向移动。由于机器人之间并没有任何区别&#xff0c;相撞可以看做是穿透&#xff0c;原本左边的机器人相撞后交换为右边的机器人&#xff0c…
阅读更多...
最新文章
推荐文章

Copyright @ 2022~2023