写点什么

短视频这么火,微视的特效是怎么做的?

  • 2019-10-29
  • 本文字数:3968 字

    阅读完需:约 13 分钟

短视频这么火,微视的特效是怎么做的?

在 AlphaGo 名声大噪之前,围棋是一项少有人问津的娱乐项目,不信你可以在记忆里细数一下,当时身边有多少个朋友会下围棋(AlphaGo 出名后一时兴起下两把的咱们就不算数了)。相比之下,德州扑克的普及程度就要好的多,以至于我们团队有一次年会就放弃传统抽奖方式,而是靠德州扑克决定奖品名单的。


为什么高大上的围棋比不上德州扑克受欢迎呢?规则太复杂吗?


真正的原因是围棋的门槛太高了。在围棋里,水平的高低说带来胜率差异是碾压式的。对于两个围棋选手而言,如果棋艺差一级,那么对弈时弱者几乎没有赢的可能。这就让围棋变成了一群高智商玩家的小圈子游戏,刚入门的进来感觉就是找虐。而德州扑克则不是,不管你是不是行家,运气的成分总还是起了很大的作用,这就让它本身适合成为一款所有人都容易接受的游戏。


视频编辑也是如此,在电脑能够处理多媒体工作之后不久,就出现了很多的视频编辑软件。比如我过年回家,就能在长辈的书架上看到一本《会声会影 从入门到精通》。长辈退休了在家搞搞摄影,想要给自己拍的照片和视频加点特效或者做个剪辑,就会用到这类专业软件。我随手翻了几页,很快就没兴趣了,里面太多流程化的操作,需要我花不少的时间去研究和练习,而我缺乏学习这款软件的动力。


由此可见,入门门槛的高低,决定了一项活动或是一款产品,是被大众所普遍接受,还是停留在一个很小的专业圈子里。


就在不久之前,视频编辑还是一个小圈子的活动,纵使很多人有兴趣创作自己的小视频,在专业工具的入门门槛面前,也就选择洗洗睡了。短视频 APP 的出现,让大家的入门门槛一下子变低了,你只要会用手机,就能快速的给自己拍的视频加一些特效,做一些个性化的编辑。


短视频这么火,背后的技术实现绝不是交互层面的一个简单调整,而是一个复杂的故事。今天,我就带您一起来看一看,这背后的技术故事。

短视频编辑原理

下图简单的展示了视频编辑的一个大体流程,这在所有的视频编辑软件里都是类似的:



第一个需要了解的细节是,手机上的影片(比如 mp4 或者 mov) 都是不能直接拿来做特效编辑的,因为里面的数据都是经过压缩的。直接编辑这些编码后的影片是很困难的,我们在不解码影片文件的情况下,最多也就是做一下简单的裁剪和拼接。


举个现实生活中的例子,比如说你刚搬了新家,带着你的爱人去宜家挑选家具,宜家的服务很人性化,他们会在你进门的时候会给你一张卡片和一支铅笔,这样你就可以把想买的家具或则配件的编号记录下来,之后你可以去仓库一件件的取货,或者去办理送货上门服务。这一切都很方便,直到买单时你发现预算超了,于是决定要把一些比较贵的型号换成比较便宜的型号。但这个时候困难也出现了,因为只有编号你是做不到的,你得回到展示区按商品编号对号入座,然后才能知道有没有心仪的便宜款商品可选。否则你能做的也就只有从商品列表里把一些型号划掉。


视频编辑也是一样,已经经过编码的影片,再不经过解码的情况下,即使计算机也无法解读文件里蕴含的画面和声音,我们所能做得事情就很有限。这也就解释了上图复杂性的由来:


要做音视频的特效编辑,原始的影片(比如 mp4 或者 mov)必须先被拆解成独立视频流和音频流。以视频流为例,我们要先对视频流进行逐帧逐画面的视频解码,这样解码出来的内容才是一副计算机可以显示的画面。在这幅画面的基础上,计算机才可以理解每一个像素点对应的色彩数值和亮度大小。进一步地,计算机才可以在画面上添加字幕,做动态特效,或者叠加挂件。声音也是一样,编码后的 AAC 文件只适合传输和存储,计算机也是需要先将其解码成 PCM 格式的波形文件,才能知道每一个点的音调高低,进而能够编辑。


视频特效和声音特效都加完之后,还不算结束,因为用户真正想要的是编辑后的视频影片,而不是一幅幅的画面和一段段的声音,所以解码出的画面在经过特效叠加和处理之后,还要再一次地送给视频编码器进行编码,进而跟音频流一起,组合成新的视频影片。

视频预览功能

上述的流程看似复杂,但它只是视频编辑的最后一步,也就是编辑器的“最终生成”的这一步,在这一步之前,必须要有人通过编辑器决定在哪一段时间加什么类型的特效。


