MXF: improve ANC/VANC caption detection (fix #1647)

[03-SudheshnaReddy]

Fixes #1647

What I changed

• Improved MXF ANC/VANC parsing logic so caption packets are not silently skipped
• Added stricter handling and validation around DID / SDID detection in VANC data
• Ensured both CEA-608 and CEA-708 payloads are recognized when present
• Minor defensive checks to avoid early exits when valid ANC data exists
• Changes are strictly limited to the MXF demuxer (ccx_demuxer_mxf.c/.h)

Why

CCExtractor currently reports “No subtitles found” for some MXF files that clearly contain captions, as confirmed by Premiere Pro.
Investigation showed that ANC/VANC caption packets can be present but not detected due to demuxer-level logic gaps.

This PR aims to ensure CCExtractor correctly identifies and processes those caption packets.

Scope

• No changes to Rust code, build scripts, or external dependencies
• No behavior changes outside MXF demuxing

Notes

• First-time contributor — feedback very welcome
• My local Windows build environment is unstable, so I focused on a minimal, reviewable fix based on code inspection and format behavior
• Happy to refine, add logging, or adjust based on maintainer guidance

[cfsmp3]

Thank you for your first contribution to CCExtractor! I appreciate the detailed PR description and your effort to investigate issue #1647.

After reviewing the code changes, I have some concerns:

Code doesn't fix the extraction issue

The PR adds a flag to track when ANC captions are detected, but doesn't actually change the extraction logic. Setting found_anc_captions = 1 when we see SDID 0x01/0x02 confirms captions exist, but if they're not being extracted, knowing they exist doesn't help.

The change in ccx_mxf_getmoredata():

if (ret <= 0 && mxf && mxf->found_anc_captions)
    return 0;

This masks error conditions but doesn't cause captions to be extracted.

To actually fix #1647, we need to debug:

1. Is the cap_essence_key matching the caption track in the problem file?
2. Is mxf_read_vanc_data() being called at all for this file?
3. Are there different DID values (not 0x61/0x80) in some MXF files?
4. Is mxf_read_cdp_data() parsing the CDP correctly?

Would you be able to add some debug logging and test with the sample file from issue #1647? That would help identify the actual root cause.

Code quality issues to fix:

1. Remove commented-out code: Delete the old ccx_mxf_init() duplicate
2. Fix indentation: The code has inconsistent tabs/spaces mixing
3. Add NULL check: Check ctx in mxf_read_vanc_data() before dereferencing
4. Remove redundant init: found_anc_captions = 0 after memset is unnecessary
5. Resolve conflicts: Rebase on current master

Sample file needed

To properly test and validate any fix for this issue, we need access to a sample MXF file that exhibits this problem. The original issue #1647 includes a Google Drive link to a sample file - could you confirm you're testing with that file, or provide a sample we can use to reproduce and verify the fix?

Without a test file, we can't validate that any changes actually solve the problem.

Happy to help debug this if you can provide more information about what's happening when CCExtractor processes MXF files with 708 captions!

[cfsmp3]

Thank you for working on this issue! This is a good area to investigate. However, several changes are needed:

1. Rebase required - This PR is based on an older master and needs to be rebased to work with the current codebase

2. Fix code formatting - The indentation is inconsistent (mixed tabs and spaces). Please run clang-format on the changed file or match the existing style

3. Remove commented-out code - The old ccx_mxf_init function is left as comments (lines 611-622). These should be deleted entirely

4. Logic clarification needed - Setting found_anc_captions = 1 when captions are detected is fine, but the check at the end (if (ret <= 0 && mxf->found_anc_captions) return 0) just returns 0 without actually fixing anything. Could you explain what this is intended to do?

Do you have a sample MXF file that demonstrates the issue? That would help us verify the fix works correctly.

[cfsmp3]

Hi @03-SudheshnaReddy, any update on this PR? It needs:

1. Rebase on master
2. Code formatting cleanup
3. Remove commented-out code
4. Clarify the detection logic

Let us know if you're still working on this or if we should close it.

[03-SudheshnaReddy]

Hi @cfsmp3

Thank you for the detailed review and for following up — I’m really sorry for going quiet on this PR. That wasn’t intentional.

I want to be honest: this is my first time working in this part of the CCExtractor codebase, and I underestimated the complexity of the MXF demuxer. After your feedback, I understand that my current changes don’t actually fix the extraction path and mostly add detection/guard logic without addressing the root cause.

I think I froze a bit because I realized the PR wasn’t in a good state yet, but I should have communicated instead — that’s on me.

I’m still very interested in learning and contributing properly. If you’re okay with it, I’d like to either:

rework this PR into a diagnostics-focused change (better logging to understand why the sample fails), or

close this PR and come back with a better-tested fix once I understand the full pipeline better.

I’m a beginner here, but I’m serious about improving and putting in the work. I appreciate your time and guidance, and I’m happy to follow whatever direction you think makes most sense.

Thanks again.

[cfsmp3]

@03-SudheshnaReddy Let's close it for you, you can work on it whenever it's convenient for you, no worries.