基于当下直播技术对下一代低延迟的直播CDN场景的思考和展望

◎赖材栋 张小强 刘 斌

(中国移动通信集团陕西有限公司，陕西 西安 710077)

随着家庭宽带业务的高速发展，陕西移动互联网电视用户规模已经突破600 万，成为传播红色能量、弘扬主旋律、传递疫情防控政策、丰富市民精神文化生活的一支重要力量。移动互联网电视业务随着规模和影响力的不断扩大，已经成为省内乃至全国主流的宣传渠道。如何构建全新的互联网电视视频直播业务发展模式，保障互联网电视视频直播业务低延迟、高品质、优体验，成为互联网电视从业人员需要关注的重大课题。

在多媒体领域技术盛会——LiveVideoStackCon 音视频技术大会上，阿里云的高级技术专家进行了下一代低延时的直播CDN 技术分享[1]，从当下直播技术回顾、低延时直播技术思考、低延时直播技术实现、直播业务未来展望四个部分展开，对直播CDN 相关从业者有一定的帮助和启发。

陕西移动结合互联网电视系统业务构架及CDN 直播业务发展需求，提出了OTTx 直播业务模式改造方案。OTTx业务是一种新的互联网电视形态，直播采用组播技术，在节省项目投资预算和提升用户体验方面具有非常明显的竞争优势。为保障OTTx 业务的安全平稳发展，互联网电视系统优化包括MRF、FCC、FEC、探针等各边缘节点网络设备及用户侧的直播频道音视频质量监测，针对接入网络、传输网络进行整体质量提升等，旨在提升移动互联网整体传输网络质量，保障互联网电视视频内容的流畅性、稳定性、安全性，为推动互联网电视业务发展提供可靠基础，为提升和优化互联网电视CDN 终端用户体验满意度提供坚强后盾。

一、直播业务发展历程

直播业务包括多种场景[2]。秀场直播是国内最早出现的直播形式，在各个直播平台比较常见。游戏直播，例如斗鱼、虎牙、战旗等直播平台都是比较典型的游戏直播平台，游戏直播对编码的要求高，同时在线观看人数多，所以它是流量贡献最大的直播形式。赛事直播，如F1、奥运会、世界杯等对即时交互要求不高，所以一般都是HLS 形式，延迟相对其他场景会稍微高一点，赛事直播最重要的指标是稳定性，热点事件带来的带宽快速增长、高收视并发需要CDN 具备足够的储备带宽应对突发情况，直播全程不能出现任何中断故障，否则会影响用户体验。移动直播、短视频是近两年井喷式发展和全民参与的直播形式，其特点是推流和播放比较便捷, 通过手机APP 就可以进行直播，所以手机直播也是推流数最多的直播形式，这种直播用户通过随机的封面选择，对于不感兴趣的直播内容，用户点进去观看不超过几分钟就可能退出观看下一个，在这样频繁地接入和退出操作下，首屏体验感知就变成最重要的指标，用户难以忍受切换慢或起播慢的体验，对延迟要求高，视频秒开是客户非常关注并评价很高的技术。还有近几年兴起的VR 直播，VR 直播视频码率很大，一般在10M/bits，VR 直播主打的就是用户的视觉冲击体验，在画质上要保证优质，在控制清晰度不变的情况下需要降低使用的带宽，这就涉及到视频编码格式。比如h265 编码格式的视频带宽比同清晰度的要低2—3 倍，也就意味着带宽最少会降低一半，直播用户并发峰值期间对CDN 出流负载要求很高，所以对网络质量及内容源流畅度要求极高，如果观看流畅度不能保证连续性，就不能带来用户体验满意度提升，无法增强互联网电视品牌竞争力。

二、低延迟直播需求

国内主要使用HTTP-FLV 和RTMP 这种传输形式，这两种传输形式一般延迟在3—5 秒，当然延迟时长也会受视频本身GOP 影响，移动直播一般在1—2 秒间隔。游戏直播关键帧延迟一般在8—10 秒，所以游戏直播的延迟更大一些，而赛事活动一般不会强调互动性，对流畅度要求比较高，所以一般会选择HLS，延迟在10 秒左右。

