7 月 28 日,又拍云 Open Talk | 2018 音视频技术沙龙·北京站顺利落幕,这是2018 音视频技术沙龙的第三站。

活动现场,在来自纹路科技的 CTO 赵凌在沙龙上做了《多格视频互动的技术实现》的分享。赵凌曾历任小米 TV 技术总监、阿里巴巴旗下天天动听技术总监、豆瓣技术总监等职,业内资深的系统架构师之一,在服务系统构建、流媒体、社交产品及内容推荐方面有丰富的技术经验和深入的技术研究。



▲ 纹路科技 CTO 赵凌

本次分享,赵凌主要介绍了动次 APP 产品的定位和特色,以及为了实现这样特色的产品采取的一些技术方法,包括使用通用的解决方案、个性化问题的处理等,并对产品和技术方案做了展望。动次 APP 是纹路科技旗下的音乐短视频产品,纹路科技是一家以自主研发运营推广为一体的新型互联网公司,主要的研发方向为音乐短视频方向和移动语音互动娱乐社交媒体,旗下包括黑黑”“动次”已经上线。

以下是分享实录:

短视频业务问题分析

1、短视频百团大战



各种直播产品 APP

在移动互联网领域,产品风口变化越来越快,比如之前的团购网站面临迅速增长的情况。从 2016 年开始,直播成为风口,如上图,当时的很多产品在图中没有列出来,而大家能记住并且还在运营的产品现在已经很少了。这说明我们现在面临的业务问题——发展的速度越来越快,风口很可能在一年甚至更短的时间内,就经历了从出现、达到高潮、百花齐放的过程。

我们目前面临的短视频领域,其实已经出现了之前团购、直播等行业的情况,短视频行业的发展速度比它们更快。今年 4 月份的一个简单的统计表明,做短视频产品已经有 400 多家企业,现在已经不止 400 多家了,各个巨头已经入场, BAT 和所有带有流量的平台都推出了短视频应用。纹路科技在 2017 年 5 月开始做“动次”这个产品,当时我们感觉短视频的风口已经起来了,很多巨头还没有入场,但是时间紧迫性又非常明显。

在短视频领域,面临以下几个业务问题:

第一,内容同质化非常严重,我们现在看到的短视频平台,不管是抖音、快手、秒拍等,内容都非常相似;

第二,用户留存率很低,因为需要靠内容黏住用户,而内容的同质化又很严重,因此用户对平台是没有忠诚度的,留存率就比较低;

第三,商业模式上变现模式比较单一,这个会带来资本层面的焦虑,资本会对产品提出很高的要求,要求产品尽快地成熟增长,但是只有在产品拥有一定的用户量之后,才会有一些商业模式的出现;

第四,竞争激烈迭代速度快,目前移动互联网行业,虽然风口出现很多很快,但是同一时间可以跑的赛道很少,导致出现的赛道上的竞争非常激烈,产品的迭代速度也一定会非常快。

2、动次App选择的业务方向

在技术上,我们也面临着很多很现实的考验,上面提到了那么多问题,技术上是不是可以支持产品层面来解决,做一些和别人不一样的产品呢?如果技术上可以实现的东西和其他产品做的都一样,那么产品就进入了一个红海,所以我们当时在设计产品的时候,在业务上做了这样几个选择。

首先定位是音乐短视频互动社交产品,市场定位是基于视频内容和音乐属性进行互动的社交平台。明确了这样的定位,就会在技术上提出和通用短视频产品不一样的技术要求。它的核心功能是通过多格音乐视频,分轨进行自由拼接,每格视频和音频都是独立的。

那如何从技术层面来解读这些业务需求呢?以多格音乐视频处理为例:

普通视频:音频流和视频流是分开的,视频流上一定是一格画面;多格视频视频互动:多格视频在客户端会有视频、音频进行合成、拼接的问题,多格视频拼接比较复杂,可能会有四格的切分,甚至六格。广电领域其实已经有视频的剪辑功能,即“非线性编辑”,这在移动互联网领域被强化了。我们在看电视的时候会有一个大的屏幕画面 ,在画面中会有一个画中画,可能是一个导播做手语解说,也有可能是远程的连线。

