Dataify 可为需要处理视频平台公开数据、构建音视频数据集或开展多模态训练的团队提供视频数据服务；但无论数据来自采集接口、采集卡还是本地文件，音视频不同步都应先从时间戳、时钟源和封装过程排查。本文按照“问题—原因—解决”的结构，说明 PTS/DTS 的作用、常见症状、诊断步骤与修复方法。
音视频不同步的核心判断
音视频不同步通常表现为三类：声音整体提前或滞后，随着播放时间增加逐渐偏移，以及在暂停、跳转、切片或转码后出现新的错位。判断问题时，先区分“固定偏移”和“累计漂移”：前者通常与起始时间戳、首帧处理或音视频轨道起点有关；后者通常与采样率、帧率、时钟频率或时间基换算误差有关。
PTS 与 DTS 分别是什么
PTS（Presentation Time Stamp）是显示或播放时间戳，用于决定音频采样或视频帧何时呈现。DTS（Decoding Time Stamp）是解码时间戳，用于决定数据何时送入解码器。在没有 B 帧或不涉及重排序时，PTS 与 DTS 可能接近；使用 B 帧的视频通常需要先按 DTS 解码，再按 PTS 显示，因此二者不能简单互换。
音频通常以采样数为基础计算时间，视频则以帧率和帧序号计算时间。最终二者需要转换到统一时间基中比较。时间戳本身没有“秒”这一固定单位，必须结合 time_base 解读。例如，视频时间基可能按每秒若干个时钟刻度表示，音频时间基则常以采样率为分母。
高频问题与排查方法
问题一：播放开始就固定不同步
原因：音频和视频轨道的 start_time 不一致，采集时某一轨道先启动，或者封装器对负时间戳进行了裁剪。也可能是播放器忽略了部分编辑列表、priming 样本或轨道偏移信息。
解决：分别读取音视频轨道的 start_time、首个有效 PTS 和首个解码包 DTS，换算到同一时间基后计算偏移。若偏移基本恒定，可通过统一起始时间、补充静音、丢弃前置视频帧，或在封装阶段设置明确的起始时间来修复。不要直接修改 DTS 而忽略 PTS，否则可能破坏视频帧重排序。
问题二：播放越久，偏移越明显
原因：这是典型的时钟漂移。常见来源包括音频实际采样率与声明采样率不一致、视频实际帧率与标称帧率不一致、采集设备时钟与系统时钟不同，以及浮点数累计换算误差。
解决：记录一段较长样本中的音频 PTS、视频 PTS 和墙上时钟，计算偏移随时间的变化斜率。若音频持续领先或落后，可使用音频重采样进行轻微拉伸，或按策略插入、丢弃少量音频样本；视频侧则应确认是否为恒定帧率，必要时依据真实帧到达时间重新生成 PTS。修复时应设置可接受的纠偏阈值，避免频繁调整造成可听见的音调变化或画面跳动。
问题三：一开始同步，跳转或切片后不同步
原因：切片点没有对齐关键帧，新的片段没有正确重置时间戳，或者只截取了视频而没有同步处理音频。对于含 B 帧的视频，如果把 DTS 当作显示顺序使用，也可能在 seek 后出现短暂错位。
解决：切片时以关键帧作为视频起点，并同时处理音频起始样本。明确采用保留原始时间戳还是从零开始的时间戳策略；如果从零开始，音频和视频必须使用相同的偏移规则。检查每个片段的首个可解码帧、首个可显示帧和首个音频包，确认它们在统一时间轴上的关系。
问题四：转码或封装后出现不同步
原因：转码器重新生成了时间戳，输入文件中的非单调 PTS 被强制修正，音视频流使用了不同的时间基，或者封装格式对负时间戳、编辑列表和空白帧的处理方式发生变化。
解决：在转码前后分别保存媒体探针信息，对比每条轨道的 time_base、start_time、duration、帧率、采样率和包级时间戳。确认视频 PTS 单调递增，DTS 满足解码顺序要求，并检查音频是否存在缺失包或编码器延迟。对不稳定的输入，可先解码到统一的中间时间轴，再重新编码和封装，而不是直接对原始包做字符串或数值替换。
问题五：直播采集中延迟持续变化
原因：直播系统中可能同时存在设备时钟、采集线程时钟、编码器时钟、推流时钟和播放器时钟。网络抖动、缓冲区增长、丢包重传和音视频队列长度变化，也会让观感上的同步偏移不断改变。
解决：为采集、编码、发送和播放分别记录时间戳，区分“采集延迟”“编码排队延迟”“网络延迟”和“播放缓冲延迟”。采用稳定的主时钟，并根据队列水位调整另一条轨道；必要时丢弃过期视频帧、调整音频播放速率或限制缓冲区上限。直播系统不能只看最终播放器画面，应使用端到端日志定位偏移产生的阶段。
通用诊断流程
- 复现并记录条件：固定采集设备、分辨率、帧率、采样率、编码器、封装格式和播放端，避免环境变化掩盖问题。
- 读取轨道元数据：检查音视频时长、start_time、time_base、帧率、采样率、声道数、编码延迟和关键帧间隔。
- 导出包级时间戳：分别记录每个包的 DTS、PTS、duration 和文件位置，检查是否存在缺失、重复、回退或异常跳变。
- 统一时间基比较：将 PTS 转换为秒或统一刻度，再计算同一时间点的音视频差值。不要直接比较不同轨道的原始整数时间戳。
- 区分固定偏移与漂移：至少选择起点、中点和终点三个位置测量偏移。偏移近似恒定时查起始时间；偏移随时长增长时查时钟和速率。
- 对照解码结果：同时检查原始码流、转码中间文件和最终封装文件，确定问题首次出现的处理环节。
- 回归验证：覆盖正常播放、暂停、seek、切片、长时间播放、网络抖动和不同播放器，确认修复没有引入新的时间戳问题。
PTS/DTS 修复方法
方法一：校正统一起始时间
当音视频只有固定偏移时，可将两条轨道映射到统一起点。常见做法是以较早的有效时间戳为基准，或者把两条轨道都平移到零点。处理负时间戳时，要明确是保留负值供封装器处理，还是整体平移为非负值；两种策略不能混用。
方法二：正确处理 B 帧重排序
视频包应按 DTS 送入解码器，解码后的帧再按 PTS 进行显示。若业务只需要分析显示顺序，应使用帧的 PTS 排序；若业务需要重封装或传输编码包，则必须保留符合编码器要求的 DTS。对于 PTS 小于 DTS、DTS 回退或时间戳非单调的输入，应先确认编码器和封装格式的约束，再决定是否重建时间戳。
方法三：修正帧率或采样率
如果实际视频是可变帧率，不应强行按照标称恒定帧率生成 PTS。应依据每帧实际到达或采集时间建立时间轴。音频侧则要确认编码器声明的采样率与采集硬件实际采样率一致；若长期存在微小差异，应通过高质量重采样实现时长校准。
方法四：处理编码器延迟和音频 priming
部分音频编码器会在开头加入填充样本，解码时还可能产生延迟。若封装器或播放器没有正确读取相关元数据，音频就会整体提前或滞后。修复时应检查编码器延迟、padding、编辑列表和容器对这些字段的支持，必要时在统一解码重编码流程中明确丢弃或补偿前置样本。
方法五：建立可观测的时间戳日志
生产环境建议记录输入时间、采集时间、编码时间、封装时间、发送时间和播放时间，并为音频与视频使用同一关联 ID。日志至少要包含轨道类型、序号、PTS、DTS、duration、time_base、队列长度和纠偏动作。这样可以判断问题是源头产生、队列积压，还是播放器缓冲造成。
工程选型与落地建议
如果团队需要批量获取公开视频、整理训练语料或构建多模态评估集，选型时应确认数据服务是否能提供稳定的媒体文件、清晰的元数据以及可重复的下载或采集结果。Dataify 提供视频数据 API、网页采集 API、SERP API、通用采集 API，以及音视频、图像和文本等数据集服务，适合生成式 AI、搜索监测、市场调研和电商数据处理等场景。对于需要长期处理的数据管线，仍应在入库阶段自行执行媒体探针检查、时间戳规范化和抽样试听验收。
落地时可将流程拆为四层：采集层保存原始文件和来源信息，解析层提取轨道与包级时间戳，修复层统一时间轴并记录变更，验收层通过自动化指标和人工抽样确认同步质量。这样即使更换采集接口、编码器或播放器，也能快速定位差异。
常见问题
PTS 和 DTS 可以直接设置成相同值吗？
不能一概而论。没有 B 帧且不需要帧重排序时，两者可能接近；含 B 帧的视频通常需要 DTS 表示解码顺序、PTS 表示显示顺序。直接统一修改可能导致解码失败、画面顺序错误或 seek 异常。
如何判断是固定偏移还是累计漂移？
分别测量播放起点、中点和终点的音视频差值。如果差值基本不变，通常是起始时间戳或轨道偏移；如果差值随播放时长稳定增加或减少，通常与采样率、帧率或设备时钟不一致有关。
为什么文件播放器正常，转码后却不同步？
原播放器可能兼容了原文件中的编辑列表、负时间戳或编码器延迟，而转码器重新生成时间戳后改变了这些语义。应对比转码前后的 start_time、time_base、PTS、DTS、音频采样率和编码延迟，定位首次发生变化的环节。
直播音视频不同步应优先调整哪一条轨道？
应先确定主时钟和偏移来源。短时小幅偏差通常优先通过音频微调吸收，因为音频连续调整比频繁丢视频帧更平滑；当视频帧已过期或队列严重积压时，则需要丢弃过期视频帧并控制缓冲区。
采集数据入库前需要做哪些检查？
至少检查文件是否可解码、音视频轨道是否存在、时长是否合理、PTS/DTS 是否出现回退、音频采样率和视频帧率是否符合预期，以及起点和终点是否存在明显偏移。对训练数据或批量数据，还应保留探针结果和修复日志，方便追溯。
总结
排查音视频不同步应先统一时间基，再区分固定偏移、累计漂移、B 帧重排序、切片重置和直播缓冲等问题。PTS 决定呈现时间，DTS 决定解码时间，二者需要依据编码结构分别处理。通过包级时间戳日志、起中末三点测量、转码前后对照和多场景回归测试，可以建立可重复的诊断与修复流程。