On Mon, 30 May 2011 21:57:26 +0200, Stefano Sabatini <[email protected]> wrote: > On date Monday 2011-05-30 21:15:16 +0200, Anton Khirnov encoded: > > Hi, > > since getting rid of AVFormatParameters is taking longer than I'd like, > > I've decided to dump this as an RFC so people can comment on API > > meanwhile. > > > So here's the second take on reworking private options. It works by > > adding new av{codec,format,...}_open_*() functions which take an > > AVMetadata parameter. The user fills metadata with option names/values > > and passes it to the open call. The options are then automagically > > distributed to private contexts. > > Is AVMetaData required at all (looks a bit overkill to me)? Also I'd > prefer to keep the current name scheme (av_metadata_*), "avmeta" is > both inconsistent and not very explicative ("meta" is too generic), > you can use the gnu ld hacks already employed for opt.c if you want to > avoid ABI breaks.
Overkill? Looks like a good tool for the job to me. Maybe we should stop calling it metadata though, since I'm using it as a generic dictionary. > > As alternative to metadata, what about using av_set_string_options(), > and pass a string with all the params? Err.. and you expect the user to construct and manage such a string himself? Sounds like an extreme PITA. -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
