代码编织梦想

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:

  1. 未来OTT直播业务的端到端延迟范围在1-10s以内。
    我们都知道,影响直播业务端到端延迟的一大因素就是媒体分片的时长,Will每次演讲都要提到的CMAF chunk就是基于这一原理达到降低端到端延迟的目的。CMAF不是一个全新的概念,想要了解更多,可以点击这里。当然,Will也指出,尽管CMAF chunk能降低OTT直播业务的端到端时延,但它也不是万能的,比如实时语音通话这种业务,还是要用webrtc,这种实事求是不吹牛的态度值得我们学习~
    在这里插入图片描述
  2. OTT直播业务在不同设备之间的同步将做到1s以内
    同一个直播流,不同网络环境下的不同设备在观看时很难保持相互之间的同步,比如你家邻居都看到比赛的进球瞬间了,你却还没有。而通过设置同步时延门限值+外部时钟信息+自动调节播放速度,就有可能在不同设备间保持一定程度的同步。
  3. 8k内容将在2022年得到普及
    当年我们总觉得4k很遥远,现在很多视频网站都提供4k清晰度选项了。8k也是一样,现在我们觉得很遥远,其实也将很快得到普及。现在传输HEVC编码的8k视频大约要64Mbps的带宽,到2022年,随着新编码方案的提出,有望用40-50Mbps的带宽即可传输8k内容。即使在网速相对落后世界的我国,也有很多地方早已达到这样的传输带宽需求,所以8k内容的普及并非痴人说梦。
  4. HDR的生态将逐渐完善,并且dolby vision将在动态元数据方向成为主导
    从下图就能看到,现在很多OTT设备都同时支持多种HDR方案,这种现状还将持续下去。
    在这里插入图片描述
  5. 多种编码格式的媒资管理将成为常态
    未来的视频编码格式有更多选择,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竞速方案颇为相似。
在这里插入图片描述
如果选择了一圈,最后CDN的质量还是不够好,怎么办呢?首先要有一套完整的埋点统计方案,基于统计结果可以在服务端给出CDN黑名单,在客户端可以做CDN切换,如下
在这里插入图片描述
在这里插入图片描述
再来说本地性能优化。针对渲染性能不足和解码性能不足的问题,网易给出的解决方案如下,其中均匀丢帧的原理在于人眼其实对连续丢帧更为敏感。当然,下面提到的诸如metal渲染、硬解码这些,要分机型予以应用。
在这里插入图片描述
当然,解决卡顿问题还可以采用码率切换的方法,这一点就是老生常谈了。
接下来说起播优化,相信大家也都知道,起播优化就是对起播流程中的每一个环节进行优化,那么来看看起播流程中都有哪些环节
在这里插入图片描述
首先是CDN调度,采用了预调度的方式来优化
在这里插入图片描述
接下来是建连优化
在这里插入图片描述
最后就来到了解析、解码、渲染优化阶段,除了前面说到的硬解、均匀丢帧之外,还可以通过一些小技巧提高解析速度。
在这里插入图片描述
然后针对具体的点播业务,也介绍了一些秒开优化的方法。其中一个场景就是列表滚动的短视频,为了达到秒开需要做预加载,在这里有两种方案。在第一种方案中使用多个播放器实例,第二个方案中则由应用实现拉流,构建DataSource,使用同一个播放实例,网易采用的是方案二。
在这里插入图片描述
在这里插入图片描述


第一天的最后一场演讲来自解决方案专场的《5G时代超高清技术实践与探索》,讲师来自当虹科技,当虹科技脱胎于虹软,是深耕广电行业的一家公司。如果这场演讲是在去年,你可能还觉得这里会讲4k,到了今年,已经是8k的世界了
在这里插入图片描述
相应的,5G也完全具备传输8k内容的能力
在这里插入图片描述
说到这里,你可能还觉得都是老生常谈,纸上谈兵,根本没有实际应用。那就来看看下面这张图,反正我是挺意外的
在这里插入图片描述
视频方面如此,音频方面也有新的方向,尤其是全景声的运用
在这里插入图片描述
基于以上背景,讲师介绍了5G+超高清视频时代的视频处理建议:
第一点是多codec的支持,这一点不必多说,想想AVS3和AV1就明白了。
第二点是在生产端,会在全链路打通对超高清视频处理的支持
在这里插入图片描述
第三点是AI技术在编解码领域的应用,其实去年netflix的文章,还有这次大会的其他一些演讲,都有提到这块内容
在这里插入图片描述
第四点是超分辨率技术的应用,这也是一个从去年甚至前年就开始被广泛讨论的一个点
在这里插入图片描述
第五点是VR产业的第二春,这个我倒持怀疑态度。
第六点是HDR/SDR同播以及动态HDR的支持,这一点也是现在已经形成的趋势。


