随着4G网络的普及以及5G网络的展开，单位流量越来越便宜，人们从而能在碎片时间内通过移动网络毫无压力的观看视频内容，抖音在2018年春节突然火爆，全民都在刷抖音。一般来说，用户上传的短视频会自动加上对应短视频App的水印Logo，我们今天就来聊一下视频处理，首先介绍一下视频基本概念和视频处理所用的API、工具。

视频基本概念

• 什么是视频？ 一组图片以给定的速率（例如 30 张图片/秒）在人眼前翻过，人的视觉就会产生一种图片在动的感觉，小时候动画片的制作也是基于这个原理，从这个角度讲，视频可以理解为以一定速率运动的一组图片的集合。
• 帧率：每秒播放的频数，fps(frames per second),拍摄的帧率和播放的帧率一般保持一致。比如，电影或者电视剧以30fps拍摄，然后以30fps播放。对于高速运动的赛车比赛，为了让观众看清赛车到达终点的场面或者两辆实力很接近的选手到底谁赢了，会以高帧率拍摄（比如60fps），然后转成30fps来回放播放，这样就会产生慢镜头，从而让观众看清赛车越过终点那一刹那的完整情形。
• 码率：每秒传输的bit位，bit/s,对应到带宽。有几点需要注意一下：1、并不是画面越清晰要求的带宽就一定越大。对于在线课程类视频（比如，吴恩达的机器学习课程），高速运动的画面很少，画面之间的像素很多也都是一样的（白板背景），即使是1080p视频，带宽也不会占用太多。1080p在线课程类视频会比1080p汽车赛事类视频占用的带宽少。进一步的，1080p在线课程类视频可能还比720p汽车赛事类视频占用的带宽还少。2、动态的码率要好于固定的码率。视频存在部分画面间变化不大、部分画面间变化较大的情形，若用同一码率，则会使得画面间变化不大的浪费了带宽，画面间变化较大的损失了画质。3、码率的设置需同时考虑移动手机端环境和画质情况。首先，对于移动手机端，很少需要1080p的视频，720p、480p已经足够。其次，移动手机端对流量仍然比较敏感，为了看1080p电影视频（假设平均需要4Mb/s的码率），30分钟就会消耗1GB的流量。若出现网络环境较差出现抖动，低码率视频能够顺畅的观看，高码率视频则会出现卡顿，严重影响观看体验。
• 视频流的编码方式：一个视频包括视频流、音频流、字幕脚本三大部分，字幕可以包括多语言字幕。视频流的编码方式有如下两种：1、ITU/ISO国际标准组织发起，包括H.264、H.265(也可写作HEVC)编码等，软件实现是libx264、libx265，是收费的。2、Google发起，包括VP8、VP9（几乎和H.265一样好）、AV1（声称比H.265还好）编码等，软件实现是libvpx、libaom，是免费的。
• 音频流的编码方式：1、ISO国际标准组织发起，包括MP3、AAC编码等，软件实现是libmp3lame、libfdk-aac，是收费的。2、Xiph.Org基金会发起，包括Vorbis、Opus编码等，软件实现是libvorbis、libopus，是免费的。
• 视频的制式：视频的制式可以理解成定义一种多媒体存储格式，用于存放视频流、音频流、字幕脚本，以及后续可能的扩展， 像一个容器一样，目前主要有如下几个：

视频信息举例

以4K网站上面的一个4K视频（地址是：https://4ksamples.com/puppies-bath-in- 4k/）为例：

• 视频总体信息

• 视频流信息

• 音频流信息

视频处理库

讲到视频处理，不得不提及ffmpeg，一个开源的视频处理库（工具），有两种使用方式：

• 二进制可执行程序ffmepg，提供了很多参数和设置，可以在命令行执行或者通过系统函数调用来执行。ffmpeg {1} {2} -i {3} {4} {5}， 其中，{1} 是全局选项，{2} 输入选项，{3}输入文件名或者url，{4}输出选项，{5} 输出文件名或者url。下面是一个样例，ffmpeg -i PUPPIES_BATH_IN_4K_Original_H.264_AAC.mp4 \ #输入文件名 -f image2 -vf fps=fps=1/20 \ #输出选项，puppies_%d.png #输出文件名
• API库，可以在程序里面通过调用API来实现视频处理。

• ffmepg处理视频的流程

信息流内容中心业务的处理

• 业务维度

• 视频处理特点

视频处理一般都比较耗时，视频文件越大处理越耗时，仍然以上面的4K视频为例，列举2个常用操作的耗时：

1、抽帧，操作耗时在34.87秒左右。

fmpeg -i PUPPIES_BATH_IN_4K_Original_H.264_AAC.mp4 -f image2 -vf fps=fps=1/20 puppies_%d.png

2、调整码率和尺寸，将4K的视频转成720P的视频（文件大小从400MB左右减少为15MB左右），以便适合手机等移动网络观看，操作耗时在77.43秒左右。

ffmpeg -i PUPPIES_BATH_IN_4K_Original_H.264_AAC.mp4 -crf 32 -b 0.5M -minrate 0.5M -maxrate 1M -bufsize 1M -vf scale=1280:720 PUPPIES_BATH_IN_1280_720p.mp4

• 不同耗时API的处理方式

1. 耗时短的API(<= 1s)，这类API通常无须考虑中断接续，一般采用无状态的设计方式，对外的proxy只用考虑鉴权、流量限制等常规措施，只要请求足够多（例如，QPS 1万/s），并遵循一定的随机或者后端服务选择算法，后端服务的负载通常是均衡的。调用方发请求，然后再接受处理结果，若本次请求若处理失败，调用方进行重试的代价也不高。
2. 耗时长的API(>= 30s,不是绝对的)，这类API执行一次耗时长，QPS不高，对外的proxy除了要考虑鉴权、流量限制等常规措施，还需要考虑实际处理服务器的负载均衡问题，否则很容易出现请求全部打到部分机器上面去的情况。假设，一个3分钟的短视频处理耗时30秒，1个4核8GB内存的云服务器每天处理11520个视频，某款短视频App的日生成视频量为1000万，则需要近900台这样云服务器，整体的QPS却只有120/s，容易出现机器繁忙程度不一。

• 某信息流内容中心的两种做法

1. 异步回调，调用方提供回调API，视频处理结束后通过回调API得到处理结果。

2. 同步等待，通过tcp长连接，在回包中将处理结果告知调用方，视频处理的QPS不高，这种方式也是可以的，同时简化了调用方的逻辑。