On 23/08/2021 12:04 pm, Chad Fraleigh wrote:
Would allocating 16M really be a lot, given typically there wouldn't
be many of them?
That's something I wanted to get clarification on. I've seen ffmpeg's
libraries used in embedded hardware / environments with restricted
memory; however I'm not sure if this is a valid concern in the first place.
If it's not an issue then it would probably be easiest to choose to use
that option instead.
What if.. LOB value reference support was added to AVDictionary, via a
av_dict_set_lob() function and AVDictionaryEntry->lob field. And
anytime av_dict_get() is called without a AV_DICT_NO_RESOLVE flag, it
would simply do a lazy resolve if it lob != NULL and fill in value
field (if not already resolved, of course). This would allow a LOB
aware callers to stream it when it is a LOB (use 'value' when not
NULL). It should even be API/ABI change safe (unless making
AVDictionaryEntry bigger counts as a break).
Anyway.. just a third option.
Oh, and on a side note: av_dict_get() should _probably_ be changed to
return a const AVDictionaryEntry * at some point, since it is internal
and really should never be modified by the caller.
That's a good point. I'm not sure if it's within the scope of this
ticket, but I'd love to hear input on it
_______________________________________________
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".
