This does not seem to have an effect currently. Fate-h264 passes with
THREADS=1..16 and both threading types as before. It fixes however a
segfault during error resilience with my adaptive-frame-mt patchset.
A picture in use during error resilience gets realloced in another
thread in the fuzzed sample sample_varPAR.avi_s226019.
AVFrame.extended_data has to reset to the AVFrame.data of the current
thread context after copying the frame contents.
Fixes crashes with frame-threading after 2bc0de3858.
Adds a flag context_reinit to MpegEncContext to relieable keep track
of frame parameter changes which require a context reinitialization.
This is required for broken inputs which change the frame size but
error out before the context can be reinitialized.
This is mainly required for frame parameter changes during frame based
multithreading but single threaded usage profits too from avoiding
ff_MPV_common_end()/ff_MPV_common_init() cycles.
Prevents dangling pointers and makes access after free more obvious.
Setting AVFrame.qscale_table to NULL is required for successfully
allocating a previously freed Picture with ff_alloc_picture().
this crashes otherwise, and can happen from try_decode_frame() in the case of decoding errors
Fixes Ticket1602
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This file defines a single, huge function, MPV_motion(), which
although being declared inline is not actually inlined by the
compiler (for good reason). There is thus no sense in defining
this function in a header file, resulting in multiple copies of
it in the final library.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Defining restrict results - for some compilers - in changing other
uses of the restrict keyword also, e.g. __declspec(restrict) gets
changed to __declspec(__restrict) on MSVC. This causes compilation
failures. Therefore, using a private namespace macro instead is
more reliable and robust.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
There have been multiple user complaints about loosing this feature
while its not clear the 3% speedloss claims where real or fabricated.
My own testing indicates no statistically significant speed difference
both with mpeg2 and mpeg4, and if at all the code with lowres support
is a tiny bit faster than without.
This reverts commit 92ef4be4ab, reversing
changes made to 2e07f42957.
Conflicts:
cmdutils.c
libavcodec/arm/vp8dsp_init_arm.c
libavcodec/mpegvideo.c
libavcodec/mpegvideo.h
libavutil/arm/Makefile
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The new lowres support is limited to decoders where lowres decoding
is possible in high quality.
I was not able to measure any speed difference, but if one is found
the 2-3 lines that might affect speed can be made compile time conditional
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fixes race conditions that ultimately lead to memory corruption.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If the dummy frame are not created from a reference frame they could
be deleted untimely resulting in multithreaded decoder waiting on
the current frame to finish.
Noticed by Ronald S. Bultje in the RV34 decoder with a broken file.
Michael Niedermayer
Janne Grunau
Luca Barbato
Mans Rullgard
Diego Biurrun
Anton Khirnov
Alberto Delmás
Ronald S. Bultje
Lou Logan
Martin Storsjö