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

news/2024/10/30 23:16:53/

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

文/周超

编辑/LiveVideoStack

-01-

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

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

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

86aef3906d3684e4d2e1ecbc9c57afca.png

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

1cedadd20dab6d4b05c93f96f99df8a8.png

c56d6e295d1723dffe587a07484cc5db.png

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

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

5fcf03d3f55895d47ff68a5a0a13b4f4.png

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

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

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

6fc740116004a0fe8091f9974325c9ca.png

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

f676ce6603c879d158e38b18505992e9.png

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

953e2abe0f3cedef139139465564507b.png

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

-02-

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

5139b076a9e90a063a7e159d29d5f4d9.png

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

d1249c3ebda68647b7ab07c9851ed496.png

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

d9cba019207aa0d842f941470a58ae4c.png

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

84236797a217aafaedd1938bb450f22e.png

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

739707680a6f9d90889162a87a97f142.png

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

d21384ec25a16edc8e3f9a158e31a2d8.png

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

e116eb791d725450c91c5bcddb0ef0d5.png

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

b14f5202513992523f906c67474a3917.png

3ff8e7ef17c9ec11df9a2a78164b3598.png

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

b3e107b1fc5792ac171ccae9959f4077.png

726504816114f08e96c948bb049c04be.png

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

072c2a2e03550a02c81d062834ffb4d5.png

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

540da5c65113475189f7b1682a1d6300.png

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

3ac618a3ae55d61421a99d9217889861.png

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

a9d9742fad1e43096dced88c97db88a4.png

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

-03-

下一代媒体传输协议:CMTP

dc5fcf3263e12c339d85bb1a06e3c0ad.png

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

b7cf4a1496c538fcf703b3a841357db1.png

在架构上,CMTP分为五层:

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

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

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

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

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

e68629cef912245be7a2cf2769c653be.png

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


362f91e43a7501ae63e2ce9506a29d49.png

LiveVideoStackCon 2023上海讲师招募中

LiveVideoStackCon是每个人的舞台,如果你在团队、公司中独当一面,在某一领域或技术拥有多年实践,并热衷于技术交流,欢迎申请成为LiveVideoStackCon的讲师。请提交演讲内容至邮箱:speaker@livevideostack.com。


http://www.ppmy.cn/news/78449.html

相关文章

算法分析基础

问题:如何比较不同算法的性能? 分析算法的运行时间 算法分析的原则 归纳基本操作 如:运算、赋值、比较 统一机器性能 假设基本操作代价均为1 统一机器性能后,算法运行时间依赖于问题输入规模与实例 相同输入规模&#xff0c…

金领冠520解密母乳源代码,助推婴配粉中国式现代化高速发展

又是一年520,又是一个“全国母乳喂养宣传日”。 1990年5月10日,为保护、促进和支持母乳喂养,更好地实行优生优育,原中华人民共和国国家卫生部召开新闻发布会,确立每年5月20日为“全国母乳喂养宣传日”。 那时&#x…

Jenkins发送邮件、定时执行、持续部署

集成Allure报告只需要配置构建后操作即可。但如果是web自动化,或是用HTMLTestRunner生成报告,构建后操作要选择Publish HTML reports,而构建中还要添加Execute system Groovy script插件,内容: System.setProperty(&q…

effective c++ 11 operator= 处理自我赋值

effective c 11 operator 处理自我赋值 我们知道复制构造函数和赋值运算符的区别是赋值构造函数用于创建一个新的对象,而赋值运算符用于给一个已经存在的对象重新赋值。 因此赋值运算符就可能存在把自己赋值给自己的情况,本节就是专门讨论这个场景的。…

MySQL(用户管理)

文章目录 1 用户1.1 用户信息1.2 创建用户1.3 删除用户1.4 修改用户密码 2 数据库的权限2.1 给用户授权2.2 回收权限 1 用户 1.1 用户信息 MySQL中的用户,都存储在系统数据库mysql的user表中 host: 表示这个用户可以从哪个主机登陆,如果是l…

日志收集机制和日志处理流程规范

本博客地址:https://security.blog.csdn.net/article/details/130792958 一、日志收集与处理流程 云原生平台中对日志提取收集以及分析处理的流程与传统日志处理模式大致是一样的,包括收集、ETL、索引、存储、检索、关联、可视化、分析、报告这9个步骤…

缓存被穿透了怎么办?

首先来了解几个概念: 缓存穿透:大量请求根本不存在的key 缓存雪崩:redis中大量key集体过期 缓存击穿:redis中一个热点key过期(大量用户访问该热点key,但是热点key过期) 穿透解决方案 对空值…

Ruby教程_编程入门自学教程_菜鸟教程-免费教程分享

教程简介 Ruby,一种简单快捷的面向对象(面向对象程序设计)脚本语言,在20世纪90年代由日本人松本行弘(Yukihiro Matsumoto)开发,遵守GPL协议和Ruby License。它的灵感与特性来自于 Perl、Smalltalk、Eiffel、Ada以及 L…