html5音频不同步主因是源文件时间戳（pts/dts）混乱，需在转码封装前用ffmpeg修复，如加-copyts或-genpts；轻度偏移可用preload=”metadata”配合currenttime微调；严重时须用web audio api手动对齐。
音频时间戳错位导致播放不同步
html5 <audio></audio> 标签本身不处理音轨对齐，不同步根本原因通常是源文件的时间戳（PTS/DTS）混乱，或转码时未保留原始时序。浏览器按时间戳解码渲染，一旦时间戳跳变、重复或缺失，就会出现音画脱节、起始延迟、中途卡顿等现象。
常见诱因包括：
– 用 ffmpeg 转码时未加 -vsync cfr 或 -copyts 参数
– 原始音频含非标准帧率（如 29.97 fps 视频配 48kHz 音频但未做 PTS 对齐）
– 多段音频拼接后未重写时间戳
- 用
ffprobe -v quiet -show_entries stream=codec_type,start_time,duration -of default检查各流起始时间是否一致 - 若
start_time显示N/A或数值偏差 >0.05s，说明时间戳不可靠 - 强制重置时间戳：用
ffmpeg -i in.mp3 -c copy -fflags +genpts out.mp3
使用 AudioContext 手动对齐音轨
当 HTML5 原生播放器无法修正偏移时，需绕过 <audio></audio>，改用 Web Audio API 精确控制。核心是把音频解码为 AudioBuffer，再通过 AudioBufferSourceNode.start(startTime) 指定毫秒级触发时刻。
注意：此法仅适用于已知固定偏移量（例如音频比视频快 120ms）的场景，不适用于动态抖动。
立即学习“前端免费学习笔记（深入）”；
- 先用
context.decodeAudioData(arrayBuffer)加载并解析音频 - 创建
source = context.createBufferSource()并赋值source.buffer = decodedBuffer - 调用
source.start(context.currentTime + 0.120)补偿 120ms 提前量 - 不能在
load事件中直接 start，必须等AudioContext处于running状态（通常需用户手势触发）
<audio></audio> 的 preload 和 currentTime 配合技巧
对轻度不同步（≤200ms），可不用 Web Audio，而靠原生属性微调。关键是避免浏览器自动加载策略干扰时间轴——比如 preload="none" 会导致首次 currentTime 设置被忽略。
- 设
preload="metadata"，确保能读取时长且允许 seek - 监听
loadedmetadata事件后再设置audio.currentTime = offsetSeconds - 若需“静音启动+精准对齐”，先
audio.muted = true，play()后立即pause()，再设currentTime，最后取消静音 - 某些安卓 webview 对
currentTime设置响应迟钝，建议加setTimeout(() => { audio.play() }, 10)避免阻塞
MP4 容器中音视频轨道时间基不一致
用 ffmpeg 封装 MP4 时，默认可能为音视频分配不同 time_base（如视频用 1/1000，音频用 1/48000），虽不影响播放，但在 js 中读取 audio.duration 或计算同步点时会因精度截断出错。
验证方式：ffprobe -v quiet -show_entries stream=time_base -of default in.mp4，对比两个流的输出。
- 统一时间基：转码时加
-video_track_timescale 48000 -audio_track_timescale 48000 - 或更稳妥地，用
-vsync cfr -r 30 -ar 48000强制音视频同采样率与时序基准 - 不要依赖
audio.duration做对齐计算——它由浏览器解析容器头得出，可能四舍五入；应以解码后AudioBuffer.duration为准
实际中最容易被忽略的是：**时间戳修复必须在封装前完成**。一旦 MP4 已生成，再用 JS 调整 currentTime 只能掩盖问题，无法根治 PTS 错乱引发的缓冲抖动或 seek 失败。