On Thu, 26 May 2011 17:44:40 +0200, Stefano Sabatini <[email protected]> wrote: > On date Thursday 2011-05-26 16:45:38 +0200, Anton Khirnov encoded: > > On Thu, 26 May 2011 16:24:30 +0200, Stefano Sabatini > > <[email protected]> wrote: > [...] > > > > I don't think it's a good idea, we risk conflicts. > > > > > > Yes indeed this is a problem that needs to be tackled. > > > > > > > Especially with current ffmpeg options parsing, where it's impossible > > > > to differentiate between format/codec options, having options named > > > > 'b' and 's' is very bad. User apps can provide aliases themselves > > > > if they need them. > > > > > > What about: > > > -codec_opts=size=qcif:r=film:... -format_opts=... -proto_opts=... > > > > Looks unreadable with all the '='s. > > If you prefer: > -format_opts 'size=qcif : rate=film : channel=3 : standard=PAL' > > this is the same syntax used by filters using AVOptions > (consistency...). > > In each case it is unreasonable to require all private/global options > to avoid name clashes, at some point you need to specify a namespace > when setting them (this should also simplify option lookup). > > > In any case, I think aliases should be provided by the applications, > > not libav*. > > libav* options are directly used by applications (in particular by the > ff* tools), specifying some convenient alias in the libs looks better > than define them (unconsistently) *in each* application.
Well that's kinda the point. By reserving 's'/'size', 'b' and other "generic" option names for ourselves we prevent the applications from using them for their own purposes. IMO this is evil and should be avoided. In any case, we're getting sidetracked here from the real problem I'm solving (which is demuxer private options). So I'm not going to add aliases myself, but you're welcome to submit patches for it if you care ;) -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
