On date Tuesday 2011-05-31 06:53:58 -0700, Ronald S. Bultje encoded: > 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.
Resuming, using a dictionary looks a good idea, but we should change av_metadata_* API to av_dict_*/av_dictionary_* for clarifying the more generic scope of the API. You could do it by deprecating the AVMetadata interface and creating a new av_dict_* API in libavutil (which would also avoid API/ABI breaks or ld hacks). _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
