直播新玩法背后的音视频技术演进

Posted 2022-02-02 LiveVideoStack_

点击上方“LiveVideoStack”关注我们

近年来，直播改变了许多行业模式，其形态在不断的演进中也逐渐丰富起来。直播在字节跳动中衍生出了KTV歌房、直播答题、互动游戏、电商拍卖及企业直播等不同场景。本次分享我们邀请到火山引擎视频云音视频直播客户端研发负责人——徐鸿，向大家介绍直播场景中沉淀下的优秀架构能力和技术能力。

文 | 徐鸿

整理 | LiveVideoStack

我从2013年开始从事直播相关工作，曾就职于百度贴吧，微视，之后加入了创业公司，创业公司被云厂商收购后先后为小米直播和字节直播提供服务，包括第一版火山直播的能力也由云厂商所提供。

从云厂商到字节跳动这样一个以用户为中心的公司之后，工作也从“唯技术论”转变为“唯实际效果论”。本次为大家介绍的直播新玩法也已在抖音及海外业务做过AB测试，并达到一定实际业务效果如用户使用时长及渗透的增长。

分享主要分为三部分：直播玩法的演进，直播新玩法背后的挑战和技术演进，未来的新玩法和火山引擎所做的准备。

1

直播玩法的演进

这三张图中的场景应该是大家在2014年左右对直播的认知，（1图）主播在家里开启直播，用户可以在评论区留言或打赏，这也是早期的PC厂商如歪歪所做的业务。（2图）新闻主播在专业的新闻直播间中播送新闻。（3图）游戏直播包括PC端游戏直播和手游直播，目前手游直播占比越来越多。

随着用户对直播场景的需求越来越广，直播领域的更多玩法也涌现了出来，如连麦、K歌、聊天房等。

上图中左2的两位主播正在PK，此时观众可以去喜欢的主播直播间里进行打赏，PK模式下的直播互动性很强，气氛非常火热。电商直播也衍生出了很多形式，但始终存在一个问题—端到端的延迟较大，这会导致主播上架商品时，有些观众无法及时看到商品链接而一定程度上影响购物体验。直播拍卖如3图中的玉石竞拍也是新的电商直播形式，主播和用户需要保持沟通互动，对延迟要求更高。图中右1的主播正在直播探店，在直播间实时测评菜品、环境，氛围等，观众根据自身感受选择是否购买套餐。

K歌功能得到了许多年轻人的青睐，疫情期间的数据显示K歌用户数量处于递增状态。K歌场景比较复杂，因为主播可能配置了声卡和话筒，屏幕前的观众可能戴或没戴耳机，由于此场景需要做RTC，涉及到3A处理（AEC、ANS、AGC），而安卓手机设备种类很多可能会出现各类问题。抖音用户还可以使用右图中的“一起看”功能，邀请伙伴一起观看自己正在看的抖音视频，并且支持实时语音对话。

左图是使用JS引擎渲染的“小游戏直播，”我们现在也有能力做一些答题小游戏，甚至可以将能力开放出去。

两位主播正在玩的是我和CV团队联合开发的弹球小游戏，主播通过移动面部控制弹板接住来自对方的小球。这只是抖音小游戏的示例，此外我们还在对产品进行探索，创造出更多有新奇的游戏形式。小游戏直播场景也比较复杂，其中涉及到JS引擎、特效、接入SDK能力、多路音频输入等（需要进行回声消除等操作）。

今年抖音上线了“付费直播/线上演唱会”，至今已有陈奕迅、孙燕姿等歌手完成了直播，用户可以在家中享受到高质量的音频，该功能目前也正处于探索阶段。

2

直播新玩法下的新挑战

上文只列举了部分已上线的玩法，火山引擎的直播不仅能提供以上玩法，更有能力支持其他未开发的新玩法。在探索过程中，火山引擎也遇到了许多新挑战。

这些挑战有：更稳定（这同时是所有业务最基本的要求），更动听（“K歌”及“线上演唱会”对音质的需求很高），更清晰，更流畅（电商直播需要做到低延迟），更安全（保障“线上演唱会”付费用户权益），更合规（国外已不允许使用Http做直播，国内工信部也在逐步进行规范），个性化（更懂用户，帮助有需要的主播达到更好的直播效果）。

