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>
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>
ff_scale_eval_dimensions blindly assumes that two inputs are always
available as of 3385989b98. This is
notably not the case when the function is called for the scale
filter. With the scale filter inputs[1] does not exist.
ff_scale_eval_dimensions now has an updated scale2ref check that
makes certain two inputs are actually available before attempting to
access the second one.
Thanks to James Almer for reporting this bug. This should fix the 820
Valgrind tests I single-handedly managed to break.
Signed-off-by: Kevin Mark <kmark937@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
TLS is currently implemented over either OpenSSL or GnuTLS, with more
backends likely to appear in the future. Currently, those backend libraries
are part of the protocol names used during e.g. the configure stage of a
build. Hide those details behind a generically-named declaration for the
TLS protocol to avoid leaking those details into the configuration stage.
If we for some unexplicable reason didn't pick up getaddrinfo
at configure, the default, IPv4-only, fallback should be good enough.
This effectively reverts 6023d84a2b.
Signed-off-by: Martin Storsjö <martin@martin.st>
Parse the playlist to recover the start sequence and previously
generated segments and continue muxing from there.
Mainly useful for near-seamless recovery in live scenarios.
This was actually broken when committed in 46e3936fb04; the
test never succeeded, and thus, _aligned_malloc wasn't actually
used on legacy mingw.
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 427f7a1f9e)
This was actually broken when committed in 46e3936fb04; the
test never succeeded, and thus, _aligned_malloc wasn't actually
used on legacy mingw.
Signed-off-by: Martin Storsjö <martin@martin.st>
This reduces the need for an edit list; streams that start with
e.g. dts=-1, pts=0 can be encoded as dts=0, pts=0 (which is valid
in mov/mp4) by shifting the dts values of all packets forward.
This avoids the need for edit lists for such streams (while they
still are needed for audio streams with encoder delay).
This eases conformance with the DASH-IF interoperability guidelines.
Signed-off-by: Martin Storsjö <martin@martin.st>
This adds tons of code for no other benefit than making VideoToolbox
support conform with the new hwaccel API (using hw_device_ctx and
hw_frames_ctx).
Since VideoToolbox decoding does not actually require the user to
allocate frames, the new code does mostly nothing.
One benefit is that ffmpeg_videotoolbox.c can be dropped once generic
hwaccel support for ffmpeg.c is merged from Libav.
Does not consider VDA or VideoToolbox encoding.
Fun fact: the frame transfer functions are copied from vaapi, as the
mapping makes copying generic boilerplate. Mapping itself is not
exported by the VT code, because I don't know how to test.
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>
Based on the H264 SEI implementation.
This will be mainly useful once support for SEI messages that can be
used by the hevc parser are implemented, like Picture Timing.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
* commit '019ab88a95cb31b698506d90e8ce56695a7f1cc5':
lavc: add an option for exporting cropping information to the caller
Merged-by: James Almer <jamrial@gmail.com>
* commit 'e435beb1ea5380a90774dbf51fdc8c941e486551':
crypto: consistently use size_t as type for length parameters
Merged-by: Clément Bœsch <cboesch@gopro.com>
This is a newer API that is intended for decoders like the cuvid
wrapper. Until now, the wrapper required to set an awkward
"incomplete" hw_frames_ctx to set the device. Now the device
can be set directly, and the user can get AV_PIX_FMT_CUDA output
for a specific device simply by setting hw_device_ctx.
This still does a dummy ff_get_format() call at init time, and should
be fully backward compatible.
Aliased compressed AAC bytes are almost certainly not meaningful SBR
data. In the wild this causes harsh artifacts switching HE-AAC streams
that don't have SBR headers aligned with segment boundaries.
Turning off SBR falls back to a default set of upsampling parameters
that can function as a sort of error concealment. This is consistent
with how the decoder handles other sorts of errors.
Bug-Id: 1047
CC: libav-stable@libav.org
Signed-off-by: Sean McGovern <gseanmcg@gmail.com>
This complex (-1 2 6 2 -1) filter slightly less reduces interlace 'twitter' but better retain detail and subjective sharpness impression compared to the linear (1 2 1) filter.
Signed-off-by: Thomas Mundt <tmundt75@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Use the flags argument of av_hwframe_ctx_create_derived() to pass the
mapping flags which will be used on allocation. Also, set the format
and hardware context on the allocated frame automatically - the user
should not be required to do this themselves.
If -hwaccel foo is supplied without any other device options, and the
foo hwaccel is meant to have a device, try to make such a device with
default parameters for the hwaccel to use.
* commit 'c2fa6bb0e8703a7a6aa10e11f9ab36094416d83f':
mpeg12dec: move setting first_field to mpeg_field_start()
This commit is a noop, see 2f6f2f4f73
Merged-by: James Almer <jamrial@gmail.com>
This was left over from an earlier version which created the new
packet inside the current frame structure. Now it just leaks an
unused packet, so remove the allocation entirely.
The non-H.26[45] codecs already use this form. Since we don't
currently generate I frames for codecs which support them separately
to IDR, the p_per_i variable is set to infinity by default so that it
doesn't interfere with any other calculation. (All the code for I
frames still exists, and it works for H.264 if set manually.)
This patch aims to reduce the number of input/output surfaces
NVENC allocates per session. Previous default sets allocated surfaces to 32
(unless there is user specified param or lookahead involved). Having large
number of surfaces consumes extra video memory (esp for higher resolution
encoding). The patch changes the surfaces calculation for default, B-frames,
lookahead scenario respectively.
The other change involves surface selection. Previously, if a session
allocates x surfaces, only x-1 surfaces are used (due to combination
of output delay and lock toggle logic). To prevent unused surfaces,
changing surface rotation to using predefined fifo.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
* commit '86157e6db2c7a9222f77fa7e7f50fb9aebc3aa81':
hevc: decouple calling get_format() from exporting the SPS parameters
See 786032cad8 (which has been reverted
and replaced with Anton's version to reduce diffs between the two
projects).
Merged-by: Clément Bœsch <u@pkh.me>
The same warning is issued when actual unknown spherical metadata is
found further down in the function.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The header is not always available in the docker build environment
Suggested-by: Kostya Serebryany
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This seems to be non-optional, and if the muxer is run without it,
strlen() is run on NULL, causing a segfault.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '404cb74793284aa03e2e1a7e911c980c4cba0e9e':
configure: Pass CFLAGS_HEADERS through the right CFLAGS filter
Merged-by: James Almer <jamrial@gmail.com>
Added parameter descriptions for all functions
and converted in-function comments into regular
(non-Doxygen) comments.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Experimental VP9 support was added to the muxer recently.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Should fix tsan warnings in fate-fifo-muxer-h264/wav:
WARNING: ThreadSanitizer: data race (pid=26552)
Write of size 4 at 0x000001e0d7c0 by main thread:
#0 transcode_init src/ffmpeg.c:3761 (ffmpeg+0x00000050ca1c)
[..]
Previous read of size 4 at 0x000001e0d7c0 by thread T1:
#0 decode_interrupt_cb src/ffmpeg.c:460 (ffmpeg+0x0000004fde19)
Takes a raw input stream containing frames with correct timestamps but
possibly out of order and inserts additional show-existing-frame
packets to correct the ordering.
* commit 'fe7bc1f16abaefe66d8a20f734ca3eb8a4ce4d43':
configure: Do not unconditionally check for (and enable) xlib
Merged-by: James Almer <jamrial@gmail.com>
* commit '7433feb82f75827884d909de34d341a1c4401d4a':
lavfi: Make default get_video_buffer work with hardware frames
Merged-by: Matthieu Bouron <matthieu.bouron@gmail.com>
num_core_channels is always equal to s->audio_header.prim_channels,
neither one of those variables ever get changed.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Get rid of the "ret" variable, and always use err. Report the packet as
consumed if err is unset. This should be equivalent to the old code,
which obviously required err=0 for p->result>=0 (and otherwise,
p->result must have had the value err was last set to). The code block
added by commit 32a5b63126 is also not needed anymore, because the new
code strictly returns err if it's >=0.
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Not all compilers can do alignment larger than the normal stack alignment
for variables on the stack. In these cases, the LOCAL_ALIGNED_* macros
produce the workaround alignment wrapper consisting of a padded array
and a pointer variable.
This fixes the hevc fate tests on RVCT/ARMCC after adding IDCT assembly
that actually assumes/relies on this alignment.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'b90c8a3d08e3f9ad4de1253376d2d1d93abb8b8c':
fate: Add tests for mov display matrix
Adapted to use ffprobe -show_entries
Merged-by: James Almer <jamrial@gmail.com>
* commit 'c454dfcff90f0ed39c7b0d4e85664986a8b4476c':
Use ISO C printf conversion specifiers where appropriate
This commit is a noop, an equivalent patch is currently under review on
the mailing-list: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209239.html
Merged-by: Clément Bœsch <u@pkh.me>
The old "API" that signaled rotation as a metadata value has been
replaced by DISPLAYMATRIX side data quite a while ago.
There is no reason to make muxers/demuxers/API users support both. In
addition, the metadata API is dangerous, as user tags could "leak" into
it, creating unintended features or bugs.
ffmpeg CLI has to be updated to use the new API. In particular, we must
not allow to leak the "rotate" tag into the muxer. Some muxers will
catch this properly (like mov), but others (like mkv) can add it as
generic tag. Note applications, which use libavformat and assume the
old rotate API, will interpret such "rotate" user tags as rotate
metadata (which it is not), and incorrectly rotate the video.
The ffmpeg/ffplay tools drop the use of the old API for muxing and
demuxing, as all muxers/demuxers support the new API. This will mean
that the tools will not mistakenly interpret per-track "rotate" user
tags as rotate metadata. It will _not_ be treated as regression.
Unfortunately, hacks have been added, that allow the user to override
rotation by setting metadata explicitly, e.g. via
-metadata:s:v:0 rotate=0
See references to trac #4560. fate-filter-meta-4560-rotate0 tests this.
It's easier to adjust the hack for supporting it than arguing for its
removal, so ffmpeg CLI now explicitly catches this case, and essentially
replaces the "rotate" value with a display matrix side data. (It would
be easier for both user and implementation to create an explicit option
for rotation.)
When the code under FF_API_OLD_ROTATE_API is disabled, one FATE
reference file has to be updated (because "rotate" is not exported
anymore).
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '5cc0057f4910c8c72421b812c8f337ef6c43696c':
lavu: remove the custom atomic API
This commit is a noop. The removal is postponed until all usages in
FFmpeg are dropped as well. A patchset is on discussion on the
mailing-list:
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209003.html
Merged-by: Clément Bœsch <u@pkh.me>
This disables everything that was deprecated at least 18 months ago.
Readjust the minimum API version as needed, postponing any
API-incompatible changes until the next bump.
Signed-off-by: Vittorio Giovara <vittorio.giovara@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 "reuses" the flags introduced for the av_vdpau_bind_context() API
function, and makes them available to all hwaccels. This does not affect
the current vdpau API, as av_vdpau_bind_context() should obviously
override the AVCodecContext.hwaccel_flags flags for the sake of
compatibility.
Cherry-picked from Libav commit 16a163b5.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Hook up all attributes that don't have a MSVC specific version at the
moment.
See f637046d31 for details.
These don't seem to be critical for building with clang in MSVC mode
though, and thus haven't been hooked up until now.
These seem to build fine with as old clang as 3.3 at least.
(clang 3.3 disguises itself as gcc 4.2 normally, so all of these
have been used for clang before, except for av_cold.)
The clang version numbers themselves are useless for detecting what
attributes are available, since Apple's clang builds use a completely
different versioning (presenting itself as e.g. clang 8.0 instead
of 3.8).
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '8ea35af7620e4f73f9e8c072e1c0fac9a04ec161':
avio: add a new flag for marking streams seekable by timestamp
Merged-by: James Almer <jamrial@gmail.com>
* commit 'e87a501e7d03ac68b58520108fe24ad9d0b36765':
swscale: Update bitdepth range check
This commit is a noop.
Up to 14 bits is supported since fa36f33422. This commits pushes the
limit to 15 bits but we don't seem to have pixel formats that enters in
that category.
12:03 <ubitux> so what's your opinion? should we move to 15 even if unused currently to make it consistent with libav and the function names, or keep our 14 suggesting there might be an issue with 15?
12:05 <ubitux> (functions are called hScale8To15_c, hScale16To15_c, ff_hscale8to15, ...)
12:06 <michaelni> I prefer to keep 14 until theres a case that allows us to test this and i suspect it will not work with 15 at least not all the code
Merged-by: Clément Bœsch <u@pkh.me>
This patch deprecates anything that has to do with merging/splitting
side data. Automatic side data merging (and splitting), as well as all
API symbols involved in it, are removed completely.
Two FF_API_ defines are dedicated to deprecating API symbols related to
this: FF_API_MERGE_SD_API removes av_packet_split/merge_side_data in
libavcodec, and FF_API_LAVF_KEEPSIDE_FLAG deprecates
AVFMT_FLAG_KEEP_SIDE_DATA in libavformat.
Since it was claimed that changing the default from merging side data to
not doing it is an ABI change, there are two additional FF_API_ defines,
which stop using the side data merging/splitting by default (and remove
any code in avformat/avcodec doing this): FF_API_MERGE_SD in libavcodec,
and FF_API_LAVF_MERGE_SD in libavformat.
It is very much intended that FF_API_MERGE_SD and FF_API_LAVF_MERGE_SD
are quickly defined to 0 in the next ABI bump, while the API symbols are
retained for a longer time for the sake of compatibility.
AVFMT_FLAG_KEEP_SIDE_DATA will (very much intentionally) do nothing for
most of the time it will still be defined. Keep in mind that no code
exists that actually tries to unset this flag for any reason, nor does
such code need to exist. Code setting this flag explicitly will work as
before. Thus it's ok for AVFMT_FLAG_KEEP_SIDE_DATA to do nothing once
side data merging has been removed from libavformat.
In order to avoid that anyone in the future does this incorrectly, here
is a small guide how to update the internal code on bumps:
- next ABI bump (probably soon):
- define FF_API_LAVF_MERGE_SD to 0, and remove all code covered by it
- define FF_API_MERGE_SD to 0, and remove all code covered by it
- next API bump (typically two years in the future or so):
- define FF_API_LAVF_KEEPSIDE_FLAG to 0, and remove all code covered
by it
- define FF_API_MERGE_SD_API to 0, and remove all code covered by it
This forces anyone who actually wants packet side data to temporarily
use deprecated API to get it all. If you ask me, this is batshit fucked
up crazy, but it's how we roll. Making AVFMT_FLAG_KEEP_SIDE_DATA to be
set by default was rejected as an ABI change, so I'm going all the way
to get rid of this once and for all.
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
This "reuses" the flags introduced for the av_vdpau_bind_context() API
function, and makes them available to all hwaccels. This does not affect
the current vdpau API, as av_vdpau_bind_context() should obviously
override the AVCodecContext.hwaccel_flags flags for the sake of
compatibility.
Adds functions to convert to/from strings and a function to iterate
over all supported device types. Also adds a new invalid type
AV_HWDEVICE_TYPE_NONE, which acts as a sentinel value.
* commit 'd7bc52bf456deba0f32d9fe5c288ec441f1ebef5':
imgutils: add a function for copying image data from GPU mapped memory
Merged-by: Clément Bœsch <u@pkh.me>
Not used by anything at all since we don't auto insert lavr filters.
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
openvela-robot