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

From: Soft Works <softworkz-at-hotmail.com@ffmpeg.org>
To: Kieran Kunhya <kieran618@googlemail.com>
Cc: Marth64 <marth64@proxyid.net>,
	FFmpeg development discussions and patches
	<ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH v2 00/11] fix broken CC detection and ffprobe fields (cover letter)
Date: Mon, 27 Jan 2025 19:36:41 +0000
Message-ID: <DM8P223MB0365A2E4217F8517838CD96ABAEC2@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <CABGuwEnsvrbZX1pQ1tAx25v+VBbjO-jW20bvjYmveFhaBifs7A@mail.gmail.com>

> -----Original Message-----
> From: Kieran Kunhya <kieran618@googlemail.com>
> Sent: Monday, January 27, 2025 8:26 PM
> To: Soft Works <softworkz@hotmail.com>
> Cc: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>; Marth64 <marth64@proxyid.net>
> Subject: Re: [FFmpeg-devel] [PATCH v2 00/11] fix broken CC detection
> and ffprobe fields (cover letter)
> 
> On Mon, Jan 27, 2025 at 7:03 PM Soft Works <softworkz@hotmail.com>
> wrote:
> >
> > > From: ffmpeg-devel <ffmpeg-devel-bounces@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

Do you have an example stream recording?
And who are those who wouldn't be following? Broadcasters? 

As mentioned previously, we have users from all over the US who are recording ATSC streams from all kinds of broadcasters and not a single case has been seen where the CC detection are part of the codec probing has led to incorrect results (in 4 years).

And since when do we care about off-spec?
Finally, it's not about breaking any existing behavior. The CC detection has been defunct for years now.

sw
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".