Added VDPAU to list of supported formats for HEVC10 and 12 bit formats
also added 42010 bit to surface_parameters and new VDP chroma formats to
VDPAUPixFmtMaps
Add HEVC 420 10/12 Bit and 444 10/12 Bit support for VDPAU
YUV444P10 is defined as the 444 surface with 10bit valid data in LSBs
but H/w returns Data in MSBs Hence if we map output as YUV444p16 it
is filtering out the LSB to convert to p10 format.
Signed-off-by: Philip Langdale <philipl@overt.org>
The driver bugs that caused decoded HEVC content to have an incorrect
memory layout have been fully fixed in the 410.xx driver release so
we can start exposing support.
* commit 'b46a77f19ddc4b2b5fa3187835ceb602a5244e24':
lavc: external hardware frame pool initialization
Includes the fix from e724bdfffb
Merged-by: James Almer <jamrial@gmail.com>
This adds a new API, which allows the API user to query the required
AVHWFramesContext parameters. This also reduces code duplication across
the hwaccels by introducing ff_decode_get_hw_frames_ctx(), which uses
the new API function. It takes care of initializing the hw_frames_ctx
if needed, and does additional error handling and API usage checking.
Support for VDA and Cuvid missing.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The public functions av_alloc_vdpaucontext() and
av_vdpau_alloc_context() are allocating AVVDPAUContext
structure that is supposed to be placed in avctx->hwaccel_context.
However the rest of libavcodec/vdpau.c uses avctx->hwaccel_context
as struct VDPAUHWContext, that is bigger and does contain
AVVDPAUContext as first member.
The usage includes write to the new variables in the bigger stuct,
without checking for block size.
Fix by always allocating the bigger structure.
Signed-off-by: Ivan Kalvachev <ikalvachev@gmail.com>
NVIDIA broke its own API when using VDPAU decoding. If you retrieve the
decoded YUV data, or if you map the surfaces with GL interop, the result
are interlacing artifacts. The only way to get non-broken data is by
using the vdpau video mixer to convert it to RGB. There is no way to
block the non-working operations in a reasonable way (a VdpVideoSurface
has to support all operations).
NVIDIA refuses to fix this issue (they "fixed" it by making it work with
the video mixer, but the rest is still broken). There is no sign of that
changing.
Do not use HEVC by default with the generic hwaccle API. Detect whether
it's the NVIDIA native implementation, and exit with an error. (The same
thing work with the MESA implementation.)
As an escape hatch and to allow applications to use the decoder if they
really want to (perhaps because they make sure to explicitly use the
video mixer), reuse AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH to disable
this check.
Once NVIDIA fixes the bug, working driver versions could be detected,
and it could be allowed again.
This supports retrieving the device from a provided hw_frames_ctx, and
automatically creating a hw_frames_ctx if hw_device_ctx is set.
The old API is not deprecated yet. The user can still use
av_vdpau_bind_context() (with or without setting hw_frames_ctx), or use
the API before that by allocating and setting hwaccel_context manually.
Cherry-picked from Libav commit 1a7ddba5.
(Adds missing APIchanges entry to the Libav version.)
Reviewed-by: Mark Thompson <sw@jkqxz.net>
This supports retrieving the device from a provided hw_frames_ctx, and
automatically creating a hw_frames_ctx if hw_device_ctx is set.
The old API is not deprecated yet. The user can still use
av_vdpau_bind_context() (with or without setting hw_frames_ctx), or use
the API before that by allocating and setting hwaccel_context manually.
* commit 'c8dcff0cdb17d0aa03ac729eba12d1a20f1f59c8':
h264: factor out calculating the POC count into a separate file
Merged-by: Clément Bœsch <u@pkh.me>
* commit '3176217c60ca7828712985092d9102d331ea4f3d':
h264: decouple h264_ps from the h264 decoder
Main changes:
- a local GetBitContext is created for the various
ff_h264_decode_seq_parameter_set() attempts
- just like the old code, remove_sps() is adjusted so it doesn't remove
the pps.
Fixes decode with Ticket #631http://ffmpeg.org/pipermail/ffmpeg-user/attachments/20111108/dae58f17/attachment.mp4
but see next point as well.
- ff_h264_update_thread_context() is updated to work even when SPS
isn't set as it breaks current skip_frame code. This makes sure we
can still decode the sample from ticket #631 without the need for
-flags2 +chunks. (Thanks to Michael)
- keep {sps,pps}_ref pointers that stay alive even when the active
pps/sps get removed from the available lists (patch by michaelni with
additionnal frees in ff_h264_free_context() from mateo)
- added a check on sps in avpriv_h264_has_num_reorder_frames() to fix
crashes with mpegts_with_dvbsubs.ts from Ticket #4074http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4074/mpegts_with_dvbsubs.ts
- in h264_parser.c:h264_parse(), after the ff_h264_decode_extradata() is
called, the pps and sps from the local parser context are updated with
the pps and sps from the used h264context. This fixes fate-flv-demux.
- in h264_slice.c, "PPS changed between slices" error is not triggered
anymore in one condition as it makes fate-h264-xavc-4389 fails with
THREADS=N (Thanks to Michael)
Merged-by: Clément Bœsch <clement@stupeflix.com>
Merged-by: Michael Niedermayer <michael@niedermayer.cc>
Merged-by: Matthieu Bouron <matthieu.bouron@stupeflix.com>
Fixes libavcodec/vdpau.c:282:5: warning:
"CONFIG_H263_VDPAU_HWACCEL" is not defined [-Wundef]
Removed in d35d0c723e.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: libavcodec/vdpau.c:320:5: warning: "CONFIG_H263_VDPAU_HWACCEL" is not defined [-Wundef]
It was removed in d15adeacf3
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It appears vdpau drivers can return constrained baseline as unsupported,
even if libvdpau knows about the symbol, and the main profile is
supported.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
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 '56febc993b928ccc039a32158ca60b234c311875':
h264: move the slice type variables into the per-slice context
Conflicts:
libavcodec/h264.c
libavcodec/h264_cabac.c
libavcodec/h264_cavlc.c
libavcodec/h264_slice.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* 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>
* commit 'ebd5320afd42d4315851f3e0ca7f5d4a6300eb68':
vdpau: add support for 4:2:2 and 4:4:4 chroma sampling
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'c220a60f92dde9c7c118fc4deddff5c1f617cda9':
vdpau: add helper for surface chroma type and size
Conflicts:
libavcodec/vdpau.c
libavcodec/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Since the VDPAU pixel format does not distinguish between different
VDPAU video surface chroma types, we need another way to pass this
data to the application.
Originally VDPAU in libavcodec only supported decoding to 8-bits YUV
with 4:2:0 chroma sampling. Correspondingly, applications assumed that
libavcodec expected VDP_CHROMA_TYPE_420 video surfaces for output.
However some of the new HEVC profiles proposed for addition to VDPAU
would require different depth and/or sampling:
http://lists.freedesktop.org/archives/vdpau/2014-July/000167.html
...as would lossless AVC profiles:
http://lists.freedesktop.org/archives/vdpau/2014-November/000241.html
To preserve backward binary compatibility with existing applications,
a new av_vdpau_bind_context() flag is introduced in a further change.
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Old VDPAU drivers do not support this newly defined profile, so falling
back to Main profile is necessary for backward binary compatibility.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
* commit 'ce91b2eae6ea52fc1a7003566d26db20ca62d745':
vdpau: return MAIN instead of BASELINE for H.264 CBP
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'c1724623ce0433c6a9ee72133b1fd4db75ec7193':
vdpau: have av_vdpau_bind_context() fail on unsupported flag
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>