但没有人可以凭空知道在影片的第几秒把一个什么特效恰到好处的放置进去,用户需要根据影片的具体内容进行即兴的创作和发挥,所以,我们需要把预览功能作为 P0 特性加入进去。



如上图所示,简单的预览在原理上是一个完全没有技术难度的工作,我们只需要将经过特效处理的画面和声音播放出来即可。这里真正的难点是要优化好画面特效的性能,同时做好音画同步的校对。


因为影片的预览跟单张图片的预览不同,预览过程必须是一个很流畅的体验,否则用户在编辑影片时就会有很明显的卡顿感,导致用户在使用时如骨鲠在喉,难以有好的产品体验。


而性能优化和音画同步也都很好解决,真正困难的是逐帧的画面预览,也就是用户想要看哪一帧的效果,就能立刻如愿,也就是标题里所谓的“心随手动”。


这里,我们将面对一个在技术原理上就很难逾越的困难:

逐帧预览

虽然手机芯片的进步这两年可谓神速,但是功耗的限制决定了 PC 机的性能依然可以碾压手机。但不知你有没有发现,即使在性能这么好的 PC 电脑上,看电影时也会遭遇“拖拽卡顿”现象,也就是当你用鼠标拖拽进度时,能明显感觉卡顿感。


这是因为简单的视频卡顿背后,有一个巨大的性能陷阱,也即是解码器的解码规则,我通过下图来解释一下:



假设你将鼠标从第 3 幅画面拖拽到第 13 幅画面,按照表面上的理解,计算机只需要读取第 13 幅画面的内容,把画面显示出来就行了,这并没有什么难度。


但实际上,编码器在处理第 13 幅画面的时候,为了减少这幅画面的存储空间,只会保留第 13 幅和第 12 幅画面的差异部分。这也就意味着,要想看到第 13 幅画面,计算机需要先把第 12 幅画面解码出来。照此类推,要想看到第 12 幅画面,计算机就需要先把第 11 幅画面解码出来…


最终,计算机需要解码出第 7 幅画面,才能将上述这个循环打破,因为第 7 幅画面比较特殊,编码器在处理这一副画面的时候,并没有参考其它画面,所以这幅画面的内容在还原时,不需要依赖其它画面的内容(也正是因为如此,这幅画面在硬盘上的存储空间比其他画面都要大)。


当然,这里说的都是最简单的情况,由于技术的进步,现在普遍使用的编码器都已经在用 main profile 和 high profile 这种高级的编码模式,画面与画面之间的参考关系更加复杂,不仅仅参考前面的画面,也会参考后续的画面,进一步提升了复杂度和计算量。


这就解释了为什么拖拽本身的等待时间不确定,有时候你可能运气好,正好拖到了上图中的第 7 幅画面,那么如你所愿,画面立刻就切到第 7 幅;但也有可能,你拖拽到了第 14 幅画面,那么计算机只能认倒霉,它要把前面的 7 幅画面全都解码完成,才能切到你想要的那一幅画面上。

视频预处理

为了解决这个问题,我们只有两条路可以走:


一条路是等待摩尔定律进步到处理十几幅画面也只需弹指一挥间的事情,但安迪比尔定理也告诉你,摩尔定律所带来的那点进步会瞬间被 4K、8K 给吃掉。


另一条路就是工程思维解决问题了,我们的做法是:如果是编辑一个已经生成好的 MP4 或者 MOV 影片,我们会先对影片进行一轮预处理,也就是影片在送给编辑器之前,先要经过一轮提前的加工处理,把视频处理的更加易于编辑。



当然,如果你认为仅仅是为了提升逐帧预览的性能就要耗费这么大的精力是不值得的,那其实是多虑了。因为我们的工程师团队会充分利用这段新引入的时间,把很多耗时但又必须要做的事情在这个阶段也完成了,比如,下面图中的预览工具条,就是在预处理过程中每隔一段时间截图拼接实现的。


特效的制作

我们都知道动画的原理本身就是一幅画面到另一幅画面的快速变化,画面之间的微小差异经过累加,使人产生画面运动的错觉。画面变化的越快,人越不容易察觉,因为画面的流畅性也就越好。


我们在短视频编辑器上说添加的各种特效也是遵循这两个原则:


  • 特效本身是逐帧变化的,每一幅特效跟上一幅特效均有细微的差别。

  • 特效的变化跟影片原来的画面变化进行叠加,这样能够确保特效的流畅性自然而不生硬。


以我们在 Demo 中提供的第三个视频特效为例,它是这样实现的:


(1)取原始画面第一幅图像,对其做 1.1 倍的图像放大,之后截取中心的部分,然后去掉 50% 的透明度,这样就能得到一张新的半透明图片,这张新的半透明图片是用来形成虚影效果的。它会被叠加在原始图像上,这样一来,我们就得到了处理后的第一幅图像(带虚影特效)。