同时多格如果想让视频更生动,可能需要的不是一个静态的切分,会涉及到格与格之间的动画,同一格还会有转场的要求。

音频也是一样,对于我们原有的视频产品形态,音频有单轨、双轨(立体声)、 5.1 声道等,但是在普通情况下都是一个声音的场景, 如果是存在多格视频拼接,就会有多个场景下音频合成的需求。

我们的市场定位是做一个音乐短视频的产品,那么用户对视频质量的要求随着手机屏幕的分辨率越高要求也越高,而对音乐的要求也越来越高。对于人声我们需要解决 300 赫兹到 3.4K 赫兹的问题,但是对于音乐,乐器的音频范围和动态范围要比人声大得多,音乐对声音提出了更高的要求。

3、产品核心功能与技术架构

动次 APP 要实现的核心功能有以下三个:

image.png

首先是”一人多角“,一个人完成一场戏,分别演绎四个角色,分四次完成,内容上把这四个视频同时呈现;

第二种是多格互动,类似乐队的模式,有四个人一起合作完成一首歌,但是四个人不在一起,A 角色录完,然后 B 角色进入创作,C、D 依次进行,这种是比较特殊的演绎形式,叫阿卡贝拉,主要是靠和声形成音乐;

第三种是内容裂变,是第二种衍生出来的一种形式,也就是在其他人完成作品后,你可以加入这个创作,也可以替换其中一个人,内容生产一次可以被多次使用。

image.png

面对这个问题,我们提出了自己的技术架构,其实所有移动互联网的短视频应用和服务都是这样一个架构。

  • 第一层:客户端,包括有 App、小程序和 H5;
  • 第二层,有 API 服务、消息服务和短视频的视频服务;
  • 底层:按照业务功能分为内容、用户、推荐、日志、push、搜索、审核等服务。

大致的技术架构大家应该都是一样的,即使不是音视频的产品也会面临这些问题,而对于音视频产品,还会有转码服务、内容存储、CDN 分发敏感信息审核等需求。

通用方案的优势和不足

1、通用方案的优势

面对这样的技术架构,如何在很短的时间内形成稳定的产品?产品从提出创意到上线,可能只有两个月时间,技术人员面对这样的一个需求的时候一定会选择一个通用的方案。实际上,对于前面提出的技术架构,每一小块的技术实现,按照人/月的工作量来计算,即使是一个熟手也都需要 2-4 周的时间,即 0.5-1 人/月,而且这个还是在相对比较熟悉这个领域的情况下。

所以我们选择通用方案,通用方案会带来哪些好处呢?

第一是速度,所有的技术人员都会被老板、产品、市场、运营人员催,当一个需求被提出来,会问你什么时候可以实现。这种情况都不是按照周来计算的,而是按照天来计算。

第二是弹性,对于一个互联网产品,用户增长的速度的曲线一定是很陡峭的,一开始用户日活可能就几十、几百个人,然后很迅速就会达到上千、上万,所以对于架构的弹性要求就会非常高,包括硬件和软件。我们不能一开始就要求上架、部署四台设备,因为一开始我们的用户量很少,一台设备就足够把所有的数据库、队列、服务放进去,但是转眼一周之后,用户量上去了,所以对弹性的要求通用方式还是很有优势的。

第三是可用性和稳定性,一个好的服务,很多时候是靠人来堆出来的,一个好的运维人员能解决很多的技术问题,但是对于一个初创公司,能否找到足够的人进行 7×24 小时运维是个问题。

第四是降低了人员成本和运营成本。

第五,上面四个问题的解决,可以让技术人员聚焦到业务问题。

  2、音视频处理的公共问题

