[FFmpeg-devel] [PATCH v2 00/11] fix broken CC detection and ffprobe fields (cover letter)

[Soft Works]

> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Kieran Kunhya via ffmpeg-devel
> Sent: Monday, January 27, 2025 10:40 AM
> > While this is a very valid concern for some kinds of frame side
> data, it
> > does not apply to CC data. It's either in every frame or none. If a
> > provider generally broadcasts CC, then it's always present in every
> frame,
> > even during programs for which no CC is available - it's always
> there. Like
> > I mentioned at the top, we're using the properties field from the
> codec
> > (via codec_par) and there hasn’t been a single case reported where
> the CC
> > detection this way would have been incorrect.
> >
> 
> This isn't true, CC data is sparse.
> I have no opinions about the rest of the text.
> 
> Kieran

Hi Kieran,

I found it 😊

It's in  EIA-708-A from 1999 as well as in the latest successor spec ANSI/CTA-708-E S-2023

from chapter 4.1 (1999): 

"for DTV and DTVCC specific (Le., ATSC A/53) caption encoding, the DTV Closed-Captioning channel is a continuous 9600 bps stream allocated from the DTV signal capacity"
(the latest version adds more variations)

and chapter 4.2 (1999): "Pre-Allocated Bandwidth"

"The DTVCC Transport Channel is a fixed, pre-allocated stream which exists in all DTV-system bit streams, even though captions may not be present. This ever-present bandwidth (which includes NTSC and DTVCC caption data) allows encoders to easily insert caption data into the DTV bit-stream at the point of origin and at multiple down-stream encoding points without having to perform complex picture data processing and bandwidth reallocation"


Maybe you just mixed it up with DVB subtitles which are actually sparse?

sw