纹路科技CTO赵凌：多格视频互动的技术实现 | 又拍云Open Talk 2018音视频技术沙龙·北京站

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 要实现的核心功能有以下三个：

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

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

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

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

• 最上层：客户端，包括有 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、视频模型

△ 视频抽象模型

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

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

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

b、使用开源框架

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

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

c、模型的作用

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

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

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

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

d、个性化问题解决实例

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

△ 四格作品声音画面校准

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

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

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

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

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

方案演进及展望

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

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

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

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

关注公众号：拾黑（shiheibook）了解更多

[广告]赞助链接：

四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/