Hi, On Mon, May 30, 2011 at 2:15 PM, Stefano Sabatini <[email protected]> wrote: > On date Monday 2011-05-30 23:00:18 +0200, Anton Khirnov encoded: >> >> 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. > > Yes, "metadata" is misleading (av_dict?).
av_dict_*() is fine with me. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
