Required by MP4's AC3SpecificBox and MPEG-TS AC-3 audio_descriptor,
of which the former is implemented in our MP4 writer.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
This function is only called from the decoder's init function
and given that this decoder has FF_CODEC_CAP_INIT_CLEANUP set,
hevc_decode_free() is called automatically (currently it would
be called twice with the second call being redundant).
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
All contexts are always initialized during init, regardless
of whether frame threading is in use or not.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
avcodec_thread_init() has been removed in
9a79bb552a.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Update the still AVIF parser to only read the primary item. With this
patch, AVIF still images with exif/icc/alpha channel will no longer
fail to parse.
For example, this patch enables parsing of files in:
https://github.com/AOMediaCodec/av1-avif/tree/master/testFiles/Microsoft
Adding two fate tests:
1) demuxing of still image with 1 item - this test will pass regardless
of this patch.
2) demuxing of still image with 2 items - this test will fail without
this patch and will pass with patch applied.
Partially fixes trac ticket #7621
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: James Zern <jzern@google.com>
Add pat and pmt table at start of each segment in single_file mode enhanced
compatibility of hls stream. Because some hls clients separate parsing segment
of hls stream, the absence of pat/pmt will cause parsing to fail.
Reviewed-by: Steven Liu <liuqi05@kuaishou.com>
Signed-off-by: huheng <heng.hu.1989@gmail.com>
This allows for wider compatibility with older devices, such as those
running iOS 3. The only difference between HLS version 2 and version 3 is
that version 3 supports non-integer EXTINF values, and as such, we can
default to version 2 if we're using whole-integer EXTINFs anyways, when
`-hls_flags round_durations` is set.
As this code seems to otherwise consistently use the lowest compatible
version, this seems to fit in properly with existing behavior.
Testing confirms with that this patch, HLS output can work all the way back
to iOS 3.
Reviewed-by: Steven Liu <liuqi05@kuaishou.com>
Signed-off-by: Lucy <lucy@absolucy.moe>
When compiling decklink, this header is included from
a C++ file (albeit inside 'extern "C"') and this
causes compilation failures because of an implicit
void* -> char* conversion. So add an explicit cast.
Fixes ticket #9819.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
- ff_pix_abs16_neon
- ff_pix_abs16_xy2_neon
In direct micro benchmarks of these ff functions verses their C implementations,
these functions performed as follows on AWS Graviton 3.
ff_pix_abs16_neon:
pix_abs_0_0_c: 141.1
pix_abs_0_0_neon: 19.6
ff_pix_abs16_xy2_neon:
pix_abs_0_3_c: 269.1
pix_abs_0_3_neon: 39.3
Tested with:
./tests/checkasm/checkasm --test=motion --bench --disable-linux-perf
Signed-off-by: Jonathan Swinney <jswinney@amazon.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Frame counters can overflow relatively easily (INT_MAX number of frames is
slightly more than 1 year for 60 fps content), so make sure we are always
using 64 bit values for them.
A live stream can easily run for more than a year and the framedup logic breaks
on an overflow.
Signed-off-by: Marton Balint <cus@passwd.hu>
For ipcm and fpcm streams, big-endian format is the default, but it can be changed
with additional 'pcmC' sub-atom of audio sample description.
Details can be found in ISO/IEC 23003-5:2020
Fixes ticket #9763.
Fixes ticket #9790.
Patch simplified by Marton Balint.
Signed-off-by: Marton Balint <cus@passwd.hu>
AVIF specification allows for alpha channel as an auxiliary item (in
case of still images) or as an auxiliary track (in case of animated
images). Add support for both of these. The AVIF muxer will take
exactly two streams (when alpha is present) as input (first one being
the YUV planes and the second one being the alpha plane).
The input has to come from two different images (one of it color and
the other one being alpha), or it can come from a single file
source with the alpha channel extracted using the "alphaextract"
filter.
Example using alphaextract:
ffmpeg -i rgba.png -filter_complex "[0:v]alphaextract[a]" -map 0 -map "[a]" -still-picture 1 avif_with_alpha.avif
Example using two sources (first source can be in any pixel format and
the second source has to be in monochrome grey pixel format):
ffmpeg -i color.avif -i grey.avif -map 0 -map 1 -c copy avif_with_alpha.avif
The generated files pass the compliance checks in Compliance Warden:
https://github.com/gpac/ComplianceWarden
libavif (the reference avif library) is able to decode the files
generated using this patch.
They also play back properly (with transparent background) in:
1) Chrome
2) Firefox (only still AVIF, no animation support)
Reviewed-by: James Zern <jzern@google.com>
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
GL and Metal cache the state at time of texture creation. GLES2 and
Direct3D 11 use the state at time of the render copy call.
So the only way we can get the correct behavior consistently is by
making sure the state is set for both the upload *and* the draw call.
This probably isn't our bug to fix (upstream should make itself behave
consistently and also document its functions), but as it stands,
`ffplay` is misrendering BT.709 as BT.601 on my stock Linux system, and
that leaves a bad taste in my mouth.
Signed-off-by: Niklas Haas <git@haasn.dev>
Currently the format listing misses the J formats completely, yet
they are marked as supported in the encoder. Thus to make the logic
support them while not explicitly listing them, make the logic
utilize chroma subsampling information in both width and height
available through the pixel format descriptor.
Enable dynamic QP configuration in runtime on qsv encoder. Through
AVFrame->metadata, we can set key "qsv_config_qp" to change QP
configuration when we encode video in CQP mode.
Signed-off-by: Yue Heng <yue.heng@intel.com>
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Change the default value of "bf" for hevc_qsv to -1. 8 isn't the best
choice so let MSDK to decide the number of b frames.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
cuvidParseVideoData only supports pure OBUs, it reports an unknown
error with AV1CodecConfigurationRecord. Check whether extradata
is AV1CodecConfigurationRecord and skip the first 4 bytes to fix
the issue.
The bug is revealed in ffmpeg cmd since 45e3b6a68 and ffd1316e.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This adds the exact bits per sample for DFPWM to
av_get_exact_bits_per_sample.
Previously, the DTS and PTS were set to 0 because the codec never
reported them, but adding this allows libavformat to automatically
set DTS and PTS from the byte position of the stream.
Signed-off-by: Jack Bruienne <jackbruienne@gmail.com>
Forgotten in 4011a76494.
The reason for this is that these functtions are marked
as av_always_inline and GCC does not emit warnings
if such functions are unused, so this went unnoticed.
Yet Clang does, so this commit removes them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Regression since 67eea6cf02.
Affects only WebVTT when muxing WebM. (This is covered
by the webm-webvtt-remux FATE test which fails for several
FATE boxes on fate-ffmpeg.org.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This ignores >64bit
Alternatively we could support that if it occurs in reality
Fixes: negation of -9223372036854775808
Fixes: integer overflows
Fixes: 46072/clusterfuzz-testcase-minimized-ffmpeg_dem_MATROSKA_fuzzer-5029840966778880
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Whether an ICC profile is present or not, the libjxl
encoder wrapper should now properly read colorspace tags
and forward them to libjxl appropriately, rather than just
assume sRGB as before. It will also print warnings when
colorimetric assumptions are made about the input data.
Reviewed-by: Niklas Haas <git@haasn.dev>
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Whether an ICC profile is present or not, the decoder
should now properly tag the colorspace of pixel data
received by the decoder.
Reviewed-by: Niklas Haas <git@haasn.dev>
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Unbreaks libavfilter builds when configured with a subset of filters.
drawutils added ff_draw_init2 in 6c3a82f043 which calls functions defined in
colorspace.c. So the latter needs to be built alongside the former.
Use the proper header for PPC CPU detection code. sys/param.h includes
sys/types, but sys/types.h is the more appropriate header to be used
here.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is needed to get LIBAVFORMAT_VERSION, used as part of the user agent.
Fixes a recent regression.
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Support for VDPAU accelerated AV1 decoding was added with libvdpau-1.5.
Support for the same in ffmpeg is added with this patch. Profiles
related to VDPAU AV1 can be found in latest vdpau.h present in
libvdpau-1.5.
Add AV1 VDPAU to list of hwaccels and supported formats
Added file vdpau_av1.c and Modified configure to add VDPAU AV1 support.
Mapped AV1 profiles to VDPAU AV1 profiles. Populated the codec specific
params that need to be passed to VDPAU.
Signed-off-by: Philip Langdale <philipl@overt.org>
Up until now, only the first four bytes (the ones preceding
the OBU) were written because not enough space has been reserved
for the complete CodecPrivate. This commit changes this
by increasing the space reserved for the CodecPrivate (it is big
enough for every sane sequence header plus something extra);
the code falls back to writing four bytes in case the increased
space turns out to be insufficient.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It will be used by the Matroska muxer to reserve a certain number
of bytes for the CodecPrivate in case no extradata is initially
available (as it is for the libaom-av1 encoder).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, updating extradata was very ad-hoc: The amount of
space reserved for extradata was not recorded when writing the
header; instead the AAC code simply presumed that it was enough.
This commit changes this by recording how much space is available.
This brings with it that the code for writing of and reserving space
for the CodecPrivate and for updating it diverges. They are therefore
split; this allows to put other common tasks like seeking to
right offset as well as writing padding (in case the new extradata did
not fill the whole reserved space) to this common function.
The code for filling up the reserved space is smarter than the code
it replaces; therefore it is no longer necessary to reserve more
than necessary just to be sure that one can add an EBML Void element
(whose minimum size is two) lateron. This is the reason for the change
to the aac-autobsf-adtstoasc test.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Instead pass extradata and extradata_size explicitly.
(It is not perfect, as ff_put_(wav|bmp)_header() still uses
the extradata embedded in codecpar, but this is not an issue
as long as their CodecPrivate isn't updated.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is in preparation for splitting writing and updating
extradata more thoroughly later.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The intention behind the current check seems to be to check for
the rbsp_trailing_bits() syntax structure which is always 0x80
for valid SEI messages. Yet this is wrong: These trailing bits
are not part of the GetBitContext -- they have already been
stripped in ff_h2645_packet_split(). And it is harmful, as
0x80 is a legal SEI message payload type (namely for
Structure of pictures information SEI messages). We ignore this
type of SEI, but because of this bug we also ignored every
SEI message in the same NALU following it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It does not exist for NALUs for which the SODB is empty;
it also does not exist for NALUs for which not even
the complete header is present. The former category contains
end of sequence and end of bitstream units. The latter category
consists of one-byte HEVC units (the ordinary H.264 header is only
one byte long).
This commit therefore stops stripping RBSP trailing padding
from the former type of unit and discards the latter type of unit
altogether.
This also fixes an assertion failure: Before this commit, a one-byte
HEVC NALU from an ISOBMFF packet could pass all the checks in
hevc_parse_nal_header() (because the first byte of the size field
of the next unit is mistaken as containing the temporal_id);
yet because the trailing padding bits were stripped, its actually
had a size of less than eight bits; because h2645_parse.c uses
the checked bitstream reader, the get_bits_count() of the GetBitContext
is not 16 in this case; it is not even a multiple of eight
and this can trigger an assert in ff_hevc_decode_nal_sei().
Fixes: Assertion failure
Fixes: 46662/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-4947860854013952
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