上面提到了很多技术问题,下面我们看下在做这样一款音视频的社交产品,在音视频领域我们需要面对的问题:

a、采集

采集问题关系的是内容的来源,在手机端我们不得不面对音频的问题,包括降噪、回声、耳返、均衡等。

耳返的是在录制的时候,录制者需要听到自己的声音,这种需求在高质量的音频录制的时候一定会出现。在录制的过程中,如果直接拿手机麦克风录制,录制质量是很差的;通常选择用耳机来做录制,因为耳机上有一个麦克风,但此时录制者是无法听到自己的声音,声音会被耳机隔离,只能听到伴奏的声音,所以会要求把自己的声音在耳机中能够听到。

在视频方面,大家普遍会面临包括美颜、滤镜、特效和 AR 贴纸等技术问题。此外,采集端还要完成合成和压缩的问题。合成功能是我们产品需要面临的问题,因为我们有多个视频合并到一个画面的需求,而且这个合成不是简单的画中画;压缩功能是为了减少上传的压力。

b、转码

转码要考虑编码格式、参数优化、分片转码提高并行度以及水印等。

C、上传

上传的时候需要考虑多点接收的问题,因为我们面对的是一个非对称的网络,下行速度可能是一百兆,但是上行可能只有十兆,上传很容易失败;分片上传可以提高大文件上传的成功率;此外还要考虑日志优化,根据日志不断调整网络。

D、CDN

CDN 大家面临的问题都是相近,这里就不多做阐述。

 3、通用方案的不足

我们的产品使用了通用方案,产品花了两个多月的开发时间就上线了,上线以后发现了一些问题,比如某个功能的确是可以使用了,但是却并不完美,存在以下的问题:

首先,同质化问题比较严重。采集端我们使用了一个公共的 SDK ,试图来解决音视频的问题,做出的产品大家都差不多,目前市场面 400-500 个短视频产品,除了极个别做出特色,大部分能录制出来的视频都很相似。

其次,无法满足产品迭代的需求。当产品和设计提出一些新的视频玩法时, SDK 支持不了,这些创新需求,SDK 提供方无法预测,甚至当他们拿到了这个需求,也要衡量这个功能会有多少客户需要,是否需要开发这个功能,开发了这个功能对已有功能会不会造成影响。我们当时合作的 SDK ,由于他们的产品的内部逻辑结构导致支持一些功能上比较困难;我们的产品模型设计是按照我们的需求来实现,这样很多功能扩展会很容易,如果产品本身不是按照多格方式来设计,那么增加一点功能需要修改很多,甚至会带来很多 Bug ,因为这些问题导致了我们提出的很多需求,平台没有办法满足。

除此之外,我们产品的一些功能虽然有了,还需要不断的进行优化,这样的情况也没法进行。Bug 的响应也是一个问题,这些是我们在使用通用方案的时候所遇到的问题。

个性化需求及技术实现

1、通用方案无法实现的个性化需求

目前的通用方案很难解决一些个性化需求,我列举一下。

首先是实现灵活的多格拼接功能,因为没有其他产品是这样设计的,所以没有合适的 SDK 可以实现这个功能。

第二个是多轨声音的合成优化,本身在音乐领域的 SDK 很少,而按照多轨方式来制作的更是没有,但实际上对于音乐的多轨合成,音频产业里面一直是如此操作,在录音棚内录完的东西本来就是多轨的,然后一定是调音师把多个声音调试合成在一起。

第三个是比较严格的音画同步,人的耳朵可以区分五十毫秒以上的声音差异,也就是两个声音前后只要相差五十毫秒就可以被完全听出来,因此在一个视频里要实现声音和图像的同步这是很简单的要求,而对于多格视频则要求四格之间的声音都需要对上。

第四个是用 AI 作为桥梁进行声音和画面的互动,是我们产品演化的方向,我们要根据声音的变化控制画面的特效、转场、滤镜等,甚至可以根据画面的情况来进行声音的比较。

