[FFmpeg-cvslog] AVDictionary: warn about its shortcommings and mention available replacements.

Michael Niedermayer michaelni at gmx.at
Wed Jun 29 01:37:15 CEST 2011


On Tue, Jun 28, 2011 at 10:04:48AM +0200, Stefano Sabatini wrote:
> On date Tuesday 2011-06-28 04:31:11 +0200, Michael Niedermayer wrote:
> > ffmpeg | branch: master | Michael Niedermayer <michaelni at gmx.at> | Tue Jun 28 04:10:40 2011 +0200| [c029ea39bd58905d7a15ad7e1eb7991447606974] | committer: Michael Niedermayer
> > 
> > AVDictionary: warn about its shortcommings and mention available replacements.
> > 
> > Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
> > 
> > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=c029ea39bd58905d7a15ad7e1eb7991447606974
> > ---
> > 
> >  libavutil/dict.h |    7 +++++++
> >  1 files changed, 7 insertions(+), 0 deletions(-)
> > 
> > diff --git a/libavutil/dict.h b/libavutil/dict.h
> > index 421be32..dc575eb 100644
> > --- a/libavutil/dict.h
> > +++ b/libavutil/dict.h
> > @@ -19,6 +19,13 @@
> >  
> >  /**
> >   * @file Public dictionary API.
> > + * @deprecated
> > + *  AVDictionary is provided for compatibility with libav. It is both in
> > + *  implementation as well as API inefficient. It doesnt scale and is
> > + *  be extreemly slow with large dictionaries.
> > + *  It is recommanded that new code uses our tree container from tree.c/h
> > + *  where applicable.
> > + *  Which uses AVL trees to achive O(log n) performance
> 
> I was concerned with the efficiency issues (which should be unrelevant
> for small sets).

yes, for normal metadata use cases this code should be ok but as a
generic dictionary it definitly is not


> 
> Though the tree.[ch] API is much more complicated than this. I supose
> an alternative would be to make this a proper hash dictionary (which
> would possibly require complicating the API).

treec.c/h isnt limited to strings which is a big part of why its
more complex. It shouldnt be hard to add some helper functions to
make it easier to use for string dictionaries
or indeed yes we could add a hash table based one

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

DNS cache poisoning attacks, popular search engine, Google internet authority
dont be evil, please
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-cvslog/attachments/20110629/ad9be50b/attachment.asc>


More information about the ffmpeg-cvslog mailing list