On date Saturday 2016-09-10 13:51:34 +0200, Nicolas George encoded:
> 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.
-show_entries is the generalization of the various -show_* options,
with the added bonus that it make it possible to specify which
sections and fields to show (and possibly ignore all the other ones).
>
> 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.
I see your point, but while -show_entries has its warts, I don't think
it really complicates the syntax, since there is a straight mapping
from the legacy -show_X options to -show_entries X.
> > > 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 think 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.
At the moment we could simplify the logic, and assume a single section
named packets_and_frames (this can be probably be done with small
effort): I'm working on the code these days and many difficulties stem
from the fact that the data structure describing the sections is not a
tree.
> 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.
In other words you're suggesting to move to an option systems and
drop/deprecate the current system based on marking what needs to be
shown (which is easy as long as you have a fixed order). But even
assuming an option-based syntax specifying the operations you still
have problems with the order of operations. In the specific case of
the subject patch, I will need to specify the order of sections to
print, and the options system (at least the one implemented in ffmpeg)
is order-independent, so:
show_format,show_streams,show_packets
will have the same effect of:
show_packets,show_format,show_streams
[...]
--
FFmpeg = Frightening Fierce Mysterious Powered Extended Goblin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
