The most interesting parts are initialization in ff_MPV_common_init() and
uninitialization in ff_MPV_common_end().
ff_mpeg_unref_picture and ff_thread_release_buffer have additional NULL
checks for Picture.f, because these functions can be called on
uninitialized or partially initialized Pictures.
NULL pointer checks are added to ff_thread_release_buffer() stub function.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
The actual usefulness of the hack is not known, and it does cause
infinite loops with some broken input files.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
Issues with the code:
1) The skip_bits_long breaks packed B-frames since we skip
of the packed frame, even for VDPAU.
2) Calling ff_h263_find_resync_marker_reverse is nonsense for MPEG-4,
and for H.263 the only code using this (vaapi_mpeg4) explicitly reverts
this change!
3) mb_x/mb_y are always 0 when vaapi_mpeg4_decode_slice, so doing
computations with them is just obfuscation
4) due to not updating mb_y the code would always go into the error
resilience case, causing nonsense error messages and maybe further
issues.
While tested to fix the data provided to the decoder in case of
VDPAU so it is the same as for the non-hwaccel code, the VA-API code
was not tested to still work, and adding regression testing even
as a quick hack is much more complicated for it.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Avoid overwriting the bitstream buffer data before we
have ended processing the frame.
This is necessary to fix hwaccels which might try to use
the buffer during the end_frame call.
I am not sure but it is possible this could even trigger
a use-after-free if the av_fast_malloc allocated a new buffer.
This would require that decode_slice did not wind the bitstream
forward all the way to the end, which does not currently happen in
normal streams.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This reverts commit bf36dc50ea, reversing
changes made to b7fc2693c7.
Conflicts:
libavcodec/h264.c
Keeping support for the old VDPAU API has been requested by our VDPAU maintainer
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Regression since c10d498bfd.
Unfortunately ff_thread_get_format can only be called from
a separate decode thread, running it during init will fail.
Fixes for that are welcome, for now just revert back to
calling avctx->get_format directly, which is correct
but having to decide on a case-by-case basis which approach
to use is a bit messy.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Just like get_buffer, get_format should not be called from a different
thread if thread_safe_callbacks is not set.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Allows use of AVHWAccel based decoders with frame based multithreading.
The decoders will be forced into an non-concurrent mode by delaying
ff_thread_finish_setup() calls after decoding of the current frame
is finished.
This wastes memory by unnecessarily using multiple threads and thus
copies of the decoder context but allows seamless switching between
hardware accelerated and frame threaded software decoding when the
hardware decoder does not support the stream.
Not all hwaccels implement all codecs, so using one single list for
multiple such codecs means some codecs will be represented in the list,
even though they don't actually handle that codec. Copying specific
lists in each codec fixes that.
Signed-off-by: Martin Storsjö <martin@martin.st>
Not all hwaccels implement all codecs, so using one single list for
multiple such codecs means some codecs will be represented in the list,
even though they don't actually handle that codec. Copying specific
lists in each codec fixes that.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Diego Biurrun
Justin Ruggles
Anton Khirnov
Michael Niedermayer
wm4
Rémi Denis-Courmont
Luca Barbato
Martin Storsjö
Reimar Döffinger
Janne Grunau
Ronald S. Bultje