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?).
> > 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.
I suppose both interfaces are useful, a dictionary is useful for
programmatic access, a string of options could be useful for
scripts/commandline. On the other hand is pretty trivial to pass from
one representation to another.
--
I just thought of something funny...your mother.
-- Cheech Marin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
