[FFmpeg-devel] [PATCH v2 2/2] ffprobe: Fix incorrect display of closed_captions property

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Anton
> Khirnov
> Sent: Monday, 20 September 2021 13:07
> To: James Almer <jamrial at gmail.com>; ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 2/2] ffprobe: Fix incorrect display of
> closed_captions property
> 
> Quoting James Almer (2021-09-19 15:04:11)
> >
> > Yes, something like that could be forced (ReadInterval in ffprobe).
> >
> > >
> > > What you're essentially suggesting is more or less a duplication
> > > of avformat_find_stream_info() and to run it right after
> > > avformat_find_stream_info() has just been run.
> > >
> > > I'm sure we can find a better solution :-)
> >
> > We could always not print codec level information, like the presence of
> > closed captions in a bitstream, when container level information is
> > requested, as is the case of show_streams.
> > It is in fact a per-frame property. One could even not show up until
> > halfways into the video and then not even avformat_find_stream_info()
> > would reflect it. And this flag is essentially a "The decoder found a CC
> > at some point" event flag rather than a stream parameter.
> >
> > The fact ffprobe looks at the decoder context to print stream values to
> > begin with is questionable, and as mentioned, its output is not even
> > guaranteed and depends on external factors, like other user-provided
> > runtime options.
> 
> I agree. ffprobe should stop printing that field as a part of the global
> stream information, it simply cannot work reliably.
> 
> Print it as a part of the frame data instead.

There's also a very practical new use case associated to that subject:

My latest patchset regarding subtitle filtering includes a new 
filter named 'split_cc'. It has a video input and output and
a second output providing subtitle data, which can be processed
in many ways that haven't been available yet.

Users need an easy and direct indication to know whether CC data is 
available and it makes sense to use the filter.

Removing that information from the codec string would rather be
counter-productive in this regard.

softworkz