[FFmpeg-devel] [PATCH] [RFC][WIP] avutil/buffer: add add a dynamnic size buffer pool API

[Michael Niedermayer]

On Sat, Mar 17, 2018 at 09:26:32PM -0300, James Almer wrote:
> On 3/17/2018 8:48 PM, Michael Niedermayer wrote:
> > On Fri, Mar 16, 2018 at 03:21:41PM -0300, James Almer wrote:
> >> Signed-off-by: James Almer <jamrial at gmail.com>
> >> ---
> >> This is a proof of concept for a dynamic size buffer pool API.
> >>
> >> For the purpose of easy testing and reviewing I replaced the current
> >> linked list used to keep a pool of fixed size buffers with the tree
> >> based pool that will be used to keep a pool of varying size buffers,
> >> instead of adding a new set of functions exclusively for the new API.
> >> The final committed work doesn't necessarely have to do the above, as
> >> there's no real benefit using a tree when you only need a fixed size
> >> buffer pool, other than simplying things.
> >>
> >> I'm open to suggestions about how to introduce this. Completely
> >> separate set of functions and struct names? Sharing the struct and
> >> init/uninit functions and only adding a new get() one like in this
> >> patch?
> >> Any preferences with function/struct naming, for that matter?
> >>
> >>  libavutil/buffer.c          | 98 ++++++++++++++++++++++++++++++++++++---------
> >>  libavutil/buffer.h          |  2 +
> >>  libavutil/buffer_internal.h |  6 ++-
> >>  3 files changed, 85 insertions(+), 21 deletions(-)
> > 
> > not sure its not intended but this causes differences
> > in error concealment on many files
> 
> Not intended by me, at least. And not sure how using a tree instead of a
> linked list to keep a pool of buffers could affect that. The way they
> are allocated or returned is not changed, and all the existing users are
> still only creating fixed sized buffers.
> 

> Do you have an idea of what could be happening? The way the tree is

is always the same buffer used as before ?
a different buffer with different content could probably leak the content
through into the output on some errors.


> being handled is afaik correct, judging by the doxy. Removing and adding
> one element at a time using a simple cmp() function and with no way to
> have races since it's all controlled by a mutex.
> 
> >  an example would be something like this:
> > 
> > ffmpeg -threads 1 -i 1069/green-block-artifacts-from-canon-100-hs.MOV test.avi
> > 
> > 
> > [...]
> > 
> > 
> > 
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel at ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180318/373bb073/attachment.sig>