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>
Makes dealing with formats that can not be used for staging textures
easier (DXGI_FORMAT_420_OPAQUE). It also saves memory if the staging
texture is never needed, so this is a good thing.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
It appears in this case, frames_ininit is called twice (once by
av_hwframe_ctx_init(), and again by unreffing the frames ctx ref).
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>
These variables might be set from a previous probe run, but one or the
other program that is probed for may not grok the flags, resulting in
errors during assembling when the values of those variables are passed
to the assembler.
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.
Also employ this mechanism to pass $libdir to the runtime library search
path if rpath is enabled. This fixes underlinking of some test binaries
on some systems.
Check the existing flags in the cc/cflags/cppflags/ldflags for
occurrances of -isysroot; if none is found but --sysroot was specified,
set -isysroot to the same value as --sysroot.
This simplifies configuring cross-builds for iOS, if the global
environment variable SDKROOT isn't set.
Signed-off-by: Martin Storsjö <martin@martin.st>
The rtmp protocol uses nonblocking reads, to poll for incoming
messages from the server while publishing a stream.
Prior to 94599a6de3 and
d13b124eaf, the tls protocol
handled the nonblocking flag, mostly as a side effect from not
using custom IO callbacks for reading from the socket. When custom
IO callbacks were taken into use in
d15eec4d6b, the handling of a nonblocking
socket wasn't necessary for the default blocking mode any longer.
The code was simplified, since it was overlooked that other code
within libavformat actually used the tls protocol in nonblocking mode.
This fixes publishing over rtmps, with the gnutls backend.
Signed-off-by: Martin Storsjö <martin@martin.st>
The rtmp protocol uses nonblocking reads, to poll for incoming
messages from the server while publishing a stream.
Prior to 94599a6de3 and
d13b124eaf, the tls protocol
handled the nonblocking flag, mostly as a side effect from not
using custom IO callbacks for reading from the socket. When custom
IO callbacks were taken into use in
d15eec4d6b, the handling of a nonblocking
socket wasn't necessary for the default blocking mode any longer.
The code was simplified, since it was overlooked that other code
within libavformat actually used the tls protocol in nonblocking mode.
This fixes publishing over rtmps, with the openssl backend.
Signed-off-by: Martin Storsjö <martin@martin.st>
mux.c init_muxer() already sets codec_tag correctly in the cases
simplified here.
This also adds the capability to support alternative tags for the
same codec_id.
ff_mp4_obj_type contains the wrong type of tags for
AVOutputFormat.codec_tag. AVOutputFormat.codec_tag is used to
validate AVCodecParameters.codec_tag so needs to be the same
type of tag.
Creates new tag lists for mp4 and ismv. New tag lists support
same list of codecs found in ff_mp4_obj_type. psp uses the same
tag list as mp4 since these both use mp4_get_codec_tag to look up tags.
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>
When targeting the UWP API subset, the LoadLibrary function is not
available (and the fallback, LoadPackagedLibrary, can't be used to
load system DLLs). In these cases, link directly to the functions
in the DLLs instead of trying to load them dynamically at runtime.
Signed-off-by: Martin Storsjö <martin@martin.st>
The handling of _select dependencies had two issues:
1) extralibs from _select dependencies of a component were not added to
the list of extralibs for that component.
2) extralibs from dependencies were only added to the extralibs of a
component if the component was enabled. This led to incorrect results
if that component was enabled by another component later in the dependency
resolution process. Instead, always generate the full list of component
extralibs for use later in the dependency resolution process.
Also remove a leftover unused variable.
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>
To be used with the new d3d11 hwaccel decode API.
With the new hwaccel API, we don't want surfaces to depend on the
decoder (other than the required dimension and format). The old D3D11VA
pixfmt uses ID3D11VideoDecoderOutputView pointers, which include the
decoder configuration, and thus is incompatible with the new hwaccel
API. This patch introduces AV_PIX_FMT_D3D11, which uses ID3D11Texture2D
and an index. It's simpler and compatible with the new hwaccel API.
The introduced hwcontext supports only the new pixfmt.
Frame upload code untested.
Significantly based on work by Steve Lhomme <robux4@gmail.com>, but with
heavy changes/rewrites.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
