[PR #1872] fix(timing): Fix --goptime producing compressed timestamps #2650

Closed
opened 2026-01-29 17:23:15 +00:00 by claunia · 0 comments
Owner

Original Pull Request: https://github.com/CCExtractor/ccextractor/pull/1872

State: closed
Merged: Yes


Summary

Fixes Test 163 where --goptime option produced compressed timestamps (00:00:01-02) instead of actual GOP times (17:56:40-47).

Root Cause

When using --goptime, there was a conflict between:

  • GOP timing set from GOP headers (wall-clock time, e.g., 17:56:40)
  • PES PTS timing (stream-relative time, e.g., 00:00:02)

The sync detection code saw these as ~64,598-second "jumps" and kept resetting timing, causing the output timestamps to be corrupted.

Fixes Applied

  1. Guard video PES timing in general_loop.c - skip set_current_pts and set_fts when use_gop_as_pts == 1 to prevent PES PTS from overwriting GOP-based timing

  2. Disable sync check in ccextractor.c when use_gop_as_pts == 1 since GOP time and PES PTS are in different time bases and sync detection is meaningless in this mode

Test Results

Sample: c83f765c661595e1bfa4750756a54c006c6f2c697a436bc0726986f71f0706cd.ts

  • Initial GOP time: 17:56:40:433
  • Final GOP time: 17:56:47:934

Before fix:

1
00:00:01,231 --> 00:00:01,729
(explosion)

After fix:

1
17:56:41,319 --> 17:56:43,084
(explosion)

Test Plan

  • Verified --goptime now produces correct GOP-based timestamps
  • Verified normal mode (without --goptime) still works correctly
  • No warnings about "Reference clock has changed abruptly"

🤖 Generated with Claude Code

**Original Pull Request:** https://github.com/CCExtractor/ccextractor/pull/1872 **State:** closed **Merged:** Yes --- ## Summary Fixes Test 163 where `--goptime` option produced compressed timestamps (00:00:01-02) instead of actual GOP times (17:56:40-47). ### Root Cause When using `--goptime`, there was a conflict between: - GOP timing set from GOP headers (wall-clock time, e.g., 17:56:40) - PES PTS timing (stream-relative time, e.g., 00:00:02) The sync detection code saw these as ~64,598-second "jumps" and kept resetting timing, causing the output timestamps to be corrupted. ### Fixes Applied 1. **Guard video PES timing** in `general_loop.c` - skip `set_current_pts` and `set_fts` when `use_gop_as_pts == 1` to prevent PES PTS from overwriting GOP-based timing 2. **Disable sync check** in `ccextractor.c` when `use_gop_as_pts == 1` since GOP time and PES PTS are in different time bases and sync detection is meaningless in this mode ### Test Results **Sample:** `c83f765c661595e1bfa4750756a54c006c6f2c697a436bc0726986f71f0706cd.ts` - Initial GOP time: 17:56:40:433 - Final GOP time: 17:56:47:934 **Before fix:** ``` 1 00:00:01,231 --> 00:00:01,729 (explosion) ``` **After fix:** ``` 1 17:56:41,319 --> 17:56:43,084 (explosion) ``` ## Test Plan - [x] Verified `--goptime` now produces correct GOP-based timestamps - [x] Verified normal mode (without `--goptime`) still works correctly - [x] No warnings about "Reference clock has changed abruptly" 🤖 Generated with [Claude Code](https://claude.com/claude-code)
claunia added the pull-request label 2026-01-29 17:23:15 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/ccextractor#2650