其实这些功能点在广电系统的非线性编辑里都实现了,我们真正面临的问题,这对对普通用户来说太难了,如何不做复杂的调整就能够让普通用户在手机上容易实现专业效果。

目前智能手机的硬件情况,它的镜头包括感光是不如单反和摄像机,手机上唯一的优势是有计算能力,有AI加持。比如滤镜,可以每隔五秒换一个,包括特效叠加;但是用户不会用这么复杂的产品,所以很多产品引入了AI,让App根据拍摄的场景不断调整滤镜参数,做简单的色调处理,简单地调整一下变速,就可以让用户拍出来的效果变得高大上,甚至比摄像机拍得好。

2、个性化需求的技术实现

以上都是在介绍产品遇到问题,下面介绍作为技术人到底怎么来解决这些需求。

a、视频模型

image.png

视频抽象模型

如上图,这里将视频抽象成一个画布,画布的尺寸比例可以自定义,上面可以叠加不同的图层,这个模型有点像 Photoshop 。这些图层可以是视频图层或摄像头图层,图上黄色的块可能是图片、文本或水印,这些图层的位置由 SYZ 三个坐标决定,多格视频都可以抽象成这种模型。这个模型比较简单,当前我们实现了视频图层、摄象头图层和图片以及文字的图层。

画布是处理渲染的容器,是一个处理单元,它负责计算它所包含的图层,可以是前台或者后台处理,前台处理完直接可以显示,后台处理会渲染后生成文件或者视频流;图层指媒体元素的处理单元,可以是采集的数据(摄像头)、视频文件、图片或者字幕等,在图层上可以叠加各种滤镜和特效。

对图层进行变换会分成几种,包括滤镜、特效等。滤镜实际上是对画布和图层进行的变换。图层是处理一个区域,画布则是当一个画布生成以后,可以在画布上再叠加一个整屏的特效。这种变换包括了颜色域和空间域,颜色域是色调的调整,比如彩色变成黑白,还有锐度的调整,对比度的调整;空间域是对某个东西做变形处理,比如做百叶窗的效果。

b、使用开源框架

由于时间所限,我们不可能什么都从头开始做,当时我们选择从 GPUImage 作为起始的框架,在此基础上进行实现。GPUImage 是一个开源的基于 GPU 的图片或视频的处理框架,其本身内置了多达 120 多种常见的滤镜效果,性能和处理效果很不错。

由于这里的计算量太大,因此使用 GPU 来计算,CPU 是完全不可能实现的,CPU 处理基本上可以认为是串行的,而 GPU 是并行多管线处理。 GPUImage 是基于 OpenGR 做的,所以已经解决了很多硬件适配的问题。目前硬件适配上 iOS 的情况会好一些,Android的情况会非常复杂,CPU 就已经分为好多种了,因此在制作过程会面临很多的问题,基于这个平台来做麻烦就少很多。

c、模型的作用

上面的模型虽然简单,但是可以实现很多事情。

用统一的模型,对不同的素材进行抽象,兼顾了性能和灵活性。比如对图层进行特效处理,基本不用考虑这是一个文件、图片还是生成的字幕。相对于直接对素材做处理,这种方式性能肯定是会损失的,但是这种损失在可控的范围内。

这个方案的定制性很好,在系统已经实现的滤镜之外,支持照相机和摄像机的实时滤镜,可以比较方便地自定义图像滤镜。实现灵活的平移、缩放、旋转、划出、百叶窗等转场特效。

用这个方案后音频流其实就被提取出来,在这个过程中可以进行灵活的音频数据采集,降噪、回声抑制、耳返、音量控制。目前在音效这块,我们做的还不是很深入,主要基于 FFMpeg 实现多路混音和音效处理。正在开发的是一键修音的功能。

d、个性化问题解决实例

下面举例说明一下个性化方案到底能解决什么样的问题,这些问题在原有方案是完全不可想象的。

image.png

四格作品声音画面校准

