低延时直播体验怎么做（解析如何构建低延时的直播体验）

QuestMobile《2020中国移动直播行业“战疫”专题报告》数据显示， 疫情期间，看直播成为休闲娱乐、获取资讯、上课学习的主要方式，一些高度依赖线下场景的行业也纷纷通过直播进行自救，线上转型直播卖货，政府部门也通过直播形式进行招商、推广农产品等。

电商平台在疫情期间加大对直播的支持力度，为滞销农产品直播、云卖车、云卖房、实体店直播卖货提供平台和支持。

直播破圈加速进行，除了各类网络红人外，国家博物馆、知名酒吧、景点等线下主体为网民提供线上逛博物馆、云蹦迪、云旅游服务，吸引了大批年轻用户参与。直播不再是线上娱乐内容的生产工具，而是与商业业务场景结合越来越紧密，逐渐演变为基础的业务工具。

直播的及时性和互动性让他成为信息触达、互动沟通的新媒介，但直播的实时互动效果够好了吗？传统的直播技术延迟非常大，从观众评论到看到主播给出反馈一般要在5-10秒以上。我们来看下几个典型的尴尬场景：

1. 在线教育，学生提问，老师都讲到下一个知识点了，再返回来回答。
2. 电商直播，询问宝贝信息，主播“视而不理”。
3. 打赏后迟迟听不到主播的口播感谢。
4. 在别人的呐喊声知道球进了，你看的还是直播吗？

高延时影响了直播互动体验，阻碍了直播在一些场景的落地，特别在电商直播，直播间的评论提问是观众和主播互动的一个重要手段，主播的实时互动反馈对直播间的活跃度和交易达成至关重要。

使用常规的直播方案（rtmp 推流，FLV/RTMP/HLS 播放），延迟大概在5-10秒左右，这些延迟主要来自以下几个方面：

1. 推流侧buffer， 这部分来自于画面从传感器模数转换到音视频编码以及输出画面到网络的buffer。最主要的还是来自于编码的延迟，这与推流软件的编码参数设置有关，如是否有B帧，帧参考关系设置，压缩性能等。以OBS为例，当输出设置如下图时，延迟达到最低（1s以内）：
   

不过，上图的配置，在MAC和windows 平台上的效果也不一样，mac 平台的延迟在几百ms，而windows 可以做到50ms （实际案例数据)。推流网络方面，主播的推流网络一般都比较稳定，有的会拉专线，质量比较可靠。

1. CDN链路延迟， 这分为两部分，一部分是网络传输延迟。CDN内部有四段网络传输，假设每段网络传输带来的延迟是20ms，那这四段延迟便是100ms；此外，使用RTMP帧为传输单位，意味着每个节点都要收满一帧之后才能启动向下游转发的流程；CDN为了提升并发性能，会有一定的优化发包策略，会增加部分延迟。在网络抖动的场景下，延迟就更加无法控制了，可靠传输协议下，一旦有网络抖动，后续的发送流程都将阻塞，需要等待前序包的重传。
2. 播放端buffer，这个是延迟的主要来源。公网环境千差万别，推流、CDN传输、播放接收这几个环节任何一个环节发生网络抖动，都会影响到播放端。为了对抗前边链路的抖动，播放器的常规策略是保留6s 左右的媒体buffer。

阿里云低延时直播（Real-time Streaming）

传统的直播技术，已经不能满足对互动要求更高的直播要求，为此，2019年阿里云与淘宝直播共同推出超低延时直播服务RTS（Real-time Streaming），该方案基于WebRTC实现，采用UDP传输协议打造，实现可以承载大规模并发，端到端延时1秒内的低延时直播体验。由于RTS服务部署于阿里云CDN节点，复用CDN的节点和网络资源，在接入成本、节点覆盖、承载能力上实现了平衡。经过一年多的不断磨炼，整体体验和服务也更为完善和成熟。