媒体传输协议的演进与未来

音视频应用近年来呈现出迅猛的发展趋势,成为互联网流量的主要载体,其玩法丰富,形态多样,众多繁杂的媒体传输协议也应运而生。LiveVideoStackCon 2022北京站邀请到快手传输算法负责人周超,结合快手在媒体传输上的优化与实践,基于快手KTP、KLP、LAS等协议和标准,为我们介绍了媒体传输协议的演进与面临的挑战;还分享了最新的媒体传输标准CMTP,探索未来更多可能。

文/周超
编辑/LiveVideoStack
原文:https://mp.weixin.qq.com/s/Ow_4PpcxyFUdBYrsSrcq9Q

-01-

音视频大时代下媒体传输协议的繁华

本次分享会从媒体传输协议的现状、快手在媒体传输协议优化上的实践和对未来的展望三部分展开。

近几年,音视频技术发展迅速,叠加网络、AI技术,音视频已无处不在,应用场景涵盖点播、直播、电商、实时互动、游戏、医疗和教育等多个方向。

媒体传输协议的演进与未来

从用户体验角度来看,音视频应用都需要在延迟、流畅度和清晰度之间寻找一个平衡点,对应到网络传输,本质就是需要在延迟、传输可靠性和带宽利用率之间找到一个平衡点。

媒体传输协议的演进与未来
媒体传输协议的演进与未来

基于此,音视频应用可以大致划分为三大类,即泛VoD、泛RTC和泛Live。

泛VoD偏重于点播类应用,对延迟不敏感,更注重传输可靠性和带宽利用率。泛RTC应用则对延迟非常敏感,在保证延时的前提下,才会追求传输的可靠性和带宽利用率。泛Live应用介于两者之间,对每个维度都有一定要求,并且不同的Live垂类场景,对三者(可靠性、延迟、带宽利用率)之间的平衡关系也有一定差异。

媒体传输协议的演进与未来

从架构上来看,泛VoD可以大致分为四个步骤。视频在采集和导入之后,叠加魔法表情等玩法,然后经过转码压缩上传到云端。在服务端进行审核和前处理等大量工作后,一般会进行二次转码,以进一步提高压缩率并生成多个质量的副本。最后,由CDN分发给用户,进行下载、解码、渲染和播放。

在生产端,创作者能否快速成功的发布作品,将直接影响他们的创作热情。

在消费侧,用户则更关注视频的清晰度和流畅度,这两个维度都需要可靠传输以及足够高的带宽利用率。提到可靠传输,最常见的就是HTTP协议和QUIC协议。此外,在消费侧,为了应对海量用户的差异性网络,一般会采用多码率自适应技术,例如DASH、HLS等。

媒体传输协议的演进与未来

泛Live应用架构与泛VoD较为类似。主播和观众都希望获得低延迟、高清晰度和高流畅度的体验。但直播流实时产生,对传输的平稳性要求较高,对带宽利用率和延迟方面会做一定的妥协。例如,当网络出现剧烈波动时,允许出现丢帧和丢包。业内直播主要采用RTMP协议,近年来也在尝试QUIC协议,例如RTMP over QUIC的方案。在消费侧,通常也会采用多码率自适应技术。然而,常见的DASH和HLS技术,都是基于分片的架构,在直播场景中会带来较大的延迟。目前,为了降低直播延迟,许多厂商也在尝试基于WebRTC的快直播方案。

媒体传输协议的演进与未来

泛RTC场景的目标非常明确,就是要实现超低延迟的互动。在满足低延迟的前提下,再提升清晰度和流畅度。目前使用最多的方案是WebRTC,很多公司也基于WebRTC进行了二次开发,形成自己的方案。

媒体传输协议的演进与未来

总体而言,每类应用场景目前都有各自比较成熟的协议,其稳定性高、各厂商支持好,但也存在灵活性差、跨层优化难和业务不感知等问题。

-02-

快手在媒体传输优化上的实践

媒体传输协议的演进与未来

在快手的传输体系中,底层算法是最核心的部分,包括常见的拥塞算法、多码率自适应算法、弱网对抗算法等等。在此基础之上,我们设计了丰富的传输协议,例如KTP、LAS、AAS、KLP等。KTP是快手自研的第一个私有传输协议,用于直播推流、作品发布和RTC等业务场景;LAS是快手自研低延迟直播多码率自适应协议,目前已形成行标,几乎所有云厂商都支持;KLP是快手自研的直播拉流协议,用于提升直播拉流的传输效率;AAS是点播场景下的多码率自适应协议,包含短视频和长视频场景。

媒体传输协议的演进与未来

KTP在设计之初,就希望一个协议能同时支持支持点播、直播和RTC等多个业务场景,解决协议繁多、维护和优化成本高的问题。在架构上,KTP总体分为两层:底层是传输控制层,通过对协议的设计,支持在传输延时、可靠性和带宽利用率之间取得动态平衡。在其之上是业务感知层,感知业务特性,根据不同业务的特征,采取最佳的策略与算法。

媒体传输协议的演进与未来

通过实际测试对比发现,在直播推流场景,KTP在60%丢包率时,依然可以保持清晰、流畅的推流体验(左图),而RTMP在15%丢包率时,会发生严重卡顿,处于不可用状态(右图)。

媒体传输协议的演进与未来

