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

Activity

1. krasnit

   changed the title [-]Extraction of CC's only works for a few seconds of video.[/-] [+]Extraction of CC's only extracts a few minutes of video.[/+] on Jul 29, 2026
2. krasnit

   changed the title [-]Extraction of CC's only extracts a few minutes of video.[/-] [+]Extraction of CC's only works for a few minutes of video.[/+] on Jul 29, 2026
3. kaihere14 commented on Aug 10, 2026

   

   kaihere14

   on Aug 10, 2026

   Contributor

   More actions

   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.