作者 | 西流 阿里云技术专家

前言

随着计算机技术和 Internet 的日新月异，视频点播技术因其良好的人机交互性和流媒体传输技术倍受教育、娱乐等行业青睐，而在当前，云计算平台厂商的产品线不断成熟完善，如果想要搭建视频点播类应用，告别刀耕火种，直接上云会扫清硬件采购、 技术等各种障碍，以阿里云为例：

这是一个非常典型的解决方案，对象存储 OSS 可以支持海量视频存储，采集上传的视频被转码以适配各种终端，CDN 加速终端设备播放视频的速度。此外还有一些[内容安全]审查需求，比如鉴黄、鉴恐等。

而在视频点播解决方案中，视频转码是最消耗计算力的一个子系统，虽然您可以使用云上专门的转码服务，但在很多情况下，您会选择自己搭建转码服务。比如：

• 您已经在虚拟机/容器平台上基于 FFmpeg 部署了一套视频处理服务，能否在此基础上让它更弹性，更高的可用性？

• 您有并发处理大量视频的需求；

• 您有很多超大的视频需要批量快速处理完，比如每周五定期产生几百个 4G 以上的 1080P 大视频，但是希望当天几个小时后全部处理完；

• 您有更高级的自定义处理需求，比如视频转码完成后，需要记录转码详情到数据库，或者在转码完成后，自动将热度很高的视频预热到 CDN 上，从而缓解源站压力；

• 自定义视频处理流程中可能会有多种操作组合，比如转码、加水印和生成视频首页 GIF。后续为视频处理系统增加新需求，比如调整转码参数，希望新功能发布上线对在线服务无影响；

• 您的需求只是简单的转码需求，或是一些极其轻量的需求，比如获取 OSS 上视频前几帧的 GIF、获取视频或者音频的时长，自己搭建成本更低；

• 各种格式的音频转换或者各种采样率自定义、音频降噪等功能；

• 您的视频源文件存放在 NAS 或者 ECS 云盘上，自建服务可以直接读取源文件处理，而不需要将它们再迁移到 OSS 上。

如果您的视频处理系统有上述需求，或者您期望实现一个弹性、高可用、低成本、免运维、灵活支持任意处理逻辑的视频处理系统，那么本文则是您期待的最佳实践方案。

Serverless 自定义音视频处理

在介绍具体方案之前，先介绍两款产品：

• [函数计算]：阿里云函数计算是事件驱动的全托管计算服务。通过函数计算，您无需管理服务器等基础设施，只需编写代码并上传。函数计算会为您准备好计算资源，以弹性、可靠的方式运行您的代码，并提供日志查询、性能监控、报警等功能。
• [函数工作流]：函数工作流（Function Flow，以下简称 FnF）是一个用来协调多个分布式任务执行的全托管云服务。您可以用顺序，分支，并行等方式来编排分布式任务，FnF 会按照设定好的步骤可靠地协调任务执行，跟踪每个任务的状态转换，并在必要时执行用户定义的重试逻辑，以确保工作流顺利完成。

函数计算可靠的执行任意逻辑，逻辑可以是利用 FFmpeg 对视频任何处理操作，也可以更新视频 meta 数据到数据库等。

函数工作流对相应的函数进行编排，比如第一步的函数是转码，第二步的函数是转码成功后，将相应 meta 数据库写入数据库等。

至此，您应该初步理解了函数计算的自定义处理能力 + 函数工作流编排能力几乎满足您任何自定义处理的需求，接下来，本文以一个具体的示例展示基于函数计算和函数工作流打造的一个弹性高可用的 Serverless 视频处理系统，并与传统方案进行性能、成本和工程效率的对比。

1. Simple 视频处理系统

假设您是对视频进行单纯的处理，架构方案图如下：

如上图所示，用户上传一个视频到 OSS，OSS 触发器自动触发函数执行，函数调用 FFmpeg 进行视频转码，并且将转码后的视频保存回 OSS。

[OSS 事件触发器]，阿里云对象存储和函数计算无缝集成。您可以为各种类型的事件设置处理函数，当 OSS 系统捕获到指定类型的事件后，会自动调用函数处理。例如，您可以设置函数来处理 PutObject 事件，当您调用 OSS PutObject API 上传视频到 OSS 后，相关联的函数会自动触发来处理该视频。

强大的监控系统：

您可以直接基于示例工程部署您的 Simple 音视频处理系统服务，但是当您想要处理大视频（比如 [test_huge.mov]）或者对小视频进行多种组合操作的时候， 您会发现函数会执行失败，原因是函数计算的执行环境有最大执行时间为 10 分钟的限制，如果最大的 10 分钟不能满足您的需求， 您可以选择：

为了突破函数计算执行环境的限制（或者说加快大视频的转码速度），进行各种复杂的组合操作，此时引入函数工作流 FnF 去编排函数实现一个功能强大的视频处理工作流系统是一个很好的方案。

2. 视频处理工作流系统

