Extraction of CC's only works for a few minutes of video.

[krasnit]

I just got some older DVDs with CC. They only contain vob files as the video stereams. VLC will properly decode and display the CCs all the way through the videos, but CCextractor will only decode them to srt for the first few minutes of video, and suddenly stop. Most are 30 minute or less videos. There is no message: it just stops extracting and the srt is incomplete. Is there any reason for this?

[kaihere14]

Hi @krasnit, thanks for the report. I dug into the DVD caption parsing path and think I've found a mechanism that would produce exactly this (silent stop, incomplete SRT, no error) but I haven't confirmed it against your actual file, so treat this as a hypothesis to test, not a diagnosis yet.

Could you try these two commands on one of the affected VOBs?

ccextractor input.VOB --out=report
ccextractor input.VOB -2 -o field2.srt

If the report shows both CC1: Yes and CC3: Yes, and field2.srt contains the captions missing from your normal output, that would confirm this theory. As a possible workaround in the meantime, -12 -o out.srt may give you the whole thing.

The theory

DVD line-21 captions are tagged per block as 0xFF (field 1) or 0xFE (field 2), with a pattern_flag bit predicting which comes first. In src/rust/src/es/userdata.rs:147-153 (C twin: src/lib_ccx/es_userdata.c:89-95), a block only counts as field 1 if the marker is 0xFF and it matches pattern_flag; everything else falls through to field 2:

if data[0] == 0xff && j == field1packet {
    data[0] = 0x04; // Field 1
} else {
    data[0] = 0x05; // Field 2   <-- catch-all
}

If the disc's real interleave order ever disagrees with pattern_flag (e.g. flips at a chapter boundary), real field-1 blocks would get relabelled as field 2 from that point on, silently.

Synthetic repro

I built a synthetic VOB and flipped the field order mid-file without touching pattern_flag: the default run ends cleanly with no warning right at the flip point, -2 recovers the "missing" captions from there onward, and --out=report confirms both fields have data. This shows the mechanism is real in principle — it doesn't yet confirm it's what's happening in your specific file.

If the field-order theory checks out against a real sample, I'd be glad to work on a fix, happy to take it on if useful.

@cfsmp3, flagging for a maintainer's read on whether this direction looks right, and whether specific discs originally motivated the pattern_flag fallback.