[FIX]Fix panic when using --mp4/--mkv without explicit input format

[gaurav02081]

[FIX]Fix panic when using --mp4/--mkv without explicit input format

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.

---

Found a issue --

if the user use --mp4 ya --mkv with invalid / broken file ,then the programs gets crashes instead of handling that with error message .

it is happeing because of the unwrap() METHOD
command used for reproduce the issue

dd if=/dev/urandom of=bad.mp4 bs=1024 c
ount=1 && ./mac/ccextractor bad.mp4 --mp4

FIX -- (src/rust/src/parser.rs)

and added flags rgs.mp4 and args.mkv in the set_input_format function
replace unwrap with map with closures.

After the fix, the program no longer crashes

[gaurav02081]

Previously:

set_input_format() was called conditionally through a guard in parse_parameters(), meaning it was skipped during most normal (autodetection) runs.

Additionally, the fatal! fallback inside set_input_format() would terminate execution if no explicit format matched, preventing autodetection from taking place.

This caused unintended behavior:

Normal runs could bypass initialization logic.

If triggered without a matching format, the function would exit instead of allowing autodetection.

Final Fix

Removed the fatal! fallback so that when no explicit format flag matches, the function simply returns and preserves autodetection behavior.

Removed the guard in parse_parameters() so that set_input_format() is always called as part of initialization.

Explicit handling for --mp4 and --mkv remains intact.

The unsafe unwrap() has been eliminated.

[cfsmp3]

Review

The bug is real — confirmed that --mp4 (and --mkv) cause an abort on master because set_input_format() doesn't handle these flags, falls through to the fatal! macro, and args.input.unwrap() panics on None.

However, the fix is over-engineered. You're commenting out the fatal! and commenting out the guard condition, when the actual fix is just 2 lines.

What's wrong with the current approach:

1. Commenting out code instead of removing it — commented-out code is dead code. Either remove it or keep it.
2. Removing the guard condition — the guard at line 661-672 correctly prevents calling set_input_format() when no format flags are set. Removing it is unnecessary.
3. Removing the fatal — the fatal! for unknown formats is a useful error message. It should stay, just with the unwrap() fixed.

The correct fix (3 lines changed):

In set_input_format(), add the missing handlers before the else branch:

        } else if args.wtv {
            self.set_input_format_type(InFormat::Wtv);
+       } else if args.mp4 {
+           self.set_input_format_type(InFormat::Mp4);
+       } else if args.mkv {
+           self.set_input_format_type(InFormat::Mkv);
        } else {
            fatal!(
                cause = ExitCause::MalformedParameter;
-              "Unknown input file format: {}\n", args.input.unwrap()
+              "Unknown input file format: {}\n", args.input.unwrap_or("unknown")
            );
        }

That's it. Keep the guard condition as-is (it already includes args.mp4 and args.mkv). Keep the fatal! for genuinely unknown formats. Just add the missing handlers and fix the unwrap().

Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com

[gaurav02081]

@cfsmp3 Thanks for the review I have applied the suggested changes and kept the original guard and fatal! logic intact.

While implementing -

args.input.unwrap_or("unknown")
the build failed because args.input is of type Option, whereas "unknown" is a &str, which resulted in a type mismatch.

To keep the behavior the same while ensuring type safety, I updated the fatal! call to:

fatal!(
    cause = ExitCause::MalformedParameter;
    "Unknown input file format: {}\n",
    args.input
        .map(|i| i.to_string())
        .unwrap_or_else(|| "unknown".to_string())
);

This preserves the intended error message while avoiding the panic .

[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 0626bb5...:

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.

[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 0626bb5...:

Report Name	Tests Passed
Broken	13/13
CEA-708	14/14
DVB	7/7
DVD	3/3
DVR-MS	2/2
General	27/27
Hardsubx	1/1
Hauppage	3/3
MP4	3/3
NoCC	10/10
Options	85/86
Teletext	21/21
WTV	13/13
XDS	34/34

Your PR breaks these cases:

• ccextractor --out=spupng c83f765c66...

Congratulations: Merging this PR would fix the following tests:

• ccextractor --autoprogram --out=srt --latin1 --quant 0 85271be4d2..., Last passed: Never
• ccextractor --autoprogram --out=ttxt --latin1 --ucla dab1c1bd65..., Last passed: Never
• ccextractor --out=srt --latin1 --autoprogram 29e5ffd34b..., Last passed: Never
• ccextractor --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never
• ccextractor --startcreditsnotbefore 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never
• ccextractor --startcreditsnotafter 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never
• ccextractor --startcreditsforatleast 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never
• ccextractor --startcreditsforatmost 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., 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.