如上图所示，假设用户上传一个 mov 格式的视频到 OSS，OSS 触发器自动触发函数执行，函数调用 FnF，会同时进行 1 种或者多种格式的转码（由您触发的函数环境变量 DST_FORMATS 参数控制）。所以您可以实现如下需求：

• 一个视频文件可以同时被转码成各种格式以及其他各种自定义处理，比如增加水印处理或者在 after-process 更新信息到数据库等。
• 当有多个文件同时上传到 OSS，函数计算会自动伸缩，并行处理多个文件，同时每次文件转码成多种格式也是并行。
• 结合 NAS + 视频切片，可以解决超大视频（大于 3G ）的转码，对于每一个视频，先进行切片处理，然后并行转码切片，最后合成，通过设置合理的切片时间，可以大大加速较大视频的转码速度。

所谓的视频切片，是将视频流按指定的时间间隔，切分成一系列分片文件，并生成一个索引文件记录分片文件的信息。

示例效果：

3. 函数计算 + 函数工作流 Serverless 方案 VS 传统方案

1）卓越的工程效率

2）弹性伸缩免运维，性能优异

函数计算 + 函数工作流 Serverless 方案转码性能表：

实验视频为是 89s 的 mov 文件 4K 视频：[4K.mov]，云服务进行 mov -> mp4 普通转码需要消耗的时间为 188s， 将这个参考时间记为 T。

性能加速百分比 = T / FC转码耗时

从上表可以看出，设置的视频切片时间越短，视频转码时间越短，函数计算可以自动瞬时调度出更多的计算资源来一起完成这个视频的转码, 转码性能优异。

3）更低的成本

• 具有明显波峰波谷的视频处理场景（比如只有部分时间段有视频处理请求，其他时间很少甚至没有视频处理请求），选择按需付费，只需为实际使用的计算资源付费。

• 没有明显波峰波谷的视频处理场景，可以使用预付费（包年包月），成本仍然极具竞争力。

假设有一个基于 ECS 搭建的视频转码服务，由于是 CPU 密集型计算，因此在这里将平均 CPU 利用率作为核心参考指标对评估成本，以一个月为周期，10 台 C5 ECS 的总计算力为例，总的计算量约为 30% 场景下, 两个解决方案 CPU 资源利用率使用情况示意图大致如下:

由上图预估出如下计费模型：

1. 函数计算预付费 3CU 一个月：246.27 元，计算能力等价于 ECS 计算型 C5；

2. ECS 计算型 C5 (2vCPU,4GB)+云盘：包月219 元；

3. 函数计算按量付费占整个计算量的占比 <= 10%，费用约为 3×864×10% = 259.2 元，（3G 规格的函数满负载跑满一个月费用为：0.00011108×3×30×24×3600 = 863.8）

在这个模型预估里面，可以看出 FC 方案具有很强的成本竞争力，在实际场景中, 基于 ECS 自建的视频转码服务 CPU 利用甚至很难达到 20%， 理由如下:

1. 可能只有部分时间段有视频转码请求；

2. 为了用户体验，视频转码速度有一定的要求，可能一个视频转码就需要 10 台 ECS 并行处理来转码，因此只能预备很多 ECS。

因此，在实际场景中，FC 在视频处理上的成本竞争力远强于上述模型。

• 即使和云厂商视频转码服务单价 PK, 该方案仍有很强的成本竞争力。

我们这边选用点播视频中最常用的两个格式（mp4、flv）之间进行相互转换，经实验验证，函数内存设置为 3G，基于该方案从 mp4 转码为 flv 的费用概览表：

mp4 转 flv：

flv 转 mp4：

成本下降百分比 = （腾讯云视频处理费用 - FC 转码费用）/ 腾讯云视频处理费用
[腾讯云视频处理]，计费使用普通转码，转码时长不足一分钟，按照一分钟计算，这里计费采用的是 2 min，即使采用 1.5 min 计算， 成本下降百分比基本在 10% 以内浮动。

从上表可以看出，基于函数计算 + 函数工作流的方案在计算资源成本上对于计算复杂度较高的 flv 转 mp4 还是计算复杂度较低的 mp4 转 flv，都具有很强的成本竞争力。 根据实际经验，往往成本下降比上表列出来的更加明显， 理由如下：

• 测试视频的码率较高，实际上很多场景绝大部分都是标清或者流畅视频的转码场景，码率也比测试视频低，这个时候计算量变小，FC 执行时间短，费用会降低，但是通用的云转码服务计费是不变的；
• 很多视频分辨率在通用的云转码服务是很吃亏的，比如转码的视频是 856*480 或者 1368*768，都会进入云转码服务的下一档计费单价，比如 856*480 进入 1280*720 高清转码计费档，1368*768 进入 1920*1080 超清转码计费档，单价基本是跨越式上升，但是实际真正的计算量增加可能还不到30%，而函数计算则是真正能做到按计算量付费；
• 比如一些转码需求就是单纯转封装（不涉及音视频的编解码），或者只转音频，这个计算量基本下降 95% 以上。