直播业务场景下3—5 秒延迟对于大多数常见直播形式一般影响不大，但是在某些特定场景下效果不能满足业务需求。如直播连麦场景下延迟造成的影响是最明显的，连麦延迟超过1 秒，对话可能就会出现卡顿甚至掉线；在答题直播场景下，需要参与者在固定时间内完成答题后提交答案，如果出现个别用户延迟比较大而不能在固定时间内完成答题并提交，就对其他用户不公平。虽然现在大多数直播平台仍然使用FLV 的传输形式进行答题类直播，但是基本都会采用SEI 插帧等方法来解决时间同步问题，需要平台的客户端和直播CDN 做一些配合来完成。除了直播连麦场景之外，像在线课堂、在线拍卖等直播场景因为涉及到实时互动，对延时的要求也比较高。从对业务的支持层面来看，仅仅有RTMP、FLV 这种3—5 秒延时以上的直播形式已经不能满足客户对流畅度的需求, 需要对更低延迟的直播业务场景进行支持。

三、技术选型的思考

技术选型首先必须要兼容已有直播业务和技术栈，因为直播CDN 系统已经承载了很多用户，短延时直播需要从现有直播的业务基础上逐步衍生, 可以让客户在短延时和常规直播手段间进行切换，这也是基于现网业务稳定性的考虑。对于直播业务来讲，视频秒开和卡顿率是非常重要的业务指标。

传统CDN 业务场景，无论是图片、大小文件、点播、直播等业务，都是在TCP 协议通信基础上实现的，所以短延时直播在研究初期就思考使用TCP 协议的可能性。我们对于短延时的目标定义为从端到端延迟在800 毫秒以内，例如一场直播的延迟主要包括推流端延迟、CDN 延迟、播放端延迟这三个方面，很多客户会关注CDN 延迟，通过实际收集相关延迟数据分析，CDN 从入流到出流整个业务流程所产生的总延时全网平均不超过100 毫秒，晚高峰期间平均也不超过200 毫秒。而从业务系统维护经验角度来分析，播放端的延迟会比较严重，主要包括两方面，一方面是开播时卡前一个关键帧所带来的延迟，另一方面如果CDN 服务器到播放端之间网络有抖动，累积的延迟会越来越多。所以我们就可以得出这样的结论，在网络正常的情况下使用现有的RTMP、HTTP-FLV 进行分发，延迟也基本可以做到控制在1 秒以内。但是现实情况是网络不可能出现不丢包的情况。当网络抖动丢包导致卡顿等质差时，TCP 协议能提供可靠的数据传输服务。为保证数据传输的正确性，TCP 会重传其认为已丢失的报文，TCP 协议通过ACK 确认机制，也就是说发送方发送一个数据包报文之后，一定要收到对方应答才会继续发送。如果传输网络由于质差出现丢包，就会在一个RTO 之后重传，RTO 的值和RTT 有关，并且RTO 的最小值是200ms。如果想保证流畅性，播放端一定要至少能容忍200ms 以上的抖动，但播放端的jitbuffer 太多又无法满足低延时的要求。

使用TCP 传输时无效传输无法避免。TCP 是采用socket buffer 进行通信，数据也是从应用层先进入socket buffer 再分发。对于RTMP 或FLV 的分发来说，假如某一帧数据的一部分已经进入了socket 缓冲区，那么就必须将这一帧剩余的数据发送出去，如果剩余的数据传输时出现拥塞等无法发送，播放端会解析错误断开连接造成用户体验会非常差。而网络在出现波动的时候，有可能socket buffer 里面的数据需要多次重传才能传送到播放端, 而在短延时直播的场景下，这些socket buffer 里面和应用层过期的数据再发送给播放端已经没有意义，也就是说会产生很多无效的传输。

