This describes more accurately what this field is for.

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Old Intel GPUs expect the reference frame index to the actual surface,
instead of the index into RefFrameList as specified by the spec.

This workaround should be set when using one of the "ClearVideo" decoder
devices.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

The latest H.264 DXVA specification states that the index in this
structure should refer to a valid entry in the RefFrameList of the picture
parameter structure, and not to the actual surface index.

Fixes H.264 DXVA2 decoding on recent Intel GPUs (tested on Sandy and Ivy)
Signed-off-by: Anton Khirnov <anton@khirnov.net>

The assumption of (MPEG) Picture and H264Picture layout matching might
not hold true in the future.
Signed-off-by: Hendrik Leppkes <h.leppkes@gmail.com>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Old Intel GPUs expect the reference frame index to the actual surface,
instead of the index into RefFrameList as specified by the spec.

This workaround should be set when using one of the "ClearVideo" decoder
devices.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

The latest H.264 DXVA specification states that the index in this
structure should refer to a valid entry in the RefFrameList of the picture
parameter structure, and not to the actual surface index.

Fixes H.264 DXVA2 decoding on recent Intel GPUs (tested on Sandy and Ivy)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This way it does not look like a constant.

This field is private and should not be present in a public struct. It
is only used in DXVA with mpegvideo-based decoders currently.

Some hwaccels use name prefixes, some do not, others only use them for
some codecs.  Add prefixes everywhere for consistency.

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>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

The MBAFF flag may only be signaled if we're actually dealing with
a full frame, and not singular fields, as it can happen in mixed content.
Signed-off-by: Martin Storsjö <martin@martin.st>

The MBAFF flag may only be signaled if we're actually dealing with
a full frame, and not singular fields, as it can happen in mixed content.
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Copy the Inter 8x8 scaling list as second 8x8 matrix into DXVA2's
quantization matrix data structure instead of a potentially unset
Intra chroma scaling matrix.

Fix dxva2 decoding for some H264 samples.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>

The workaround needs to be enabled per PCI ID which cannot be detected inside
libavcodec. So add a flag to manually enable the alternate behavior.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

The workaround need to be enabled per pci id which can not
be detected inside ffmpeg. So this adds a flag that enabled
the alternate behavior.

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Mans Rullgard <mans@mansr.com>

That unbreaks compilation of vaapi and dxva2
Signed-off-by: Janne Grunau <janne-ffmpeg@jannau.net>
(cherry picked from commit d1b6f33b)

That unbreaks compilation of vaapi and dxva2
Signed-off-by: Janne Grunau <janne-ffmpeg@jannau.net>

The 8 bits offset (nal unit type) should not be added, as the spec says:

"This bit offset is the offset within the RBSP data for the slice, relative
to the starting position of the slice_header() in the RBSP"

This fixes DXVA2 support for intel GPU.

Patch by Rafaël Carré (funman _AT_ videolan _DOT_ org).

Originally committed as revision 25538 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 23141 to svn://svn.ffmpeg.org/ffmpeg/trunk

Based on a commit for vaapi(r22869).

Originally committed as revision 23140 to svn://svn.ffmpeg.org/ffmpeg/trunk

is deprecated and will be dropped at the next major bump.

Originally committed as revision 22735 to svn://svn.ffmpeg.org/ffmpeg/trunk