[FFmpeg-devel] [PATCH] ffprobe: add -show_headers_first option

Nicolas George george at nsup.org
Sat Sep 10 14:51:34 EEST 2016


Le tridi 23 fructidor, an CCXXIV, Stefano Sabatini a écrit :
> We have the -show_entries option, and we can extend it to consider
> order. The equivalent syntax will then be:
> 
> ffprobe -show_entries format,streams,packets

As I said, I never really understood what -show_entries does. I had
remembered it was for enabling/disabling fields within sections, not
enabling/disabling sections. I suppose the reasoning is that it does not
make sense to enable a field in a section if the section is not printed.

Still, the result is that the same effect can be achieved by several
different means, with slightly different contours, and I think this is not
good for anybody: users are confused about the "right" way of doing it,
maintainers have a higher risk of breaking something.

I think it may be time to put aside all the options that were added to
implement features incrementally in a backward-compatible way, and rebuild a
brand new syntax for all the features at once.

> > ffprobe -show format,streams,packets,rewind,packets+frames=silent=1,streams
> Now the problem with this idea is the interaction with
> -read_packets. The option was useful to force reading of packets so
> that the gained information was also available in the streams and
> format sections (but without showing the packets output).
> 
> I can think about extending the -show_entries syntax, so that we could
> have:
> 
> -show_entries !packets,format,streams
> 
> What I don't like is that this special syntax will only work with
> packets (it makes no sense for the other sections).

This issue of reading packets to extract information but not clutter the
output with them is the reason I suggested in my example
"packets+frames=silent=1".

Still, the inconsistent syntax does not bother me either way: I think users
can understand that a feature (doing the probe but suppressing the output)
only works for a particular section, but they can also understand that the
same feature works for all sections but is only useful for one. Therefore,
we do whichever is simpler to implement and just make sure to explain it in
the doc.

There is another, more confusing case, where "print sections in order" can
not work: packets and frames must be probed and printed together.

I think it would help to thinks of the steps not as sections to print but as
tasks to perform. Most tasks are just printing a section, but the task about
packets has three optional subtasks: printing the packets, decoding the
frames, printing the frames (of course, printing the frames without decoding
makes no sense).

If we design things to allow tasks to have aliases ("f" for "formats") and
allow aliases to have different defaults for options, things can work in a
way that is both convenient and logical. Consider a single task,
"packets_and_frames", with three options, "print_packets=[01]",
"decode_frames=[01]", "print_frames=[01]", and aliases: "packets" causing
the options to default to 1/0/0, "frames" to 0/1/1; any other combination
can be achieved by setting the options explicitly.

The enabling or disabling of individual fields can also be an option to
tasks. That allow to support the same features as -show_entries in a more
logical way.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160910/8f9e4132/attachment.sig>


More information about the ffmpeg-devel mailing list