近些年发展起来的WebRTC 协议，能够实现亚秒级的延迟，它并不是通过分块传输降低延迟，使用的是UDP/IP协议传输，提供了在Web、iOS、Android、Mac、Windows、Linux 等所有平台的API，保证了API 在所有平台的一致性，而且大多数的浏览器均支持，不需要额外的插件，支持自适应比特流的传输来适应复杂的网络状况。

因为WebRTC 在移动端拥塞控制和重传方面有部分技术优化，卡顿率方面不会比TCP 差，所以技术选型对齐到WebRTC 会是最终的结果, 毕竟用户能够使用H5 就可以直接推流或者观看直播, 能够提高用户的接受度和使用率。完整地支持WebRTC 要解决加解密、打洞、音频格式等问题，所以前期考虑只使用WebRTC 中的一部分技术，完整支持WebRTC 会是后期的长远工作规划。

这里对比一下WebRTC 中RTP 传输使用的NACK 机制，NACK 的丢包反馈更加及时，如果网络偶然性抖动较多时，NACK 机制效果会更好。通过统计网络数据分析，全网平均RTT 小于15ms，如果CDN 节点覆盖足够好的情况下，延迟理论上会非常低。以1.5Mbps 码率的音视频流举例，每秒钟100 个数据包，包和包之间就是10ms 的间隔。如果第二个丢包出现的时候，第三个包对方接收到了，就可以立即知道第二个包是丢掉了，然后立刻返回一个NACK 进行重传。在这种极限场景下重传间隔就是25ms，相比之前TCP 的200ms 重传延迟是一个质的提升，不再需要通过服务器进行路由，减少了延迟和带宽消耗，实现直接通信可提高数据传输和文件共享的速度。

四、应用实践

(一)解决端口问题

标准WebRTC 的建连流程，最简单的服务器端端口方案是我们可以为每个客户端分配一个端口，服务器端上使用这个端口区分每个用户。那么多端口有什么不足呢？很多的网络出口防火墙对能够通过的UDP 端口是有限制的；对于服务器端来说开辟这么多端口，安全性也有一定的问题；开辟这么多的端口在Server 端上，端口的开销和性能均有一定的影响。那能否用单端口？首先要解决的一个问题是：如何区分每一个RTP/RTCP 包是属于哪一个WebRTC 客户端。WebRTC 在服务器SDP Answer 中设置 ice-ufrag 为roomid/userid，其中RoomID 和UserID 是通话业务层分配的内容，用于区分会话连接以及客户端。接着做Ice candidate 协商，客户端开始做连通性检测，也就是stun binding request 里的USERNAME 为SDP local 和remote 的ice-ufrag 指定内容。服务器收到stun binding request 的客户端ip 和端口，并正常回stun binding response。记录客户端地址与用户信息的映射关系。服务器收到一个rtp/rtcp 媒体数据包，通过包的源ip 和端口，查询映射表就可以识别这个包属于哪个用户。

(二)视频秒开

秒开是指用户点击播放到看到画面的时间非常短，在1秒之内。实现视频秒开是基于GOP 的视频缓存策略实现的。例如RTC 交流场景下，可直接通过PLI 交流，向发布端索要关键帧，对于接收端立即完成视频渲染。但是对于直播CDN 场景，海量的客户端向服务器端索要PLI 是不现实的。为了解决这个问题，服务器端需要加入Gop Cache 数据结构，构建基于Gop 的缓存结构。在低延迟直播的情况下，需要考虑在Gop 下发后客户端能够快速追上服务端的发流，所以在客户端感知不明显的情况下会对P 祯和B 祯采用1.1 或1.2倍速下发，直到所有包能够追上服务端下推包的进程，后续在合流完成后的整体时间即可同步，延迟会降到最低。

(三)RTP 报文

RTP 数据包中，PT 字段是载荷类型，sequence number是包序列号，发送端切片的时候写好序列号，接收端依据这个序列号进行数据的还原。而且在数据报文发生重传的时候，还依靠这个序列号进行NACK 的返回。同时，时间戳对流媒体传输非常重要，播放器依赖它进行解码和同步。SSRC 用来识别不同的身份，同一个IP 和端口被NAT 重新分配的时候，SSRC 能够识别出这是一个不同的连接。

