[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.

Well, but that's what the concept of "probing" is all about:

Take a selected amount of a subject (the "probe") and generate an 
aggregated summary result from that probe.

It's not only the small detail of closed_captions - many other essential
other information (like available streams and details) can (depending on 
the container) be subject to that procedure.
Without relying on those results, ffmpeg couldn't work like it does.

From practical experience, I can says that the closed_captions information
that ffmpeg/ffprobe gathers when executing avformat_find_stream_info()
is sufficiently reliable. 
That's exactly the information that we need (further downstream as a 
consumer of ffmpeg/ffprobe) - plus: that's the information that ffmpeg
has available internally. For being able to properly interoperate 
with ffmpeg, it's important that the information that we get from ffprobe
is exactly matching what ffmpeg has internally (given that the probesize
and analyzeduration used for ffprobe and ffmpeg are equal).

That’s why I think that there exists a legitimate interest for a 
consumer to be able to access this information, without needing to 
repeat and duplicate the probing procedure that has already been run.

Kind regards,
softworkz