Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Chiusa
  • Qualcosa non va?
#2,358 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
c, rust
Ambito
audio-video-rtc, backend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
C
Stelle
908
Fork
595
Merge medio
3g 6h
PR unite (30g)
31

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di CCExtractor/ccextractor

Tutte le issue di CCExtractor/ccextractor

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.