> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Anton > Khirnov > Sent: Monday, 20 September 2021 13:07 > To: James Almer <jamr...@gmail.com>; ffmpeg-devel@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
