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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel