| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Add vdpau_parse_rext_profile and use profile constraint flags to
determine the exact vdp_profile for HEVC_REXT.
If profile mismatch is allowed, select Main profile by default.
Add build object in Makefile for h265_profile_level dependency.
Signed-off-by: Philip Langdale <philipl@overt.org>
|
| |
|
|
|
| |
This already applied to decoders as well as hwaccels, and adding encoder
support was going to make the name even more inaccurate.
|
| |
|
|
|
|
|
| |
Pass SPS, PPS range extensions to VDPAU layer via
VdpPictureInfoHEVC444. Added VdpPictureInfoHEVC444 struct to
VdpPictureInfo union to populate the range extension params. Mapped
FF_PROFILE_HEVC_REXT to VDP_DECODER_PROFILE_HEVC_MAIN_444.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
* commit 'b46a77f19ddc4b2b5fa3187835ceb602a5244e24':
lavc: external hardware frame pool initialization
Includes the fix from e724bdfffbd3c27aac53d1f32f20f105f37caef0
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>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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).
|
| |\|
| |
| |
| |
| |
| |
| | |
* commit '150c896a9e46b23b97debb0a5f66fbaeaa32f153':
hevcdec: split ff_hevc_diag_scan* declarations into a separate header
Merged-by: James Almer <jamrial@gmail.com>
|
| | |
| |
| |
| | |
This will be useful in the following commits.
|
| |\|
| |
| |
| |
| |
| |
| | |
* commit '4abe3b049d987420eb891f74a35af2cebbf52144':
hevc: rename hevc.[ch] to hevcdec.[ch]
Merged-by: Clément Bœsch <u@pkh.me>
|
| | |
| |
| |
| |
| | |
This is more consistent with the rest of libav and frees up the hevc.h
name for decoder-independent shared declarations.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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).
Merges Libav commit d4a91e65.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
|
| | |
| |
| |
| |
| |
| |
| | |
The maximum number of references is 16, so the index value cannot
exceed 15.
Fixes Coverity CID 1348139, 1348140, 1348141
|
| |\|
| |
| |
| |
| |
| |
| | |
* commit '8d34a2f803c9ca9433b5a51bacbbe352e8d327e2':
vdpau: Support for VDPAU accelerated HEVC decoding
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
| |
|
|
|
| |
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
| |
|
|
|
|
| |
This is the same fix that Hendrik made to dxva2_hevc. It should be
equally required here, although I don't see any visual difference.
Nevertheless, best to stay consistent.
|
| |
|
|
|
|
|
| |
The latest nvidia 355.06 drivers fixes the interleaving bug when
video surfaces are rendered. It still seems to be broken for
read-back with getBits but that's sufficiently uninteresting that
I don't think we need to wait for it to remove the flag.
|
| |
|
|
|
| |
There was some reorganisation in the HEVC headers so the sps and pps
now live in a different place.
|
| |
|
|
|
|
|
|
| |
This HWAccel isn't really usable right now due to an nvidia driver bug,
so we don't want it selected by default.
HWAccels have a capabilities field and there's a comment about flags,
but no flags exist today, so let's add one for experimental hwaccels.
|
|
|
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>
|
