On Fri, Mar 16, 2018 at 03:21:41PM -0300, James Almer wrote: > Signed-off-by: James Almer <jamr...@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 an example would be something like this: ffmpeg -threads 1 -i 1069/green-block-artifacts-from-canon-100-hs.MOV test.avi [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel