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

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Devin Heitmueller
> Sent: Monday, January 27, 2025 9:16 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Cc: Marth64 <marth64 at proxyid.net>; Kieran Kunhya
> <kieran618 at googlemail.com>
> Subject: Re: [FFmpeg-devel] [PATCH v2 00/11] fix broken CC detection
> and ffprobe fields (cover letter)
> 
> > Do you have an example stream recording?
> > And who are those who wouldn't be following? Broadcasters?
> 
> For what it's worth, I have seen this and it can definitely happen.
> It's not common though since it both technically violates the spec
> and
> also not best practice (for example, some televisions won't show you
> the option to enable captions if the caption stream isn't present at
> all).  Generally it occurs when the broadcaster is doing splicing of
> TS streams entirely in the compressed domain (e.g. for ad insertion),
> or cases where ads or programs don't contain captions and the
> encoder/transcoder isn't smart enough to generate empty caption
> packets and include them in the output.
> 
> That said, I think it's very defensible to say, "We don't set the
> flag
> saying captions are present if not detected within the probing
> window".
> 
> Devin

Hi Devin,

thanks a lot for your insights. Sure that those kinds of cases exist. Another example would be shared program slots where one broadcaster sends CC and the other doesn't.

But that's different from what Kieran said (= "sparse"), which would mean that there's no continuous stream and caption data comes around only when there's some caption content to display. I was about to say that this isn't even possible due to the way TVs are working, but I didn't feel to have sufficient evidence, so thanks for confirming this.

In case of "sparse" data, it would have meant that there could be captions which can only be detected by scanning frames for a certain time range (like 20s).
But as we agree - the result from the initial parsing is sufficient to reliably know whether there are captions at the start of the stream - same like we determine the frame size. Both can change at a later time, but both are definitive for the probed section of the stream.

Besides: one doesn't exclude the other, we should anyway keep the -analyze_frames feature because it's very useful for other side data, and that means you'd also be able to get an answer to the question whether there's CC data _anywhere_ in the stream - if you want it.

Thanks
sw