最近在工作中遇到一个ffmpeg的坑，特此记录下。我们在工作中，有个需求是将分段存储的视频拼接成一个完整的视频，发现使用ffmpeg拼接后视频时长不对。举个列子，我用ffmpeg将4个半小时的mp4视频拼接后，得到的视频长度远超过2小时，观看后发现在视频的连接点，会出现长时间的卡顿，导致最终视频时间超长。
在ffmpeg官方文档Concatenating media files中，介绍了三种视频拼接的方式，分别如下：
1. 针对同种编码的视频
可以将所有视频文件名列到一个文本文件中，格式如下：
复制
file '/path/to/file1.wav' file '/path/to/file2.wav' file '/path/to/file3.wav'
然后使用命令ffmpeg -f concat -safe 0 -i mylist.txt -c copy output.wav 完成对视频的拼接，这种方式也是拼接最快的方式。大致原理是直接将视频首位相接，不会涉及到编解码，整体执行的时间主要是磁盘IO的时间，我们实测100个文件，拼接成一个5g大的长视频，也只需要几十秒的时间。
但是，这种拼接方式有自己的局限，首先它只能拼接相同编码的视频，比如都是mp4。而且，这种方式也有bug，拼接mp4视频文件得出来的视频时长不对，就是我开头所说的问题，因为这个bug我们差点改业务需求。不过这个bug可以绕过去，就是将所有mp4文件先转成ts文件，然后对ts文件拼接，拼接ts视频不会出现这个bug。
mp4转ts文件的命令如下：
复制
ffmpeg -i input.mp4 -c:v copy ouput.ts
因为mp4转ts的过程也不涉及到视频编解码，所以也很快，我们也是用这种方式绕开了bug，完成了整个需求。 其实视频拼接还有两种方式，对我们都不太合适，后续会说到。
2.使用concat协议
复制
ffmpeg -i "concat:input1.ts|input2.ts|input3.ts" -c copy output.ts
这个方式我们没有具体测试，貌似不会涉及到编解码，所以应该也挺快的，但网上说这个命令执行的条件也比较苛刻，也不推荐使用。我们没有用的原因单纯是因为需要拼接上百个视频，这种方式需要拼一个非常长的命令行。
3. 使用Concat filter
复制
ffmpeg -i input1.mp4 -i input2.webm -i input3.mov -filter_complex "[0:v:0][0:a:0][1:v:0][1:a:0][2:v:0][2:a:0]concat=n=3:v=1:a=1[outv][outa]" -map "[outv]" -map "[outa]" output.mkv
这种使用方式还是偏复杂，具体可以参考下官方文档Concatenating media files。该方法的优点就是效果稳定、且支持不同格式的视频，所以也是最推荐的视频拼接方式。但缺点也很明显，需要涉及到视频的编解码，所以会非常耗性能，就是因为性能问题，我们也抛弃这种方案了。
说下我们实测的数据，我们用通用服务器，拼接60分钟的视频需要20-30分钟(和服务器配置有关)，看着还行，但我们每天有数千小时的视频需要拼接，需要几十台服务器24小时满负荷工作才能完成，对于我们当下来说成本还是偏高。 我们也委托别人试了使用GPU加速的拼接效果，确实快了很多，1小时视频1分钟内就可以完成。
总结
我们当前没有GPU资源，所以当下还是选择了使用第一种视频拼接方式，第一种方式目前最大的瓶颈只在于网络IO(视频下载上传)上，但这种方案也限制了我们只能完成对视频的拼接，无法调整其分辨率以达到降低存储的目的。长期来看我们肯定得考虑使用硬件加速的方式完成超大视频量的处理。
