Fix: Prevent AVC segfault in report-only mode (-out=report)

[x15sr71]

In raising this pull request, I confirm the following (please check boxes):

• I have read and understood the contributors guide.
• I have checked that another pull request for this purpose does not exist.
• I have considered, and confirmed that this submission will be valuable to others.
• I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
• I give this submission freely, and claim no ownership to its content.
• I have mentioned this change in the changelog.

My familiarity with the project is as follows (check one):

• I have never used CCExtractor.
• I have used CCExtractor just a couple of times.
• I absolutely love CCExtractor, but have not contributed previously.
• I am an active contributor to CCExtractor.

---

Summary

This PR fixes a segmentation fault that occurs (as reported in issue #2023) when running CCExtractor in report-only mode (-out=report) on files containing AVC (H.264) video streams with the Rust AVC decoder enabled.

---

Problem

When running:

./ccextractor -out=report input.ts

on transport streams containing AVC/H.264 video, CCExtractor crashes with a segmentation fault.

Solution

Add a defensive guard at the C → Rust FFI boundary in process_avc() to skip AVC processing when the decoder context isn't fully initialized (such as in report-only mode).

Guard Conditions

Skip calling the Rust AVC decoder if any of the following are true:

• encoder_ctx is NULL
• encoder_ctx->timing is NULL
• lib_cc_decode is NULL
• lib_cc_decode->avc_ctx is NULL

In these cases, process_avc() simply returns without invoking the Rust decoder.

Rationale

• The fix belongs at the C → Rust boundary, where assumptions about initialization must be enforced
• Only affects process_avc(); no changes to Rust internals
• Report-only mode does not require AVC frame decoding.
• Prevents similar crashes if decoding state isn't initialized elsewhere

[ccextractor-bot]

CCExtractor CI platform finished running the test files on linux. Below is a summary of the test results, when compared to test for commit 2028754...:

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	78/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 --no-codec dvbsub c83f765c66...
• ccextractor --debug --out=srt c83f765c66...
• ccextractor --cbraw --out=srt 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...

Congratulations: Merging this PR would fix the following tests:

• ccextractor --autoprogram --out=srt --latin1 --quant 0 85271be4d2..., Last passed: Never
• ccextractor --out=spupng c83f765c66..., 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]

CCExtractor CI platform finished running the test files on windows. Below is a summary of the test results, when compared to test for commit 2028754...:

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	81/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 --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 --out=spupng c83f765c66..., 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.

[cfsmp3]

Thank you for working on this fix! However, I'm closing this PR in favor of #2025, which takes a simpler approach that doesn't break existing tests.

Why this PR breaks tests

The guard conditions are too aggressive:

if (!enc_ctx || !enc_ctx->timing || !dec_ctx || !dec_ctx->avc_ctx)

This checks 4 conditions, but only !enc_ctx is needed for the report-only mode fix. The additional checks (!enc_ctx->timing, !dec_ctx->avc_ctx) reject legitimate processing scenarios:

1. !enc_ctx->timing - This can be NULL in certain initialization states during normal processing, not just report mode
2. !dec_ctx->avc_ctx - Same issue; this blocks AVC processing even when it should proceed

The CI shows 10+ test failures including --autoprogram, --startcreditstext, and other options that have nothing to do with report mode.

The simpler fix (#2025)

PR #2025 adds the guard at the Rust FFI boundary with minimal checks:

if enc_ctx.is_null() {
    return avcbuflen;
}

This precisely targets the report-only mode case (where enc_ctx is NULL because no encoder is created) without affecting any other code paths.

Location consideration

The fix belongs at the Rust FFI boundary (inside ccxr_process_avc) rather than in the C wrapper, because:

• The Rust code is what dereferences the pointers
• Rust's safety guarantees should be enforced at the Rust boundary
• It keeps the C code clean and unchanged

Thank you again for identifying this issue and submitting a fix! Your contribution helped highlight the problem.

[x15sr71]

Thanks for the review and explanation. I see the issue now, I was checking too many things when only the enc_ctx NULL case mattered for report mode. The extra checks on timing and avc_ctx ended up blocking legitimate scenarios during normal processing also putting the guard in the Rust FFI function is cleaner too, since that's where the crash actually happens. Appreciate you fixing it properly and explaining why.