上图是一个四格的作品,存在的问题是“声音不齐”。在视频录制的过程中,比如我要录制第四格,在录制的过程中,手机会播放前三格人的表演的内容,然后我听着他们的声音开始唱。在人唱准的情况下,在程序的处理过程中,它的播放和录制是在不同的线程里处理,这些线程之间是没有办法保证做很准确的对齐的。比如播放的线程是在 10 分 10 秒准时开始,但是它的录制却早开始了 0.5 秒,即第四格录制的视频比其他的视频长了0.5秒,我们听的时候就会发现第四格声音比前面三格滞后,此时我们就需要对第四格声音进行校准,包括声音和画面都需要对时间戳进行校准。

上面那栏是一个手工校准的画面,上面是正在播放的声音轨和视频轨,下面那栏的是在发现前面比下面长了,所以需要把前面的一部分裁掉,裁掉以后前面的两个黄条会对齐,这样就解决了下面这个轨比上面滞后的问题。但是这个问题我们不能让用户拿手不停地调整,它的精度可能要到 50 毫秒,点一下至多只能走 50 毫秒,如果点多了就是滞后或者超前,会没完没了。所以我们在技术上就做了这样的事情:

第一种办法是记录视频本身的相对位置,在开始录制后,从五秒的时候开始播放,加入第二轨,这个时候首先要记录播放时候相对位置,同时要记录播放时的系统绝对时间,还要记录录制时候的系统绝对时间,这两个时间之间是有一个差值,这是我们在程序里顺序调用功能的时候一定没有办法完全准时的,然后这个差值会影响到录制下来的第二条内容。那么用这个差值对第二条内容进行剪裁,合并到这个时间相对应的位置上,这其实就是进行多轨优化的基本原理。只要这三个数据可以记得很准,就可以对得毫厘不差,可悲的是这个是不可能记得很准,因为本身记录也是一个系统调用,而且情况复杂,不同的手机,不同的录制方式都不一样。

经过这样处理会发现绝大部分都很准了,但是还是会发现有一部分比较低端的手机,不光是Android,包括了iOS的,还不是很准,对于这些性能较差的手机,通过云端,根据手机型号下发调整参数。

在以上两种方式都无效的情况,会提供手动校准界面,因为如果用户本身自己唱的不准,你还得让他有办法,这个时候会提供手动校准界面。

方案演进及展望

在基本的功能实现优化的差不多的情况下,我们现在在这个方案上还有以下的一些事情可以做,而这些事情也基本上决定了一个产品是否成功,是否与通用的东西不同,如果你真的做出一些不一样的东西给用户带来价值,这个产品才有成功的可能性。

第一个,基于对画面的实时场景分析,自动调整滤镜的参数,短视频领域已经有一些先行的产品做得不错了,像 VUE 的滤镜,你会发现你不选滤镜的时候拍出来的东西就很好看,因为程序本身会分析你的画面,比如录制了一个一分钟的视频,可能前面十秒面对大海,剩十秒里面出现了一个人,再后十秒就出现了天空,在你的画面变化的过程中,不同的画面它会自动帮助你选择不同的滤镜和不同的参数进行优化,这个对于用户来说是自然的方式,用户只需要去关心录制什么样的内容,而不是在录制过程中去修改滤镜。

第二个,基于对于音频内容的分析,自动进行转场及叠加特效。举例一个场景,我现在有一个视频录制好了,但是录好了以后看起来平平无奇,即使配上一段音乐,画面看起来还是没太大变化。这里实际上可以根据音频的内容,比如音频会有节奏的变化,可能会有小节之间的切分,可以在节奏发生变化的位置,超简单可以对视频速度进行调整,比如快进,做特写,在音频变化的时候,直接做一个放缩,给用户感觉是视频的拉近和放远。

第三个,因为我们做的是一个纯音乐相关的产品,它有一个基本的要求就是一键修音,校准音高、节奏、多轨同步。

OT官网二维码.png