Repository navigation
[BUG] tx3g subtitle timestamps broken — integer overflow on GPAC path, off-by-one on FFmpeg path #2198
Description
Description
tx3g (mov_text) subtitle extraction produces incorrect timestamps on both the GPAC and FFmpeg code paths.
Reproduction
Create a test MP4 with tx3g subtitles:
Verify subtitles are correct:
Output (correct):
Bug 1: GPAC path (master branch) — integer overflow
Output:
End timestamps are 0xFFFFFFFF — unsigned integer overflow. Start times are also wrong (both 00:00:00 instead of 00:00:01 and 00:00:04).
Bug 2: FFmpeg/Rust path (feat/replace-gpac-with-ffmpeg branch) — timing offset
Output:
- Subtitle 1 start time is 00:00:00 instead of 00:00:01 (off by 1 second)
- Subtitle 2 end time is 00:00:09,965 instead of 00:00:06,000 (uses video end instead of subtitle end)
Environment
- macOS arm64
- CCExtractor 0.96.5
- FFmpeg 8.0.1
- Test file: MP4 with H.264 video + tx3g subtitle track
Activity
fix: correct tx3g subtitle start timestamps in FFmpeg MP4 demuxer
pantha704 commentedon Oct 16, 2026
Hi! I went through the remaining FFmpeg-path timing issue on current master (97a0d24) with a freshly muxed tx3g MP4 (H.264 + mov_text, subtitles at 1s-3s and 4s-6s) and could still reproduce it:
The GPAC path is correct on master now — it produces
00:00:01,000 --> 00:00:02,999/00:00:04,000 --> 00:00:05,999for the same file. On the FFmpeg path the times come from the shared timing pointer, which can already be past the subtitle (or stuck at zero for the first one) because all tracks share it and packets are interleaved. I have a fix that makes the FFmpeg path match the GPAC path exactly: #2378