得物直播低延迟探索 ｜ 得物技术
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 配合，就形成完整的端到端延迟。
GOP（Group 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）
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 协议，如果使用超低延时方案还需确认使用场景（例如头部热门直播间有需要的才采用）
阿里云的 RTS（Real-Time Streaming）和字节的 RTM（RTM，Real Time Media）都是超低延时商业化方案，有着使延迟降低至<=1s 的效果， 在具体的应用场景和功能方面都差不多。
RTS 全链路延时监控、CDN 传输协议改造、UDP 等底层技术优，可以提供低延迟的流媒体数据传输和处理服务，支持高并发、低卡顿、秒开流畅的直播体验。
RTM 通过链路传输协议改造为 UDP 等底层技术优化，解决 TCP 协议自身局限和网络抖动引起延迟累加，支持高并发、高可靠性的优质直播观看体验。
以上两种商业化方案都需要配合播放器 SDK 使用，且 RTM 需要配合火山 CDN 环境使用，两者费用也不一样。需要针对我们当前架构和现状作出权衡考虑。
使用 QUIC 协议（底层 UDP 协议理论上延迟会更低），已在三方播放器上验证过。普通 flv <=5s 下降到 <=2s
常规直播推流底层协议是基于 TCP 的，理论上极限在 3 秒左右已经是最低的了。
而 QUIC（Quick UDP Internet Connections）是一种基于用户数据报协议（UDP）的协议，它在传输上相比于传统的传输层协议（TCP）有以下优势，导致延迟更低:
连接建立时间短, TCP 协议需要经过三次握手的过程来建立连接，而 QUIC 协议只需要一次握手，这样就大大减少了连接建立的时间，提高了通信效率。
报文传输方式不同, TCP 协议在发送数据之前首先需要进行慢启动过程，以逐步增加发送速率并监测网络拥塞。QUIC 协议通过动态地调整窗口大小和传输速率，使得数据传输更加高效。
多路复用支持度更好, QUIC 协议支持多路复用，这意味着可以在单个连接上同时传输多个流，从而保证更高的带宽利用率和更低的延迟。
减少网络服务的依赖, QUIC 协议能够在连接失效或者网络服务不可用的情况下，进行快速恢复，从而保证了稳定的数据传输。
综上所述，由于 QUIC 协议在连接建立、报文传输、多路复用和网络故障处理等方面都有着比. TCP 协议更好的表现，因此它可以提供更低的延迟，更高的速率以及更可靠的连接。另外一个使用 QUIC（UDP）也需要综合考虑一些问题，它带来更低的延迟后，会不会有一些其他方面受到负面影响，例如拉流成功率、稳定性问题之类的。所以最终实施方案还需要做更详细的测试权衡利弊。
6.一些思考
直播延迟问题涉及的因素较多，包括推流端和播放端的缓存设置、传输协议、GOP 控制等方面。为了解决延迟问题，在实际开发中，为了达到更好的用户体验，我们需要对这些因素进行综合考虑和优化，在不断的实践和实验中寻找最佳方案，通过综合使用这些技术方案，可以更好地提高直播平台的实时性和观看体验。
活动推荐：得物技术社招开始啦！点击关注得物技术公众号了解详情！
本文属得物技术原创，来源于：得物技术官网
得物技术文章可以任意分享和转发，但请务必注明版权和来源：得物技术官网
版权声明: 本文为 InfoQ 作者【得物技术】的原创文章。
原文链接:【http://xie.infoq.cn/article/668cfb7fb9dcc8c4562b31285】。
本文遵守【CC-BY 4.0】协议，转载请保留原文出处及本版权声明。
得物APP技术部 2019-11-13 加入
关注微信公众号「得物技术」
评论