岁岁年年人不同——LVS2019多媒体会议见闻（一）

作者: zhanghuicuc | 来源:发表于2019-05-08 19:43 被阅读9次

2017年参加了在北京举办的第一届LiveVideoStack多媒体技术大会，去年没能参加，今年则远赴上海参加了第三届大会。会议的票价几乎每年上涨一千元，今年8月在北京还有一场，全价票已经达到了3000元的水平，令人咂舌。要不是抽到了一张免费门票，这次我大概也不会来上海参加这次会议。

先说结论，通过这次参会，我掌握了如何快速分辨一场演讲水不水的技巧：如果一场演讲的嘉宾来自你没听过的一家公司，并且这家公司又恰巧在大会赞助商名单上，那么大概率会是一场比较水的演讲；如果在同一时间段有两场演讲的时间冲突，那么优先选择演讲嘉宾来自大厂的那一个，这样水掉的概率会比较小。

好了，说回会议现场，看到人头攒动，布展的赞助商也比当年多了不少，不禁要感慨，有钱的个人or公司还是多啊。

在这里插入图片描述

今年的联席主席是来自上海交大的宋利教授，宋教授的学术水平毋庸置疑，在交大官网的个人页面上有所介绍（可能因为真的十分厉害，交大官网上把宋教授的简介重复粘贴了两遍==）。宋教授的发言很简短有趣，主要推荐了两本书：《系统化思维导论》和《像外行一样思考，像专家一样实践》，都是帮助我们重塑思维模式的经典书籍，值得阅读。

首先带来主题演讲的是腾讯VP刘杉女士，刘女士的履历十分闪耀，大家一搜便知。刘女士带来的主题演讲题目是《从视频编解码标准生态的历史看未来》，标题很大，但内容其实就两大块：视频压缩编码知识科普与未来展望。

在这里插入图片描述
视频压缩编码这块，刘女士讲的内容在任何一本教科书上都能找到，对这块不熟的朋友，也可以参考我的文章：x264源码分析与应用示例（一）——视频编码基本流程和HEVC码率控制算法研究与HM相应代码分析（一）——HEVC标准及编码流程介绍。

未来展望这块，主要提及了VVC（Versatile Video Coding），刘女士向我们透露了三点信息：VVC的V1版本预计于2020年底完成；相比于HEVC， VVC预计可以节省30%以上的码率；VVC标准组正在考虑神经网络在视频编码中的应用。

第二个主题演讲由LiveVideoStack的老朋友Akamai首席架构师Will Law带来，这老哥好像经常出没于各种大会，不过人家讲的东西确实干货多，不服不行。演讲题目是《电视的未来》，这里说的电视是指OTT，未来则是指3-5年之后。

在这里插入图片描述

Will主要立了如下几个flag：

未来OTT直播业务的端到端延迟范围在1-10s以内。
我们都知道，影响直播业务端到端延迟的一大因素就是媒体分片的时长，Will每次演讲都要提到的CMAF chunk就是基于这一原理达到降低端到端延迟的目的。CMAF不是一个全新的概念，想要了解更多，可以点击这里。当然，Will也指出，尽管CMAF chunk能降低OTT直播业务的端到端时延，但它也不是万能的，比如实时语音通话这种业务，还是要用webrtc，这种实事求是不吹牛的态度值得我们学习~
在这里插入图片描述
OTT直播业务在不同设备之间的同步将做到1s以内
同一个直播流，不同网络环境下的不同设备在观看时很难保持相互之间的同步，比如你家邻居都看到比赛的进球瞬间了，你却还没有。而通过设置同步时延门限值+外部时钟信息+自动调节播放速度，就有可能在不同设备间保持一定程度的同步。
8k内容将在2022年得到普及
当年我们总觉得4k很遥远，现在很多视频网站都提供4k清晰度选项了。8k也是一样，现在我们觉得很遥远，其实也将很快得到普及。现在传输HEVC编码的8k视频大约要64Mbps的带宽，到2022年，随着新编码方案的提出，有望用40-50Mbps的带宽即可传输8k内容。即使在网速相对落后世界的我国，也有很多地方早已达到这样的传输带宽需求，所以8k内容的普及并非痴人说梦。
HDR的生态将逐渐完善，并且dolby vision将在动态元数据方向成为主导
从下图就能看到，现在很多OTT设备都同时支持多种HDR方案，这种现状还将持续下去。