(2)照此步骤,我们对第二幅图像也做同样的处理,但这次稍有不同的是,不再做 1.1 倍放大,这次我们把放大倍数改成 1.2 倍,这样叠加出来的图像,50%透明度所形成的虚化部分,就相比于上一幅就要扩大了一圈。这扩大出来的一圈如果叠加起来,就可以制造出一种画面向外放射的错觉。


(3)对第三幅画面也是类似的操作,这次我们将放大倍数改为 1.3 倍,因此虚影部分又扩大了一圈…


(4)如此逐步做下去,处理后的图像就会形成一组新的连续动画,而这组新的动画已经包含了我们所期望的视频特效。



相比于其他的部分,特效本身的技术难度是比较简单的,尤其是视频特效的实现。


真正的困难则是来自于定制上的灵活性,由于抽象能力比价若,我们目前还没有把视频特效的制作能力开放出来供开发者自行设计,而是只能用更直接的办法,想到一个做一个。真正要做到客户随意定制,还需要一段时间的努力。


作者介绍:


常青, 2008 年毕业加入腾讯,一直从事客户端研发相关工作,先后参与过 PC QQ、手机 QQ、QQ 物联 等产品项目,目前在腾讯视频云团队负责音视频终端解决方案的优化和落地工作,帮助客户在可控的研发成本投入之下,获得业内一流的音视频解决方案,目前我们的产品线包括:互动直播、点播、短视频、实时视频通话,图像处理,AI 等等。


本文转载自公众号云加社区(ID:QcloudCommunity)。


原文链接:


https://mp.weixin.qq.com/s/aqoLyUHLhctPpoU0vB5I-w


2019-10-29 12:192136

评论

发布
暂无评论
发现更多内容

JAVA 短链码生成工具类

爱好编程进阶

Java 面试 后端开发

git(7)自定义 Git

爱好编程进阶

Java 面试 后端开发

JAVA 序列化、反序列化以及serialVersionUID

爱好编程进阶

Java 面试 后端开发

JavaWeb快速入门--Servlet(2)

爱好编程进阶

Java 面试 后端开发

【国产化替代专题】星环科技春季新品发布周

星环科技

Canal 如何实现数据库库事务的一致性

爱好编程进阶

Java 面试 后端开发

架构训练营模块八

刘帅

ELK + Filebeat + Kafka 分布式日志管理平台搭建

爱好编程进阶

Java 面试 后端开发

Java中的复用类

爱好编程进阶

Java 面试 后端开发

GitOps多环境部署问题及解决方案

俞凡

研发效能 gitops

HashMap + 软引用进行缓存

爱好编程进阶

Java 面试 后端开发

Gitlab Java API 使用示例

Java gitlab 4月月更

week6作业

Asha

Java中高级核心知识全面解析——Linux基本命令

爱好编程进阶

Java 面试 后端开发

Java7日期时间API

爱好编程进阶

Java 面试 后端开发

JavaWeb之Cookie和Session技术(四)

爱好编程进阶

Java 面试 后端开发

模块8-设计消息队列存储消息数据的 MySQL 表格

卡西毛豆静爸

#架构实战营

统计代码耗时的工具

Rubble

4月日更 4月月更

消息队列数据存储表设计

随欣所遇

架构训练营5期

Alibaba2021年船新Java架构师成长笔记开源

爱好编程进阶

Java 面试 后端开发

DDD领域驱动设计实战-分层架构及代码目录结构

爱好编程进阶

Java 面试 后端开发

Flink处理函数实战之三:KeyedProcessFunction类

爱好编程进阶

Java 面试 后端开发

消息队列存储消息数据的mysql表设计

五月雨

架构实战营 「架构实战营」

模块八作业:设计消息队列存储消息数据的 MySQL 表格

炎彬

「架构实战营」

Elasticsearch Query DSL概述与查询、过滤上下文

爱好编程进阶

Java 面试 后端开发

Hibernate和MyBatis的区别比较

爱好编程进阶

Java 面试 后端开发

消息队列存储消息数据的 MySQL 表格设计

李大虾

#架构实战营 「架构实战营」

商业分析:SheIn是怎样成功的?

石云升

跨境电商 商业分析 4月月更

DNS解析时发现域名和IP不一致,访问了该域名会如何(大厂真题

爱好编程进阶

Java 面试 后端开发

【模块八】设计消息队列存储消息数据的MySQL 表格

yhjhero

#架构训练营

市场进展不断,STI 包括ZB等一系列上线预示着什么?

西柚子

短视频这么火,微视的特效是怎么做的?_文化 & 方法_常青_InfoQ精选文章