为了做到“更稳定”，首先我们搭建了完善的问题快速诊断系统，线上出现问题时系统能够第一时间诊断出故障所在的环节如推流编码阶段、特效渲染阶段、CDN的上行、某一节点、下行或是观众端。目前此系统已经在普通直播或周年直播中进行保障实践。其次完善的质量统计和自动归因系统能够在直播质量发生变化时，从多维度出发判断故障所在地。最后，对于“K歌”，“一起看”场景，灵活的组件化设计使客户能够很快将娱乐能力复制到自己的业务中。

右图展示了小游戏场景的音频链路，主要有三路输入，分别是麦克风，游戏音乐播放，远端音频输入，输入后进行3A处理，最后输出的声音可能从用户的设备扬声器播放，也可能从有线或蓝牙耳机中播放。在上线小游戏场景的过程中，我们也积累了许多解决音频链路中出现问题的经验。

针对右图的音频场景，我列举了以下几个可能遇到的问题：

1. 使用场景对音频要求复杂，不同场景走不同的音频路由，路由切换会带来声音小，无声，卡顿等问题。

2. 存在多套android audio api，使用复杂，兼容性不够好，硬件3A效果参差不齐。

3. 可插拔硬件设备多，声卡、蓝牙耳机、有线耳机质量参差不齐，引入较多物理问题如杂音、漏回声。

4. 每位用户对声音的主观感受上不同，用户反馈的信息不够专业，工程师难以理解从而无法解决问题。

我们评价音频的维度包括音质、响度、音画同步、语音音质、音乐音质、双讲、耳返延迟。目前ios的耳返延迟可控制在30ms，和厂商合作能将Android的耳返延迟控制在50ms之内。多媒体音频评价实验室的同事每个双月会做一份专业的音频评价，评价内容包括主观专家测试、客观mos分，AB测试（验证优化后的收益）。

不仅“线上演唱会”需要做到更清晰，普通直播场景中我们也在不断尝试提升清晰度。

首先提升分辨率及码率，分辨率已从2017年的360p、540p、720p，到现在有部分比例的主播可以达到1080p。提升分辨率的同时还需要适应性提升码率，两者之间需要进行配合，从国内外的上线情况来看，分辨率和码率的提升对于用户侧的播放时长等都是显著正向的。

此外，美颜算法的优化也关系到清晰度的提升。编码上的调优这里不再赘述。“线上演唱会”等场景需要转码，目前的窄带高清技术可以在转码时为用户提供更高清的视频。经过AB测试后，我们发现超分对于用户的很多QoE指标都有正向指引。

清晰度的评价标准包括VMAF和自研的VQSCORE。

面对“更流畅”的挑战，我们分别对上下行自行网络做了优化。目前国内网络环境较好，数据显示抖音的卡顿率已降至非常低。火山引擎在QUIC上投入比较多，没有去研发私有传输算法。在QUIC上也遇到了许多稳定性及性能方面的问题，通过不断的探索，今年也获得了显著的收益，QoE也都显著正向。主要工作包括参数调优，客户端和服务端的性能优化（UDP传输在性能上比TCP更复杂），自研了拥塞控制算法，个性化策略（针对不同用户网络情况制定相应的策略）。

右上图是在GQUIC中的实践，之后会逐渐演化到IQUIC，HTTP/3目前也在跟进，整体来看，上线QUIC之后，首帧时长和百秒卡顿时长都有显著的收益。另外，0-RTT率在海外更是达到了95%。我们也在上行使用QUIC，将其估计的网络带宽反馈至编码器后在上行做网络自适应，对卡顿的优化效果很明显。

上文提到了电商场景下的需求是更低的延迟，行业内有三种主流降低延迟的方法：第一种是使用FLV，目前有一些厂商在做尝试，我们新上线后测试延迟从8s降至3s左右，业务收获了显著的收益。第二种是切片式，字节刚开始做低延迟的时候，Apple还未提出LL-HLS，考虑到业务量级较大需要用到海外CDN，而海外CDN节点最多的服务商是Akamai，他提出了CMAF FOR DASH方案，于是我们最终选择了CMAF。第三种RTS比较热门，是使用RTC做直播，我们也在线上进行了大量的实践。

CMAF将每个切片切成了更小的chunk，切片在没有完全生产出来时就可以开始传输并在播放端开始解码，CMAF要求chunk作为传输单位，和原始的HLS和DASH相比，延迟可以降到更低。

综合上线CMAF之后的数据可以发现其质量和FLV存在较大差距，左图可以看到首帧很长，建立连接时需要经过3个RTT，我们也就这点与CMAF的作者进行了多次探讨。最后经过优化，建立连接时如右图，在请求时同时把第一个视频和mpd信息、init信息和视频数据返回客户端，此外我们还在探索Server Push的方案。由于以上优化上线之后还存在差距，所以我们将CMAF的底层传输协议切换为了QUIC，还支持了HTTP/2，切换之后的首帧及卡顿都获得了不错的收益。

