> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of
> Nicolas George
> Sent: Donnerstag, 10. April 2025 10:40
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] AVDictionary2
>
> Michael Niedermayer (HE12025-04-08):
> > As i have too many things to do already i did the most logic thing and
> > started thinking about a new and unrelated idea.
> >
> > This is a list of problems and ideas, that everyone is welcome to add
> to and
> > comment on.
> >
> > AVDictionary is just bad.
>
> A few notes on the topic:
>
> Steal a few ideas from BPrint, adapt them to a dictionary:
>
> Include an initial buffer in the root structure.
>
> Make the code tolerant to the size of the included buffer.
>
> That ensures that the root structure can be allocated by the caller on
> the stack.
The technique from BPrint is nice, but I'm not sure whether there are many
usages of AVDictionary where stack allocation would be feasible or advantageous
over the current way of "lazy init on first use", no?
Also, same like BPrint, a stack-alloc dictionary would be prone to forgotten
uninit.
> Do we want only string → string, or do we want string → any or any →
> any?
>
> To handle any data structure, we can do:
>
> const struct {
> int (*clone)(void *, const void *);
> void (*free)(void *);
> void (*ref)(void *);
> void (*unref)(void *);
> int (*compare)(const void *, const void *);
> unsigned (*hash)(const void *);
> } *key_ops, *val_ops;
>
What if values are integers for example?
sw
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
