前言

余忆童稚时。。。。开个玩笑，说正经的，当我是个萌新的时候，就有这个困惑。后续大佬点醒了我，没有基础的运用，犹如空中楼阁。这个问题其实很简单，就是mp4格式本身的问题，例如换成ts就没有这个问题了。

成因

当我使用ffmpeg录制组播源，或者http的mp4格式的流的时候，我期望录制一个指定准确的时间。网上文章一大抄，复制来复制去，很多人具体自己实验过么？或者压根就是没有感情的伪原创机器人小编？

基本上大多数人都在纠结-t参数，或者是-to参数，希望用参数来解决时间截取不准确的问题？这是害人，改参数真的有效的，确实有效，能够直接解决，但是ffmpeg瞬间打满了arm64的全部8个核心，ffmpeg表示，当前处理帧率0.05fps，意味着1秒钟的视频，加入重编码之后，arm孱弱的身躯要干10分钟。

此处也点一下疯狂吹捧Apple M1/M2处理视频神速的大佬们。你们宣传能量太大了。但是这玩意儿交给M2来干？如果没有调用硬件加速，纯粹用CPU软解+CPU编码？这编码速度上古的RMVB都不够流畅播放好么？此时功耗看样子也到了大概20瓦的样子（市电输入到MAC MINI）。该不会有人觉得MAC MINI M2会比其他地方的有天壤之别吧。

如果简单剪辑，以空间换取时间，快速磨损固态硬盘宝贵的写入寿命，占用巨大的空间，确实很快；但是我又菜又爱玩，想要加一些大佬们开发的有趣的插件，实现一些有趣的动态效果，M2完全搞不了好么。目前吃灰，一开始就心里有数选择的万兆电口版本，假装他是一台万兆的树莓派。日常上上网确实省电，但是MAC MINI完全没有移动的可能性，兼具手机和台式机的缺点，Windows的INTEL核显笔记本电脑现在日常上上网续航七八个小时也没毛病啊。而打开有BUG的网页，狂吃性能的页面，M2也不能免俗处理器满载啊。下一台树莓派何必是树莓派，买一台MAC MINI M2，具有万兆电口的树莓派，外设接口基本上都是原生，不需要担心树莓派3的千兆网口实际上依赖USB2.0只能大约300Mbps带宽，不担心树莓派4代那不稳定的USB3.0+2.0桥接芯片插入一些USB设备时整个芯片拐跑了全部设备玩失踪。与树莓派对比，MAC MINI M2相当于去年、前年两三台树莓派的价格，能够购买到如今消费级环境顶尖梯队的制程打造的“树莓派”，如此比较，性价比爆棚。

最本质的原因，就是IPB问题。在H264编码方式中，用I帧存储完整的画面，这个位置，是具有完整的画面的。而P帧，只存储了与前面的I帧的差异，依赖前序画面，才能够显示当前的画面。而B帧，依赖I帧和P帧，在结构上，一个I帧为开头，中间有若干个B帧，最终由P帧结束，当编码的时候，程序自动的将视频依据相似程度截断。相似的画面会合并在一起。

如果使用copy的方式进行裁切、剪辑，那么就会由于IPB导致的边界问题，如果是录制，用copy的方式直接保存，最终视频就会截断不正确。开头少几秒，总长度多几秒。

解决方法

原因找到了，解决的方法就非常简单

1、通过压制的方式

不管是CPU力大飞砖，还是通过VAAPI或者QSV，注定不是一种节能的方案。如果arm之类的，且没有提供编解码器支持的例如全志，完全就行不通嘛。CPU的处理帧数不到0.05FPS，处理一秒的视频需要接近10分钟，虽然硬件加速性能很快，但是只有安卓的支持，根本玩不了。

好的压制，能够修补画面的瑕疵，而我们通过批量的“粗制滥造”，本身就一知半解，只会让画质更加糟糕。所以能够直接复制就不要重复编码吧。

2、换格式

换格式就好了。例如捕获的时候，后缀填写为ts。日常的时候也储存ts文件便于裁剪、编辑。当需要的时候再快速的copy为mp4或者mkv格式。

ffmpeg -i source -c copy xxx.ts

-c copy就直接复制音频流视频流了。在这个情况下，添加开始时跳过的时间，以及停止截取的时间，出来的视频时间位置就准确了。截取出来的时间长度也就正确了。