Skip to content

Conversation

@cfsmp3
Copy link
Contributor

@cfsmp3 cfsmp3 commented Jan 4, 2026

Summary

  • Fixed MXF files containing CEA-708 captions not being detected or extracted
  • Root cause: CCX_RAW_TYPE data from MXF demuxer was only passed to the legacy 608 decoder, not the DTVCC decoder for 708 captions
  • Changed CCX_RAW_TYPE handling to use process_cc_data instead of process_raw_with_field
  • Added DTVCC decoder activation for MXF/GXF sources
  • Fixed PTS calculation in MXF demuxer to use 90kHz units

Test plan

  • Tested with sample MXF file containing CEA-708 captions (708cc_5seconds.mxf)
  • Verified output: captions extracted correctly to .p0.svc01.srt file
  • Build passes successfully

Files changed

  • src/lib_ccx/general_loop.c - Main fix: route CCX_RAW_TYPE through DTVCC decoder
  • src/lib_ccx/ccx_dtvcc.h - Added FFI declaration for ccxr_dtvcc_set_active
  • src/rust/src/lib.rs - Added ccxr_dtvcc_set_active function
  • src/rust/src/decoder/mod.rs - Fixed flush logic for visible windows
  • src/lib_ccx/ccx_demuxer_mxf.c - Fixed PTS calculation, changed verbose logging to debug

Fixes #1647

🤖 Generated with Claude Code

Root cause: CCX_RAW_TYPE data from MXF demuxer was not being passed to
the DTVCC decoder, only to the legacy 608 decoder via process_raw_with_field.

Changes:
- general_loop.c: Changed CCX_RAW_TYPE handling to use process_cc_data
  instead of process_raw_with_field to properly invoke DTVCC decoder
- general_loop.c: Added DTVCC activation for MXF/GXF sources since they
  may contain 708 captions
- general_loop.c: Initialize timing from caption PTS when not set
- ccx_dtvcc.h: Added ccxr_dtvcc_set_active FFI declaration
- lib.rs: Added ccxr_dtvcc_set_active function to enable DTVCC decoder
- decoder/mod.rs: Fixed flush logic to always process visible windows
- ccx_demuxer_mxf.c: Fixed PTS calculation to use 90kHz units based on
  edit_rate, and changed verbose logging to debug()

Fixes #1647

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@cfsmp3 cfsmp3 force-pushed the fix/issue-1647-mxf-708-captions branch from ddf2967 to 6950a76 Compare January 4, 2026 10:17
@cfsmp3 cfsmp3 closed this Jan 4, 2026
@cfsmp3 cfsmp3 reopened this Jan 4, 2026
@ccextractor-bot
Copy link
Collaborator

CCExtractor CI platform finished running the test files on linux. Below is a summary of the test results, when compared to test for commit 8c33412...:
Report Name Tests Passed
Broken 13/13
CEA-708 14/14
DVB 7/7
DVD 3/3
DVR-MS 2/2
General 25/27
Hardsubx 1/1
Hauppage 3/3
MP4 3/3
NoCC 10/10
Options 81/86
Teletext 21/21
WTV 13/13
XDS 34/34

Your PR breaks these cases:

  • ccextractor --autoprogram --out=ttxt --latin1 --ucla dab1c1bd65...
  • ccextractor --out=srt --latin1 --autoprogram 29e5ffd34b...
  • ccextractor --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
  • ccextractor --startcreditsnotbefore 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
  • ccextractor --startcreditsnotafter 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
  • ccextractor --startcreditsforatleast 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
  • ccextractor --startcreditsforatmost 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...

Congratulations: Merging this PR would fix the following tests:

  • ccextractor --autoprogram --out=srt --latin1 --quant 0 85271be4d2..., Last passed: Never

It seems that not all tests were passed completely. This is an indication that the output of some files is not as expected (but might be according to you).

Check the result page for more info.

@ccextractor-bot
Copy link
Collaborator

CCExtractor CI platform finished running the test files on windows. Below is a summary of the test results, when compared to test for commit 8c33412...:
Report Name Tests Passed
Broken 13/13
CEA-708 14/14
DVB 6/7
DVD 3/3
DVR-MS 2/2
General 25/27
Hardsubx 1/1
Hauppage 3/3
MP4 3/3
NoCC 10/10
Options 80/86
Teletext 21/21
WTV 13/13
XDS 34/34

Your PR breaks these cases:

  • ccextractor --autoprogram --out=srt --latin1 --quant 0 85271be4d2...
  • ccextractor --autoprogram --out=ttxt --latin1 --ucla dab1c1bd65...
  • ccextractor --out=srt --latin1 --autoprogram 29e5ffd34b...
  • ccextractor --out=spupng c83f765c66...
  • ccextractor --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
  • ccextractor --startcreditsnotbefore 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
  • ccextractor --startcreditsnotafter 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
  • ccextractor --startcreditsforatleast 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
  • ccextractor --startcreditsforatmost 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...

It seems that not all tests were passed completely. This is an indication that the output of some files is not as expected (but might be according to you).

Check the result page for more info.

@cfsmp3 cfsmp3 merged commit 1c75156 into master Jan 4, 2026
43 of 45 checks passed
@cfsmp3 cfsmp3 deleted the fix/issue-1647-mxf-708-captions branch January 4, 2026 16:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] 708 captions inside of an MXF file are not being detected by CCExtractor

3 participants