吉首企业网站建设价格,济宁鱼台网站建设,做网站+广告费+步骤,亚马逊免费的关键词工具1.背景
直播的时效性保证了良好的用户体验#xff0c;根据经验在交易环节#xff0c;延迟越低转化效果也会越好。传统的直播延迟问题已经成为了一个不容忽视的问题#xff0c;高延迟不仅破坏了用户的观看体验#xff0c;也让主播难以实时获取到用户的反馈。为了进一步优化…1.背景
直播的时效性保证了良好的用户体验根据经验在交易环节延迟越低转化效果也会越好。传统的直播延迟问题已经成为了一个不容忽视的问题高延迟不仅破坏了用户的观看体验也让主播难以实时获取到用户的反馈。为了进一步优化直播时效体验我们需要对产生延迟的原因以及整个交互链路有个清晰的认知才能稳定的实施相关方案。 2.主观体验
我们团队内部观察了其他电商平台的延时其中 TOP1 的平台端到端的延迟在 3s 左右而得物在 5s 左右提升空间还是比较明显我们需要进一步明确具体原因。 3.延迟降低有什么好处
3.1 提升交易环节顺畅度
在得物的直播场景中有添加秒杀商品的环节秒杀商品的倒计时是实时进行的假如直播画面有将近8s的延迟才能追上在这一过程中无论是用户还是主播沟通中都会存在gap。在直播过程中用户在延迟高的场景中提问了但是主播迟迟没有反馈在这个期间用户有可能退出直播间或者跳过这个商品这个结果无论是对主播或者是对交易转换都不太能接受。 3.2 提升体验不同用户之间延迟差别太大
A、B两个用户可能在看某一个直播间A用户可能很早就进直播间了而B用户是新进来的但是B用户的延迟却比A用户的低了几秒A用户看到可能就会怀疑自己手机、网络、APP是不是哪个有问题造成不好的体验反馈。 4.直播延迟是如何产生的
要搞清楚延迟是如何产生的我们势必要了解到其中哪些程序可能出现延迟并且是可优化的。
主播 -- 云服务器 -- CDN节点 -- 用户
云服务器 -- 主播: 直播内容转码、压缩等处理
CDN节点 -- 用户: 直播内容分发到多个边缘节点
用户 -- 设备: 接收直播内容 -- 显示直播内容 4.1 在这些过程中可能会产生延迟的地方
(部分解释来源第三方文献) 主播端所使用的采集编码设备可能存在延迟
主要包含编码延迟以及发送缓存引入的延迟这个环节的延迟优化空间不多虽然通过调节编码器参数可有效降低编码延迟但带来的是画质的损失同时也影响压缩效果因此多数集中在优化弱网传输出发点是为了提供用户观看流畅体验而不仅限于降低延迟 云服务器对直播内容的转码、压缩等处理的时间
对于直播平台而言实时转码是非常必要的一项技术。通过对视频流进行实时转码可以将高清视频流优化为多个分辨率满足不同终端设备的兼容性和带宽需求并且减小了网络传输的开销。但是实时转码过程中必然会带来一定的延迟这是因为 转码过程需要对视频流进行分析和处理比如压缩、格式转换等。这个过程需要一定的计算资源和时间。 转码后的视频需要重新传输到CDN节点中再由观众设备进行播放。这个过程可能会受到网络带宽、传输速率等因素的影响导致一定的延迟。
因此针对转码延迟的问题需要在减小延迟和提高视频质量之间进行权衡。采用一些高级的转码算法、减少图片质量降低对视频画质的伤害、优化编码参数等方法但也同样会带来画质与压缩率的损失因此这部分延迟需要根据实际场景综合来考虑如果对延迟要求很高可以略微调整下。 CDN节点的网络传输延迟
不考虑回源的情况这个环节主要影响延迟的是 gop cache 策略各类 CDN 厂商称呼都不一致有的又叫RTMP、FLV、HLS...Delay即在边缘节点缓存一路流最新的几个 gop(一般媒体时长平均为 5 7s)目的是为了在拉流请求建立时可以有媒体数据即时发送优化首帧和卡顿这样也就导致了播放端收到的第一帧数据就是 5 7s 前的旧数据第一帧的延迟就达到了 5 7s这个环节是端到端延迟过大的根因。 播放器的防卡顿缓存buffer固定延迟n(s)
在直播拉流播放过程中为了提高播放的流畅度和用户体验通常进行缓存一部分buffer。缓存是指在播放器开始播放之前预先加载一定量的视频数据到本地缓存中以便后续播放时能够快速读取缓存中的数据避免卡顿和不流畅的现象。这种“预加载”的缓存被称为“缓存buffer”。
缓存buffer大小不同可能会导致延迟时间也不同常见的缓存buffer大小为2秒或者更小这意味着播放器会预先从视频源中加载2秒到本地缓存中等播放器播放到接近缓存末尾时会再次预加载2秒内容到缓存中以保证播放的流畅性。
固定延迟是指播放器在接收到网络数据之后为保证数据正常播放而需要等待一定的固定时间一般用于防止视频播放过程中的卡顿和不流畅。例如如果设置的固定延迟为1秒那么从数据包到达手机端再到数据包真正播放出来这个过程就需要多等待1秒左右的时间这就是固定延迟产生的效果。
通常情况下播放器会自动根据当前的网络环境动态调整缓存buffer大小和固定延迟时间以保证最佳的播放效果。不过如果网络环境不太理想仍有可能出现视频卡顿和不流畅的情况此时可以通过配置和优化缓存buffer大小和固定延迟时间来改善播放效果。 用户设备的接收、解码等操作产生的延迟
假设用户的设备硬件性能较为低端在接收和解码直播数据时出现卡顿等问题。为此可以通过优化码流参数如对码率、分辨率等进行调节使其更加适应用户设备的硬件性能或者采用尽量少的传输协议以减少解码时间和相关计算资源的使用。 综合所述
其中任何一个环节出现问题都有可能导致直播过程中产生延迟。为了减少这种延迟可以优化各个环节的处理效率并优化网络传输等方面的参数和设置。
在直播的传输环节里对延迟影响大的主要是CDN的传输、转码、分发和播放缓冲使用实时的转码模式转码器引入的延迟一般在 300ms 以内甚至更短。CDN 的分发环节也会带来一定的延迟但相对也较短。而为了对抗网络抖动引入的播放缓冲区引入的延迟播放缓冲引入的延迟常常会有 5s 甚至更多。
4.2 如何知道具体延迟 方法一
采用端到端的测试方法即计算播放端到推流端的时间差作为延迟。
找一个在线的精确到毫秒的时钟http://www.daojishiqi.com/bjtime.asp
A. 打开上述网页推流端对准该网页或者抓取窗口
B. 播放端到对应直播间观看对应的时间差
对A、B屏幕进行对比截图计算时间差。 方法二
编码的时候把时间戳写到 SEI 信息中播放器通过拉流成功后解析 SEI 信息然后与当前时间戳做差值对比。 SEI 需要涉及到推拉流侧底层开发所以暂选的方法一进行测试测试结果发现现阶段最保守以及快速的解决方式是直接调整云直播控制台的延迟档位。如果要调整延迟档位那势必要了解到调整之后会带来什么影响以及变化这其中就涉及到了 GOP 相关的知识点。
4.3 GOP 以及 GOP cache 是什么我们为什么要了解它
顾名思义 GOP cache是一组存于 CDN 服务端的 GOP 缓存GOP cache 越大延迟影响也越大。通过了解 GOP cache 我们能在直播延迟链路中能做出更精准的优化。GOP cache 是某一方厂商提出的名词各大 CDN 的称呼也不一致有的云厂商又称之为RTMP、FLV、HLS...Delay。与推流 GOP 或者 转码播流 GOP 配合就形成完整的端到端延迟。 GOPGroup of Pictures
而 GOP 是一组连续的视频帧通常包括一个I帧关键帧和若干个P帧预测帧和B帧双向预测帧。在直播过程中如果 GOP 的大小过大会导致接收端在等待I帧的到来时需要等待相对较长的时间这就会增加视频的延迟。因此降低 GOP 大小可以在一定程度上减小视频的延迟。 直播控制台的延迟GOP cache 配置路径 域名配置-直播延迟配置 选项中选择 推流 GOP 转码 GOP 关系 无转码的情况下推流 GOP 播流的 GOP 有转码的情况下如果转码模板配置了 GOP 则播流的 GOP 转码配置的 GOP 如果转码模板未指定具体的 GOP则推流 GOP 转码后的 GOP 延迟配置的描述强调的都是推流 gop是否有误导问题
不算完全算误导一方面不是所有直播流都走转码甚至修改 GOP。另一方面推流 GOP 对流传输效率可能存在一定影响。主要描述没有把转码 GOP 的影响和区别包括进去。 缓存的单位 duration or size?
得物使用的直播缓存的单位是 duration
在直播延迟中缓存的单位可以是时间(duration)或大小(size)。
以时间(duration)为单位的缓存指的是在视频采集、编码和推送到云服务器的过程中视频数据会先被存放在缓冲区中等待一定的时间也就是缓存时间后才会被推送到CDN分发节点上进行播放。
以大小(size)为单位的缓存则是根据缓存容量进行控制视频在采集、编码和推送到云服务器的过程中每当视频数据达到一定的大小就会被推送到CDN分发节点上进行播放。
在实际的直播过程中通常会综合使用时间和大小两种缓存单位来进行延迟控制。如果对延迟比较在意可以适当增加缓存时间和大小保证接收端有足够的缓存时间进行播放减少出现卡顿和停顿的概率。如果实时性比较重要的话可以适当降低缓存时间和大小缩短延迟时间保证直播的实时性。
需要注意的是缓存时间和缓存大小是直播平台优化延迟的两个关键因素。合理的设置能够显著减小延迟提升用户体验。但同时缓存过多或者过少都可能会带来一定的问题因此需要根据实际情况进行调整和优化。 缓存的 gop 数?
不固定且没有 GOP 数量的概念是以时长论大小取决于 CDN 侧的 buffer 不管 buffer 多大发送数据是按照至少一个 delay, 最多 delay gop 发送的流数据是不断产生新数据的发送的时候内容不断在滑动。对延迟没有直接的影响关系。 基础时间值
RTMP 低2s中4s高8s
FLV 低2s中4s高8s
计算延迟方式[RtmpDelay, RtmpDelay GOP] 这里的 GOP转码前用的推流设置的 GOP转码后用的转码模板配置的 GOP自定义模版配置的 1080pgop 10s 200桢 的情况下 理论上最小最大值就下面的几种范围[212][414][818]
flv 播放的话delay设置2秒gop 设置1秒理论上端到端的延迟基本在3秒左右如果码率高的情况下还得适当提升 delay 的值保证直播的流畅。另外除了 CDN 缓存延迟以外播放器缓存策略也需要考虑。
如果要实现稳定2秒可以考虑超低延迟直播的方案。 5.后续可实施的有效降低直播延迟手段 降低 CDN 正式环境的 gopCache 至低档位
调整完之后端到端延迟预计能从 5s-8s 降低至 3s-5s 推流 GOP 调整为 1s平均端到端延迟再下降 1s
理论上来说降低推流 GOP是对延迟有帮助的将 GOP 降至1秒则每秒会推送一个关键帧接收端就可以在接收到关键帧后直接播放进一步减小延迟。同时由于每秒会推送更多关键帧对视频的画质和稳定性也会产生积极的影响。
推流 GOP 的大小不是唯一的影响直播延迟的因素。还有视频编码、推流服务器的 配置、网络环境等因素都会对延迟产生影响因此只有在综合考虑到各种因素后合理设置推流GOP大小才能够最大程度地降低直播延迟。 增加 buffer 中视频数据的消费速度有效降低延迟例如倍速播放或者直接丢帧策略需要更精细化
也就是说增加拉流侧的消费速度在有需求的情况下配合倍速追桢的策略加快视频的播放速度在某一个阀值中开启或者停止。
推流侧在推流的过程中把关键帧打入时间戳到 SEI 信息里去
拉流侧在拉流的过程中解码成功之后把对应的 SEI 信息里的时间戳解析出来
然后根据服务端的在线时间对比两者之差决定播放器的播放器倍速例如 (1.0 ~ 1.4s) 之间逐渐增加和递减最终在符合预期的延迟时间停止加速消费 确认自研播放器 buffer 缓存当前现状是多少秒对齐竞品至少 2s buffer
常见的直播播放器缓存buffer大小为2秒主要是出于减少卡顿和停顿的概率提升用户体验的考虑。
播放器缓存buffer是指播放器预先缓存一定量的视频数据进行播放。当网络状况不好、视频流传输中断或者延迟过高时播放器缓存就会派上用场保证播放过程的连续性和流畅性。
一般来说播放器缓存buffer大小会根据网络环境和带宽等因素而不同。如果缓存过小会导致卡顿和停顿如果缓存过大会增加延迟影响实时性。经过优化常见的直播播放器缓存buffer大小为2秒左右既能够保证播放过程的流畅性又不会过度增加延迟。
不同的直播平台PC、移动端、不同的网络WIFI、4G、5G和设备不同厂商可能会有不同的播放器缓存 buffer 大小设置因此在实际使用中需要根据具体情况进行调整和优化。 使用阿里云的 RTS 或者字节的 RTM 协议如果使用超低延时方案还需确认使用场景例如头部热门直播间有需要的才采用
阿里云的 RTSReal-Time Streaming和字节的 RTMRTMReal Time Media都是超低延时商业化方案有着使延迟降低至1s的效果 在具体的应用场景和功能方面都差不多。 RTS全链路延时监控、CDN 传输协议改造、UDP 等底层技术优可以提供低延迟的流媒体数据传输和处理服务支持高并发、低卡顿、秒开流畅的直播体验。 RTM通过链路传输协议改造为 UDP 等底层技术优化解决 TCP 协议自身局限和网络抖动引起延迟累加支持高并发、高可靠性的优质直播观看体验。
以上两种商业化方案都需要配合播放器SDK使用且 RTM 需要配合火山 CDN 环境使用两者费用也不一样。需要针对我们当前架构和现状作出权衡考虑。 使用 QUIC 协议底层UDP协议理论上延迟会更低已在三方播放器上验证过。普通 flv 5s 下降到 2s
常规直播推流底层协议是基于TCP的理论上极限在3秒左右已经是最低的了。
而 QUICQuick UDP Internet Connections是一种基于用户数据报协议UDP的协议它在传输上相比于传统的传输层协议TCP有以下优势导致延迟更低: 连接建立时间短, TCP 协议需要经过三次握手的过程来建立连接而QUIC协议只需要一次握手这样就大大减少了连接建立的时间提高了通信效率。 报文传输方式不同, TCP 协议在发送数据之前首先需要进行慢启动过程以逐步增加发送速率并监测网络拥塞。QUIC 协议通过动态地调整窗口大小和传输速率使得数据传输更加高效。 多路复用支持度更好, QUIC 协议支持多路复用这意味着可以在单个连接上同时传输多个流从而保证更高的带宽利用率和更低的延迟。 减少网络服务的依赖, QUIC协议能够在连接失效或者网络服务不可用的情况下进行快速恢复从而保证了稳定的数据传输。
综上所述由于QUIC协议在连接建立、报文传输、多路复用和网络故障处理等方面都有着比. TCP协议更好的表现因此它可以提供更低的延迟更高的速率以及更可靠的连接。另外一个使用QUICUDP也需要综合考虑一些问题它带来更低的延迟后会不会有一些其他方面受到负面影响例如拉流成功率、稳定性问题之类的。所以最终实施方案还需要做更详细的测试权衡利弊。 6.一些思考
直播延迟问题涉及的因素较多包括推流端和播放端的缓存设置、传输协议、GOP控制等方面。为了解决延迟问题在实际开发中为了达到更好的用户体验我们需要对这些因素进行综合考虑和优化在不断的实践和实验中寻找最佳方案通过综合使用这些技术方案可以更好地提高直播平台的实时性和观看体验。
文Brave 活动推荐
得物技术社招开始啦点击下方了解活动详情社招得物技术岗位火爆来袭
本文属得物技术原创来源于得物技术官网
未经得物技术许可严禁转载否则依法追究法律责任