总结

基于函数计算 FC 和函数工作流 FnF 的弹性高可用视频处理系统天然继承了这两个产品的优点：

• 无需采购和管理服务器等基础设施，只需专注视频处理业务逻辑的开发，大幅缩短项目交付时间和人力成本；
• 提供日志查询、性能监控、报警等功能快速排查故障；
• 以事件驱动的方式触发响应用户请求；
• 免运维，毫秒级别弹性伸缩，快速实现底层扩容以应对峰值压力，性能优异；
• 成本极具竞争力。

1. 相比于通用的转码处理服务:

• 超强自定义，对用户透明，基于 FFmpeg 或者其他音视频处理工具命令快速开发相应的音视频处理逻辑；
• 原有基于 FFmpeg 自建的音视频处理服务可以一键迁移；
• 弹性更强，可以保证有充足的计算资源为转码服务，比如每周五定期产生几百个 4G 以上的 1080P 大视频，但是希望当天几个小时后全部处理完；
• 各种格式的音频转换或者各种采样率自定义、音频降噪等功能，比如专业音频处理工具 aacgain 和 mp3gain；
• 可以和 serverless 工作流完成更加复杂、自定义的任务编排，比如视频转码完成后，记录转码详情到数据库，同时自动将热度很高的视频预热到 CDN 上， 从而缓解源站压力；
• 更多的方式的事件驱动，比如可以选择 OSS 自动触发（丰富的触发规则），也可以根据业务选择 MNS 消息（支持 tag 过滤）触发；
• 在大部分场景下具有很强的成本竞争力。

2. 相比于其他自建服务:

• 毫秒级弹性伸缩，弹性能力超强，支持大规模资源调用，可弹性支持几万核.小时的计算力，比如 1 万节课半个小时完成转码；
• 只需要专注业务逻辑代码即可，原生自带事件驱动模式，简化开发编程模型，同时可以达到消息(即音视频任务)处理的优先级，可大大提高开发运维效率；
• 函数计算采用 3AZ 部署，安全性高，计算资源也是多 AZ 获取，能保证每个用户需要的算力峰值；
• 开箱即用的监控系统，如上面 gif 动图所示，可以多维度监控函数的执行情况，根据监控快速定位问题，同时给用户提供分析能力，比如视频的格式分布，size 分布等；
• 在大部分场景下具有很强的成本竞争力，因为在函数计算是真正的按量付费（计费粒度在百毫秒），可以理解为 CPU 的利用率为 100%。

最后一一回答一下之前列出的问题：

Q1: 您已经在虚拟机/容器平台上基于 FFmpeg 部署了一套视频处理服务，能否在此基础上让它更弹性，更高的可用性？

A1：如工程示例所示，在虚拟机/容器平台上基于 FFmpeg 的服务可以轻松切换到函数计算，FFmpeg 相关命令可以直接移值到函数计算，改造成本较低，同时天然继承了函数计算弹性高可用性特性。

Q2：您的需求只是简单的转码需求，或是一些极其轻量的需求，比如获取 OSS 上视频前几帧的 GIF 等。自己搭建成本更低。

A2：函数计算天生就是解决这些自定义问题，你的代码你做主, 代码中快速执行几个 FFmpeg 的命令即可完成需求。

Q3: 您有更高级的自定义处理需求，比如视频转码完成后，需要记录转码详情到数据库，或者在转码完成后，自动将热度很高的视频预热到 CDN 上，从而缓解源站压力。

A3：详情见视频处理工作流系统（函数计算 + 函数工作流方案），after-process 中可以做一些自定义的操作，您还可以基于此流程再做一些额外处理等，比如：

• 再增加后续流程
• 最开始增加 pre-process

Q4: 您有并发同时处理大量视频的需求。

A4：详情见视频处理工作流系统（函数计算 + 函数工作流方案）, 当有多个文件同时上传到 OSS，函数计算会自动伸缩，并行处理多个文件。

Q5：您有很多超大的视频需要批量快速处理完，比如每周五定期产生几百个 4G 以上的 1080P 大视频，但是希望当天几个小时后全部处理完。

A5：可以通过控制分片的大小，可以使得每个大视频都有足够多的计算资源参与转码计算，大大提高转码速度。

Q6: 自定义视频处理流程中可能会有多种操作组合，比如转码、加水印和生成视频首页 GIF，后续为视频处理系统增加新需求，比如调整转码参数，希望新功能发布上线对在线服务无影响。

A6：详情见视频处理工作流系统（函数计算 + 函数工作流方案）, FnF 只负责编排调用函数，因此只需要更新相应的处理函数即可，同时函数有 version 和 alias 功能，更好地控制灰度上线。

Q7: 您的视频源文件存放在 NAS 或者 ECS 云盘上，自建服务可以直接读取源文件处理，而不需要将他们再迁移到 OSS 上。

A7：直接对 NAS 中的文件进行处理。