为什么视频中FrameCount / FrameRate ≠ Duration？
为什么 FrameCount / FrameRate ≠ Duration？
直觉上的公式
时长 = 总帧数 / 帧率 Duration = FrameCount / FrameRate这个公式看似正确，但在实际视频文件中，几乎从不成立。以下逐一分析原因。
原因一：可变帧率（VFR，Variable Frame Rate）
固定帧率（CFR）每帧间隔相同，公式勉强成立。
可变帧率（VFR）帧与帧之间的间隔不固定，"帧率"只是一个名义上的平均值。
CFR 25fps: 帧0 帧1 帧2 帧3 帧4 时间: 0ms 40ms 80ms 120ms 160ms → 间隔固定 40ms VFR: 帧0 帧1 帧2 帧3 时间: 0ms 20ms 110ms 160ms → 间隔不等VFR 常见于：手机录制的视频、屏幕录制、直播推流、游戏录制。
此时FrameCount / FrameRate（平均）只是粗略估算，误差可能达到数秒。
原因二：时长由时间戳决定，而非帧数
视频的实际时长由容器中记录的PTS（Presentation Time Stamp，呈现时间戳）决定：
Duration = 最后一帧的PTS + 最后一帧的持续时长(duration) - 第一帧的PTSPTS 是编码时写入每一帧的绝对时间标记，单位是timebase（时间基）的整数倍。
帧率只是一个"建议播放速度"的元数据，播放器真正依赖的是 PTS。
极端例子：一个视频有 1000 帧，声称 25fps，但第一帧 PTS=0，最后一帧 PTS=50s。
→FrameCount / FrameRate = 1000 / 25 = 40s，但实际时长是50s。
原因三：时间基（Timebase）的精度问题
PTS 以整数存储，单位是1/timebase。常见时间基：
| 容器/编码 | 常见 timebase |
|---|---|
| MP4 | 1/12800、1/90000 |
| MPEG-TS | 1/90000 |
| AVI | 1/帧率（如 1/25） |
| MKV | 1/1000000000（纳秒） |
25fps 视频，每帧理论间隔 =1/25 = 0.04s。
若 timebase = 1/90000，则每帧 PTS 增量 =90000/25 = 3600，是整数，无误差。
若 timebase = 1/1001（某些 NTSC 场景），则累积误差在长视频中会放大。
结果：Duration 来自 PTS 累加，FrameCount/FrameRate 来自除法，两者因整数截断而有微小差异。
原因四：容器层时长与流层时长不一致
MP4 文件中，时长存在多个地方：
MP4 文件结构: └── moov box ├── mvhd（Movie Header）← 容器级别时长，单位 movie timescale └── trak（Track） └── mdhd（Media Header）← 流级别时长，单位 media timescalemvhd中的时长：整个文件的时长，可能与实际视频流不一致mdhd中的时长：该轨道（视频/音频）的实际时长
FFprobe 读取的duration默认取容器级别（mvhd），而帧数是从视频流（trak）统计的，两者 timescale 不同，换算后可能有微小差异。
原因五：Edit List（elst box）偏移了呈现时间线
MP4 的elst（Edit List）box 可以对视频的呈现时间线做偏移，而不改变任何已编码的帧：
编码帧: [帧0] [帧1] [帧2] [帧3] ... ↑ PTS 从 -512 开始（因为 B 帧编码延迟） elst 修正: 将呈现起点向后偏移 512 个 timebase 单位 ↓ 播放器看到: [帧0] 从 t=0 开始播放此时 Duration（容器记录）= 编码帧覆盖的时间 - elst 偏移量，与 FrameCount/FrameRate 的计算结果不同。
常见场景：H.264 编码器因 B 帧的 DTS/PTS 错位，会插入负 PTS 的空白帧（encoder delay），elst 用来剪掉这部分偏移。
原因六：编码器延迟帧（Encoder Delay）
H.264/H.265 使用 B 帧时，编码器需要"向前看"若干帧，导致输出流中前几帧的 DTS（解码时间戳）为负值：
输入帧顺序（PTS）: I B B P B B P 编码输出顺序（DTS）: I P B B P B B ↑ 第一个 B 帧的 DTS 可能为负这些延迟帧会使实际流的起始 PTS 偏移，导致从 PTS 计算的时长与FrameCount/FrameRate不一致。
原因七：音视频流时长本就不同
视频文件通常包含视频流和音频流，两者时长可以不同：
视频流: ████████████████████ 19.98s（1000帧 × 25fps 取整误差） 音频流: ████████████████████ 20.02s（AAC 编码块对齐到 1024 采样） 容器时长: 取两者中较长的，或由 moov 头单独记录ffprobe的duration可能是音频流时长，而不是视频帧数推算的时长。
两者差异通常在 100ms 以内，但对精确计算影响显著。
原因八：掉帧与重复帧
编码过程中可能发生：
- 掉帧：编码器来不及处理，跳过某帧，但时间线继续推进（PTS 出现跳跃）
- 重复帧：为维持恒定码率，某帧被复制，但只增加一次 PTS
掉帧场景: 帧序号: 0 1 2 4 5 （帧3被丢弃） PTS: 0ms 40ms 80ms 160ms 200ms ↑ PTS 跳过了 120ms（帧3的位置） FrameCount=5, FrameRate=25fps → 5/25 = 0.2s 实际 Duration = 最后一帧PTS + 最后一帧自身持续时长 - 第一帧PTS = 200ms + 40ms（25fps每帧占1/25s） - 0ms = 0.24s ← 不等 时间轴验证： 0ms 40ms 80ms 160ms 200ms 240ms |帧0 |帧1 |帧2 ×跳 |帧4 |帧5 |← 帧5播完，视频结束 ↑ Duration = 240ms汇总
| 原因 | 典型误差量级 | 常见场景 |
|---|---|---|
| 可变帧率（VFR） | 秒级 | 手机视频、屏幕录制 |
| 时间基精度误差 | 毫秒级 | 所有视频 |
| 容器/流时长不一致 | 毫秒级 | 所有 MP4 |
| Edit List 偏移 | 毫秒~秒级 | H.264/H.265 编码视频 |
| 编码器延迟帧 | 毫秒级 | 含 B 帧的视频 |
| 音视频流时长差异 | 毫秒~百毫秒 | 所有音视频混合文件 |
| 掉帧/重复帧 | 毫秒~秒级 | 直播、屏幕录制 |
实践建议
获取准确时长
# 方式一：读取容器头（最快，但可能不准）ffprobe-verror-show_entriesformat=duration-ofdefault=noprint_wrappers=1input.mp4# 方式二：解码所有帧，取最后一帧 PTS（最准，但最慢）ffprobe-verror-select_streamsv:0\-show_entriesframe=pkt_pts_time\-ofcsv=p=0input.mp4|tail-1# 方式三：读取视频流级别时长（比容器头更准）ffprobe-verror-select_streamsv:0\-show_entriesstream=duration\-ofdefault=noprint_wrappers=1input.mp4获取准确帧数
# 方式一：容器头中的 nb_frames（不一定存在）ffprobe-verror-select_streamsv:0\-show_entriesstream=nb_frames\-ofdefault=noprint_wrappers=1input.mp4# 方式二：逐帧统计（准确但慢）ffprobe-verror-count_frames-select_streamsv:0\-show_entriesstream=nb_read_frames\-ofdefault=noprint_wrappers=1input.mp4代码中的正确做法
// 错误：用帧数推算时长doubleduration=frameCount/frameRate;// ❌ 不可靠// 正确：直接读取容器记录的时长doubleduration=mediaInfo.getDuration();// ✅ 来自 PTS 或容器头// 需要帧数时，优先用时长反推（VFR 场景仍有误差，仅供参考）longestimatedFrameCount=Math.round(duration*frameRate);总结
FrameCount / FrameRate ≠ Duration的根本原因是：
帧率是编码参数，时长是时间戳的结果。两者属于不同体系，只有在 CFR + 无延迟 + 无 elst 偏移的理想情况下才近似相等。
实际工程中，永远以 PTS/容器头记录的 Duration 为准，不要用帧数反推时长。