在作品发布场景上,基于KTP的通用上传服务,已经用户快手各个作品发布/文件传输的场景,并显著提升了作品发布成功率,从最初的70%~80%提升到99%以上。此外,即便在用户网络越来越复杂、作品大小越来越大的情况下,其发布耗时也一直处于下降的状态。

媒体传输协议的演进与未来

最后,在RTC场景,KTP支撑着快手内部所有的RTC业务,例如PK、连麦、会议、StreamLake等等。基于先进的算法与架构,基于KTP的RTC解决方案,在体验和性能等多个维度上,都显著领先竞品。

媒体传输协议的演进与未来

此外,在2021年ACM Multimedia的低延迟传输挑战赛中,快手也以巨大的优势取得了第一名的好成绩。

媒体传输协议的演进与未来

协议是桥梁,支撑各种功能与业务需求,但其传输性能主要取决于底层算法。例如网络领域的核心算法之一的拥塞控制算法,在过去几十年一直是研究的热点与难点,直接影响着协议的传输性能、带宽利用率、弱网抗性等。快手一直持续在算法领域深耕,例如自研的拥塞控制算法IA2C,性能远超BBR;基于强化学习的NNCC,在带宽利用率上取得新的突破;最近正在准备上线的下一代拥塞算法AQDC,在带宽利用率和延迟上,均取得显著收益。

媒体传输协议的演进与未来

媒体传输协议的演进与未来

KTP广泛用于作品发布、直播推流和RTC等场景,并取得了很好的收益。但由于历史原因,在下行链路上,KTP并未很好的做支持和优化。于是,在2020年,我们复用了KTP的底层传输控制,并在此基础上,增加了适用于直播拉流特性的策略与算法,形成了KLP协议。KLP在海外上线的时候,取得了非常好的效果。

媒体传输协议的演进与未来

媒体传输协议的演进与未来

在消费侧,为了应对用户差异性的网络特性,一般会采用多码率自适应技术,来平衡流畅度和清晰度,例如国际标准DASH和HLS,其大致原理为将视频文件转码成多个档位,每个档位进行分片处理,消费侧依据实时网络状况选择不同的分片,最终拼接成一个完整的视频。这两个标准成熟度高,但最初都是为点播设计,直接用于直播场景,会带来较大的延迟。

媒体传输协议的演进与未来

在经过充分的调研和讨论后,快手决定自己建立一套低延迟的直播多码率标准,也就是LAS,目前LAS已经正式成为行标,也被业界广泛采用,相关细节可参考官网介绍(https://las-tech.org.cn/#/)。

媒体传输协议的演进与未来

在点播多码率上,我们同时考虑了短视频和长视频之间的差异,形成了快手点播多码率自适应标准——AAS。在协议描述上,参考了MPD和DASH的设计,最核心的是快手自研究的多码率算法,包括传统基于模型的算法、基于深度学习的ABR等,这些算法在不同场景,均取得了非常好的效果。

媒体传输协议的演进与未来

此外,在2022年ACM Multimedia的短视频传输挑战赛中,快手也以巨大的优势取得第一名的好成绩。

媒体传输协议的演进与未来

目前,快手的网络传输主要依托于自研的一系列协议,但仍存在一系列问题,例如下行场景覆盖不足、业务耦合、生态封闭、无法赋能行业、三方CDN不能全场景支持等。

-03-

下一代媒体传输协议:CMTP

媒体传输协议的演进与未来

基于之前多个协议成功的经验和算法积累,我们期望设计一套全新的协议CMTP,可适用于所有场景,并能解决覆盖不足、生态封闭等问题。总体而言,CMTP具有以下四个特性:架构通用、全场景、高扩展性和特性丰富。

媒体传输协议的演进与未来

在架构上,CMTP分为五层:

UDP/TCP层:底层IO使用的网络协议,默认采用UDP,UDP灵活性高,易扩展,可以支持多种算法与策略,对于UDP Block的情况,则采用TCP。

传输控制层:支持UDP和TCP两种模式。基于UDP规范了协议字段、组包拆包方式、会话管理等,支持ARQ、FEC、拥塞控制、0-RTT、加密、多路复用等功能。基于TCP也规范了协议字段、组包拆包方式等,并支持加密、多路复用等功能。

传输表示层:规范了传输控制层所需要提供的接口和功能,包括媒体会话、媒体流的定义,以及媒体数据、控制信令的表示方式等,同时支持协议优选。

应用感知层:以组件化的方式组织,感知业务的不同需求,并通过对应的组件提供专属优化功能,包含直播组件(Live)、点播组件(VoD)、实时通信组件(RTC)和通用组件。各个组件功能独立,可插拔、替换或新增,从而保证其足够强的扩展性、兼容性和业务适应性。

通用接口层:规范了对外的标准接口和配置,包括客户端和服务端接口,元信息和通用配置的格式等。

媒体传输协议的演进与未来

目前CMTP已经在快手落地,也取得了显著的收益。此外,很多厂商也已经支持CMTP,并与快手一起推进标准化。未来,希望有更多团队加入我们,共同建设良好的CMTP生态。

 

版权声明:本文内容转自互联网,本文观点仅代表作者本人。本站仅提供信息存储空间服务,所有权归原作者所有。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至1393616908@qq.com 举报,一经查实,本站将立刻删除。

(0)

相关推荐

发表回复

登录后才能评论