Age | Commit message (Collapse) | Author |
|
If the identification string ever changed, we might not match anything
in the sscanf(). At least have predictable behaviour.
|
|
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 e724bdfffbd3c27aac53d1f32f20f105f37caef0
Merged-by: James Almer <jamrial@gmail.com>
|
|
* commit 'dd343fd986459f467a2d1d70c26101dff1d47d68':
lavu: Drop deprecated VDPAU pixel formats
Merged-by: James Almer <jamrial@gmail.com>
|
|
* commit '5c1585c4c3b5281835d784c5daef0069915ccd57':
lavc: Drop deprecated VDPAU buffer fields
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.
|
|
* commit '800d91d348c89fc8ca3fbec7696ab1ec8787acc6':
Drop pointless void* casts
Merged-by: James Almer <jamrial@gmail.com>
|
|
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 '9df889a5f116c1ee78c2f239e0ba599c492431aa':
h264: rename h264.[ch] to h264dec.[ch]
Merged-by: Clément Bœsch <u@pkh.me>
|
|
* commit '0f40c9098498ad90dbbd2380eb4269015e84bde4':
Drop pointless assert.h #includes
Merged-by: Clément Bœsch <clement@stupeflix.com>
|
|
This is more consistent with the naming of other decoders.
|
|
* 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 #631
http://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 #4074
http://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>
|
|
|
|
* commit 'e10b7ef2fe56603fb1baac6b20fd6bd0a3fdd0d0':
vdpau: Add missing deprecation guards
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
|
|
|
Fixes libavcodec/vdpau.c:282:5: warning:
"CONFIG_H263_VDPAU_HWACCEL" is not defined [-Wundef]
Removed in d35d0c723e3c8fc8cde76bf677f67928f5e179a8.
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 d15adeacf3e61cd8d2169c090bf06f6d8fc62f8b
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
* commit 'a41e5e192ed8f79f6607f978dee3205580ba5039':
vdpau: fix constrained baseline fallback
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
|
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>
|
|
Tested-by: wm4 <nfxjfg@googlemail.com>
Tested-by: Philip Langdale <philipl@overt.org>
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
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 'a0f2946068c62e18cb05ac25c0df3d86077251a6':
h264: use properly allocated AVFrames
Conflicts:
libavcodec/h264.c
libavcodec/h264.h
libavcodec/h264_refs.c
libavcodec/h264_slice.c
libavcodec/svq3.c
libavcodec/vda_h264.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
|
* commit '95eb35f30513e335990ad0d5dca6ddc318477291':
h264: move the ref lists variables into the per-slice context
Conflicts:
libavcodec/h264.c
libavcodec/h264.h
libavcodec/h264_cabac.c
libavcodec/h264_cavlc.c
libavcodec/h264_direct.c
libavcodec/h264_mb.c
libavcodec/h264_picture.c
libavcodec/h264_refs.c
libavcodec/h264_slice.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
|
* 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>
|
|
Fixes Ticket4211
Signed-off-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>
|
|
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|
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>
|
|
* commit '559fa0d41b5cf8f7e1ba89d1ac70e74712eb2816':
vdpau: add mapping for H.264 Constrained Baseline profile and fallback
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
|
* commit '8502c1e9ff9c1dbb6e467630c048d098f4064021':
vdpau: add mapping for H.264 Extended profile
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
|
* commit '8b51bcfed75721e0d20832e5a90e1d585318c9d9':
vdpau: revector macro to reduce line span
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
|
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>
|
|
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|
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>
|
|
This is the same as the previous change, but for applications using the
old API (such as VLC 2.2).
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|
* commit 'd565fef1b83b6c5f8afb32229260b79f67c68109':
vdpau: add AV_HWACCEL_FLAG_IGNORE_LEVEL to skip the codec level check
Conflicts:
libavcodec/version.h
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>
|
|
Currently, no flags are supported.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
|
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|