This change introduces basic support for HEVC decoding through vdpau.
Right now, there are problems with the nvidia driver/library implementation
that mean that frames are incorrectly laid out in memory when they are
returned from the decoder, and it is normally impossible to recover the
complete decoded frame due to loss of data from alignment inconsistencies.
I obviously hope that nvidia will be fixing it in due course - I've verified
the problems exist with their example application.
As such, this support is not useful for any real world application, but I
believe that it is correct (with the caveat that the mangled frames may hide
problems) and will work properly once the nvidia problem is fixed.
Right now it appears that any file encoded by x265 or nvenc is decoded
correctly, but that's because these files don't use a bunch of HEVC
features.
Quick summary:
Features that seem to work:
1) Short Term References
2) Scaling Lists
3) Tiling
Features with known problems:
1) Long Term References
It's hard to tell what's going on here. After I read the nvidia example
app that does not set the IsLongTerm flag on LTRs, and changed my code,
a bunch of frames using LTR started to display correctly, but there
are still samples with glitches that are related to LTRs.
In terms of real world files, both x265 and nvenc only use short term
refs from this list. The divx encoder seems similar.
Signed-off-by: Philip Langdale <philipl@overt.org>
h264.h and hevc.h are mutually exclusive due to defining some of the same
names. As such, we need to avoid forcing h264.h to be included if we want
hevc decode acceleration to be possible.
However, some of the pre-hwaccel helper functions need h264.h. To avoid
messy collisions, let's move the declaration of all those helpers to
a separate header which we will exclude for the hevc support (which will
be hwaccel-only).
Signed-off-by: Philip Langdale <philipl@overt.org>
* commit '737d35e33408263c04d7730f5487eed0d04938ba':
vdpau: add support for the H.264 High 4:4:4 Predictive profile
Conflicts:
libavcodec/vdpau_internal.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Decoding acceleration may work even if the codec level is higher than
the stated limit of the VDPAU driver. Or the problem may be considered
acceptable by the user. This flag allows skipping the codec level
capability checks and proceed with decoding.
Applications should obviously not set this flag by default, but only if
the user explicitly requested this behavior (and presumably knows how
to turn it back off if it fails).
Signed-off-by: Anton Khirnov <anton@khirnov.net>
* commit 'ce083282f0a8b7d63c4047c30b7bac498f9806dd':
vdpau: common support for managing the VdpDecoder in avcodec
Conflicts:
libavcodec/vdpau.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This function provides an explicit VDPAU device and VDPAU driver to
libavcodec, so that the application is relieved from codec specifics
and VdpDevice life cycle management.
A stub flags parameter is added for future extension. For instance, it
could be used to ignore codec level capabilities (if someone feels
dangerous).
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This is necessary to recreate the decoder with the correct parameters,
as not all codecs invoke get_format() in this case.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Using the not so new init and uninit callbacks, avcodec can now take
care of creating and destroying the VDPAU decoder instance.
The application is still responsible for creating the VDPAU device
and allocating video surfaces - this is necessary to keep video
surfaces on the GPU all the way to the output. But the application
will no longer needs to care about any codec-specific aspects.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
* commit '7948a51b5c3d08e1a1173442a7ff72b220def303':
vdpau: don't assume Picture and H264Picture are the same
Conflicts:
libavcodec/vdpau.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This gets rid of aliasing completely unrelated structs to Picture.
Fixes the remaining compilation warnings in the vdpau code.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The code passed H264Picture* and Picture*, and assumed the
hwaccel_picture_private field was in the same place in both
structs. Somehow this happened to work in Libav, but broke in
FFmpeg (and probably subtly breaks in Libav too).
Signed-off-by: Anton Khirnov <anton@khirnov.net>
* commit '70cbf33405f50dfaf77e85f382a188acf17dc71a':
vdpau: Add missing #includes to fix standalone header compilation
Conflicts:
libavcodec/vdpau_internal.h
Not completely merged as this would break use of vdpau.h from C++
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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>
* commit '2852740e23f91d6775714d7cc29b9a73e1111ce0':
vdpau: store picture data in picture's rather than codec's context
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The bitstream buffers are now private and freed by libavcodec. For
backward compatibility, the hold bitstream buffer pointer is left NULL
(applications were supposed to av_freep() it).
Signed-off-by: Anton Khirnov <anton@khirnov.net>
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>
* commit 'd8c772de53d29afb1bada88afa859fce8489c668':
nutdec: Always return a value from nut_read_timestamp()
configure: Make warnings from -Wreturn-type fatal errors
x86: ABS2: port to cpuflags
vdpau: Remove av_unused attribute from function declaration
h264: fix ff_generate_sliding_window_mmcos() prototype.
Conflicts:
configure
libavformat/nutdec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '44e065d56c87d6a9d0effccec5f31517f72924ec':
vdpau: Add context and common helpers for hwaccel support
Conflicts:
Changelog
doc/APIchanges
libavcodec/vdpau.h
libavcodec/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
Move id3v2 tag writing to a separate file.
swscale: add missing colons to x86 assembly yuv2planeX.
g722: split decoder and encoder into separate files
cosmetics: remove extra spaces before end-of-statement semi-colons
vorbisdec: check output buffer size before writing output
wavpack: calculate bpp using av_get_bytes_per_sample()
ac3enc: Set max value for mode options correctly
lavc: move get_b_cbp() from h263.h to mpeg4videoenc.c
mpeg12: move closed_gop from MpegEncContext to Mpeg1Context
mpeg12: move full_pel from MpegEncContext to Mpeg1Context
mpeg12: move Mpeg1Context from mpeg12.c to mpeg12.h
mpegvideo: remove some unused variables from MpegEncContext.
Conflicts:
libavcodec/mpeg12.c
libavformat/mp3enc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This reverts commit da22ba7df4 since it
broke slice threading. Slice threading just duplicates MpegEncContext
so every value used during mpeg_decode_slice has to be in it.
A second patch will fix the illusion that Mpeg1Context is available
in mpeg_decode_slice.
start of decoding a picture instead of at the end.
Fixes mmco01.264
Patch by Stephen Warren
Originally committed as revision 22728 to svn://svn.ffmpeg.org/ffmpeg/trunk
