Replying to everybody at once:
To Ronald, regarding "rewrite EVERYTHING!!!" versus "added as extensions of the current API": My gut feeling is that starting from scratch would prove less efforts in total. The current code is already quite convoluted, even adding a single type requires adding code in various places, and it is already not easy to know what places are mandatory and what places are optional or squarely redundant. There are functions with similar names because one was added after the other, etc. The way I see it, just getting the current code into shape for serious extensions would require a big refactoring. I believe this is a situation where the desired new features are significantly larger that the current code base, and in these case, not worrying with the existing, taking only what is useful as it comes seems easier. But of course, this is up to whoever does the work. To Paul, about dynamic options changing: This one, I think, is rather orthogonal to what I am suggesting. Right now, you could call av_opt_set() on a filter or a codec that is already in use. It would give awful results, but not because of the options system, because filters and codec are not ready for options changing below their feet. Of course, some support from the options system would help, like a flag telling us if an option can be changed later or not (dynamic read/write status), but the bulk of the effort seems to be getting filters into shape. To James, regarding allowing only simple string arguments: I do not quite understand what you are proposing. How would the user specify a PAN matrix like "FL<FL+RL+0.5*FC:FR<FR+RR+0.5*FC" with just simple string arguments? Or a drawtext string with expanded variable snippets? To James again, regarding using a scripting language like Lua: I believe supporting it would be a great improvement, but relying on it, making it the main entry point, would not. I partially agree with Tobias Rapp that it would make beginners' life harder: the base syntax does not need to be complicated, but the extra features would make error diagnosis much harder. Furthermore, there are security considerations. Reimar already warned that allowing untrusted users to set some options is dangerous, but it is mostly minor and theoretical. Security levels could be added to options to make it really safe. On the other hand, with a full scripting language, I could get an online transcoding service to mine bitcoins for me while parsing the options and get the results in the encoded video. So completely yes to a scripting language, but not as the only entry point. To Tobias, about using JSON syntax: I must say, I do not see how it would help. It seems to make things rather worse. JSON have lists and key-value pairs, and we need these, but only at the toplevel, not nested. Escaping hell comes from nesting syntaxes. What we nest are types unknown to JSON: video sizes, drawtext formated strings, channel layouts, expressions. As your examples show, expressions need to be quoted inside JSON, and the example seems rather longer than the current syntax for the same thing. There is another feature of the current option system that neither JSON nor scripting languages provide: context-dependant constants. Right now, I can write "application=voip" for libopusenc and arnr-type=backward for libvpxenc, but "voip" makes no sense for libvpx, nor "backward" for libopus. General-purpose syntaxes are not aware of the context and can not take that into account. To Ryan, regarding reading values from a file: It helps, of course, but reading from a file, like using single quotes, works only once. It saves one level of escaping, but the contents of the file is still subject to escaping hell. Unless users are expected to use another file indirection for each level of nested syntax, which seems rather inconvenient. I hope I addressed most of the remarks. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