在这里插入图片描述
多种编码格式的媒资管理将成为常态
未来的视频编码格式有更多选择，AV1/HEVC/VVC将成为主流，H264将仅作为向下兼容的选项存在。Will本人也表达了VVC的悲观态度，认为VVC也会像HEVC那样面临license的问题。Will还介绍了一个新东西：MPEG-5 EVC（Essential Video Codec），根据Will的介绍这是一个MPEG新提出的压缩方案，简单来说它为了规避HEVC的license问题，抽取除了HEVC中不受License影响的技术，在添加一些新的技术，最后也达到了优于HEVC的表现。详情可以参考这里。

除了上面几个flag外，Will还立了几个网络传输方面的flag，例如视频内容从源到端的传输方式将发生改变、HTTP3将占据30%以上的份额、CDN定价的方式将发生改变等等，这里不一一展开说了，下图展示了Will立的所有flag，我们2022年再来看结果如何~

在这里插入图片描述

第三位主题演讲的嘉宾是一位操着伦敦腔英语的小哥，来自初创企业MUX，小哥独自一人第一次前来中国，诚意满满。演讲主题是《视频API的发展》，主要介绍视频云服务商如何设计API。但是小哥明显高估了听众的英语水平，连个翻译也没请，ppt文字又很多，估计许多人都没听懂。
因为演讲内容跟我的工作关系不大，我也没仔细听，晒一张最后的总结图吧

在这里插入图片描述

上午的演讲到这里基本就结束了。

下午主要听得是客户端与前端这个主题分会场的演讲，下面详细说一下。
第一场演讲来自美摄，美摄是一家脱胎于新奥特的公司，主要提供视频编辑SDK服务。广电圈的朋友一定都对新奥特很熟悉，来自美摄的讲师也很有广电技术人员的朴实风格，几乎是把团队内部wiki文档和SDK文档（我后来在美摄SDK官网上找到了他PPT上的一些图）全搬过来讲了，从非常细节的角度介绍了美摄视频编辑SDK的架构：

在这里插入图片描述

在下面的数据流图中可以看到，在美摄SDK中以时间线来管理所有的媒体轨道和添加的各类特效、字幕等，并根据需求决定最后是输出到预览窗口还是本地文件。

在这里插入图片描述
线程模型上，下图中的每一个模块都在自己单独的线程中，每个线程完成自己的工作后通知其他线程，进行下一步的工作

在这里插入图片描述
到目前为止应该说都还是比较常规的视频编辑SDK设计思路，到video processor组件这里就有点意思了，提到了graph的概念。根据讲师的介绍，在美摄的视频处理组件中不同于传统非编软件按层次叠加的思路，而是采用了graph的思想，graph中每一个节点（可以理解为一个视频算法）都可以有多个输入和输出。不过从讲师给的图中倒是没明显看出graph的感觉，感觉还是传统的非编软件设计思路，也许是我理解的不够透彻。

在这里插入图片描述

讲师还着重介绍了一下美摄SDK特效的可扩展性，这里主要是通过资源包的形式来实现

在这里插入图片描述
资源包的加载流程如下所示

在这里插入图片描述
除此之外，讲师还介绍了一下美摄现在的AI智能剪辑功能，不过还比较初级，只是识别视频中的内容主体，将主体抽取出来，再套用固定的剪辑模板。当然这样的智能剪辑功能已经可以满足很多人的需求了，不过我心目中的智能剪辑应该是能达到自动组合视频主体和空镜，自动匹配音乐节奏，脱离固定模板的程度。

第二场演讲来自腾讯音乐，介绍了在全民K歌中的互动直播技术创新与优化。先来看一下全民K歌的总体架构，分为三层：底层模块+基础能力模块+业务需求模块。

在这里插入图片描述

首先第一点提到的是如何做到低延迟的音视频传输

在这里插入图片描述
主要利用的是腾讯私有的UDP协议，并且结合了FEC/ARQ来提升网络抗性

在这里插入图片描述

与此同时，为了提升弱网环境下的视频流畅度，使用了多级流控的方法

在这里插入图片描述
除了以上两点外，腾讯的小哥哥还提到了一个有趣的case：有时候视频卡顿是因为网络选择了错误的IP，比如上海的用户却走了香港IP，为了解决类似问题，设计了IP竞速策略，来优化上下行接入导致的卡顿问题。

在这里插入图片描述
在介绍了如何做到低延迟音视频传输后，接下来介绍了一些音频上的优化。对于一款K歌应用来说，好的音频体验应该能做到如下几点

在这里插入图片描述
先来看一下全民K歌的音视频数据核心处理流程

在这里插入图片描述
基于以上流程，可以做到全流程分析并优化音频卡顿的问题，这里比较有意思的一点是在网络卡顿时可以通过放慢音乐播放的速度来迷惑观众，达到提升用户体验的效果。这一点也许也对播放器开发人员有启发。

在这里插入图片描述

在音频卡顿问题之外，对于一款K歌应用还有一个非常重要的指标是耳返延迟与音伴同步。在ios设备上可以自己做一些系统优化，在android设备上则需要联合手机厂商一起做合作优化。一般来说，伴奏与人声之间的偏移要在40ms以内才能达到同步的效果，这里有一个有趣的问题：如何量化伴奏和演唱人声之间的延迟呢？其实可以让左声道只放伴奏，右声道只放人声，然后取两个声道的频谱看偏移量来作为延迟的量化方法。

在这里插入图片描述

除了音伴同步之外，还有一个歌词伴奏之间的同步问题。对于这一问题，也有如下的解决方案。

在这里插入图片描述

介绍了网络优化和音频优化之后，腾讯的小哥哥又介绍了一下如何从研发流程和质量监控的角度提升用户体验。不过这里数据上报的时间粒度会不会太小了一点，恐怕值得商榷。

在这里插入图片描述

上面介绍的都是优化方案，在创新业务上，主要介绍了以下几点。
首先是连麦，其实这个也不算创新业务了，不过小哥哥倒是详细对比了各种连麦方案，全民K歌最后使用的是方案三，虽然流量损耗大，但是灵活性更高

在这里插入图片描述

最终形成的组件化架构设计如下

在这里插入图片描述
第二项创新业务是实时在线合唱，要说明的是，这里只是做到了二人合唱，还做不到多人合唱。还是一样，介绍了各种合唱方案的区别，最终选择了方案二。

在这里插入图片描述
在这一场景下的音视频处理流程如下

在这里插入图片描述

在这里插入图片描述
最后一项业务创新是歌词动效，腾讯这里是利用libass来实现的，并且做了一些优化，达到可以应用的程度

在这里插入图片描述

第三场演讲来自网易，主题是移动端播放器优化实践，主要介绍的是如何做到降低卡顿率和提升起播速度。这里要说明的是，网易的播放器是基于ijkplayer研发的。
首先来说卡顿优化，卡顿的原因总共有三种：缓存不足；性能不足（解码能力不足或渲染能力不足）；时间戳混乱。
先来说缓存问题，缓存不足的原因有以下几点：发送出来的视频流就已经丢掉了；CDN转发过程中丢帧或者不及时；本地带宽不够。
针对以上三点，第一个卡顿优化方案就是智能选择CDN，这一点和全民K歌使用的IP竞速方案颇为相似。