FFmpeg使用-t参数处理M2TS文件时出现PTS时间戳异常或丢帧：是BUG还是操作失误？

看起来你遇到的这个问题大概率是FFmpeg在处理M2TS文件时结合-t参数的一个现有问题（甚至可以归类为bug），完全不是你的操作失误——你的命令写法是标准的流复制裁剪操作，没有任何语法或逻辑错误。让我来详细拆解一下：

先确认你的操作没问题 #

你用到的命令：

ffmpeg.exe -i 1.m2ts -codec copy -map 0 -t 2 2.m2ts

是非常规范的：-codec copy指定流复制（不重新编码）、-map 0保留所有流、-t 2指定输出时长为2秒，本身没有任何问题。

问题根源大概率在FFmpeg对M2TS的流复制裁剪逻辑 #

M2TS是一种面向传输场景的容器格式，它依赖PCR（节目时钟参考）来同步，而且帧是打包在PES（分组 Elementary Stream）里的。当你用-t参数在流复制模式下裁剪时，FFmpeg的截断逻辑可能没有正确对齐M2TS的帧边界或PES包结构：

• 要么是为了凑够指定的2秒时长，FFmpeg错误地跳过了一帧（本该是3.520的那帧）；
• 要么是截断时破坏了PES包的完整性，导致最后一帧的PTS被错误地计算成了3.560。

你提到这个问题在多个不同来源、不同帧率的M2TS文件上都出现，这更说明这是FFmpeg处理M2TS流复制裁剪时的共性问题，而非单个文件的异常。

几个可以验证/规避的方法 #

1. 换成-to参数试试
   -t是指定输出的持续时长，而-to是指定输出的结束时间点（相对于输入的起始时间），两者的裁剪逻辑有细微区别。试试这个命令：

ffmpeg.exe -i 1.m2ts -codec copy -map 0 -to 2 2_to.m2ts

很多情况下-to在处理M2TS的流复制裁剪时会更准确，能避免PTS异常或丢帧。

2. 尝试转码而非流复制
   如果流复制不是必须的，试试转码生成输出：

ffmpeg.exe -i 1.m2ts -c:v libx264 -map 0 -t 2 2_transcoded.m2ts

转码时FFmpeg会重新生成完整且正确的时间戳序列，大概率能解决PTS异常的问题——当然代价是需要重新编码，耗时更长。

3. 查看debug日志找细节
   添加-v debug参数运行命令，查看FFmpeg处理帧和时间戳的详细日志：

ffmpeg.exe -i 1.m2ts -codec copy -map 0 -t 2 -v debug 2.m2ts

从日志里你能看到FFmpeg是如何选择截断点、处理最后几帧的PTS的，能更精准地定位问题。

结论 #

这绝对不是你的操作错误，更可能是FFmpeg在流复制模式下处理M2TS文件结合-t参数时的bug。如果-to或转码能解决你的问题，那可以先用这些方法规避；如果需要彻底解决，你可以去FFmpeg的官方issue平台搜索类似问题，或者提交新的issue（附上你的测试命令、debug日志和问题描述）。

备注：内容来源于stack exchange，提问作者Binarus