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

[Kieran Kunhya]

On Mon, Jan 27, 2025 at 7:03 PM Soft Works <softworkz at hotmail.com> wrote:
>
> > 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"

Not everyone follows this.

Kieran