When merging the formats around the automatically inserted
convert filters, the refcount of the format lists can not be 0.
Coverity does not detect it, and suspects a memory leak,
because if refcount is 0 the newly allocated lists are not
stored anywhere. That gives CIDs 1224282, 1224283 and 1224284.
Lists with refcount 0 are used in can_merge_formats(), so the
asserts can not be moved inside the merge functions.
It evaluates expression and outputs it as integer value, using specified
format.
Address trac ticket #3699.
Signed-off-by: Stefano Sabatini <stefasab@gmail.com>
the libavfilter/vf_blackframe.c filter now not only logs detected
values, but also sets frame metadata. Currently, only `pblack` value is set
but `SET_META` macro has been introduced to ease development in the future.
Signed-off-by: Stepan Bujnak <stepan.bujnak@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
And use the x86util ones instead, which are optimized for mmxext/sse2.
About ~1% increase in performance on pre SSSE3 processors.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'f46bb608d9d76c543e4929dc8cffe36b84bd789e':
dsputil: Split off pixel block routines into their own context
Conflicts:
configure
libavcodec/dsputil.c
libavcodec/mpegvideo_enc.c
libavcodec/pixblockdsp_template.c
libavcodec/x86/dsputilenc.asm
libavcodec/x86/dsputilenc_mmx.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'd3cfd7aff86ee3d449ca68aba21d67b9b2136a9b':
af_compand: make sure request_frame always outputs at least one frame
See: 6b68e2a43b
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This fixes a segmentation fault because request_frame in fifo.c assumes
that the call to ff_request_frame will populate fifo->root.next.
Before, it was possible for request_frame in af_compand to not do this,
resulting in a null pointer access. Now, request_frame in af_compand
always will return at least one frame or an error, as per the API
specifications in avfilter.h for request_frame.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This is especially useful to debug queue overflow issues.
Ideally we should be able to set the debug message at the
dualinput/framesync level, but they do not have the information related
to the filter context and the inlink, so cannot access much useful
information.
Signed-off-by: Stefano Sabatini <stefasab@gmail.com>
The gcc version affected is very old and unmaintained AFAIK thus i made no
attempt to report this to the gcc developers.
The workaround is pushed as it may still affect users and does affect one
fate client
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This makes C and MMX match, no change to fate as the differences where
apparently not sufficient to show up in fate
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
5389024880 -> 1389386610 dezicycles
This surely can be optimized more, i just didnt want to cause a slowdown
when trying to make the fate test bitexact.
Further optimization left to ubitux
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
