Skip to content

Commit 76bbbb8

Browse files
cfsmp3claude
andcommitted
fix(rust): remove double-increment of cb_708 counter
The cb_708 counter was being incremented twice for each CEA-708 data block: 1. In do_cb_dtvcc_rust() in Rust (src/rust/src/lib.rs) 2. In do_cb() in C (src/lib_ccx/ccx_decoders_common.c) Since FTS calculation uses cb_708 (fts = fts_now + fts_global + cb_708 * 1001 / 30), the double-increment caused timestamps to advance ~2x as fast as expected, resulting in incorrect milliseconds in start timestamps. This fix removes the increment from the Rust code since the C code already handles it in do_cb(). Fixes timestamp issues reported in PR CCExtractor#1782 tests where start times like 00:00:20,688 were incorrectly output as 00:00:20,737. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
1 parent ec68342 commit 76bbbb8

File tree

1 file changed

+3
-1
lines changed

1 file changed

+3
-1
lines changed

src/rust/src/lib.rs

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -549,7 +549,9 @@ pub fn do_cb_dtvcc_rust(ctx: &mut lib_cc_decode, dtvcc: &mut DtvccRust, cc_block
549549
if timeok && ctx.write_format != ccx_output_format::CCX_OF_RAW {
550550
dtvcc.process_cc_data(cc_valid, cc_type, cc_block[1], cc_block[2]);
551551
}
552-
unsafe { cb_708 += 1 }
552+
// Note: cb_708 is incremented by the C code in do_cb(), not here.
553+
// Previously incrementing here caused a double-increment bug that
554+
// resulted in incorrect start timestamps.
553555
}
554556
_ => warn!("Invalid cc_type"),
555557
}

0 commit comments

Comments
 (0)