DVB subtitle decoder silently discards character-coded ("string coding") object segments — coding_method == 1 is a no-op that reports success

[GuTS805]

Component

C-core — src/lib_ccx/dvb_subtitle_decoder.c

Problem

dvbsub_parse_object_segment() branches on object_coding_method (bits 3-2 of the
object-coding-method byte, per ETSI EN 300 743 §7.2.5). coding_method == 0 (pixel/bitmap
objects) is fully handled via dvbsub_parse_pixel_data_block(). But coding_method == 1
("character coded" / string-coded objects — a legal, bandwidth-saving encoding some
broadcasters use) is a no-op:

https://github.com/CCExtractor/ccextractor/blob/master/src/lib_ccx/dvb_subtitle_decoder.c#L1122-L1130

else if (coding_method == 1)
{
	mprint("FIXME support for string coding standard\n");
}
else
{
	mprint("Unknown object coding %d\n", coding_method);
}
return 0;
No pixel or text data is ever written for that object, and the function still return 0
— the same value used on success. Every caller up the chain (dvbsub_decode() →
dvbsub_parse_segment switch) treats 0 as "proceed normally," so the caption region is
silently left blank with only a buried mprint line as evidence.

Why it matters
CCExtractor's entire purpose is making caption/subtitle content accessible. This isn't a
crash or loud error — it's silent data loss. A hard-of-hearing/deaf viewer relying on
extracted captions gets nothing for that segment, and there's no clear signal in normal
usage (the FIXME line is easy to miss in a full extraction log, and nothing marks the
output as incomplete).

Reproduction (confirmed against current master, actual code — not simulated)
I built current master with autotools (./autogen.sh && ./configure && make) and wrote
a small harness that #includes dvb_subtitle_decoder.c directly (so it calls the real,
compiled static functions) and drives it with two crafted segment buffers per EN 300 743:

A minimal region-composition-segment (16 bytes) registering region_id=1 (16×16, depth=4) and referencing object_id=1 — matches what a real broadcast stream sends before an object segment.
An object-data-segment (00 01 04) for object_id=1 with object_coding_method=1 (byte 0x04 → bits [3:2] = 01).
Output:


Region 1 registered OK. region->dirty BEFORE object segment = 0
FIXME support for string coding standard
dvbsub_parse_object_segment(coding_method=1) returned = 0  (0 == "success" to every caller)
region->dirty AFTER object segment  = 0  (0 == no pixel/text data was ever written)

CONFIRMED: character-coded DVB subtitle object was silently discarded.
region->dirty (the flag dvbsub_parse_pixel_data_block() sets when it writes pixel
data) stays 0 — confirming no output was produced — while the function still returns
success.

Not a duplicate
Searched open/closed issues and PRs for "string coding", "coding_method",
"dvb subtitle object", "character-coded", and dvb_subtitle_decoder. The closest
historical issue, #243 ("Corrupt or empty subtitles (OCR, ts, DVB)"), has unrelated root
causes (missing DVBSUB_DISPLAY_SEGMENT handling, OCR failures, a telxcc fuzzy-match
bug). The one PR touching this file, #1794, only added malloc NULL checks.

Proposed fix direction
Minimum: stop returning 0 (success) from a path that did no work — surface this at a real warning/error level distinguishable from "decoded successfully" (e.g. track dropped-object stats so users can tell captions were silently lost).
Full fix: implement §7.2.5.2 character-object parsing (map character codes through the associated CLUT/character table). Since CCExtractor already OCRs pixel-object bitmaps down to text, a character-coded object could arguably be extracted as plain text with less code than the existing bitmap path.

[GuTS805]

Hi, I'd like to work on this issue. I've already confirmed the bug with a minimal repro (see issue description). Planning to start with the fix. let me know if there's a preferred approach.