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

[Soft Works]

From: Marth64 <marth64 at proxyid.net> 
Sent: Thursday, January 30, 2025 5:44 AM
To: Soft Works <softworkz at hotmail.com>
Cc: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>; Kieran Kunhya <kieran618 at googlemail.com>
Subject: Re: [FFmpeg-devel] [PATCH v2 00/11] fix broken CC detection and ffprobe fields (cover letter)

> > For what it's worth, I have seen this and it can definitely happen.
> Hi, I have seen it too, especially with SCTE-20 samples. Thanks

Which kind of recurrence pattern are you talking about?
I don't think this is conforming to spec. I've been contacted by somebody who was too afraid to post on this ML. He said that the one source from which "sparse" CC data is coming from is a library named libcaption which produces off-spec CC data.

As mentioned before: off-spec CC data or a CC stream appearing due to changes in broadcast can still be detected via analyze_frames. That's not much different to frame size changes, which can also happen at any later point in time. But what's relevant is the frame size at the beginning and CC data in the same way. For spec-conforming streams, this method is very reliable. Most importantly: it doesn't waste precious time by processing the initial frames twice.

Even if it was just 98% reliable, those 2% could not serve as justification for why probing of the 98% takes twice or thrice the time.

sw