找回密码
 立即注册
LiveVideoStack 首页 资讯 查看内容
  • QQ空间
  • 回复
  • 收藏

李大龙:音视频技术是互联网品质生活的连接器(1)

2018-6-11 09:00

结识李大龙源于LiveVideoStackCon 2017,忙碌的工作让我们在会场擦肩而过,并相约一场采访。通过采访,我深深的感受到他对行业的执着与热情,他将音视频技术定义为互联网品质生活的连接器,而我们这些社区媒体不也是这些开发者与生态的连接器吗?


策划 / LiveVideoStack


LiveVideoStack:李大龙你好,请介绍下自己,包括正在研究的技术领域以及感兴趣的方向。


李大龙:2007年从武汉大学研究生毕业后,我加入腾讯大家庭,并一直工作到现在。在多媒体领域,我主要参与的产品及项目包括:QQ影音、手机QQ视频聊天和腾讯视频等。现阶段我们团队主要负责腾讯视频移动端的流媒体播放解决方案及其用户播放体验,我个人对播放器架构演进、流媒体存储传输、视频编解码标准及图像声音信号处理,都会保持长期关注和跟进。


眼下蓬勃发展的HDR产业、双雄争霸局面下的新一代视频Codec,以及AI技术如何有效提升现有音视频产品体验,在这些技术方向上非常有想象空间、我自己很感兴趣,也在谨慎中积极寻求从“纸上得来”到亲身“躬行”之路。


LiveVideoStack:从求学阶段到步入职场,十多年为什么一直在多媒体开发领域呢?有没有考虑更换过赛道,多媒体技术的有何魅力吸引着你?


