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. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
