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