Certain hardware decoding APIs are not guaranteed to be thread-safe, so
having the user access decoded hardware surfaces while the decoder is
running in another thread can cause failures (this is mainly known to
happen with DXVA2).
For such hwaccels, only allow the decoding thread to run while the user
is inside a lavc decode call (avcodec_send_packet/receive_frame).
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>
Most of the changes are just trivial are just trivial replacements of
fields from MpegEncContext with equivalent fields in H264Context.
Everything in h264* other than h264.c are those trivial changes.
The nontrivial parts are:
1) extracting a simplified version of the frame management code from
mpegvideo.c. We don't need last/next_picture anymore, since h264 uses
its own more complex system already and those were set only to appease
the mpegvideo parts.
2) some tables that need to be allocated/freed in appropriate places.
3) hwaccels -- mostly trivial replacements.
for dxva, the draw_horiz_band() call is moved from
ff_dxva2_common_end_frame() to per-codec end_frame() callbacks,
because it's now different for h264 and MpegEncContext-based
decoders.
4) svq3 -- it does not use h264 complex reference system, so I just
added some very simplistic frame management instead and dropped the
use of ff_h264_frame_start(). Because of this I also had to move some
initialization code to svq3.
Additional fixes for chroma format and bit depth changes by
Janne Grunau <janne-libav@jannau.net>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
VASliceParameterBufferMPEG2.slice_vertical_position shall express
the slice vertical position from the original bitstream. The HW
decoder will correctly decode to the right line computed from the
appropriate top_field_first and is_first_field flags.
This patch aligns with DXVA's definition, which is what most HW and
drivers expect. In particular, Intel PowerVR (Cedarview et al.) and
NVIDIA (through VA-to-VDPAU layer). Since it looks more complex to fix
binary drivers, I aligned the Intel Gen driver (Sandy Bridge et al.)
to this behaviour, while maintaining compatibility with codec layers
not providing this patch yet.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
User-provided data should never trigger an assert; return error instead.
Also fix an instance of get_bits where get_bits_long should have been used.
This eliminates the following warning:
libavcodec/vaapi_mpeg2.c:112:14: warning: variable 'start_code' set but not used
down to ~60 bytes vs. a few KBs before, and gets rid of explicit VA data types.
Originally committed as revision 18256 to svn://svn.ffmpeg.org/ffmpeg/trunk