以H264 为例[3]，RTP 在封装的时候，如果NAL 单元小于MTU，那么我们认为一个RTP 包可以完整封装一个NAL单元，如果出现丢帧，那么我们认为缺少的是一个完整的NAL 单元，对后面NAL 单元的解析不会出现数据错乱。如果一个NAL 单元大于一个MTU 的时候，假设一个NAL 单元需要三个RTP 包封装，不管丢掉部分还是全部丢掉，接收端都可以标识出这个NAL 单元，不会影响其他NAL 单元的解析。所以采用RPT 报文是可以满足设想需求的。

(四)平滑发送机制

现在通常采用的混合拥塞算法，基于丢包率和延迟进行码率控制。标准的方案是当播放端卡顿时，发送端码率会降低。当推流端上行网络出现抖动的时候，CDN 服务器返回数据包通知推流端把码率降下来。当播放端下行网络出现抖动的时候，一种是输出转码视频流，另一种是让推流端推两路视频流，提醒播放卡顿的用户切换到低码率。

陕西移动互联网电视系统结合当前业务平台系统现状，分析CDN 服务器使用的拥塞控制算法取决于sysctl 接口的net.ipv4.tcp_congestion_control。缺省的拥塞控制算法是最后注册的算法(LIFO),如果全部编译成模块，则将使用reno 算法，如果使用缺省的Kconfig 配置，CUBIC 算法将编译进内核，并且内核将使用CUBIC 作为默认的拥塞控制算法，CUBIC 拥塞控制基础[4]提升优化TCP 快速重传算法net.ipv4.tcp_congestion_control = cubic，在快速重传丢失的数据包后启用拥塞避免算法，而不是慢启动算法被调用，这就是快速恢复的意义。这一方法使得在中度拥塞的情况下CDN 服务器能有较高的吞吐率，达到优化出流效率的目的，最终提升终端用户的体验感和满意度。

(五)FEC 冗余传输

FEC 是通过数据报文冗余传输来提高容错率。关键帧10%冗余率，非关键帧5%，根据丢包率判断网络状况，动态调整冗余度。现在H264 和AAC 数据会在内部先进行切片，放到平滑发送队列再发送给播放端，同时重传包也会进入平滑发送队列，并且会放到平滑发送队列的队首位置，完成数据报文冗余传输。

陕西移动互联网电视系统OTTx 业务是使用华为MRF 编码[5]，在中转过程中采用RTP 协议封装组播流，生成FEC冗余流，使用户在终端获得更流畅的播放体验。FEC 采用带外承载方式，与组播组使用同一个IP 地址，以UDP 端口区分原始组播流和FEC 冗余流，默认端口为组播端口减1，播放端获取的频道列表信息中有指定的FEC 端口，则必须采用指定端口。FEC 算法采用移动集团规范，能够适配组播流任意位置随机丢包恢复业务场景，FEC 冗余度不超过5%，对于1%的随机丢包至少要达到99%以上的恢复成功率，对于2%的随机丢包至少要达到95%以上的恢复成功率。

(六)探测活动

采用RTCP 报文的方式实现对播放和推流连接的断开进行控制。采用TCP 方式传输的时候也有类似的问题，推流端发送了FIN 结束报文，但是CDN 服务器未必收到，所以要有超时的机制来进行管理。我们采用数据及时反馈机制，下行播放端要求周期性返回，上行推流端必须在8—10 秒内完成真实视频流数据传输，否则连接就会断开。

五、结语

对于CDN 低延迟优化要做的另一个关键点就是优化传输，其实无论对于文件加速还是流媒体加速，传输永远都是最重要的环节，CDN 这个分发网络质量提升本身就是为了优化传输而存在的。

完整地支持WebRTC 一定是下一阶段实现的目标, 毕竟直接通过浏览器就可以完成推流和播放，对于用户端的接入便捷性有质的提升，对于CDN 来说，控制接入一定是最重要且必须做的事情。