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

[BUG] MAX_CC_COUNT = 31 in ccxr_process_cc_data silently discards CEA-708 data on H.264 frames with multiple SEI messages

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

Maintainers usually reply within 1 day

@kaihere14 is already working on this.

Since Sep 28, 2026.

  • #2359 by @kaihere14 — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
68/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
c, rust
Domain
audio-video-rtc, backend

Research direction

Start with ccxr_process_cc_data in src/rust/src/lib.rs and trace callers in avc_functions.c, core.rs, and mp4_rust_bridge.c. Compare the processing limit with store_hdcc capacity, then inspect mcc_encode_cc_data and ccx_encoders_mcc.c for the wire-format constraint. Done means large caption batches are processed without discarding CEA-708 data while MCC output still respects its per-envelope limit.

Written by the indexing model from the issue text.

Description

Summary

ccxr_process_cc_data (src/rust/src/lib.rs:~411) rejects any call with more than 31 caption triplets, discarding the entire frame's 708 data (returns -1, logs "discarding frame"). This cap is misapplied: 31 is a real constraint, but it applies to a single envelope's wire-format encoding (a 5-bit cc_count field in ATSC A/53, H.264 SEI, SCTE-20, and CDP), not to how many triplets a decoder call may process at once. The two are being conflated.

Root cause

The 31 cap was added in 65df24e6 (#2241) as an integer-overflow guard, a legitimate fix for a real problem, but placed at the wrong layer. The commit's own reasoning cites the 5-bit cc_count field width in the wire formats as justification, correctly identifying where 31 comes from, but incorrectly applying that per-envelope wire limit as a per-call processing limit.

Nothing downstream in the general decode path actually needs this cap:

  • The triplets get copied into a heap-allocated Vec sized to the actual cc_count, no fixed-size array bound
  • The DTVCC packet assembler processes one triplet at a time across calls; its only real limit is a 128-byte packet length, unrelated to triplet count per call
  • The real storage bound that does matter is the store_hdcc slot capacity, cc_data_pkts[SORTBUF][10*31*3+1], i.e. room for 310 triplets, not 31
Reachability, this is a live bug today, independent of #2350

process_avc (H.264/HEVC extraction) already accumulates every SEI message in a single video picture via copy_ccdata_to_buffer (avc_functions.c:448 / Rust core.rs:444), with no cap, before calling process_cc_data. Any H.264 or HEVC frame carrying enough SEI-embedded caption data to exceed 31 triplets, on real broadcast content this is plausible whenever a frame carries dense caption bursts, has its entire 708 payload for that frame silently discarded, while the 608 data from the same buffer processes normally (since the C do_cb loop has no such cap). This requires no concat, no multi-envelope collision, nothing from #2350, it's independently reachable on unmodified master right now.

Same applies to MP4 files with c708 samples (mp4_rust_bridge.c:174, cc_count = payload_len / 3, bounded only by sample size, not 31).

Where 31 actually is a hard limit, and should stay one

Only mcc_encode_cc_data (--out=mcc), since it packs cc_count into the CDP's real 5-bit field (cc_count | 0xE0, ccx_encoders_mcc.c). That's a genuine wire-format constraint for that one output path, not a general processing limit.

Proposed fix
  1. Raise MAX_CC_COUNT in ccxr_process_cc_data to the real storage bound (310, matching the store_hdcc slot capacity), or otherwise remove the artificial 31 ceiling from general-purpose processing
  2. Move the actual ≤31-per-envelope chunking into mcc_encode_cc_data specifically, looping over the buffer in chunks of ≤31 triplets, one CDP per chunk, since that's the only place the 5-bit constraint is real
  3. mcc_encode_cc_data's uint8 data_size = cc_count * 3 should also be widened or bounded by the chunking, to avoid the wraparound the earlier investigation flagged
Note

Found while investigating #2350 (store_hdcc concat behavior), but this bug is fully independent, it doesn't require #2350's fix or concat to be involved at all, and should be fixed on its own regardless of how #2350 proceeds.

@cfsmp3 tagging for a read, this one looks like a straightforward, well-scoped fix if the reasoning checks out. Happy to work on it.

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.