在低延迟上，我们也上线了基于RTC的RTS方案，RTS方案也需要在RTC基础上做许多改动，以下列举了几个方面：

1. 编解码类型的扩展，原始的RTC只支持H.264类的编码标准，需要拓展，音频也需要做一些拓展。

2. 信令的改造，RTC建立连接的过程相较于CMAF更为复杂，所以其RTT更多，需要对其进行采点、改造、定义SDP。首帧优化包括简化ICE，信令底层切换为QUIC传输，目前首帧时长和FLV的差距越来越小。

3. RTC播放器和传统播放器的结合，方案如右图，收到RTP包后经过音视频jitter buffer做音视频同步，后面的解码、后处理、音视频渲染都是由传统播放器组件进行。一定程度上避免重复超分和音量均衡操作。

4. 信令加密，进行海外业务时在部分场景下需要做加密协议的传输，需要将其切换为QUIC或者HTTPS。

在“线上演唱会”中提到了保障付费用户权益，防止盗播也是需要注意的地方，我们在打击黑产中积累了许多经验。除了更安全之外，海外业务中也需要注意更合规，在推拉流过程中要进行加密传输。保护直播内容方面字节采取了DRM方案（数字版权管理解决方案（Digital Rights Management）。

如何做到个性化也就是更懂用户，首先需要针对不同的场景、网络类型、网络级别、机型打分等定制不同的参数。其次是端智能，利用AI推理引擎进行参数个性化。

随着直播间形式越来越多，主播也有了更多手机端无法完成的需求如绿幕抠图，字节正在尝试研发硬件—自研直播一体机，在视频编码及音频方面做了许多优化。

总之，火山引擎的直播解决方案有如下优势：

通过完善的质量监控和问题诊断系统做到“更稳定”，通过音视频链路的优化方案和强大的音频团队做到“更动听”，同时RTC团队不断进行清晰度优化实践，在网络传输及网络优化方面持续探索。应用CMAF方案和RTS直播技术应用做到3s以下和1s以下的低延迟直播。在安全合规方面使用RTMPS和HTTPS进行加密传输。利用端智能实现个性化。尝试研发硬件为主播提供更专业的服务。

3

未来的新玩法和火山引擎的准备

大家应该注意到今天Facebook更名为了Meta，所以我认为VR直播领域有很大前景。

图中是联通列举的VR直播全链路架构图，在专业VR摄像机进行拼图或由摄像机采集并在本地PC进行拼图后推流到服务器，这两种方案对应的传输方式也不同。可以在播放端做拼接，也可以通过传输多路流后在播放端做拼接。目前这些方法都处于探索阶段，近期会支持全景播放，不久后也会支持VR播放。

图中是刘德华在抖音的直播，直播使用专业的影视级摄像机进行拍摄，清晰度非常高，并且背景是虚拟的，实现了混合现实的效果，这次直播的观看人数达到一亿次。整体来看，清晰度和混合现实直播的效果都很不错。

右图展示了从不同角度看比赛，观看体验相较于固定角度有明显提升，在采集端需要做许多工作，如左图用手机做自由视角直播采集推流，用更专业的设备也可以达到更好的效果。

谷歌发布的starline项目，在直播端用高分辨率摄像头和数十个定制深度传感器，在观众端用高清显示器，使用户身临其境。对光场视频感兴趣的同学可以访问https://blog.google/technology/research/project-starline/。

云游戏也是火山引擎正在探索的方向，图中的玩家正在操作游戏，但实际上游戏是在云端服务器中运行，并由云端服务器将游戏场景渲染为视频音频流，通过网络传输给玩家游戏终端。

除了视频方面，各大厂也在尝试在音频方面使用户更有现场感，如Apple现在已经能够支持空间音频。图中分别是空间音频的两种采集方式。

以上就是本次分享的主要内容，谢谢！

---

讲师招募

LiveVideoStackCon 2022 音视频技术大会 上海站，正在面向社会公开招募讲师，无论你所处的公司大小，title高低，老鸟还是菜鸟，只要你的内容对技术人有帮助，其他都是次要的。欢迎通过 [e-mail] 提交个人资料及议题描述，我们将会在24小时内给予反馈。

喜欢我们的内容就点个“在看”吧！