丽江手机网站建设,1688成品网站源码下载,热水器网站建设 中企动力,安徽智农网络信息技术服务有限公司 网站开发一、概述
网络基础设施升级、音视频传输技术迭代、WebRTC 开源等因素#xff0c;驱动音视频服务时延逐渐降低#xff0c;使超低延时直播技术成为炙手可热的研究方向。实时音视频业务在消费互联网领域蓬勃发展#xff0c;并逐渐向产业互联网领域加速渗透。经历了行业第一轮的…一、概述
网络基础设施升级、音视频传输技术迭代、WebRTC 开源等因素驱动音视频服务时延逐渐降低使超低延时直播技术成为炙手可热的研究方向。实时音视频业务在消费互联网领域蓬勃发展并逐渐向产业互联网领域加速渗透。经历了行业第一轮的红利爆发期我国实时音视频行业的场景效能逐渐深化步入到理性增长阶段。
延时的指标选择很大程度上取决于用户与内容制作方的交互耦合程度场景丰富多样。 在这些极端场景下延时在用户侧希望越小越好接近于实时通信的低延迟模式可以最大化地激发用户的参与感无缝地与内容生产方产生互动效应调动用户所见即所得的积极性。比如在主播秀场的 PK 、送礼、工会冲榜、打赏的活动关键环节竞争双方的储值大户都希望实时地观察到自身主播在礼物刷榜后的反应为后台运营决策团队或者后续活动策略提供第一时间的信息反馈。
下图体现了从技术/产品/运营的三方角度来综合思考低延时直播技术的作用从外部-内部综合因素考虑技术的变迁对整个生态正向循环的影响。 二、传统标准直播技术的局限性
2.1 RTMP 协议的延迟问题
RTMP 协议是最传统的直播协议主播端采用 RTMP 协议推送 H.264/5 和 AAC 编码的视音频数据到云厂商 CDN 服务器进行转封装分发端到端延迟一般控制在 3 到 7 秒。问题是 RTMP 的可扩展性存在缺陷同时对于延迟的进一步下探存在一定的技术困难。RTMP 协议情况下为了满足延时降低必然压缩播放器的下载缓冲区这样会引发显著的卡顿问题使得播放的观感产生不舒适的感受延时下探至 2 秒以下。 2.2 传统直播技术在实时互动场景中的不足
比较典型的有以下一些不足
视频延时和弹幕交互的延时存在显著差异问题聊天内容互动与视频传输图像节奏不匹配。 观众与主播互动形式单一是单向内容传导无法做到双向在 RTC 技术引入之前无法显著解决。单向传导的局限第一个方面表现在观众端拉流传输无法做到根据网络情况自适应调节。用户只能以固定的码率进行流媒体传输无法做到动态感知在网络情况实时变化的场景比如弱网移动基站切换等固定单向码率传输有较大概率造成丢帧卡顿等因素影响观播体验另一方面在网络条件更好时固定码率传输无法动态提升视频传输码率更高的画质带来更加舒适的体验。在直播和连麦场景共存的互动直播场景下主播采用传统 RTMP 推流在遇到连麦 PK 场景时会产生推流/本地连麦合流/服务器连麦合流的切换问题这种场景变换的切换会使得观众端产生瞬间的卡顿问题如果采用基于 webRTC 直播技术的超低延时直播方案这种推流–连麦逻辑的合流切换问题可以得到比较友好的解决只需要改变服务器转发-订阅流通道的分发逻辑不涉及推流媒体数据流的旁路调度切换。
2.3 超低延时直播与标准直播的区别
超低延时直播是近年来新兴起的一类应用。如电商直播、赛事直播等场景兼具高并发与低延时的特性传统直播 3-20s 的时延难以满足其需求但对实时互动的要求又不及视频会议等典型的实时音视频应用无需将时延降低至 400ms 以下。 为此超低延时直播融合了传统直播与实时音视频的技术架构通过取长补短的方式实现了介于二者之间的端到端时延。 尽管针对超低延时直播厂商尚无一套标准的技术路径但大体可以归纳为拉流协议、网络架构和推流协议三个方面的改造 在实际应用过程中厂商会平衡成本及性能指标等因素在不同的协议和网络架构之间进行选择。传输层协议的差异 基于 UDP 协议的可靠性优化为弱网对抗策略提供依据。
传统直播 FLV/RTMP 等采用的是 TCP 协议或者 QUIC 协议TCP 是牺牲传输实时性来换取数据完整性的可靠传输协议。弱网环境下其在数据传输前的“三次 握手”连接会带来较大延时。而 UDP 作为不可靠的传输协议其最大的优点为高实时性但不保证数据的到达和排序。 实时音视频产品如 RTM 超低延时直播往往采用 UDP 协议并在此之上进行协议层与算法层的优化来提高传输的可靠性与逻辑性。
UDP 协议的优化
UDP 协议往往和 RTP/RTCP 协议一起在实际应用中出现。RTP 负责数据传输其协议头中的序列号、 端口类型、时间戳等字段可为数据包的分组、组装、排序提供逻辑依据RTCP 作为 RTP 的控制协议负责对 RTP 的传输质量进行统计反馈并为弱网对抗策略提供控制参数。 三、超低延时直播技术的演进历程
1基于业务场景发展的直播技术演进过程延迟主线
2RTM 协议本身的演进历程
miniSDP 信令标准实现部分抖音)CDN 信令异步回源RTP 携带扩展头组成部分 aextmap:18 http://www.webrtc.org/experiments/rtp-hdrext/decoding-timestamp
aextmap:19 uri:webrtc:rtc:rtp-hdrext:video:CompositionTime
aextmap:21 uri:webrtc:rtc:rtp-hdrext:video:frame-seq-range
aextmap:22 uri:webrtc:rtc:rtp-hdrext:video:frame-type
aextmap:23 uri:webrtc:rtc:rtp-hdrext:video:reference-frame-timestamp
aextmap:27 uri:webrtc:rtc:rtp-hdrext:audio:aac-configaextmap:18 “http://www.webrtc.org/experiments/rtp-hdrext/decoding-timestamp”aextmap: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 计算当前帧的时间戳。用于启播快速音画同步和播放器播控逻辑精准音画同步。
aextmap:21 uri:webrtc:rtc:rtp-hdrext:video:frame-seq-range
扩展头携带帧的起始/结束序号如果首帧的前几个包丢失那么可根据起始序号快速发起重传加快首帧如果当前帧的后几个包丢失那么可根据该帧的结束序号快速发起重传降低延时减少卡顿。
aextmap:22 uri:webrtc:rtc:rtp-hdrext:video:frame-type
扩展头携带帧的类型如果携带并解析了正确的帧类型客户端可以不用解析 metadata 同时在弱网情形客户端可以跳过 B 帧直接解码 P 帧加速出帧并减少潜在卡顿。
aextmap:23 uri:webrtc:rtc:rtp-hdrext:video:reference-frame-timestamp
扩展头携带 P 帧的参考帧信息如果发生弱网情形那么客户端可以依照扩展头指定的参考帧关系及其对应时间戳跳过 B 帧解码减少卡顿发生。
aextmap: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 点对点媒体数据传输。 信令部分客户端-服务器单独开发利用了 SDP 标准报文模式媒体传输部分采用开源的 WebRTC 框架和自截自研的实时音视频媒体引擎进行媒体传输。
3.2 RTC 信令协议的改造升级 MiniSDP 压缩协议
参考链接https://github.com/zhzane/mini_sdp 经过升级后的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 数据。如下图右 3.4 视频渲染卡顿的优化百秒卡顿平均降低 4 秒
改善人均看播时长改变 RTC 引擎的组帧/解码策略禁止 RTC 在低延时模式下的丢帧改善直播的视频渲染卡顿。
实验组视频渲染百秒卡顿直播间场景RTM默认JitterBuffer策略8.3sRTM改进的JitterBuffer非丢帧策略3.6s
传统的 RTC 场景优先保时延全链路会触发各种丢帧包括但不限于解码模块网络模块FLV 直播场景会优先保证观播体验不丢帧良好的音画同步效果。RTM 要想减少卡顿取得 qoe 的收益播控策略需进行定制化 , 定制逻辑修改点
确保不会由于软解的解码耗时或者硬解的 dequeuinputbuffer 等其它 api 操作阻塞 jitterbuffer 内核层有一层强制的音画同步逻辑可以确保音视频的播放体验同时上层在监控网络模块和解码模块的缓存长度有相应的兜底逻辑a判断硬解确实解不过来dec_cache_frames 过多上报错误会降级到软解bjitterbuffer 异常缓存的 frame_list 过多触发播放器异常逻辑上报错误重新拉流。 3.5 RTM 播控逻辑的优化
改善移动端看播渗透RTC 统一内核方案天生存在缺陷 MediaCodec 硬件解码器初始化耗时久将 RTM 视频解码模块从 RTC 内核中迁移至 TTMP 播放内核复用了 FLV 的视频解码模块 MediaCodec 避免重新初始化显著的降低了安卓平台的首帧渲染时间提升了拉流的成功率。RTC 内核通用逻辑 改进的 RTM 内核播控逻辑