以上是第一天我所参与的所有演讲,在下一篇文章《岁岁年年人不同——LVS2019多媒体会议见闻(二)》中我们再来看看第二天的内容。


关注公众号,掌握更多多媒体领域知识与资讯
在这里插入图片描述

文章帮到你了?可以扫描如下二维码进行打赏,打赏多少您随意~
在这里插入图片描述

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/nonmarking/article/details/89407495

独家重磅 | 微软研究院首席研究员张正友离职 加盟腾讯机器人实验室_网易智能的博客-爱代码爱编程

▼ 点击上方蓝字 关注网易智能 为你解读AI领域大公司大事件,新观点新应用

腾讯二十年了,马化腾定了个新方向!_roger_coderlife的博客-爱代码爱编程

                         前几天,知乎又搞了个互联网十问营销活动,美其名曰“互联网洞见者”,掀起了一众吃瓜热潮。而腾讯公司董事会主席兼首席执行官马化腾延续了六年前的优良传统,率先扛起了第一枪。                       知友们对这个潜水六年才冒一次泡的大佬“难掩热情”,疯狂地送上了 3000+ 多条回答,可见

腾讯笔试归来_yiyiboy2010的博客-爱代码爱编程

上周14号到武汉参加的腾讯笔试,直到今天依旧没有收到面试通知,估计是被刷了,我们班有一个通知去参加面试的。 之后我简单总结了下被刷的原因,其实自我感觉笔试的那张试卷自己做的并不是很差,反倒是坐在我旁边的那个华科的学生的试卷做的倒是很差劲,选择题部分就有很大一部分不一样,因为其中有些题目我是可以肯定答案的,但就是这样还是被刷其实还是有一定的原因的,下面简单

【teg第7年】这里有你和你的永不妥协_腾讯技术工程的博客-爱代码爱编程

腾讯技术工程事业群七周年视频 这里有这么一群人, 他们对一切事物的本质依然好奇, 编程的操纵感让他们感到安心。 他们追求最纯粹优雅的代码, 他们享受最炙热的技术生命。 今年是TEG成立的第七个年头, 谨以此视频,献给腾讯永不妥协的硬核技术人。 我喜欢刨根问底,了解一切事物的本质。 从原始的01开始,在

Structure Aware Single-stage 3D Object Detection from Point Cloud-爱代码爱编程

Structure Aware Single-stage 3D Object Detection from Point Cloud 作者:Chenhang He, Hui Zeng, Jianqiang Huang, Xian-Sheng Hua, Lei Zhang机构:The Hong Kong Polytechnic University, DAM

计算机人文英语1形考答案,国开《人文英语1》形考任务(单元自测1至8)试题及答案...-爱代码爱编程

null 国开(中央电大) 专科《人文英语1》网上形考(单元自测1 至8) 试题及答案 单元自测1 Unit 1 题目为随机,用查找功能(Ctrl+F)搜索题目 一、选择填空 [题目]—Hi! How are you doing. ? —________________ [答案] C. I' m doing well. [题目]—Alb

cmu计算机学院华人教授,卡内基梅隆大学(CMU)计算机系正教授-张辉_江苏省未来网络创新研究院...-爱代码爱编程

Zhang Hui is Professor of Computer Scienceat Carnegie Mellon University and Co-Founder and Chief Scientist of Conviva. As a researcher, Zhang has worked in thearea of Internet

lvs负载均衡_高并发负载均衡lvs,怎样删除新增的虚拟ip-爱代码爱编程

LVS(Linux virtual server) 它是一个负载均衡、高可用性集群,主要针对大业务量的网络应用(比如新闻。电子商务、网上银行…) LVS是建立在一个主控服务器(双机)及若干个真实服务器组成。真实服务器负责提

lvs看这篇就够了-爱代码爱编程

1lvs 的由来 1公司的钱大部分都花在了获客,营销上,营销效果好就会带来新的流量,如果自身应用承接不住大的流量将会造成很大的经济损失。所以lvs负载均衡技术就此诞生了。当然不差钱也可以使用F5 等硬件 lvs 学名 Lin