Do not use the one in the SEI directly as that is reset at certain
points.
Inspired by patches from Michael Niedermayer <michaelni@gmx.at> and
Anton Mitrofanov <BugMaster@narod.ru>.
CC: libav-stable@libav.org
This mode apparently does not support decoding of HEVC Main (8 bit).
With D3D11 and Intel drivers on Windows 10 I get green corruption, while
using DXVA2_ModeHEVC_VLD_Main works.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Otherwise the first decoded frame will still be tagged with the
original transfer instead of the alternative one.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Do not use skip_remaining() to fully wipe the cache, as this could do
a 64-bit shift of a 64-bit variable which is undefined behavior in C.
Instead set the related variables to zero directly.
Thanks to Uoti for pointing out the problem.
CC: libav-stable@libav.org
Avoid anonymously typedeffed structs and enums, drop an unused context member,
fix a small wording mishap, sizeof(type) ---> sizeof(*variable), drop a
needlessly verbose log message, use av_malloc_array() where appropriate.
Now it is possible to adjust compression speed vs R/D when needed
and also skip vintage player compatibility at will.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
version 2013-02-08 Rl
- fixes/optimization in multistrip encoding and codebook size choice,
quality/bitrate is now better than that of the binary proprietary encoder
version 2013-02-12 Rl
- separated codebook training sets, avoided the transfer of wasted bytes,
which yields both better quality and smaller files
- now using the correct colorspace (TODO: move conversion to libswscale)
version 2013-02-14 Rl "Valentine's Day" version:
- made strip division more robust
- minimized bruteforcing the number of strips,
(costs some R/D but speeds up compession a lot), the heuristic
assumption is that score as a function of the number of strips has
one wide minimum which moves slowly, of course not fully true
- simplified codebook generation,
the old code was meant for other optimizations than we actually do
- optimized the codebook generation / error estimation for MODE_MC
version 2013-04-28 Rl
- bugfixed codebook optimization logic
version 2014-01-20 Rl
- made the encoder compatible with vintage decoders
and added some yet unused code for possible future
incremental codebook updates
- fixed a small memory leak
version 2014-01-21 Rl
- believe it or not, now we get even smaller files, with better quality
(which means I missed an optimization earlier :)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
The use of this SEI is for backward compatibility in HLG HDR systems:
older devices that cannot interpret the "arib-std-b67" transfer will
get the compatible transfer (usually bt709 or bt2020) from the VUI,
while newer devices that can interpret HDR will read the SEI and use
its value instead.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This fixes a segfault (originally found in Movian, but traced to libav)
when decoding subtitles because only an array of rects is allocated,
but not the actual structs it contains. The issue was probably
introduced in commit 2383323 where the loop to allocate the rects in
the array was thrown away.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Hardware accelerated decoding generally uses AVHWFramesContext for pool
allocation of hardware surfaces. These are setup to allocate surfaces
aligned to hardware and hwaccel API requirements. Due to the
architecture, av_hwframe_get_buffer() will return AVFrames with
the dimensions set to the aligned sizes.
This causes some decoders (like hevc) return these aligned size as
final frame size, instead of cropping them to the video's actual
dimensions. To make sure this doesn't happen, crop the frame to the
size the decoder expects when ff_get_buffer() is called.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Some devices (some phones, apparently) will support only this opaque
format. Of course this won't work with CLI, because copying data
directly is not supported.
Automatic frame allocation (setting AVCodecContext.hw_device_ctx) does
not support this mode, even if it's the only supported mode. But since
opaque surfaces are generally less useful, that's probably ok.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Some existed since forever, some are new.
The cast in get_surface() is silly, but unless we change the av_log
function signature, or all callers of ff_dxva2_get_surface_index(), it's
needed to remove the const warning.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Make supported codec profiles part of each dxva_modes entry. Every DXVA2
mode is representative for a codec with a subset of supported profiles,
so reflecting that in dxva_modes seems appropriate.
In practice, this will more strictly check MPEG2 profiles, will stop
relying on the surface format checks for selecting the correct HEVC
profile, and remove the verbose messages for mismatching H264/HEVC
profiles. Instead of the latter, it will now print the more nebulous "No
decoder device for codec found" verbose message.
This also respects AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH. Move the
Main10 HEVC entry before the normal one to make this work better.
Originally inspired by VLC's code.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The previous default sets the allocated surfaces to 32 unless it is
user-overridden or the lookahead parameter is set.
Change the surfaces calculation for default, B-frames and lookahead scenario.
Properly use the b.eq/b.ge forms instead of the nonstandard forms
(which both gas and newer clang accept though), and expand the
register list that used a range (which the Xcode 6.2 clang, based
on clang 3.5 svn, didn't support).
Signed-off-by: Martin Storsjö <martin@martin.st>
The timeDataSize argument to aacDecoder_DecodeFrame() seems undocumented
and until 2016 04 (203e3f28fbebec7011342017fafc2a0bda0ce530) unused.
After that commit libfdk-aacdec interprets it as size in sample units
and memsets that on error.
FFmpeg as well as others (like GStreamer) did interpret it as size in
bytes.
Fixes: 1442/clusterfuzz-testcase-minimized-4540199973421056 (This requires recent libfdk to reproduce)
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Martin Storsjö <martin@martin.st>
AVCodecContext::refs is used to control the DPB size to be used by the
encoder. The default value for AVCodecContext::refs as set in
libavcodec/options_table.h is 1.
This patch sets AVCodecContext::refs to 0 for h264_nvenc and hevc_nvenc in
order to let the driver take the decision of the correct DPB size to use in
all cases.
Signed-off-by: Srinath K R <skr@nvidia.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This also adds support to avconv (which is trivial due to the new
hwaccel API being generic enough).
The new decoder setup code in dxva2.c is significantly based on work by
Steve Lhomme <robux4@gmail.com>, but with heavy changes/rewrites.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
I want to make it non-mandatory to set a mutex in the D3D11 device
context, and replacing it with user callbacks seems like the best
solution. This is preparation for it. Also makes the code slightly more
readable.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
The actual hwaccel code will need to access an internal context instead
of avctx->hwaccel_context, so add a new DXVA_CONTEXT() macro, that will
dispatch between the "old" external and the new internal context.
Also, the new API requires a new D3D11 pixfmt, so all places which check
for the pixfmt need to be adjusted. Introduce a ff_dxva2_is_d3d11()
function, which does the check.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
So a hwaccel can access avctx->hwaccel in init for whatever reason. This
is for the new d3d hwaccel API. We could create separate entrypoints for
each of the 3 hwaccel types (dxva2, d3d11va, new d3d11va), but this
seems nicer.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
HEVCSEIPictureHash should store only the information extracted from the
bitstream and exported to the higher layer (the decoder or the parser).
The MD5 context is allocated, used and freed by this higher layer, so it
makes more sense for it to also be stored there.
This mimics the behavior of the now unused h264/hevc parser's split()
function and fixes decoding some files when extract_extradata bsf is
enabled.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
clang now (in the upcoming 5.0 version) is capable of building our
arm assembly without relying on gas-preprocessor, although clang/LLVM
doesn't support .dn register aliases.
The VC1 MC assembly was only built and used if the chosen assembler
supported the .dn directives though. This was supported as long as
gas-preprocessor was used.
This means that VC1 decoding got a speed regression on clang 5.0,
unless the user manually chose using gas-preprocessor again.
By avoiding using the .dn register aliases, we can build the VC1 MC
assembly with the latest clang version.
Support for the .dn/.qn directives in clang/LLVM isn't actively planned,
see https://bugs.llvm.org/show_bug.cgi?id=18199.
This partially reverts 896a5bff64.
Signed-off-by: Martin Storsjö <martin@martin.st>