李大龙:我从小学到高中,一直处于应试和学科竞赛氛围很浓厚的环境,高考填报志愿时选择了一个既对数学要求较高又与当时全民IT热相结合的专业——(计算机)信息安全。四年的本科学习中,精妙绝伦的数论及密码学很好地满足了我的挑战欲望。此外还有一门在当时看来并无太大难度,仅仅是比较有趣的课程——多媒体信息隐藏,给我留下了深刻印象。研究生选择方向和导师的时候,既能应用密码学的知识技能又能和声色并茂的多媒体场景结合起来的信息隐藏和数字水印,再次进入我的视野,加上我的导师胡瑞敏教授(http://multimedia.whu.edu.cn/index.php?m=content&c=index&a=show&catid=123&id=89)在音视频领域的大师感召力,所以决定以此为方向。直至研究生毕业、在就业选择时,也是理工生常有的做一行爱一行、坚持一行的惯性思维,坚决选择音视频技术相关的岗位和团队。


时光荏苒,曾经的选择在这十余年中当然也有过技术困境下的蹉跎和无助、有过业务调整期的失望和灰心、面临内外其他机遇的诱惑,及互联网行业高速更迭引发的焦虑和反思。但如果抛开单体业务的沉浮、放下个人一时一地的得失,用开放、学习和期待的心态对待不断变化的市场和用户,我还是能真切地感受到多媒体技术领域的长足发展和勃勃生机。


多年的专业阅历,让我坚信:音视频技术是互联网品质生活的连接器。这个“连接器”,一头连接着人类最原始的视听需求、同时也是最直接的感官享受之一,其在现代文明社会中作为社交、商务、效能和娱乐工具丝毫不为任何外部条件所改变。“连接器”的另一头则连接且聚合着信息论、最优化理论、图形图像学、声学、人类视觉系统等一众根基深厚、源远流长的学派。互联网场景下的多媒体技术,作为更加综合和全面性的专业领域,其魅力就在于我们总能直接面对和满足万千大众的需求,技术上的精进带来业务的发展,也在潜移默化中影响人们的社交、商务、娱乐行为。作为曾经的莘莘学子,和如今埋没在写字楼大厦中的普通程序员,专注并投身这个行业,能够让我们的所学所思所为有了用武之地!


LiveVideoStack:对于大多数开发者而言学习多媒体开发并不容易,对此你有哪些建议?


李大龙:对于多媒体开发这种综合性较强的领域,个人感觉很难抽丝剥茧般地理出一份类似“N天精通多媒体开发”之类的东西出来。回顾自己的历程,也是顺着自己的脾气秉性、并受到外部条件的机缘影响而来。这里尝试归纳几点,仅供参考,但愿恰好能合乎读此小文的朋友们的心意,或者也就当一介码农的浅薄见解罢了。


首先,务必明确自己的目标和定位。用互联网式的语言说,就是场景在哪里、有什么样的痛点,最终学习/开发出的技术方案/软件产品需要满足哪些可量化的指标。我个人建议在入门阶段不要过早聚焦在一个技术点上,而应该更多建立一个偏全局、偏框架性的概念理解。早早地手捧一份类似ISO/IEC 14496-10的大部头生掰硬啃,收获的可能只有心理上的高大上。不如先以外行心态、以给产品经理或者商务销售讲技术的心态,仅仅从通用性的逻辑层面来入门学习。把大象放进冰箱需要3步,那么一个实时视频聊天系统有哪几个逻辑模块呢?从一方好友开始呼叫、到双方建立连接、开始数据通信直至最终会话终止,其间的协议交互和流程是怎样的呢?不考虑具体的Codec实现及复杂的应用场景技术指标要求,就当是加强版的CS通信,比起某年初学socket API调用时的DEMO代码如何?……由此一层层、一步步用自己熟悉的技术类比、反推和延伸,并逐步理解主要环节的实现原理及技术难点,最终能给自己明确一两个点进行后续的深究挖掘,例如:彻底排查和理清实时通话中时延的原因并优化、寻找系统中能够影响图像质量的因素并进行优化等。


其次,针对一个具体的、“局部性”问题不妨以“庖丁解牛”“掘地三尺”的态度来对待。因为音视频技术有一定的数学基础和较清晰的年代演进历程,所以我个人非常主张追根溯源式的学习。例如我在公司内开设视频压缩原理的课程时,一定会先讲一次图像压缩的课程。看似古老的JPEG压缩框架,能够非常直接地理解Spatial domain到Transform domain的意义、DCT频带数据特征之于人类视觉的影响、量化及量化表的由来、变长字编码的设计理念等等。这些技术环节构成了视频压缩的半壁江山,而且虽然历经二十余年的发展,很多环节不断演进更迭,但其数学理论根基和工程设计理念得以传承和延续。再略微进一步,体会下WebP和JPEG流程上的差异与改进,Intra prediction的设计理念与作用已然清晰。至此,视频编码框架下I frame的主干流程跃然眼前;剩下的细节,比如Intra prediction如何从H.264/AVC的9种模式演变到HEVC的35种,虽是匠心不改、历经雕琢、但可作为锦上添花之物了。


再次,当一个个小的局部性问题逐个攻克后,就需要回归全局性视角,对之前已有的结论和观点再次推敲。多媒体项目产品中往往会遇到技术指标之间的冲突和矛盾,例如:开启复杂的算法工具可以获得更高的压缩效率,即同等码率下可以有更高的图像清晰度,但在中低端设备上复杂度过高会导致编码帧率上不来,严重时用户甚至会觉得画面有明显的顿挫感、通话质量不好。如何在一对对矛盾中取得权衡,既需要对每个指标背后的技术原理有深刻的理解,同时更要求对整体业务需求和应用场景有所把控。懂得取舍、合理平衡,也是多媒体开发进阶的必由之路。


最后,身处互联网行业,自然要重视信息的交流。但我个人不建议白纸一张时就盲目交流,也对很多自媒体鼓吹的碎片化干货学习保留怀疑。我建议初学者在具备一定基础后,带着自己的理解、感悟和困惑去交流,切勿人云亦云、东施效颦,对所谓大公司的“成功案例”、“领先指标”最好在充分对比业务场景、成本投入、平台差异、目标用户群等等因素后进行消化,并为我所用。


One more thing,不要沉迷“专”家、更不要将专长Codec算法居于这个行业的鄙视链(如果存在的话)顶端。好比一款理想中的手机,要纵享丝滑般的用户操作体验,绝非植入一款高端的CPU芯片就能搞定。一套完整的音视频产品,要打造端到端的用户体验,需要考虑CDN调度接入、媒体文件存储分发、流媒体传输、客户端网络连接等等环节,其间相互配合、制约、平衡,哪里是单纯的Codec或者某个算法就能决定得了。偶尔有兄弟找我咨询问题,往往开场就说因为Codec性能不好导致他们的画面很卡啦、CPU占用率高啦、延时很大啦之类,似乎所有的矛头都指向高大上且神秘的Codec模块。那么在我们给Codec扣上背锅侠的大黑帽之前,是不是去看看项目工程中有没有低效的RGB与YUV互转、有没有一次又一次漫不经心的memcpy而只为把解码后的Raw Data在一层层callback之间传递?还有那些在thread中任性的sleep,以及蹩脚的AVSync等待,这些都是杀人不见血的高手啊。


LiveVideoStack:编码器压缩率与编码复杂度似乎是一对矛盾。在实时编解码场景,复杂度是关键的指标,对此你有哪些体会?


李大龙:实时音视频应用,压缩率与复杂度的矛盾非常突出。虽然可以投入精力进行诸如算法汇编指令等优化工作,但在有限的计算资源和处理时延要求下,面对无限的更清晰更流畅的视听体验需求,单纯的Codec优化往往显得杯水车薪。两全其美的办法似乎不存在,以下谈谈自己作取舍和权衡的体会。


第一,是物尽其用原则。常有论调把智能手机划归为快速消费品之列,我们也能看到市场更迭很快。随之而来的问题就是用户侧机型分布极其碎片化,各机型CPU/GPU计算能力、屏幕分辨率、视频硬件模块等方面的差异很大。所以,我们在哭喊“不可承受的复杂度”之前,其实很有必要先想想到底可以承受的复杂度上限在哪里?通常的做法是建立一个能力模型,将给定机型的软硬件条件折算成一套视频参数集,这个集合可以包括:默认情况下使用的Codec格式、默认情况下使用硬件/软件Codec、最高图像分辨率、码率、Codec的Profile、帧率等。很多视频聊天应用,在会话建立阶段,往往也会进行通话两端机型能力交换,然后按照木桶原则,来商定出最终通话过程中的Codec参数。


第二,贴合业务场景需求、抓住主要矛盾。上文也提到过,音视频产品往往需要权衡和取舍,以争取到端到端的整体表现和用户体验。以下有3个典型的场景举例:


  1. 点对点视频聊天、视频会议场景。这类用户场景对时延的要求很高,以至于传输协议很多时候是基于UDP的私有协议。甚至可以说,时延以及图像声音的连续性就决定了用户体验,而单帧图像的分辨率、纹理细腻度等,应该让位给前者。换言之,Codec的压缩率可以作出一定程度牺牲。因为可以预期的是,我们输入的图像分辨率不会太大、目标输出码率也不会太高,所以我们可以选择baseline方案、关闭B Frame类型、限制P Frame的参考范围等等。这种场景下,对Codec的更大期望,反而是追求输出码率的平稳,尽量避免发送数据量的陡变。


  2. 个人直播、典型的1 vs. N场景。这类应用对时延的要求相比会议应用要宽松不少,协议侧往往使用RTMP推流(主播端)和HTTP FLV/HLS播放(观众端)。显然,用户对图像质量有了较高的期望,图像分辨率和码率会向高位倾斜。此时的Codec应该尽力迎合质量的要求,提升压缩率、提升宝贵的上行带宽利用率,但需要留意的底线是Codec编码效率切勿直接造成(发送端)帧率低下、或者码流输出的严重滞后。如上文所言,我们需要建立和完善机型能力模型,另外APP内部具备不同档位码流切换的策略和能力。


  3. 拍摄类短视频场景。严格意义上这个不算实时场景,但考虑拍摄环节所见即所得的用户体验要求,我也一并讨论。这个场景下,对图像质量的要求极高,拍摄阶段需要尽可能快地响应用户回看、编辑等操作,发表阶段则一般是异步式的文件上传,所以时延完全是个伪命题。重点说下拍摄阶段的Codec要求,因为图像质量极高,所以按理应该极致追求压缩率,但如此一来,几乎必然影响用户回看操作的响应时间。可行的方案是转换思维,在拍摄阶段尽可能快、且保留图像细节,硬件Codec、高码率、“粗糙”的压缩算法配置为先;等待拍摄完成后,再开启复杂的Codec算法工具,作二次压缩,提高压缩率、保障发布阶段的上行效率。


LiveVideoStack:在下一代编解码器的市场,HEVC、AV1或其他产品中你更看好谁?


李大龙:现阶段在国内市场,以H.264/AVC和HEVC为主的MPEG阵营占据了绝对份额。如果扩大到全球范围,VP8/VP9的流量份额或许能形成一定挑战。这背后当然主要是Google在全球互联网领域的主导地位。


纯粹技术层面的比较,有关压缩效率、编码复杂度、解码复杂度等等,已经有太多的专业评测报告。抛开细节的数据,至少目前可以看到:MPEG阵营和Google开源阵营,并没有哪一方是绝对完胜的。所以,到底是吃麦当劳还是肯德基?买单反,是选佳能还是尼康呢?虽然技术参数上难分高下,但综合其它因素,我个人更看好MPEG阵营。


首先,视频Codec市场是很广义的。既存在于急吼吼的互联网行业,也分布在慢吞吞的传统行业。直接或者间接使用Codec产品的人,既有穿梭在科技园中的格子衫工友,也有扛着昂贵设备、扎马尾的直男艺术家。更换Codec、更换软硬件产品,对于前者是创新可以吹牛逼,对于后者是成本要破财。从技术生态链、产业完备性,包括技术品牌的延续性来看,MPEG阵营的地盘甚至可以形容为固若金汤。


其次,大家现在津津乐道于双雄争霸的局面,最直接的动机莫过于版权问题。大家心里的算盘应该比较类似:万一哪天MPEG伸出魔爪扼住我的喉咙,那么敌人的敌人就是我的朋友。道理如此,但存在一些变数:


  1. VP8/9、AV1自身是否足够“干净”?目前提出的视频编码标准都是基于变换编码和运动预测的混合框架模式,相同步骤下的算法工具设计理念比较类似。HEVC(包括其后代VVC)与AV1在技术方案上的交集可谓盘根错节,如果Google真格地执意颠覆MPEG的技术领地,可能会触发旷日持久的专利互诉大战。


  2. 也许有明修栈道、暗度陈仓的办法。大公司、巨头企业可以通过参与视频编码标准化的方式主动加入专利池,小公司则可以通过向大公司购买技术服务的方式来规避或者打擦边球。


  3. 今年年初MPEG创始人兼主席主动撰文,反思MPEG专利模式的危机。也许大家臆想中最大的敌人,从内部被攻破了呢?


最后我还想表达自己的另一点看法:技术发展的百家争鸣是行业大幸,但标准化的分歧对峙,我更倾向于认为是劳民伤财。虽然综合来看,我个人更看好HEVC及其续作VVC,但我也希望若干年后谈起VP8/9、AV1时大家不光想到的是Google亲儿子和免费午餐这样的字眼。我很期待AOM联盟能够在某些细分领域,例如:甚低时延的恒定码率应用、超大规模点云空间重建应用,在这些或小众或前卫的领域上能够突围而出、另立乾坤。作为技术人员,相比新的商业模式,我更期待有新的技术流派和产品应用给这个行业注入动力。


LiveVideoStack:能否聊聊AI在多媒体领域的应用的现状及未来机会?


李大龙:这一波AI热潮的兴起,最大的推手之一可归为Deep Learning在Computer Vision上的突破。作为近缘的技术领域,AI对多媒体领域的赋能可谓是全方面的。限于我个人的知识体系,无法呈现全盘透彻的梳理,只能基于我熟悉的业务场景做以下零散举例描述。


在内容编码侧,基于AI技术的感知编码方案已经大行其道,而且在降低带宽成本、提升图像质量方面的效果令人振奋。有关感知编码、Content Aware Encoding方面的技术内容,LiveVideoStack社区有长期深入的持续性报道,大家可以自行查阅。目前AI技术很多是Codec层以上,以辅助者角色来参与编码,并没有直接替换Codec框架内的算法工具。这既是出于码流标准兼容性的考虑,同时也带来一个有趣的问题:H.264/AVC借助AI辅助编码后,几乎就能完成大部分HEVC之于H.264/AVC的带宽节省目标,而我们知道HEVC的解码复杂度高、且目前HEVC解码设备并没有全面普及,所以这是否意味着HEVC的登基加冕日期还得放缓延后呢?


除参与编码过程外,AI应用于图像质量评测,尤其是无参考图像质量评测,我个人认为是非常值得关注的。多媒体数据压缩的根基很多时候就是利用人类视觉听觉上的“迟钝”或者掩蔽效应,而现行客观指标PSNR/SSIM更多是对信号差异的数学性建模,VMAF已经融合累计了主观评测的因素,那么未来是否有更加符合人眼特性的评价模型呢?而且可以预期的是,评价模型的深度变革或者历史性突破,必然会反哺引爆编码算法的跃进式发展,且让我们拭目以待。


在内容传输侧,无论像微信视频聊天、FaceTime类型的RTC应用,还是Netflix、腾讯视频这样的大规模流媒体点播应用,服务提供商都很重视用户体验的建设。传统QoS的思维,会着力于追踪丢包、时延、错误、缓冲等这样的客观技术指标,而转变为QoE的思维后,则需要全局考虑各项指标对用户体验的影响。QoE的困难之处就是难以严谨数学建模,而使用类似统计拟合的办法,需要投入可观的用户调研,周期长、实际效果有待验证。自适应流媒体架构,对前后台的部署要求不高,目前业内都在广泛使用以提升QoE。传统的BBA(Buffer Based Adaptation)和RBA(Rate Based Adaptation)算法对复杂变化场景的适应性不好,MIT团队基于强化学习的流媒体系统Pensieve(http://web.mit.edu/pensieve/)给大家提供了不错的参考思路,目前这个项目已经开源,大家也可去了解下。


最后,在客户端播放器层面,AI的应用更是花样繁多。比如在图像后处理算法环节,基于AI的实时视频超分辨率算法,相比传统的插值算法,能够有更好的细节表现,也被寄希望用小图像呈现高一档分辨率的主观体验、以变相节省带宽成本。AI技术的发展已经渗透到全产业链,芯片商推出NPU概念、Apple/Google在各自的系统Framework层提出ML解决方案、成熟的DL框架也在逐步推出适合移动平台的Lite版本。可以预见的是,未来AI算法会在移动端以轻量模型的方式被广泛实施,提供像SDR反向tone mapping、输入低分辨率向空间域提升、输入低帧率向时间域扩展等等超越传统算法的能力,把视听享受的“脑补”程度提到一个新高度。


来自: LiveVideoStack
文章点评
相关文章