重封装后时间轴从零开始了，怎样核对copyts与start_at_zero

重封装后时间从零开始，可能是工具处理了输入起点。-copyts用于保留输入时间戳偏移，配合-start_at_zero则会整体平移起点；是否保留应由接收时间线要求决定，不能把任何非零起点都当作故障。

这组文件怎样比较

本例先生成起点为五秒的两秒原创MKV，再制作默认、copyts和copyts加start_at_zero三个副本。只使用正起点，避免把B帧前导负DTS的修正混进本题。所有副本保持原编码内容，便于检查时间变化而画面未变。

按原始结构逐项检查

1. 先读取源文件首包PTS并保存原始时间基，确认五秒偏移确实写入最终文件。不能只看-output_ts_offset参数，因为封装器还可能做后续处理；源片是本题比较基准，其实际首包比生成命令中的目标数字更有证据价值。

2. 将-copyts放在适用的位置，另一路显式加入-start_at_zero，生成后分别读回首PTS。本例保留路径为五秒，归零路径为零；默认路径也单独报告，不把默认行为当成所有容器、编码及选项组合都固定不变的承诺。

3. 逐帧解码计算摘要，确认四份文件的画面序列一致，再检查完整解码无错误。相同画面并不表示容器文件SHA相同，时间字段变化本身就会改变字节；因此将文件身份摘要与画面内容摘要分开使用，不拿其中一项替代另一项。

容易误读的地方

反例是认为-copyts能冻结所有时间处理。官方明确提醒，输出帧率模式及封装器仍可能调整时间戳；若另开avoid_negative_ts等处理，应一并记录。需要严谨保留时，实际输出每条流都要读回，而不是只在命令里找到copyts这个词。

下载与本地读回

copyts.mkv、default.mkv、generation.json、observed.csv、observed.json、shifted.mkv、zero.mkv。

下载全部附件到同一个独立目录，用 python verify.py 运行本题独立核验脚本。依赖为Python 3.12.4、PATH中的FFmpeg及ffprobe 8.0.1；程序不联网、不连接设备，读取本题文件并在终端输出检查结果。本地实际执行回执保存实际命令、退出码和完整输出。

回执列出四个首PTS以及对应帧摘要，所有输入输出完成本地解码。没有验证外部剪辑系统是否按照原时间定位，也没有测试多输入的共同绝对时钟；正偏移只是在本地样例中人为设置，不能用它代表现场同步已完成。

命令已在原创短片上实际执行并读回文件。官方文档为滚动版本，本文所列选项已用本地8.0.1确认；未测试目标硬解、网络起播或现场实时性能。

把结果带回交付

交付应写明接收方要相对节目零点还是保留制作时刻，并提供源输出起点对照。将文件导入实际工程后检查同一事件的位置，若软件自行归零，记录导入策略而非继续修改素材；只有统一了两端时间语境，保留时间戳才有意义。

相关背景见手机拍的视频放久了声音不同步，怎样先核对 VFR 与 CFR，还可从多媒体播放专题继续查找文件处理方法。需要核对实际工程的接收条件时，可携带本题文件与读回结果进行工程对接咨询。

一级依据

• copyts保留输入起点偏移，start_at_zero与其联用会平移起点；muxer仍可能另处理时间戳。

来源核对日期：2026-10-24。引用支持文件机制；原创输入的本地结果不代表客户素材或现场系统已经通过验收。