@Chenxiaolannnnn 谢谢老哥，我先了解一下，其实我也怕重复造轮子，这样容易中途放弃

@BLANCE 不难啊，我感觉

@FeifeiJin 对的，我就是要这种效果，看历史总觉得太片面了，就是想要这样对比才能更好的理解为什么

@mxalbert1996 这么说吧，input seeking 快但是切割时间不准确，output seeking 准确但是耗时久，两种我都试了，都有各种问题

@mxalbert1996 不是不行，是很慢。。。几个 g 的视频相当于每次切都重新编码

@tcp 我试试能不能局部解压，整个视频解压的话，体积大，时间也久

@coderluan 我发现我做的软件竟然和这个有点类似，卧槽了。。。

@xuhaoyangx 是的，我也想到了不应该频繁的去操作原视频，只是我的功能比较特殊，需要实时的预览，涉及到字幕、声音、图片等都要同步，所以索性直接当场合成了，现在用户用的反馈还算可以

@Sasasu 还有这种骚操作？

@misdake 作为输入参数会跳过开始片段，作为输出参数就会重新编码全部，但是这两种做法，都无法做到精确切割，我都尝试过了

@xuhaoyangx 哦哦，我怀疑有没有一种可能剪影它在视频轨道上显示用图片显示出来的，都是 I 帧，所以用户切的时候，都是在切 I 帧

我现在软件功能都 ok 了，采用的也是类似有损压缩的方式，但是这种方式需要用户提前把视频编码成全部是 I 帧的，比较麻烦，现在就一个难点，就是这个切割时间问题

@xuhaoyangx 我只了解大概，因为刚接触视频处理一个多月，看了一些文章，GOP 、IDR 和 PTS, DTS 很多概念还是很模糊

@xuhaoyangx 最后合成的时候也要进行一次切割的吧，这个时候可以保证精准吗

@hazardous 思路不错，如何取得这三段视频的信息呢，有没有好的思路

@Natsumoku 你了解剪映之类的软件是如何切割的吗？他们切割起来好像挺准确的啊，而且他们的视频感觉导入的速度非常快，一下子就解码然后放到视频轨道上了

@misdake 你测试的命令只有 0.7 秒确实比我电脑上运行的快，但是你这个只是使用的 copy 模式，得出的开始时间和结束时间就是刚开始说的那个不准确问题，我说的久的情况，是为了得到准确的开始和结束，而用的重新编码模式，要加上输出命令 ffmpeg -i a.mp4 -ss 700 -to 701 -c:v libx264 -c:a copy out.mp4 ，这样就会比较慢

@misdake 我把日志全都拉出来了，loglevel 全开，然而没有找到，太多了，所以想问问有没有知道是 log 里面的哪个信息，能拿到实际的切割的关键帧。。。

@misdake 谢谢，这个我试过了，关键帧信息不稳定，比如现在我要从 10s 开始切，那么我要去算出离 10s 最近的一个关键帧。。。
记录下这个误差，最后在调整，太难了，而且那个命令输出的关键帧感觉不是很准确
所以我说 ffmpeg 能不能再切的时候把它实际切割的关键帧的时间返回给我，我拿到这时间，在做一个调整，就可以得到精确的视频，这样最方便

@ksword 不一定是要 copy ，只要可以完成，并且耗时不这么长，就 ok