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!