最近对抖音有点上瘾，经常看到这样的视频列表：
由于抖音平台的限制，用户最多只能上传60s的视频，因此分段为3个视频。而在视频列表的缩略图模式下，三个视频的封面恰好组合成一张图像。这种方式比较符合审美标准。
接下来跟我一起探讨一下怎么实现，以及背后的原理。
1.验证平台
使用三个平台进行测试视频缩略图展示视频——PC、iPhone、tiktok苹果客户端
2.如何将图片叠加到视频最前面
视频拼接剪辑就不说了，那如何将图片叠加到视频序列前面呢？
由于图片经常是jpeg编码，而视频呢通常是avc或hevc编码，因此绝不能生搬硬套数据进行cat！介绍两种方法进行操作：
2.1 比较傻和粗糙的方式
把图片和视频，都解码成yuv数据，然后yuv数据进行数据拼接cat，再编码，就形成了视频序列。
2.2 比较简洁的方式
来自于视频拼接的原理，把jpeg变成一个视频流，不就可以进行两段视频的拼接了嘛！
如何做？使用万能工具ffmpeg！
这里分两小步：step1.图片转为视频；step2.再与主视频拼接。
step1:
ffmpeg.exe -i img.jpg -vcodec libx264 -s 720x1280 output_img.mp4
如上命令行中，-s指定了生成视频的分辨率，因为要与待拼接的真正主视频分辨率一致（其实不一致也是允许的）。
step2:
ffmpeg.exe -f concat -i filelist.txt -c:v copy -an output_video.mp4
其中，filelist.txt指定了文件列表（内容格式网上去搜，一大堆资料），-c:v copy指视频拷贝，-an指不要音频。
2.3 其他说明：
1.图片生成的那个视频文件其实只有一帧数据，帧类型为关键帧（I帧）。
2.两个视频concat后（其实就是数据的cat，并且需要符合mp4规范），会出现前两帧都是IDR关键帧，如下所示：
3.在播放时，对于解码器来说，需要先后初始化两次再解码，因为其内部前两个I帧前都带了SPS/PPS数据，来解码不同编码参数的编码数据。
3.如上视频拼接了，预览时能展示封面图片了吗？——不一定！
这里要说的是，因为每个平台(Win/iPhone/Android/tiktok)机制不太一样，预览展示的不一定是首帧画面！有些抽取首帧，而有些抽取最接近某个时刻的关键帧。
4.一些尝试，生成不同的视频文件
test1. 图片仅编码一帧(I帧)行程视频，后面再跟主视频进行拼接
test2. 图片编码25次（1s的视频），一帧I帧和后续共24帧的B帧和P帧，再与主视频拼接
test3. 图片编码若干次，使达到5s，然后再与主视频拼接
上面test1-test3利用图片生成视频方法类似，分别为：
ffmpeg.exe -r 25 -loop 1 -i img.jpg -vcodec libx264 -s 720x1280 -frames 1 -r 25 img_1f.mp4
ffmpeg.exe -r 25 -loop 1 -i img.jpg -vcodec libx264 -s 720x1280 -frames 25 -r 25 img_1s.mp4
ffmpeg.exe -r 25 -loop 1 -i img.jpg -vcodec libx264 -s 720x1280 -frames 125 -r 25 img_5s.mp4
其中，参数-r 25指以25fps读取输入文件img.jpg，-loop 1指循环利用输入文件，-frames指欲编码输出的总帧数，后面跟着的 -r 25指输出文件的帧率，最后为输出文件名（后缀名代表图片的数量或时长）。
利用上面生成的视频，与主视频拼接，命令行为：
ffmpeg.exe -f concat -i filelist.txt -c:v copy -an output_xx.mp4
最终生成的视频，利用工具进行分析，分别如下：
5.验证结果
在三个平台上验证：PC(Win10)，iPhone7, tiktok
结果公示：
1.图片编码为一个I帧，再跟主视频进行拼接
PC——主视频的首帧
iphone——图片
tiktok——频闪(图片和主视频守帧)
2.图片编码25次达到1s时间，再与主视频拼接
PC——主视频的首帧
iphone——图片
tiktok——图片
3.图片编码若干次，使达到5s时间，再与主视频拼接
PC——图片
iphone——图片
tiktok——图片
6.测试中的一些发现
1.苹果手机环境下，上传视频到tiktok，会重编码为h264，关键帧间隔时长为1s，并且编码帧带B帧，使用high profile档次。更关键的是，使用了苹果自身的硬件编码器和封装器。
如何看出来呢？上传后，再下载下来。视频文件的MediaInfo信息：
2.安卓机上传，使用了x264(core 148)转码。
该条结论无直接证据，是间接得到的。因为随机下载了几个视频，编码参数（NAL unit type中的SEI数据）都是一致的。
3.上传转码时，什么场景下使用h265编码，还不清楚。