Supports both prefix and suffix SEI, decoding all of the common SEI
types and some more obscure ones. Most of this is tested by the
existing tests in fate.
Add comments to describe the sources of the constraint values expressed here,
and add some more related values which will be used in following patches.
Fix the incorrect values for SPS and PPS count (they are not the same as those
used for H.264), and remove HEVC_MAX_CU_SIZE because it is not used anywhere.
(cherry picked from commit b88da98b34)
Add comments to describe the sources of the constraint values expressed here,
and add some more related values which will be used in following patches.
Fix the incorrect values for SPS and PPS count (they are not the same as those
used for H.264), and remove HEVC_MAX_CU_SIZE because it is not used anywhere.
This way they can be reused by other code without including the whole
decoder-specific hevcdec.h
Also, add the HEVC_ prefix to them, since similarly named values exist
for H.264 as well and are sometimes used in the same code.
Add support for parsing SEI_TYPE_MASTERING_DISPLAY_INFO and propagate contents into
the AVMasteringDisplayMetadata side data. Primaries are ordered in RGB order and
the values are converted to rationals ([0,1] for CEI 1931 Chroma coords,
and cd/m^2 for luma).
Signed-off-by: Neil Birkbeck <neil.birkbeck@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Today, we track the short term RPS size for DXVA, but only if the
SliceHeader RPS is being used. Otherwise it's left uninitialized.
NVIDIA's VDPAU implementation requires that the size be accurately
tracked even if an SPS RPS is being used. In this case, it's really
counting the size of the RPS idx information, but you end up with
mangled output if the value is not accurate.
VDPAU also needs the size of the long term RPS.
Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
ucNumDeltaPocsOfRefRpsIdx needs to contain the flat value from the SPS RPS,
and not the final computed value from the slice header RPS, as this calculation
is done internally by the driver again.
Sample-Id: http://trailers.divx.com/hevc/Sintel_4k_27qp_24fps_1aud_9subs.mkvi
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Fixes out of array read
Fixes: d41d8cd98f00b204e9800998ecf8427e/signal_sigsegv_321165b_7641_077dfcd8cbc80b1c0b470c8554cd6ffb.bit
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ucNumDeltaPocsOfRefRpsIdx needs to contain the flat value from the SPS RPS,
and not the final computed value from the slice header RPS, as this calculation
is done internally by the driver again.
Sample-Id: http://trailers.divx.com/hevc/Sintel_4k_27qp_24fps_1aud_9subs.mkvi
Also, make hls_nal_unit() work only on the provided NAL unit, without
requiring a whole decoding context.
This will allow splitting this code for reuse by the parser.
Today, we track the short term RPS size for DXVA, but only if the
SliceHeader RPS is being used. Otherwise it's left uninitialized.
NVIDIA's VDPAU implementation requires that the size be accurately
tracked even if an SPS RPS is being used. In this case, it's really
counting the size of the RPS idx information, but you end up with
mangled output if the value is not accurate.
VDPAU also needs the size of the long term RPS.
Signed-off-by: Philip Langdale <philipl@overt.org>
Use edge emu buffers
And enable the code unconditionally
Speed difference without USE_SAO_SMALL_BUFFER and with the new code:
Decicycles: 26772->26220 (BO32), 83803->80942 (BO64)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
cherry picked from commit 5d9f79edef2c11b915bdac3a025b59a32082f409
SAO edge filter uses pre-SAO pixel data on the left and top of the ctb, so
this data must be kept available. This was done previously by having 2
copies of the frame, one before and one after SAO.
This commit reduces the storage to just that, instead of the previous whole
frame.
Commit message taken from patch by Christophe Gisquet <christophe.gisquet@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>