Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#2,303 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@GuTS805 is already working on this.

Since Aug 11, 2026.

  • #2304 by @GuTS805 — closed without merging
  • #2313 by @GuTS805 — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
c
Domain
audio-video-rtc

Research direction

Start in src/lib_ccx/dvb_subtitle_decoder.c at dvbsub_parse_object_segment() and trace its callers, dvbsub_decode() and dvbsub_parse_segment. Reproduce the coding_method == 1 case using the described crafted segment buffers, then consult ETSI EN 300 743 §7.2.5.2. Done means character-coded objects are handled or their loss is surfaced distinctly from successful decoding, with coverage for the affected path.

Written by the indexing model from the issue text.

Description

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.
Dominant language
C
Stars
901
Forks
592
Avg merge
5d 19h
Merged PRs (30d)
5

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from CCExtractor/ccextractor

All issues in CCExtractor/ccextractor

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.