Fixes: signed integer overflow: 2147483645 + 16 cannot be represented in type 'int'
Fixes: 46993/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_FIXED_fuzzer-4759025234870272
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This function needs more cleanup and it lacks error handling
Fixes: use of uninitialized memory
Fixes: CID700776
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This limit is possibly not reachable due to other restrictions on buffers but
the decoder run table is too small beyond this, so explicitly check for it.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 315680096256 * 134215943 cannot be represented in type 'long long'
Fixes: 48713/clusterfuzz-testcase-minimized-ffmpeg_dem_IFF_fuzzer-5886272312311808
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Data does not have to be decrypted in 16-byte blocks for AES-CTR mode, so
existing buggy code can be hugely simplified.
Fixes ticket #9829.
Signed-off-by: Marton Balint <cus@passwd.hu>
This resulted in the wrong column/row being chosen.
This can be seen best when using xfade on streams with transparency.
For example: in case of a slideleft transition, the first column from
the first input will overwrite the first column of the second stream
throught the transition.
GSoC'22
libavfilter/vf_chromakey_cuda.cu:the CUDA kernel for the filter
libavfilter/vf_chromakey_cuda.c: the C side that calls the kernel and gets user input
libavfilter/allfilters.c: added the filter to it
libavfilter/Makefile: added the filter to it
cuda/cuda_runtime.h: added two math CUDA functions that are used in the filter
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
The earlier code ignored the lower 16 bits and instead used
the highest 8 bits twice.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
pkg_config fallback for SDL2 use 2.1.0 as max (excluded) version
where the pkg_config specify 3.0.0
Correcting fallback version to be in line with the pkg_config version
Signed-off-by: dvhh <dvhh@yahoo.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
For 422 frames we should not use hard coded 8 to calculate mb size for
uv plane. Chroma shift should be taken into consideration to be
compatiple with different sampling format.
The error is reported by fate test when av_cpu_max_align() return 64
on the platform supporting AVX512. This is a hidden error and it is
exposed after commit 17a59a634c.
mpeg2enc has a mechanism to reuse frames. When it computes SSE (sum of
squared error) on current mb, reconstructed mb will be wrote to the
previous mb space, so that the memory can be saved. However if the align
is 64, the frame is shared in somewhere else, so the frame cannot be
reused and a new frame to store reconstrued data is created. Because the
height of mb is wrong when compute sse on 422 frame, starting from the
second line of macro block, changed data is read when frame is reused
(we need to read row 16 rather than row 8 if frame is 422), and unchanged
data is read when frame is not reused (a new frame is created so the
original frame will not be changed).
That is why commit 17a59a634c exposes this
issue, because it add av_cpu_max_align() and this function return 64 on
platform supporting AVX512 which lead to creating a frame in mpeg2enc,
and this lead to the different outputs.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Some samples contain Active Format Descriptors, yet the output
of no test depends upon them, so that they are de-facto untested.
So add a dedicated test for them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes memleaks when the trailer is never written or when shift_data()
fails when writing the trailer.
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
encode_send_frame_internal() is always only called if
the buffer packet is empty and except when we are dealing
with an audio codec that does not allow variable frame size
it stays that way until a call to av_frame_ref() at the end
of encode_send_frame_internal(). In case we are dealing
with the small last frame of an audio encoder requiring
constant frame size the frame will be allocated by pad_last_frame()
and this the only case where this is so. So by returning directly
after pad_last_frame(), we can avoid having to recheck
whether the frame is still empty before av_frame_ref().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These packets need not be writable (and are not modified by us),
so it is best to access them via const uint8_t*.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The packets given to decoder need not be writable,
so it is best to access them via const uint8_t*.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The packets given to muxers need not be writable,
so it is best to access them via const uint8_t*.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Some files I have from circa year 2000 are 16:9 NTSC DV video
encoded as QuickTime with Radius SoftDV. This marked 4:3 videos
with the box 'dvc ' for NTSC or 'dvcp' for PAL, which are already
supported, but 16:9 videos as 'dvl ' or 'dvlp', which were not.
Adding these to the list for DV codec processing gives the
expected metadata and playback.
I have not tested PAL as I have no sample data, only NTSC.
Signed-off-by: Marton Balint <cus@passwd.hu>
Dual mono files report a channel count of 2 with each individual channel in its
own SCE, instead of both in a single CPE as is the case with standard stereo.
This commit handles this non default channel configuration scenario.
Fixes ticket #1614
Signed-off-by: James Almer <jamrial@gmail.com>
regression since 13350e81fd
Fix looking for .ffmpeg subfolder in FFMPEG_DATADIR and inversely not in HOME.
Fix search order (documentation).
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
A cosmetic change only, it basically just changes the user facing error message
to clients that interpret the errors to something that makes sense.
Signed-off-by: Andreas Schneider <asn@cryptomilk.org>
Signed-off-by: Marton Balint <cus@passwd.hu>
Fixes: signed integer overflow: 9223372036848019263 + 134232320 cannot be represented in type 'long'
Fixes: 48155/clusterfuzz-testcase-minimized-ffmpeg_dem_CINE_fuzzer-5751429207293952
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Also warn the user that for single images -update should be used, for sequences
a proper pattern should be specified.
Fixes ticket #9748.
Signed-off-by: Marton Balint <cus@passwd.hu>
In order to not generate 0 sized packets or create a huge index table
needlessly.
Fixes: Timeout
Fixes: 43717/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-5206008287330304
Fixes: 45738/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-6142535657979904
Signed-off-by: Marton Balint <cus@passwd.hu>
Modifying avformat_find_stream_info() behaviour based on the number of EAGAINs
it encounters is a hack which usually only hides the real issue if such thing
happen.
This reverts commit b0cac7082d.
av_fast_realloc and av_fast_mallocz? store the size of
the objects they allocate in an unsigned. Yet they overallocate
and currently they can allocate more than UINT_MAX bytes
in case a user has requested a size of about UINT_MAX * 16 / 17
or more if SIZE_MAX > UINT_MAX (and if the user increased
max_alloc_size via av_max_alloc). In this case it is impossible
to store the true size of the buffer via the unsigned*;
future requests are likely to use the (re)allocation codepath
even if the buffer is actually large enough because of
the incorrect size.
Fix this by ensuring that the actually allocated size
always fits into an unsigned. (This entails erroring out
in case the user requested more than UINT_MAX.)
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add a short hand parameter for making a fixed size grid. The existing
xstack layout parameter syntax gets tedious if all one wants is a
matrix like grid of the input streams. Add a grid option to the xstack
filter that simplifies this use case by simply specifying the number of
rows and columns instead of specific x/y co-ordinate for each stream.
Also updating the filter documentation to explain the new option.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
The doxy for av_channel_layout_describe() states that the user should look
at the return value to check if the string was truncated. Returning an error
code in this scenario goes against this and is an API break.
A proper fix for the timeout was applied to the Matroska demuxer in 94901a9518.
This reverts commit 8154cb7c2f.
If the stream's channel layout is first set into a native layout using codec
private parameters, this code here could potentially result in an invalid
native layout where popcnt(ch_layout.u.mask) != ch_layout.nb_channels being
propagated.
Fixes: Timeout printing a billion channels
Fixes: 48099/clusterfuzz-testcase-minimized-ffmpeg_dem_MATROSKA_fuzzer-6754782204788736
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
A decoder's input packet need not be writable, so we must not modify
the data.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The packets muxers receive are not guaranteed to be writable,
so they must not be modified. Ergo only access the packet's data
via a const uint8_t*.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-shortest stops 'recording' when the shortest output stream ends. The
native or even seek-adjusted duration of the source input stream isn't
considered.
davs2_decoder_close doesn't free those on the fly frames which
don't get output yet. It's a design bug, but easy to workaround.
Before the patch:
Direct leak of 1198606 byte(s) in 2 object(s) allocated from:
#0 0x563af5e1e5f0 in malloc (ffmpeg+0x6675f0)
#1 0x563af9765ef3 in davs2_malloc davs2/source/common/common.h:1240
#2 0x563af9765ef3 in davs2_alloc_picture davs2/source/common/header.cc:815
Indirect leak of 3595818 byte(s) in 6 object(s) allocated from:
#0 0x563af5e1e5f0 in malloc (ffmpeg+0x6675f0)
#1 0x563af9765ef3 in davs2_malloc davs2/source/common/common.h:1240
#2 0x563af9765ef3 in davs2_alloc_picture davs2/source/common/header.cc:815
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Fixes: signed integer overflow: -14914387 + -2147418648 cannot be represented in type 'int'
Fixes: 46464/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALAC_fuzzer-474307197311385
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It results in undefined behaviour. Instead initialize the mutexes
and condition variables once during init (and check these
initializations).
Also combine the corresponding mutex and condition variable
into one structure so that one can allocate their array
jointly.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Adding a new AVHWAccel also adds a new CONFIG variable for it
and said config variables are typically used to calculate the
size of stack arrays. In such a context, an undefined CONFIG
variable does not evaluate to zero; instead it leads to
a compilation failure. Therefore treat this file like the other
files containing lists of configurable components and prompt
for reconfiguration if it is modified.
(E.g. a44fba0b5b led to compilation
failures for me.)
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This leaves out RealAudio DolbyNet, which utilizes bsids 9 and 10,
It is not clear whether the interpreted bit rate value (divided by
2 or 4 depending on the variant), or the original bit rate value
should be utilized to receive the bit_rate_code index.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
Add the AC-3 frame type, as well as early exit from additional packet
parsing in case of AC-3, as only a single packet is required to get
the required information.
Additionally, expose ac3_bit_rate_code via the eac3_info struct as
it is required for AC3SpecificBox.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
This simplifies the code to no longer have #ifs in a manner which
does not require handling avpriv_ac3_parse_header returning ENOSYS.
As an existing example, the MPEG-TS muxer already requires the AC-3
parser, and in order to fix existing issues with the current AC-3
movenc code, switching to use the AC-3 parser is required, so this
is an enabling change for that.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
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>
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>
because the AudioConverterFillComplexBuffer can return 0 or 1 if
success.
so set the ret to 0 it AudioConverterFillComplexBuffer success and
return ret value for success or return AVERROR_EXTERNAL when
AudioConverterFillComplexBuffer failed.
BTW change the error message log level from warning to error.
Reviewed-by: Zhao Zhili <zhilizhao@tencent.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
This avoids overflow checks on additions with 32bit numbers
Fixes: signed integer overflow: 9223372036854775806 + 2 cannot be represented in type 'long'
Fixes: 44012/clusterfuzz-testcase-minimized-ffmpeg_dem_HLS_fuzzer-4747770734444544
Fixes: 48065/clusterfuzz-testcase-minimized-ffmpeg_dem_HLS_fuzzer-5372410355908608
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Use the new codec control AV1E_GET_NUM_OPERATING_POINTS to get the
number of operating points. This is the size of the output arrays of
AV1E_GET_SEQ_LEVEL_IDX and AV1E_GET_TARGET_SEQ_LEVEL_IDX.
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: James Zern <jzern@google.com>
The only systems which benefit from these are truely
ancient 32bit x86s as all other systems use at least the SSE2 versions
(this includes all x64 cpus (which is why this code is restricted
to x86-32)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only systems which benefit from ff_diff_bytes_mmx are truely
ancient 32bit x86s as all other systems use at least the SSE2 versions
(this includes all x64 cpus (which is why this code is restricted
to x86-32)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only systems which benefit from ff_diff_int16_mmx are truely
ancient 32bit x86s as all other systems use at least the SSE2 versions
(this includes all x64 cpus (which is why this code is restricted
to x86-32)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only systems which benefit from these are truely
ancient 32bit x86s as all other systems use at least the SSE2 versions
(this includes all x64 cpus (which is why this code is restricted
to x86-32)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only systems which benefit from these are truely
ancient 32bit x86s as all other systems use at least the SSE2 versions
(this includes all x64 cpus (which is why this code is restricted
to x86-32)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only systems which benefit from these are truely
ancient 32bit x86s as all other systems use at least the SSE2 versions
(this includes all x64 cpus (which is why this code is restricted
to x86-32)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only systems which benefit from ff_lfe_fir0_float_sse are truely
ancient 32bit x86s as all other systems use at least the SSE2 versions
(this includes all x64 cpus (which is why this code is restricted
to x86-32)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only systems which benefit from ff_rv34_idct_dc_add_mmx are truely
ancient 32bit x86s as all other systems use at least the SSE2 versions
(this includes all x64 cpus (which is why this code is restricted
to x86-32)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only systems which benefit from synth_filter_sse are truely
ancient 32bit x86s as all other systems use at least the SSE2 versions
(this includes all x64 cpus (which is why this code is restricted
to x86-32)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only systems which benefit from ff_dct32_float_sse are truely
ancient 32bit x86s as all other systems use at least the SSE2 versions
(this includes all x64 cpus (which is why this code is restricted
to x86-32)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only systems which benefit from imdct36_blocks_sse are truely
ancient 32bit x86s as all other systems use at least the SSE2 versions
(this includes all x64 cpus (which is why this code is restricted
to x86-32)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only systems which benefit from it are truely ancient
32bit x86s as all other systems use at least the SSE2 versions
(this includes all x64 cpus (which is why this code is restricted
to x86-32)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only system which benefit from these are truely ancient
32bit x86s as all other systems use at least the SSE2 versions
(this includes all x64 cpus (which is why this code is restricted
to x86-32)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only system which benefit from these are truely ancient
32bit x86s as all other systems use at least the SSE2 versions
(this includes all x64 cpus (which is why this code is restricted
to x86-32)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only system which benefit from these are truely ancient
32bit x86s as all other systems use at least the SSE2 versions
(this includes all x64 cpus (which is why this code is restricted
to x86-32)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only system which benefit from these are truely ancient
32bit x86s as all other systems use at least the SSE2 versions
(this includes all x64 cpus (which is why this code is restricted
to x86-32)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT, SSE and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2). So given that the only systems which benefit
from these functions are truely ancient 32bit x86s they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT, SSE and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2). So given that the only systems which benefit
from ff_vector_fmul_window_3dnowext are truely ancient 32bit
AMD x86s it is removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT, SSE and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2). So given that the only systems which benefit
from the 3dnow implementations are truely ancient 32bit AMD x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT, SSE and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2). So given that the only systems which benefit
from the 3dnow implementations are truely ancient 32bit AMD x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT, SSE and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2). So given that the only systems which benefit
from the 8x8 MMX (overridden by MMXEXT) or the 16x16 MMXEXT
(overridden by SSE2) are truely ancient 32bit x86s they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from process_mmxext are truely ancient 32bit x86s
it is removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT, SSE and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2). So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Moreover, some of the removed code was buggy/not bitexact
and lead to failures involving the f32le and f32be versions of
gray, gbrp and gbrap on x86-32 when SSE2 was not disabled.
See e.g.
https://fate.ffmpeg.org/report.cgi?time=20220609221253&slot=x86_32-debian-kfreebsd-gcc-4.4-cpuflags-mmx
Notice that yuv2yuvX_mmx is not removed, because it is used
by SSE3 and AVX2 as fallback in case of unaligned data and
also for tail processing. I don't know why yuv2yuvX_mmxext
isn't being used for this; an earlier version [1] of
554c2bc708 used it, but
the version that was eventually applied does not.
[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-November/272124.html
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from ff_ssd_int8_vs_int16_mmx are truely ancient
32bit x86s it is removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from ff_scalarproduct_and_madd_int16_mmxext are truely
ancient 32bit x86s it is removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from ff_sbr_qmf_deint_bfly_sse are truely ancient 32bit x86s
it is removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from line_noise_mmx are truely ancient 32bit x86s
it is removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
1. getenv() is replaced with getenv_utf8() across libavformat.
2. New versions of AviSynth+ are now called with UTF-8 filenames.
3. Old versions of AviSynth are still using ANSI strings,
but MAX_PATH limit on filename is removed.
Signed-off-by: Martin Storsjö <martin@martin.st>
wchartoutf8() converts strings returned by WinAPI into UTF-8,
which is FFmpeg's preffered encoding.
Some external dependencies, such as AviSynth, are still
not Unicode-enabled. utf8toansi() converts UTF-8 strings
into ANSI in two steps: UTF-8 -> wchar_t -> ANSI.
wchartoansi() is responsible for the second step of the conversion.
Conversion in just one step is not supported by WinAPI.
Since these character converting functions allocate the buffer
of necessary size, they also facilitate the removal of MAX_PATH limit
in places where fixed-size ANSI/WCHAR strings were used
as filename buffers.
On Windows, getenv_utf8() wraps _wgetenv() converting its input from
and its output to UTF-8. Strings returned by getenv_utf8()
must be freed by freeenv_utf8().
On all other platforms getenv_utf8() is a wrapper around getenv(),
and freeenv_utf8() is a no-op.
The value returned by plain getenv() cannot be modified;
av_strdup() is usually used when modifications are required.
However, on Windows, av_strdup() after getenv_utf8() leads to
unnecessary allocation. getenv_dup() is introduced to avoid
such an allocation. Value returned by getenv_dup() must be freed
by av_free().
Because of cleanup complexities, in places that only test the existence
of an environment variable or compare its value with a string
consisting entirely of ASCII characters, the use of plain getenv()
is still preferred. (libavutil/log.c check_color_terminal()
is an example of such a place.)
Plain getenv() is also preffered in UNIX-only code,
such as bktr.c, fbdev_common.c, oss.c in libavdevice
or af_ladspa.c in libavfilter.
Signed-off-by: Martin Storsjö <martin@martin.st>
Because not all metadata is written as tags, the Matroska muxer
filters out the tags that are not written as tags.
Therefore the code first checks whether a Tag master element
needs to be opened for a given stream/chapter/attachment/global
metadata. If the answer turns out to be yes, it is checked again
whether a given AVDictionaryEntry is written as a tag.
This commit changes this: The Tag element is opened unconditionally
and in case it turns out that it was unneeded, it is discarded again.
This is possible because the Tag element is written into its own
dynamic buffer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible by using a dynamic buffer to write them;
said dynamic buffer is (re)used and reset as appropriate.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Ffmpeg/ffprobe/ffplay sets scan_all_pmts to 1 when finding the streams, that
should be enough to handle files for which some early PMTs miss some streams.
Fixes ticket #9782.
Signed-off-by: Marton Balint <cus@passwd.hu>
Default avctx->frame_size is 0 which led to init failure for
audio MediaFoundation encoders since 827d6fe73d.
The MF audio encoders accept variable frame size input buffers.
Fixes#9802
SSE3 instruction movdqa in ff_yuv2yuvX_sse3() expects a 16-byte aligned address for a memory address, or else a segfault is generated.
The src_pixels buffer below was not aligned to 16 bytes on the stack necessarily, so we got segfaults during fate-checkasm-sw_scale.
Therefore 16-byte align all of these local variables, aligning them too much shouldn't hurt.
- Introduce ff_draw_init2, which takes explicit colorspace and range
args
- Use lavu/csp and lavfi/colorspace for conversion, rather than the
lavu/colorspace.h macros
- Use the passed-in colorspace when performing RGB->YUV conversions
The upshot of this is:
- Support for YUV spaces other than BT601
- Better rounding for all conversions
- Particular rounding improvements in >8-bit formats, which previously
used simple left-shifts
- Support for limited-range RGB
- Support for full-range YUV in non-J pixfmts
Due to the rounding improvements, this results in a large number of
minor changes to FATE tests.
Signed-off-by: rcombs <rcombs@rcombs.me>
Don't assume each sample is one byte in size. Doing so results in wrong and
occasionally non-monotonically-increasing timestamps.
Fix nearby cosmetic typo.
Signed-off-by: Marton Balint <cus@passwd.hu>
For SSE2 and SSE3, there are four states that the two flags
involved (AV_CPU_FLAG_SSE[23] and AV_CPU_FLAG_SSE[23]SLOW) can convey.
When ordered from worst to best they are:
1. both flags unset (SSE[23] unavailable)
2. the slow flag set, the ordinary flag unset (this is designed
for cases where SSE2 is available, but so slow that MMX(EXT)/SSE
code is usually faster)
3. both flags set (SSE2 is available, but there might be scenarios
where MMX(EXT)/SSE code is faster)
4. the ordinary flag set, the slow flag unset (this is the normal case)
The ordinary macros for checking cpuflags return true
in the latter two cases; the fast macros only return true for
the latter case. Yet the macros to check for slow currently
only return true in case three.
This seems unintended. In fact, the only uses of the slow macros
are all of the form
if (EXTERNAL_SSE2(cpu_flags) || EXTERNAL_SSE2_SLOW(cpu_flags))
where the check for EXTERNAL_SSE2_SLOW is completely redundant.
Even more importantly, it is not what was intended. Before
6369ba3c9c, the checks passed
in cases 2 to 4. Said commit changed this to something that
only passes for the third case. Commits
7fb758cd8e and
c1913064e3 restored the old behaviour,
yet merging 4efab89332 (in commit
ac774cfa57) broke this again
by changing it to what it is now.*
This commit changes the macros to make the slow macros check
whether a specific instruction is supported, even if slow.
This restores the intended meaning to all uses of the SLOW macros
and is generally more natural.
*: Libav only checks for EXTERNAL_SSE2_SLOW, i.e. for the third case
only.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In C, qualifiers for arrays are broken:
const VLC_TYPE (*foo)[2] is a pointer to an array of two const VLC_TYPE
elements and unfortunately this is not compatible with a pointer
to a const array of two VLC_TYPE, because the latter does not exist
as array types are never qualified (the qualifier applies to the base
type instead). This is the reason why get_vlc2() doesn't accept
a const VLC table despite not modifying the table at all, as
there is no automatic conversion from VLC_TYPE (*)[2] to
const VLC_TYPE (*)[2].
Fix this by using a structure VLCElem for the VLC table.
This also has the advantage of making it clear which
element is which.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use The mfxEncoderCtrl parameter to enable ROI. Get side data
"AVRegionOfInterest" and use it to configure "mfxExtEncoderROI" which is
the MediaSDK's ROI configuration.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Fixes: read_frame_internal() which does not return even though both demuxer and parser do return
Fixes: 43717/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-5206008287330304
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Reduces default fragment size from the pulse audio default of 2 sec to 50 ms.
This also has an effect on the size of the returned frames, which will be
around 50 ms as well, making timestamps more accurate.
This should fix the regression in ticket #9776.
Pulseaudio timestamps for monitor sources are still pretty inaccurate for me,
but I don't see how else should we query latencies from the library.
Signed-off-by: Marton Balint <cus@passwd.hu>
This reverts commit 7f059a250b.
Apparently adjusting latency makes a difference even if fragment size is specifed.
Signed-off-by: Marton Balint <cus@passwd.hu>
It is no longer converted since mkv_write_chapters() is called
before mkv_write_tags() which happens since commit
4ebfc13c33. Given the fact that
chapters can also be written late, mkv_write_chapters() has to
convert the metadata itself.
Fixes ticket #9812.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Before this patch the muxer writes an invalid file
(namely one in which the Projection master is a child of
the Colour element) if the following conditions are met:
a) The stream contains AVMasteringDisplayMetadata without primaries
and luminance (i.e. useless AVMasteringDisplayMetadata).
b) The stream contains AV_PKT_DATA_SPHERICAL side data.
c) All the colour elements of the stream are equal to default
(i.e. unknown).
Fortunately these conditions are very unlikely to be met.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In this case it also stops pretending that the length of
the output string is somehow checked (which is currently
being done by using snprintf that is called with the amount
of space needed instead of the amount of space actually available).
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only used by exif.c (and e.g. EXIF_TAG_NAME_LENGTH
is an implementation detail anyway).
Also remove the sentinel, as it is used in conjunction
with FF_ARRAY_ELEMS.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is more spec-compliant because it does not rely
on dead-code elimination by the compiler. Especially
MSVC has problems with this, as can be seen in
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/296373.html
or
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/297022.html
This commit does not eliminate every instance where we rely
on dead code elimination: It only tackles branching to
the initialization of arch-specific dsp code, not e.g. all
uses of CONFIG_ and HAVE_ checks. But maybe it is already
enough to compile FFmpeg with MSVC with whole-programm-optimizations
enabled (if one does not disable too many components).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Its not supported to maintain a frame as receive_frame() argument
over multiple calls
Fixes: store to null pointer of type 'FFTSample' (aka 'float')
Fixes: 46231/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_BINKAUDIO_DCT_fuzzer-6276566037954560
Fixes: ACDC.smo
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT, SSE and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2). So given that the only systems which benefit
from the MMXEXT resamplers (which are overridden by SSE2)
are truely ancient 32bit x86s they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There is a x86-32 MMXEXT implementation for resampling
planar 16bit data. multiple_resample() therefore calls
emms_c() if it thinks that this needed. And this is bad:
1. It is a maintenance nightmare because changes to the
x86 resample DSP code would necessitate changes to the check
whether to call emms_c().
2. The return value of av_get_cpu_flags() does not tell
whether the MMX DSP functions are in use, as they could
have been overridden by av_force_cpu_flags().
3. The MMX DSP functions will never be overridden in case of
an x86-32 build with --disable-sse2. In this scenario lots of
resampling tests (like swr-resample_exact_lin_async-s16p-8000-48000)
fail because the cpuflags indicate that SSE2 is available
(presuming that the test is run on a CPU with SSE2).
4. The check includes a call to av_get_cpu_flags(). This is not
optimized away for arches other than x86-32.
5. The check takes about as much time as emms_c() itself,
making it pointless.
This commit therefore removes the check and calls emms_c()
unconditionally (it is a no-op for non-x86).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This enables printing to a resource specified with -o OUTPUT.
In case the output is not specified, prints to stdout as usual.
Address issue: http://trac.ffmpeg.org/ticket/8024
Signed-off-by: Marton Balint <cus@passwd.hu>
This new function makes it possible to use avio_printf() functionality from
a function taking a variable list of arguments.
Signed-off-by: Marton Balint <cus@passwd.hu>
Namely ff_avg_h264_qpel8or16_hv1_lowpass_op_mmxext. It seems to exist
since 610e00b359 (a function like this
already existed before that commit, but it was static and
av_always_inline and was therefore not present in the actual binaries).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This file does not use anything from get_bits.h at all;
furthermore hevcdsp.h now includes get_bits.h itself.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"
Setting X264_API_IMPORTS only affects msvc builds and it breaks
linking to static builds (although is required for shared builds).
This flag is set by x264 in its pkgconfig as required since build
158 (a615f027ed172e2dd5380e736d487aa858a0c4ff) from July 2019.
So this patch updates configure to require a newer x264 build that
correctly sets the imports flag.
The min version requirement of 158 is applied for msvc builds only.
This is also removing the check for 'libx264 without pkg-config'
which was left for compatibility reasons about 7 years ago when
the pkg-config check was introduced by commit
e06263ef1e.
Co-authored-by: softworkz <softworkz@hotmail.com>
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Matt Oliver <protogonoi@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Introduce fifo_size and overrun_nonfatal params to configure fifo buffer
behavior.
Use newly introduced RIST_DATA_FLAGS_OVERFLOW flag to check for overrun
and error out in that case.
Signed-off-by: Marton Balint <cus@passwd.hu>
Option was added in commit 39aafa5ee9 but was never documented.
Also does not seem there are current use cases for it,
tests for which it was introduced are still working therefore we drop
it altogether.
Indirectly fix trac issue: http://trac.ffmpeg.org/ticket/1698
Signed-off-by: Marton Balint <cus@passwd.hu>
buffer_size is an int
Fixes: signed integer overflow: 9223372036854775754 + 32767 cannot be represented in type 'long'
Fixes: 45691/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-5263458831040512
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -2145378272 - 538976288 cannot be represented in type 'int'
Fixes: 45690/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-5015496544616448
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -9223372036854775808 - 4607 cannot be represented in type 'long'
Fixes: 45685/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-5280102802391040
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: 46194/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-580292873827123
Fixes: stack-buffer-overflow on address 0x7ffc0ce69b30 at pc 0x00000062fb03 bp 0x7ffc0ce69af0 sp 0x7ffc0ce69ae8
Fixes: 46205/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-5354894996930560
Fixes: 47861/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-4817404984688640
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
stat is now re-mapped with long path support
in os_support.h
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Fixes CID1396405
MSE and PSNR is slightly improved, and some noticable corruptions disappear as
well.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marton Balint <cus@passwd.hu>
According to the tls documentation: tls_read() and tls_write() can
return TLS_WANT_POLLIN and TLS_WANT_POLLOUT which indicates that the
same operation must be repeated immediately.
This commit prevents the libtls backend from failing when libtls returns
TLS_WANT_POLLIN or TLS_WANT_POLLOUT with the following error:
[tls @ 0x7f6e20005a00] (null)
Signed-off-by: Marton Balint <cus@passwd.hu>
It's been a regular annoyance and often undesired.
There will be a subtitle filter which allows to dump individual
subtitle bitmaps.
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Those are always showing up on Patchwork when FATE tests are failing,
covering some possibly more useful information.
The volatile keyword was used as a workaround for an eight year old
clang version.
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
There is no reason to think that an attachment will contain text
subtitles. Furthermore, attachments are exported in extradata, so the
AV_CODEC_ID_TEXT decoder would not do anything useful with them anyway.
mov_mdhd_language_map table doesn't contain ISO 639 codes for some of
the languages. I added a few which have no contradictory mappings
Fixes ticket #9743
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Unlike avcodec_default_get_buffer2(), this version does not allocate more than
what the lavu image helper functions consider should be allocated for a given
frame.
Since the get_buffer2() documentation does not require any kind of buffer
padding for any of the planes, this should help detect bugs in our DR1 decoders
if they read beyond the end of the buffer, simulating what some library users
might experience when they use their own custom get_buffer2() implementations.
Signed-off-by: James Almer <jamrial@gmail.com>
Y, U, V data is loaded at the end of the current iteration for the next
iteration.
It results in memory access past the frame data on the last iteration
(that data is never used after the loading).
So load data at the start of the iteration, so that only useful data is
loaded.
Signed-off-by: Vardan Margaryan <v.t.margaryan@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
To do more accurate QP control, add min/max QP control on I/P/B frame
separately to qsv encoder. qmax and qmin still work but newly-added
options have higher priority.
Signed-off-by: Yue Heng <yue.heng@intel.com>
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Add support for max frame size:
- max_frame_size (bytes) to indicate the max allowed size for frame.
Control each encoded frame size into target limitation size by adjusting
whole frame's average QP value. The driver will use multi passes to
adjust average QP setp by step to achieve the target, and the result
may not strictly guaranteed. Frame size may exceed target alone with
using the maximum average QP value. The failure always happens on the
intra(especially the first intra frame of a new GOP) frames or set
max_frame_size with a very small number.
example cmdline:
ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -f rawvideo \
-v verbose -s:v 352x288 -i ./input.yuv -vf format=nv12,hwupload \
-c:v h264_vaapi -profile:v main -g 30 -rc_mode VBR -b:v 500k \
-bf 3 -max_frame_size 40000 -vframes 100 -y ./max_frame_size.h264
Max frame size was enabled since VA-API version (0, 33, 0), but query
is available since (1, 5, 0). It will be passed as a parameter in picParam
and should be set for each frame.
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Normally, both the source and dest frame would have only the old API fields
set, only the new API fields set, or both set. But in some cases, like when
calling av_frame_ref() using a non reference counted source frame where only
the old channel layout API fields were populated, the result would be the dst
frame having both the new and old fields populated.
This commit takes this into account and fixes the checks by calling
av_channel_layout_compare() only if the source frame has the new API fields
set, and doing sanity checks for the source frame old API fields if the new
ones are not set.
Signed-off-by: James Almer <jamrial@gmail.com>
On macOS, code-signing information for executables (including those signed
automatically by the linker) is cached by the system on a per-inode basis.
The cp(1) tool will truncate and overwrite an existing file if present,
so we need to delete it first to avoid strange crashes.
See https://developer.apple.com/documentation/security/updating_mac_software
The VideoToolbox hwaccel needs the entire NAL (including the stop bit),
but ff_h2645_packet_split may remove it. Detect this case by looking for
bit counts divisible by 8 and insert a stop-bit-only 0x80 byte.
Signed-off-by: rcombs <rcombs@rcombs.me>
This commit moves some of the functionality from avfilter/colorspace
into avutil/csp and exposes it as a public API so it can be used by
libavcodec and/or libavformat. It also converts those structs from
double values to AVRational to make regression testing easier and
more consistent.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
libaom added an usage=allintra mode for doing better with still
images. Expose that in the ffmpeg's wrapper. This is especially
useful for encoding still AVIF images.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The cue_sheet.wv sample contains a cue sheet as APE tags,
yet this is not really covered by fate-wavpack-cuesheet
because the metadata does not affect the output of said test.
So add a proper test for this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use the md5 protocol instead of creating a file just to calculate
its MD5 checksum. This is possible because there are no output seeks
involved in any of these tests.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
av_channel_layout_copy() will uninit the dst channel layout
before copying the new one.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
log2() remains, this can either be replaced by a integer implementation or the table
hardcoded if needed
Tested-by: Anton Khirnov <anton@khirnov.net>
Tested-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The dlopen wrapper contains code to make loading libraries safer,
to avoid loading a potentially malicious DLL with the same name.
Signed-off-by: Martin Storsjö <martin@martin.st>
This patch adds code to support specializations of the hscale function
and adds a specialization for filterSize == 4.
ff_hscale8to15_4_neon is a complete rewrite. Since the main bottleneck
here is loading the data from src, this data is loaded a whole block
ahead and stored back to the stack to be loaded again with ld4. This
arranges the data for most efficient use of the vector instructions and
removes the need for completion adds at the end. The number of
iterations of the C per iteration of the assembly is increased from 4 to
8, but because of the prefetching, there must be a special section
without prefetching when dstW < 16.
This improves speed on Graviton 2 (Neoverse N1) dramatically in the case
where previously fs=8 would have been required.
before: hscale_8_to_15__fs_8_dstW_512_neon: 1962.8
after : hscale_8_to_15__fs_4_dstW_512_neon: 1220.9
Signed-off-by: Jonathan Swinney <jswinney@amazon.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
When target levels are set, this patch checks whether they are
satisfied by libaom. If not, a warning is shown. Otherwise the output
levels are also logged.
This patch applies basically the same approach used for libvpx.
Signed-off-by: Bohan Li <bohanli@google.com>
Signed-off-by: James Zern <jzern@google.com>
The doc says those function are like av_free if size or nmemb is
zero. It doesn't match the code. av_realloc() realloc one byte if
size is zero, which was added by 91ff05f6ac ten years ago.
realloc() itself in C is implementation-dependent. Make the doc
match the longstanding behaviour.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Allows non-UWP builds of FFmpeg with MediaFoundation to work on
N editions of Windows which are without MediaFoundation by default.
On UWP target, FFmpeg is linked directly against MediaFoundation since
LoadLibrary is not available.
This commit adresses https://trac.ffmpeg.org/ticket/9788
Signed-off-by: Martin Storsjö <martin@martin.st>
libmfx 1.28 was released 3 years ago, it is easy to get a greater
version than 1.28. We may remove lots of compile-time checks if adding
the requirement for the minimal version in the configure script.
Reviewed-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
vp9, hevc, avc, mpeg2 QSV encoders inherit common list
of options (QSV_COMMON_OPTS) while bunch of options is not
actually supported by current qsv code. The only codec which
supportes everything is avc, followed by hevc, while vp9 and
mpeg2 significantly fall behind. This creates difficulties
for the users to use qsv encoders. This patch fixes options
list for encoders leaving only those which are actually
supported.
Signed-off-by: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
The HEVC decoder can call these functions with smaller widths than the
functions themselves are designed to operate on so we should only check
the relevant output
Signed-off-by: J. Dekker <jdek@itanimul.li>
The SAO band filter can be called with non-multiples of 8, we round up
to the nearest multiple of 8 to account for this.
Signed-off-by: J. Dekker <jdek@itanimul.li>
This commit removes the ineffective FF_MPV_DEPRECATED_ options,
namely mpeg_quant (this is only an option for MPEG-4), a53cc
(this is only an option for MPEG-2), force_duplicated_matrix
(applies only to MJPEG) and b_strategy, b_sensitivity and brd_scale
(these options only make sense for encoders supporting B-frames,
which currently means the MPEG-1/2 and MPEG-4 encoders).
Given that these options never changed the outcome of encoding,
they are removed at once.
Notice that the options for the encoders for which it made sense
are not affected by this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(M)JPEG does not use motion estimation/motion vectors at all.
These options therefore don't affect the output at all.
So remove them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The user-provided value is overwritten in ff_mpv_encode_init()
without having ever been read.
(This has been broken when making these options mpegvideo-specific
in commits 910247f172 and
cf7d2f2d21. No one has ever complained,
so this commit removes these fields.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Currently, ff_frame_thread_free() uses the last worker thread
to updates the first worker thread via update_context_from_thread()
immediately before freeing all these worker threads. This is
a remnant of the time in which the first worker was special.
(E.g. the first worker shared its AVCodecInternal with the public
AVCodecContext.)
But these times are over (none of the uses of is_copy matter
for ff_frame_thread_free()); nowadays the only thing that
update_context_from_thread() does is referencing a few
buffers/frames and replacing them with other references instead.
These new references will then be freed immediately thereafter
when the first worker thread is freed. Ensuring that the code is
free of double-frees is achieved by using reference-counted structures
(or in case of AVChannelLayouts: by giving each worker its own copy).
Some archaeology:
a) Updating the first worker thread from the last one used
has been done since frame-threading was added in
37b00b47cb.
b) The precursor to ff_mpv_common_end() checked for is_copy
before freeing pictures (i.e. it only freed them for the first
worker thread).
c) Commits c2dfb1e37c and
e33811bd26 modified the
update_thread_context function of the H.264 decoder
so that it could fail before calling ff_mpeg_update_thread_context().
d) This led to a double free/an assert violation with a H.264
sample for which ff_mpeg_update_thread_context() is not reached
for the final update_context_from_thread(). Commit
a6e4796fbf added code to fix this
sample.
e) This issue was fixed (even with the last mentioned commit reverted)
when the H.264 decoder was deMpegEncContextized in commit
b7fe35c9e5 (merging commit
2c54155407).
f) mpegvideo.c stopped using is_copy when it was switched to refcounted
frames in 759001c534.
g) 1f4cf92cfb removed the init_thread_copy
callbacks; now no FFCodec.close callback checks for is_copy at all
any more.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Currently, $(CPPFLAGS) and $(CFLAGS) are prepended to CXXFLAGS
(the flags for compiling C++) like this:
CXXFLAGS := $(CPPFLAGS) $(CFLAGS) $(CXXFLAGS)
Using ":=" creates a simply expanded variable, i.e. the values
of the variable at the time of assignment are used and later
modifications to them are ignored (using a recursively expanding
variable (i.e. "=" instead of ":=") is not really possible here,
as there would be an infinite loop when evaluating CXXFLAGS).
Yet we perform later additions to CPPFLAGS: HAVE_AV_CONFIG_H and
BUILDING_libfoo are defined. These do not reach C++ compilations.
To fix this a trick is employed to prepend to a recursively
expanded variable while keeping it recursively expanded.
There are two practical consequences of this: C++ files now no longer
include the version.h header, but only the version_major.h header
of their library, saving some recompilations. Furthermore, they
now get some optimized math functions (namely the ones from
lavu/intmath.h instead of the ones from lavu/common.h).
(av_parity() is the only one for which it makes a difference.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is a more appropriate place for this code, since the values we read
from AV_PKT_DATA_QUALITY_STATS side data are primarily written into
video stats. This ensures that the values written into stats actually
apply to the right packet.
Rename the function to update_video_stats() to better reflect its new
purpose.
It retrieves libavformat's internal dts value (contrary to the
function's name), which is not only incorrect in general, but also
unnecessary because we can access the packet directly.
Its use for muxing is not documented, in practice it is incremented per
each packet successfully passed to the muxer's write_packet(). Since
there is a lot of indirection between ffmpeg receiving a packet from the
encoder and it actually being written (e.g. bitstream filters, the
interleaving queue), using nb_frames here is incorrect.
Add a new counter for packets received from encoder instead.
The top/bottom of the barrel are each coded as two semicircles inside a
square block in the frame. Mask out the parts of the square that lie
outside of these semicircles, so they are made transparent when
alpha_mask=1.
Fixes the other part of #9725.
enc_dec() performs two ffmpeg runs - the first one encoding a source
file into a specified output format, the second one decoding previously
encoded file.
The arguments to this function currently have confusing names - e.g.
dec_opt contains _output_ (i.e. encoding) options for the second
(decoding) ffmpeg invocation. It is also possible to supply _input_
(i.e. decoding) options for the second ffmpeg run, but the argument
is currently unnamed and referred to by number.
Add an _in/_out suffix to argument names to make it clear what they are
used for. Give a name to input options for the decoding ffmpeg run.
has_b_frames should be output_reorder_delay field in AVS3 sequence
header and larger than 1. The parser implementation doesn't parse
that field. Decoder can set has_b_frames properly, so use FFMAX
here to avoid resetting has_b_frames from output_reorder_delay to 1.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Unify file access operations by replacing usages of direct calls
to posix fopen() to prepare for long filename support on Windows.
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Unify file access operations by replacing usages of direct calls
to posix fopen() to prepare for long filename support on Windows.
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Since every DLL can use an individual CRT on Windows, having
an exported function that opens a FILE* won't work if that
FILE* is going to be used from a different DLL (or from user
application code).
Internally within the libraries, the issue can be worked around
by duplicating the function in all libraries (this already happened
implicitly because the function resided in file_open.c) and renaming
the function to ff_fopen_utf8 (so that it doesn't end up exported from
the DLLs) and duplicating it in all libraries that use it.
This makes the avpriv_fopen_utf8 / ff_fopen_utf8 function work in
the exact same way as the existing avpriv_open / ff_open, with the
same setup as introduced in e743e7ae6e.
That mechanism doesn't work for external users, thus deprecate the
existing function.
Signed-off-by: Martin Storsjö <martin@martin.st>
Provide a header based inline reimplementation of it.
Using av_fopen_utf8 doesn't work outside of the libraries when built
with MSVC as shared libraries (in the default configuration, where
each DLL gets a separate statically linked CRT).
Signed-off-by: Martin Storsjö <martin@martin.st>
In d3d11va_create_staging_texture(), during the hwmap process, the
ctx->internal->priv is not initialized, resulting in the
texDesc.Format not initialized. Now pass the format value from
d3d11va_transfer_data() to fix it.
$ ffmpeg.exe -y -hwaccel qsv -init_hw_device d3d11va=d3d11 \
-init_hw_device qsv=qsv@d3d11 -c:v h264_qsv \
-i input.h264 -vf "hwmap=derive_device=d3d11va,format=d3d11,hwdownload,format=nv12" \
-f null -
Reviewed-by: Soft Works <softworkz@hotmail.com>
Signed-off-by: Tong Wu <tong1.wu@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
When the SLOW_GATHER flag was added to the AVX2 version, this
made FMA3-features not enabled on Zen CPUs.
As FMA3 adds 6-7% across all platforms that support it, in
the interest of saving space, this commit removes the AVX
version and replaces it with an FMA3 version.
The only CPUs affected are Sandy Bridge and Bulldozer, which
have AVX support, but no FMA3 support.
In the future, if there's a demand for it, a version of the
function duplicated for AVX can be added.
Instead of having a fixed -64 prio penalty, make the penalties
more granular.
As the prio is based on the register size in bits, decrementing
it by 129 makes AVX SLOW functions be avoided in favor of any
SSE versions.
This reverts commit 82a68a8771.
Smarter slow ISA penalties makes gathers still useful.
The intention is to use gathers with the final stage of non-ptwo iMDCTs,
where they give benefit.
Do this by making this test a transcode test.
Also fix the test requirements and don't add this test to FATE_AFILTER;
instead use a new variable and a new target for flvenc-tests.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also add a fate-filter-overlays target containing all these tests
and fix the requirements of the tests; furthermore, remove
unnecessary scale filters from filter-overlay-rgba?_rgba.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also fix the requirements of these tests: Only the anaglyph
tests need a scale filter, yet it has been inserted for all tests
without any check for its presence.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Lots of tests use the framecrc command together with some filters,
so adding a special function for it seems worthwhile. This commit
adds one new one and modifies an already existing one:
All users of FILTERDEMDEC already use framecrc and the more general
FILTERDEMDECENCMUX can be used in scenarios where more control over
the used encoders/muxers is needed, so use this in cases where
an actual input file is involved.
Furthermore, add FILTERFRAMECRC for the cases where no demuxing/decoding
occurs, because the input is generated via lavfi.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is unused and given that one needs an encoder to produce
packets from AVFrames (as output by filters) this is likely
to remain so, because FILTERDEMDECENCMUX is better for these
scenarios.
The only case where one can use filters without encoders is
with the lavfi input device: It outputs AVPackets which could
be copied without another conversion to AVFrames. Yet the variable
to check for this is CONFIG_LAVFI_INDEV, but FILTERDEMDECMUX
is designed to work with demuxers (i.e. CONFIG_*_DEMUXER).
So there is no usecase for FILTERDEMDECMUX.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Its performance loss ranges from either being just as fast as individual loads
(Skylake), a few percent slower (Alderlake), 8% slower (Zen 3), to completely
disasterous (older/other CPUs).
Sadly, gathers never panned out fast on x86, even with the benefit of time and
implementation experience.
This also saves a register, as there's no need to fill out an additional
register mask.
Zen 3 (16384-point transform):
Before: 1561050 decicycles in av_tx (fft), 131072 runs, 0 skips
After: 1449621 decicycles in av_tx (fft), 131072 runs, 0 skips
Alderlake:
2% slower on big transforms (65536), to 1% (131072), to a few percent for smaller
sizes.
ERContext currently has an embedded MECmpContext, despite only
needing exactly one function from it. This is wasteful because
MECmpContext is pretty large (135 pointers, 1080 B for eight byte
pointers). So keep only what is needed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add support for AVIF muxing in the image2 muxer.
Tested with this example:
ffmpeg -lavfi testsrc=duration=1:size=320x320 -g 1 -flags global_header -c:v libaom-av1 -f image2 img-%2d.avif
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
av_dict_set() expects a different set of flags, namely the AV_DICT_*
flags. Using AV_OPT_FLAG_DECODING_PARAM (or any AV_OPT_FLAG_*) ic
av_dict_set() is therefore completely wrong and given that av_dict_set()
just doesn't care about whether the string it receives has anything
to do with a decoding parameter or not, it should just be removed
without replacement.
(The numerical value of AV_OPT_FLAG_DECODING_PARAM currently coincides
with AV_DICT_IGNORE_SUFFIX. Given that the dictionaries we are dealing
with here are always empty (i.e. NULL) before the calls to
av_dict_set(), this flag changes nothing. It would be different if
it were equal to one of the AV_DICT_DONT_STRDUP_* values.)
Reviewed-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Move AC3HeaderInfo into ac3_parser_internal.h and the rest
into a new header ac3defs.h.
This also breaks an include cycle of ac3.h and ac3tab.h
(the latter now only needs ac3defs.h).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add an AVIF muxer by re-using the existing the mov/mp4 muxer.
AVIF Specification: https://aomediacodec.github.io/av1-avif
Sample usage for still image:
ffmpeg -i image.png -c:v libaom-av1 -still-picture 1 image.avif
Sample usage for animated AVIF image:
ffmpeg -i video.mp4 animated.avif
We can re-use any of the AV1 encoding options that will make
sense for image encoding (like bitrate, tiles, encoding speed,
etc).
The files generated by this muxer has been verified to be valid
AVIF files by the following:
1) Displays on Chrome (both still and animated images).
2) Displays on Firefox (only still images, firefox does not support
animated AVIF yet).
3) Verified to be valid by Compliance Warden:
https://github.com/gpac/ComplianceWarden
Fixes the encoder/muxer part of Trac Ticket #7621
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Add a parameter to omit seq header when generating the av1C atom.
For now, this does not change any behavior. This will be used by a
follow-up patch to add AVIF support.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Add a parameter to libaom-av1 encoder to enforce some of the single
image constraints in the AV1 encoder. Setting this flag will limit
the encoder to producing exactly one frame and the sequence header
that is produced by the encoder will be conformant to the AVIF
specification [1].
Part of Fixing Trac ticket #7621
[1] https://aomediacodec.github.io/av1-avif
Signed-off-by:: Vignesh Venkatasubramanian <vigneshv@google.com>
Fix ticket: 9238
In parse_playlist, the discont_program_date_time should be used after
EXT-X-PROGRAM-DATE-TIME tag parsed.
Tested-by: pero
Reviewed-by: Zhao Zhili <zhilizhao@tencent.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
The general demuxing API uses bitstream filters to extract extradata
and the muxing API uses them in order to transform packets into
the format desired by the target format. Therefore FFStream contains
pointers to AVBSFContexts and lavf/internal.h includes lavc/bsf.h.
Yet actually, only a few files files are supposed to use these,
namely avformat.c, demux.c and mux.c. For all the other files,
it should be an opaque type that they should not touch and that
they need not know anything about. This can be achieved by not
including these headers and using the structs instead of the
corresponding typedefs.
This also forces translation units that really use the BSF API
themselves to include lavc/bsf.h directly instead of relying on
indirect inclusions (a few other files also use the BSF API;
they already abided by this).
Of course, it also avoids unnecessary rebuilds when bsf.h changes.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The general decoding API uses bitstream filters and an AVFifo
and therefore AVCodecInternal contains pointers to an AVBSFContext
and to an AVFifo and lavc/internal.h includes lavc/bsf.h and
lavu/fifo.h.
Yet actually, only two files are supposed to use these, namely
avcodec.c and (mainly) decode.c. For all the other files,
it should be an opaque type that they should not touch and that
they need not know anything about. This can be achieved by not
including these headers and using the structs instead of the
corresponding typedefs.
This also forces translation units that really use the BSF
and the FIFO APIs themselves to include the relevant headers
directly instead of relying on indirect inclusions (up until now,
even avcodec.c and decode.c relied on fifo.h to be included
by internal.h).
Of course, it also avoids unnecessary rebuilds when bsf.h or fifo.h
change.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Left shifts of signed types are UB unless the results fit
into the type. (Furthermore the value to be shifted need to be
nonnegative.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
sdl2 recently changed their versioning, moving the patch level to minor level
cd7c2f1de7
and have said that they will instead ship sdl3.pc for 3.0.0
Fixes ticket 9768
Signed-off-by: Christopher Degawa <ccom@randomderp.com>
Signed-off-by: Gyan Doshi <ffmpeg@gyani.pro>
Several encoders (roqvideo, svq1, snow, and the mpegvideo family)
currently call ff_get_buffer(). However this function is written
assuming it is called by a decoder. Though nothing has been obviously
broken by this until now, that may change in the future.
To avoid potential future issues, introduce a simple encode-specific
wrapper around avcodec_default_get_buffer2() and enforce its use in
encoders.
av_get_pix_fmt_name() is used in an ff_tlog(), which is only
compiled if TRACE is defined. Fixes a regression caused by
f2b79c5b85.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Required to remux m2ts to mkv
Minor changes and porting to FFBitStreamFilter done by the committer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
An auxiliary function for AVFormatContexts (mainly muxers,
but potentially (e.g. rtsp) also demuxers).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only used by demuxers (and it is generally demuxers
who have to translate format-specific IDs to stream indices).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They are also needed by the MMSH and MMST protocols and therefore
the file they are in is pulled in when these protocols are enabled
and used. By moving them to a separate file, linking statically to
libavformat while only using AVIO no longer pulls in all the
muxers/demuxers (and also no longer any AVCodecs when linking
statically to libavcodec).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is not forbidden to call this with a muxer, so it is moved to
avformat.c and not demux_utils.c. ff_find_decoder(), which is used
by av_find_best_stream() is also moved as well, despite being even
more geared towards demuxers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
While it is clearly written with demuxers in mind,
it is not forbidden to call it with muxers, hence avformat.c
and not demux_utils.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is not explicitly forbidden to call these functions with muxers
(although it is probably intended to be only called by demuxers;
av_guess_sample_aspect_ratio even says that "the stream aspect ratio
is set by the demuxer").
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is not to call this with a muxer, so move it to avformat.c
and not demux_utils.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This file will contain the AVFormatContext-specific parts
that are used by both demuxers and muxers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only used by demuxers (although it is hypothetically
possible that some day e.g. a protocol might need it, but
that is unlikely given that they don't deal with AVCodecParameters).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is demuxer-only: It potentially adds an AVStream and it sets
AVStream.attached_pic.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This function is only intended for demuxers (as calling it doesn't
have any observable effect for a muxer).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is demuxer-only: Muxers deal only with chapters given to them;
they don't create any of their own.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This file is both for the various public APIs that are demuxer-only
as well as for the demuxer-only internal functions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_get_packet_palette() and ff_reshuffle_raw_rgb() belong together:
E.g. the former takes the return value of the latter as argument.
So move ff_get_packet_palette() to rawutils.c (which consists solely
of ff_reshuffle_raw_rgb()).
Also add a separate header for these two functions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only used by muxers. Given that it is not part of
the core muxing code and given that mux.c is already big enough,
it is moved to a new file for utility functions for muxing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is the appropriate place given that AVStream is about to
become an AVOpt-enabled struct.
Also move av_disposition_(to|from)_string, as these are tied
to the disposition stream option.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also improve the size check a bit; given that av_realloc_array()
checks for overflow itself, we only have to check for
nb_side_data + 1 still being representable in an int.
But given that we can check for representability in size_t
at no additional cost we do so as it leads to a nicer error code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids having to rebuild big files every time FFMPEG_VERSION
changes (which it does with every commit).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This way values such as maxrate/bufsize can be utilized further
down the chain.
First, syncs up the max_rate and buffer_size from SVT-AV1 back to
avctx, and then in case at least one of the utilized values is
nonzero, adds the CPB properties side data.
This way we can filter out the default value for this member, which
is nonzero. Bases on the current affairs that bit rate based rate
control is nonzero in SVT-AV1.
filter-pp and filter-pp7 are the only ones of the filter-pp* tests
that use the file generated by fate-vsynth1-mpeg4-qprd.
Also combine the dependency on this test for all the tests that need it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fix ticket: 9010
there have been get http/https shutdown status in ffurl_shutdown.
so unnecessary http/https shutdown status operate.
Tested-by: RytoEX
Tested-by: ushadow
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
These are actually null statements here and therefore lead
to -Wdeclaration-after-statement warnings.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The temporary fate-lavf files can easily be removed
if they are not needed as inputs for other tests (mainly
fate-seek-tests). This commit implements this.
The size of the remaining files decreases from 260890083B
to 79481793B.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Extend the ordinary mechanism to signal KEEP for this.
This also allows to remove the keep-parameter from enc_dec,
transcode and stream_remux, so that several empty parameters
'""' could be removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These CRC-only files (the output of the CRC-muxer) are only used once,
so they need not be preserved. Furthermore, errors from ffmpeg (used
for creating the CRC) are no longer ignored with this patch.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The output of this test is just a file containing the positions
of peaks; it is not a wave file and trying to demux it just
returns AVERROR_INVALIDDATA; said error has just been ignored
as the return value from do_avconv_crc is the return value from echo.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This removes a dependency of checkasm on lavc/v210_enc.o
and also allows to inline ff_v210enc_init() irrespectively of
interposing.
This dependency pulled basically all of libavcodec into checkasm,
in particular all codecs.
This also makes checkasm work when using shared Windows builds:
On Windows, it needs to be known to the compiler whether a data
symbol is external to the library/executable or not; hence the
need for av_export_avutil. checkasm needs access to the internals
of the libraries it tests and is therefore linked statically to all
the libraries. This means that the users of avpriv_cga_font and
avpriv_vga16_font in libavcodec (namely ansi.o, bintext.o, tmv.o)
end up in the same executable as the symbols, although they have
been compiled as if these symbols were external, leading to linker
errors. With this commit said files are discarded by the linker,
bypassing this problem.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This removes a dependency of checkasm on lavc/v210_dec.o
and also allows to inline ff_v210dec_init() irrespectively of
interposing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This removes a dependency of checkasm on lavfi/vf_threshold.o
and also allows to inline ff_threshold_init() irrespectively of
interposing.
With this patch checkasm no longer pulls all of lavfi and lavf in.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This removes a dependency of checkasm on lavfi/vf_nlmeans.o
and also allows to inline ff_nlmeans_init() irrespectively of
interposing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This removes a dependency of checkasm on lavfi/vf_hflip.o
and also allows to inline ff_hflip_init() irrespectively of
interposing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This removes a dependency of checkasm on lavfi/vf_gblur.o
and also allows to inline ff_gblur_init() irrespectively of
interposing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This removes a dependency of checkasm on lavfi/vf_eq.o
and also allows to inline ff_eq_init() irrespectively of
interposing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This removes a dependency of checkasm on lavfi/vf_blend.o
and also allows to inline ff_blend_init() irrespectively of
interposing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This allows to inline it in af_afir.c (regardless of interposing);
moreover it removes a dependency of the checkasm test on
lavfi/af_afir.o.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only the AudioFIRDSPContext and the functions for its initialization
are needed outside of lavfi/af_afir.c.
Also rename the header to af_afirdsp.h to reflect the change.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_codec_get_id loops over ff_codec_movvideo_tags (which is a large
array) two times. The result is unused most of the cases.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
It seems as if it was intended to declare fate-gif-color as prerequisite
of the fate-gifenc% tests. Yet the latter do not need anything from
the former, so this would be unnecessary. Furthermore, given that this
line has no associated recipe, it actually cancels implicit rules for
fate-gifenc% instead of adding a prerequisite.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These tests have basically nothing to do with VPX (they do not even
require the decoder).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add options to h264, hevc and prores encoders to prioritize speed.
Speeds up encoding by 50% - 70%
Signed-off-by: Simone Karin Lehmann <simone@lisanet.de>
Signed-off-by: Rick Kern <kernrj@gmail.com>
supports forcing or disabling the writing of the btrt atom.
the default behavior is to write the atom only for mp4 mode.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Previously, the default timebase caused two warnings during decoding about not being able to update timestamps for skipped and discarded samples, respectively.
Signed-off-by: Andreas Unterweger <dustsigns@gmail.com>
The last encoded frame is now fetched on EOF. It was previously left in the encoder and caused a "1 frame left in queue" warning.
Signed-off-by: Andreas Unterweger <dustsigns@gmail.com>
Issue: On extremely new hardware using either IceLake or super sets of
Intel IceLakes avx512 instructions, commit
d4cd8830bd causes build issues.
Specifically a NASM macro expansion of qpel_filter_v is never properly
defined/initialized.
The issue is the definition was erroneously placed inside a conditional
which will not trigger unless the original definition failed (has to do
with if PIC is defined, becomes a bit of a catch 22)
Specifically the error is
X86ASM libavcodec/x86/hevc_mc.o
libavcodec/x86/hevc_mc.asm:1854: error: symbol `..@88472.table' not defined
libavcodec/x86/hevc_mc.asm:1806: ... from macro
`HEVC_PUT_HEVC_QPEL_HV_AVX512ICL' defined here
libavcodec/x86/hevc_mc.asm:1730: ... from macro `QPEL_FILTER_V' defined here
...
repeats a few times...
...
make: *** [ffbuild/common.mak💯 libavcodec/x86/hevc_mc.o] Error 1
```
Specific error was discussed by kurosu and myself (fclc) on the
ffmpeg-devel irc.
This commit fixes the above by swapping lines 1796 and 1795, moving the
define out of the conditional
Side note: It seems fate didn't pick up on this, may merit looking into
(as mentioned by nevcairiel).
Reviewed-by: Wu Jianhua <toqsxw@outlook.com>
Signed-off-by: Felix LeClair (FCLC) <felix.leclair123@hotmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
In particular remove config_components.h in order to avoid unnecessary
rebuilds.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The tests in concatdec.mak reuse files created by tests
from lavf-container. Therefore these tests have the other tests
as prerequisite and mostly duplicate their CONFIG-requirements.
(The mxf_d10 tests did it incorrect as they only required
the MXF muxer.) This duplication is of course bad as usual,
so stop it by using the corresponding variable
that contains the non-lavf-container-tests that are enabled
to filter out all the concat-tests without a corresponding enabled
non-concat test.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These changes are automatically inherited by the fate-seek-tests
based upon lavf-audio.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The new requirements are also automatically inherited
by the FATE_SEEK_LAVF_VIDEO seek-tests.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This automatically fixes the requirements of the fate-seek-acodec*
tests (e.g. 16 of the 27 such tests are now automatically disabled
if the aresample filter is disabled).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This automatically fixes the requirements of the fate-seek-vsynth*
tests (e.g. 16 of the 49 such tests are now automatically disabled
if the scale filter is disabled).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If one uses a -s command, a scale filter is inserted
even when doing so is redundant. This patch stops
doing so. This makes the tests that don't need libswscale
actually succeed in case it is disabled (only 315 of 470 tests
need it).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Most of the tests in seek.mak use files created by other tests
as input. Therefore these tests have the other tests as prerequisite
and duplicate their CONFIG-requirements. This duplication is of course
bad as usual, so stop it by using the corresponding variable
that contains the non-seek-tests that are enabled to filter out all
the seek-tests without a corresponding enabled non-seek test.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The output files of the lavf tests are highly regular,
allowing to use rules for the src files instead of a list.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Each of the intermediately generated lena-*.fits files is only used
for exactly one test; so it could be deleted right after the test.
Switching to a transcode test (which is also more natural) achieves
this. It also adds checksums of the intermediate files to the ref-file.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In particular, add the missing dependency on the scale and
aresample filters (and therefore on libswscale resp. libswresample).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In particular, add the missing dependency on the scale filter
(and therefore on libswscale).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Intended for scenarios that currently use DEMDEC, but are missing
the requirements that are implicitly needed by framecrc.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add a parameter that allows to add additional requirements.
Also add FILE_PROTOCOL to all the auxiliary functions
that use a demuxer.
Also fix the requirements for the fate-mpegts-probe-(latm|program)
tests. They have misused DEMDEC.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In particular, add the missing dependency on the scale filter
(and therefore on libswscale).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also fix the requirements of fate-mov-channel-description:
It needs the pcm_s16le decoder and the mov demuxer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
And drop the FATE_CAF_REMUX variables which only existed
to avoid having to repeat the common FILE_PROTOCOL PIPE_PROTOCOL
FRAMECRC_MUXER stuff.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This decoder uses ff_get_buffer() and does nothing weird
(it does not even rely on any alignment of the frame's data/linesize).
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Both AV_PIX_FMT_GRAY8 and AV_PIX_FMT_GRAY16 use unsigned values,
not signed ones. The fact that the input might be signed
in some cases in the original format doesn't change this.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The PGX decoder accesses the lines via code like
(PIXEL*)frame->data[0] + i*frame->linesize[0]/sizeof(PIXEL)
where PIXEL is a macro parameter. This code has issues with negative
linesizes, because the type of sizeof(PIXEL) is size_t, so
that on common systems i*linesize/sizeof(PIXEL) will
always be an unsigned type that is very large in case linesize is
negative. This happens to work*, but it is undefined behaviour
and e.g. leads to "src/libavcodec/pgxdec.c:114:1: runtime error:
addition of unsigned offset to 0x7efe9c2b7040 overflowed to 0x7efe9c2b6040"
errors from UBSAN.
Fix this by using (PIXEL*)(frame->data[0] + i*frame->linesize[0]).
This is allowed because linesize has to be suitably aligned.
*: Converting a negative int to size_t works by adding SIZE_MAX + 1
to the number, so that the result is off by (SIZE_MAX + 1) /
sizeof(PIXEL). Converting the pointer arithmetic (performed on PIXELs)
back to ordinary pointers is tantamount to multiplying by sizeof(PIXEL),
so that the result is off by SIZE_MAX + 1; but SIZE_MAX + 1 == 0
for the underlying pointers.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These checks were (most likely) added to check for overreads
as the bytestream2_get_* functions return 0 in this case.
Yet this is not necessary anymore as we now have an explicit check
for the size. Should the input contain a real \0, pgx_get_number()
will error out lateron.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Each of the three calls to pgx_get_number() consumes at least two bytes.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
- certs.h is gone. Only contains test data, and was not used at all.
- config.h is renamed. Was seemingly not used, so can be removed.
- MBEDTLS_ERR_SSL_NO_USABLE_CIPHERSUITE is gone, instead
MBEDTLS_ERR_SSL_HANDSHAKE_FAILURE will be thrown.
- mbedtls_pk_parse_keyfile now needs to be passed a properly seeded
RNG. Hence, move the call to after RNG seeding.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
The stsc_index is checked and updated for the next sample. If the
next sample needs to update stsd_index and stsc_index, then only
stsc_index is updated, which leads to a missing
AV_PKT_DATA_NEW_EXTRADATA. For example, the sample in the second
chunk needs to update both.
entry[0]
first_chunk = 1
samples_per_chunk = 3
sample_description_index = 1
entry[1]
first_chunk = 2
samples_per_chunk = 1
sample_description_index = 2
entry[2]
first_chunk = 3
samples_per_chunk = 8
sample_description_index = 2
The fix is simple: first check and update stsd_index for current
sample, then check and update stsc_index for the next.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
This patch fixes a wrong type of BTI landing pad when branching to
functions instantiated via the fft*_neon macro.
Although the previously employed paciasp instruction serves as a landing
pad, for the ways that this function is invoked it is the wrong type, resulting
in an unexpected termination of the running process.
Signed-off-by: André Kempe <andre.kempe@arm.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
match the behavior of SvtAv1EncApp to ensure pic_type is always set
before passing it to the library.
The other options for pic_type aren't currently used inside the library,
so they aren't introduced in this patch.
Signed-off-by: Christopher Degawa <ccom@randomderp.com>
Signed-off-by: James Almer <jamrial@gmail.com>
AVIF still and animations are now supported by the MOV parser.
Add the "avif" extension to the list of supported extensions to
AVInputFormat.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Monterey needs mBytesPerFrame and mBytesPerPacket to be set, and I'm
surprised this didn't break any previous system versions.
Fixes bug #9564: Cannot decode xHE-AAC with audiotoolbox (aac_at) on
Mac OS Monterey. Fixes likely bug that none of the AudioToolbox
decoders work on Monterey.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
This filter is designed to parse embedded ICC profiles and attempt
extracting colorspace tags from them, updating the AVFrame metadata
accordingly.
This is intentionally made a separate filter, rather than being part of
libavcodec itself, so that it's an opt-in behavior for the time being.
This also gives the user more flexibility to e.g. first attach an ICC
profile and then also set the colorspace tags from it.
This makes #9673 possible, though not automatic.
Signed-off-by: Niklas Haas <git@haasn.dev>
This filter is designed to specifically cover the task of generating ICC
profiles (and attaching them to output frames) on demand. Other tasks,
such as ICC profile loading/stripping, or ICC profile application, are
better left to separate filters (or included into e.g. vf_setparams).
Signed-off-by: Niklas Haas <git@haasn.dev>
This introduces an optional dependency on lcms2 into FFmpeg. lcms2 is a
widely used library for ICC profile handling, which apart from being
used in almost all major image processing programs and video players,
has also been deployed in browsers. As such, it's both widely available
and well-tested.
Add a few helpers to cover our major use cases. This commit merely
introduces the helpers (and configure check), even though nothing uses
them yet.
It's worth pointing out that the reason the cmsToneCurves for each
AVCOL_TRC are cached inside the context, is because constructing a
cmsToneCurve requires evaluating the curve at 4096 (by default) grid
points and constructing a LUT. So, we ideally only want to do this once
per curve. This matters for e.g. ff_icc_profile_detect_transfer, which
essentially compares a profile against all of these generated LUTs.
Re-generating the LUTs for every iteration would be unnecessarily
wasteful.
The same consideration does not apply to e.g. cmsCreate*Profile, which
is a very lightweight operation just involving struct allocation and
setting a few pointers.
The cutoff value of 0.01 was determined by experimentation. The lowest
"false positive" delta I saw in practice was 0.13, and the largest
"false negative" delta was 0.0008. So a value of 0.01 sits comfortaby
almost exactly in the middle.
Signed-off-by: Niklas Haas <git@haasn.dev>
Related to #9673, this helper exists to facilitate "guessing" the right
primary tags from a given set of raw primary coefficients.
The cutoff value of 0.001 was chosen by experimentation. The smallest
"false positive" delta observed in practice was 0.023329, while the
largest "false negative" delta was 0.00016. So, a value of 0.001 sits
comfortably in the middle.
Signed-off-by: Niklas Haas <git@haasn.dev>
These are needed beyond just vf_colorspace, so give them a new home in
colorspace.h.
In addition to moving code around, also merge the white point and
primary coefficients into a single struct to slightly increase the
convenience and shrink the size of the new API by avoiding the need
to introduce an extra function just to look up the white point as well.
The only place the distinction matters is in a single enum comparison,
which can just as well be a single memcpy - the difference is
negligible.
Signed-off-by: Niklas Haas <git@haasn.dev>
This patch supports AVIF still images conforming to the
final specification that have exactly one item (i.e. no alpha channel).
The iloc box is parsed and the mov index populated.
Partially fixes#7621.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Gyan Doshi <ffmpeg@gyani.pro>
60 fps content have "Number of Frames" set to 30 in the tmcd atom, but the
frame duration / timescale reflects the original video frame rate.
Therefore we multiply the frame count with the quotient of the rounded timecode
frame rate and the "Number of Frames" per second to get a frame count in the original
(higher) frame rate.
Note that the frames part in the timecode will be in high frame rate which will
make the timecode different to e.g. MediaInfo which seems to show the 30 fps
timecode even for 120 fps content.
Regression since 428b4aacb1.
Fixes ticket #9710.
Fixes ticket #9492.
Signed-off-by: Marton Balint <cus@passwd.hu>
Otherwise its effect might not work causing CPU_COUNT to not get defined.
Fixes cpu count detection to actually use sched_getaffinity if available.
Signed-off-by: Marton Balint <cus@passwd.hu>
This avoids having to do one pass to calculate the full length to allocate
followed by a second pass to actually append values.
Signed-off-by: Martin Storsjö <martin@martin.st>
It also adds the missing depenencies on the file and pipe protocols
and the framecrc muxer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Tests using the transcode and stream_remux functions have some common
requirements (namely the file and pipe protocols as well as the framecrc
muxer) and also other commonalities: The create a file and read it
immediately afterwards, so that they typically rely on a corresponding
muxer+demuxer pair which typically shares the same name; for transcode
(if it does not use stream copy) the same is true for encoders and
decoders. This means that using special Makefile-functions instead
of the general ALLYES is worthwhile. This commit adds such functions.
These functions allow to add arbitrary CONFIG-checks on top of the
aforementioned ones in order to satisfy special needs (for e.g. parsers,
filters) that several intended users have.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The size of the ICC chunk has already been accounted for when
the packet's buffer was initially set in ff_mpv_encode_picture()
and the header (including the ICC chunk) has already been written
at this point.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is a remnant of the old way for user-supplied buffers;
it is always-true since 93016f5d1d.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If one encodes MJPEG with a single slice and uses input with
AV_FRAME_DATA_ICC_PROFILE side data, the current allocation code
in ff_mpv_encode_picture() will always increase the size of the
temporary buffer used for allocating packets by the size needed
for to write the ICC chunk even when the current buffer is actually
large enough. This commit fixes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MJPEG is the only mpegvideo-based encoder making use of it.
Fixes linking failures in case mpegvideo_enc.c is compiled
with AMV, LJPEG and MJPEG encoders disabled.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
PATH_MAX is posix. Some compilers (MSVC) don't define this
thus failing to compile the ipfsgateway file.
Defining it fixes the compile.
Signed-off-by: Mark Gaiser <markg85@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
This field is currently used by checks
- skipping packets before the first keyframe
- skipping packets before start time
to test whether any packets have been output already. But since
frame_number is incremented after the bitstream filters are applied
(which may involve delay), this use is incorrect. The keyframe check
works around this by adding an extra flag, the start-time check does
not.
Simplify both checks by replacing the seen_kf flag with a flag tracking
whether any packets have been output by do_streamcopy().
The width and height for qsv frame to download need to be
aligned with 16. Add the alignment operation.
Now the following command works:
ffmpeg -hwaccel qsv -f rawvideo -s 1920x1080 -pix_fmt yuv420p -i \
input.yuv -vf "hwupload=extra_hw_frames=16,format=qsv,hwdownload, \
format=nv12" -f null -
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Do this by switching to bytestream2_(get|put)_le32u() from
bytestream2_(get|put)_le32(); it has after all already been checked
that the packet contains at least a full header, making all
the implicit checks in bytestream2_(get|put)_le32() dead code.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Therefore move the (Get|Put)ByteContext from the context to the stack.
It is transient anyway.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This patch adds support for:
- ffplay ipfs://<cid>
- ffplay ipns://<cid>
IPFS data can be played from so called "ipfs gateways".
A gateway is essentially a webserver that gives access to the
distributed IPFS network.
This protocol support (ipfs and ipns) therefore translates
ipfs:// and ipns:// to a http:// url. This resulting url is
then handled by the http protocol. It could also be https
depending on the gateway provided.
To use this protocol, a gateway must be provided.
If you do nothing it will try to find it in your
$HOME/.ipfs/gateway file. The ways to set it manually are:
1. Define a -gateway <url> to the gateway.
2. Define $IPFS_GATEWAY with the full http link to the gateway.
3. Define $IPFS_PATH and point it to the IPFS data path.
4. Have IPFS running in your local user folder (under $HOME/.ipfs).
Signed-off-by: Mark Gaiser <markg85@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The lensfun filter, at present, loads its database from a path hardcoded
at build time. This may not be known or available to end users.
Added option db_path allows custom path.
The test also requires a png decoder, which often can be disabled in
cross building setups, where zlib might be missing.
Signed-off-by: Martin Storsjö <martin@martin.st>
SEI messages are naturally byte-aligned by adding padding bits
to achieve byte-alignment. The parsing code in libavcodec/hevc_sei.c
nevertheless uses a GetBitContext to read it. When doing so, parsing
the next SEI message starts exactly at the position where reading
the last message (if any) ended.
This means that one would have to handle both the payload extension data
(which makes most SEI messages extensible structs) as well as the
padding bits for byte-alignment. Yet our SEI parsing code in
libavcodec/hevc_sei.c does not read these at all. Instead several of
the functions used for parsing specific SEI messages use
skip_bits_long(); some don't use it at all, in which case it is possible
for the GetBitContext to not be byte-aligned at the start of the next
SEI message (the parsing code for several types of SEI messages relies
on byte-alignment).
Fix this by always using a dedicated GetBitContext per SEI message;
skipping the necessary amount of bytes in the NALU context
is done at a higher level. This also allows to remove unnecessary
parsing code that only existed in order to skip enough bytes.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is mostly straightforward. The major complication is that, as a
result of the 16-bit chunk size limitation, ICC profiles may need to be
split up into multiple chunks.
We also need to make sure to allocate enough extra space in the packet
to fit the ICC profile, so modify both mpegvideo_enc.c and ljpegenc.c to
take into account this extra overhead, failing cleanly if necessary.
Also add a FATE transcode test to ensure that the ICC profile gets
written (and read) correctly. Note that this ICC profile is smaller than
64 kB, so this doesn't test the APP2 chunk re-arranging code at all.
Signed-off-by: Niklas Haas <git@haasn.dev>
We re-use the PNGEncContext.zstream for deflate-related operations.
Other than that, the code is pretty straightforward. Special care needs
to be taken to avoid writing more than 79 characters of the profile
description (the maximum supported).
To write the (dynamically sized) deflate-encoded data, we allocate extra
space in the packet and use that directly as a scratch buffer. Modify
png_write_chunk slightly to allow pre-writing the chunk contents like
this.
Also add a FATE transcode test to ensure that the ICC profile gets
encoded correctly.
Signed-off-by: Niklas Haas <git@haasn.dev>
max_14bit_constraint_flag should be set if the bit depth is not greater than
14 (currently always true).
one_picture_only_flag should not be set because we don't support the still
picture profiles.
general_profile_compatibility_flag should be set according to general_profile_idc
instead of bit depth.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
The block size can be dependent on the profile and entrypoint selected.
It defaults to 16x16, with codecs able to override this choice with their
own function.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Use GPB frames to replace regular P/B frames if backend driver does not
support it.
- GPB:
Generalized P and B picture. Regular P/B frames replaced by B
frames with previous-predict only, L0 == L1. Normal B frames
still have 2 different ref_lists and allow bi-prediction
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
This will allow using a common threaded decode or encode function from most
codecs using texture DSP functions.
Signed-off-by: Marton Balint <cus@passwd.hu>
On empty input the awk script was always successful which caused the
filter-refcmp tests to always succeed.
Also fix the command lines for refcmp_metadata compare function because it
needs auto conversion filters, and update reference of test
filter-refcmp-psnr-rgb because it was missed in
a7fc78c1a6 but was never noticed due to the
original issue...
Signed-off-by: Marton Balint <cus@passwd.hu>
on glibc memory.h drags in string.h, but codec2 does not use any
str* or mem* functions. additionally, memory.h is not part of the
C99 or POSIX standards.
Signed-off-by: Marton Balint <cus@passwd.hu>
'current_next_indicator' of 0 (next) on each section header indicates
the service information is for immediate future one.
ffmpeg doesn't need to parse it but current (1) one.
ref: section 5.1.1 of DVB BlueBook A038 (EN 300 468)
Signed-off-by: TADANO Tokumei <aimingoff@pc.nifty.jp>
Signed-off-by: Marton Balint <cus@passwd.hu>
Current code incorrectly check against end of section rather than
end of descriptor.
Signed-off-by: TADANO Tokumei <aimingoff@pc.nifty.jp>
Signed-off-by: Marton Balint <cus@passwd.hu>
The guess_palette() implementation is questionable in itself
as its results don't match those from other DVD subtitle decoders.
This commit starts cleanup by fixing an obvious bug which has made
certain DVD subs appear yellow instead of white or grey for more than
10 years..
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: rcombs <rcombs@rcombs.me>
A bug was found in dav1d <= 1.0.0 where the event flag New Sequence Header would
not be signaled for some samples using delayed random access points.
It has since been fixed, but nonetheless it's best to ensure the AVCodecContext
is filled with parameters when parsing the first frame, regardless of what events
were signaled.
Fixes ticket #9694.
Signed-off-by: James Almer <jamrial@gmail.com>
If the svt equivalent option to an avctx AVOption is passed by the user
then it should have priority. The exception are fields like dimensions, bitdepth
and pixel format, which must match what lavc will feed the encoder after init.
This addresses libsvt-av1 issue #1858.
Signed-off-by: James Almer <jamrial@gmail.com>
Qsv encoder only support input P010 and nv12 format directly from system
memory. For other format, we need to upload frame to device memory and
input qsv format to encoder. Now add other system memory format support
to qsv encoder.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Qsv decoder only supports directly output nv12 and p010 to system
memory. For other format, we need to download frame from qsv format
to system memory. Now add other supported format to qsvdec.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
The init_pool_size is set to be 64 and it is too many.
Use IOSurfQuery to get NumFrameSuggest which is the suggested
number of frame that needed to be allocated when initializing the decoder.
Considering that the hevc_qsv encoder uses the most frame buffer,
async is 4 (default) and max_b_frames is 8 (default) and decoder
may followed by VPP, use NumFrameSuggest + 16 to set init_pool_size.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Guangxin Xu <guangxin.xu@intel.com>
Since ffmpeg-qsv uses return value to reinit decoder, it doesn't need to
decode header each time. Move qsv_decode_header's position so that
it will be called only if codec needed to be reinitialized.
Rearrange the code of flushing decoder and re-init decoder operation.
Remove the buffer_count and use the got_frame to decide whether the
decoder is drain.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Guangxin Xu <guangxin.xu@intel.com>
FFmpeg-qsv decoder reinit codec when width and height change, but there
are not only resolution change need to reinit codec. I change it to use
return value from DecodeFrameAsync() to decide whether decoder need to
be reinitialized.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Guangxin Xu <guangxin.xu@intel.com>
Commit e050959103 implemented passing in
modifiers by using the PRIME_2 memory type, which only exists in v2 of
the library.
To still support v1 of the library, conditionally compile using
VA_CHECK_VERSION() for both the new code and the old code before
the commit.
Note PRIME_2 memory was introduced from VA-API 1.1, so use
VA_CHECK_VERSION(1, 1, 0) instead of VA_CHECK_VERSION(2, 0, 0) (Haihao)
Signed-off-by: Ingo Brückl <ib@wupperonline.de>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
In case the BSF has not been drained before flushing/closing,
the context's next_frame might be set; yet it is not freed
in flush or close. The former only zeroes it (which automatically
causes a leak in case it was set). So do this when closing
and flushing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since the switch to the new FIFO API in commit
ea511196a6, the FIFO is always
grown by the amount of data intended to be written into it
even in case the FIFO has enough free space. Fix this by
only growing the FIFO if needed and then only by the amount that is
actually needed.
The allocation errors that resulted from this uncovered another bug:
The context is left in an inconsistent state in case the FIFO can't
be grown, because the FIFO does not contain as much data as the sizes
contained in the PacketDesc list claim. This led to an infinite loop
in output_packet() (called from mpeg_mux_end()).
Fix this by growing the FIFO before adding a new PacketDesc element,
thereby preventing the context from becoming inconsistent.
Reported-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible, because every given FFCodec has to implement
exactly one of these. Doing so decreases sizeof(FFCodec) and
therefore decreases the size of the binary.
Notice that in case of position-independent code the decrease
is in .data.rel.ro, so that this translates to decreased
memory consumption.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This increases type-safety by avoiding conversions from/through void*.
It also avoids the boilerplate "AVFrame *frame = data;" line
for non-subtitle decoders.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This increases type-safety by avoiding conversions from/through void*.
It also avoids the boilerplate "AVSubtitle *sub = data;" line
for subtitle decoders. Its only downside is that it increases
sizeof(FFCodec), yet this can be more than offset lateron.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
On output streams where a multichannel stream needs to be stored as one track
per channel, each track will have a channel layout describing the position of
the channel they contain. For the track with front center, the mov muxer was
using the mov layout "mono" instead of the label for the front center position.
Since our channel layout API considers front center == mono, we need to do some
heuristics. To achieve this, we make sure all audio tracks contain streams with
a single channel, and only one of them is front center. In that case, we write
the front center label instead of signaling mono layout.
Fixes the last part of ticket #2865
Signed-off-by: James Almer <jamrial@gmail.com>
The inputs are unused except for this computation so wraparound
does not give an attacker any extra values as they are already fully
controlled
Fixes: signed integer overflow: 0 - -2147483648 cannot be represented in type 'int'
Fixes: 45820/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-5766159019933696
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -128275513086 * -76056576 cannot be represented in type 'long'
Fixes: 45818/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5129799149944832
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -2146549696 - 3923884 cannot be represented in type 'int'
Fixes: 45907/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5992380584558592
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This makes the filters match their declaration in
libavfilter/allfilters.c; the earlier discrepancy was btw UB.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Calculate Spatial Info (SI) and Temporal Info (TI) scores for a video, as defined
in ITU-T P.910: Subjective video quality assessment methods for multimedia
applications.
It is currently a "Picture", an mpegvideo-specific type
that has a lot of baggage, all of which is unnecessary
for new_picture, because only its embedded AVFrame
is ever used. So just use an ordinary AVFrame.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In the aforementioned case mpegvideo_enc.c calls
ff_mjpeg_encode_stuffing() at the end of every line which
pads the output to byte-alignment and escapes it;
yet it does not write the restart-markers (and also not
the DRI marker when writing the header) and so the output files
are broken.
Fix this by writing these markers depending upon the number of
slices and not the number of threads in use; this also makes
the output of the encoder reproducible given a slice count
and is therefore important if encoder tests that actually use
-threads auto are added in the future.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Our code for writing optimal huffman tables is incompatible
with using multiple slices and hence commit
884506dfe2 that implemented this
also added an assert that slice_context_count is always 1.
Yet this was always wrong: a) The MJPEG-encoder has (and had)
the AV_CODEC_CAP_SLICE_THREADS capability, so asserting that
it always uses one slice context is incorrect.
b) This commit did not add any proper checks that ensured that
optimal huffman tables are never used together with multiple slices.
This only happened with 03eb0515c1.
c) This assert is at the wrong place: ff_mjpeg_encode_init() is
called before the actual slice_context_count is set. This is
the reason why this assert was never triggered.
Therefore this commit removes this assert.
Also remove an assert from the SpeedHQ encoder sharing b) and c).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
One can use slices without slice-threading. The results for
mpegvideo-encoders are abysmal: AMV, SpeedHQ, H.263, RV10, RV20,
MSMPEG4v2, MSMPEG4v3 and WMV1 produce broken files.
WMV2 meanwhile expects the MpegEncContext given to ff_wmv2_encode_mb()
to be at the beginning of a Wmv2Context (a structure that this encoder
shares with the WMV2 decoder), yet this is only true for the
main context and not for the slice contexts, leading to segfaults.
SpeedHQ additionally triggers an av_assert2, because it is not
byte-aligned at a position where it ought to be byte-aligned.
Given that no codec not supporting slice threading works this commit
disallows using slices unless the encoder supports slice threading.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
checkasm benchmarks on 1.5 GHz Cortex-A72 are as follows.
vc1dsp.vc1_unescape_buffer_c: 918624.7
vc1dsp.vc1_unescape_buffer_neon: 142958.0
Signed-off-by: Ben Avison <bavison@riscosopen.org>
Signed-off-by: Martin Storsjö <martin@martin.st>
checkasm benchmarks on 1.5 GHz Cortex-A72 are as follows.
vc1dsp.vc1_unescape_buffer_c: 655617.7
vc1dsp.vc1_unescape_buffer_neon: 118237.0
Signed-off-by: Ben Avison <bavison@riscosopen.org>
Signed-off-by: Martin Storsjö <martin@martin.st>
checkasm benchmarks on 1.5 GHz Cortex-A72 are as follows. Note that the C
version can still outperform the NEON version in specific cases. The balance
between different code paths is stream-dependent, but in practice the best
case happens about 5% of the time, the worst case happens about 40% of the
time, and the complexity of the remaining cases fall somewhere in between.
Therefore, taking the average of the best and worst case timings is
probably a conservative estimate of the degree by which the NEON code
improves performance.
vc1dsp.vc1_h_loop_filter4_bestcase_c: 19.0
vc1dsp.vc1_h_loop_filter4_bestcase_neon: 48.5
vc1dsp.vc1_h_loop_filter4_worstcase_c: 144.7
vc1dsp.vc1_h_loop_filter4_worstcase_neon: 76.2
vc1dsp.vc1_h_loop_filter8_bestcase_c: 41.0
vc1dsp.vc1_h_loop_filter8_bestcase_neon: 75.0
vc1dsp.vc1_h_loop_filter8_worstcase_c: 294.0
vc1dsp.vc1_h_loop_filter8_worstcase_neon: 102.7
vc1dsp.vc1_h_loop_filter16_bestcase_c: 54.7
vc1dsp.vc1_h_loop_filter16_bestcase_neon: 130.0
vc1dsp.vc1_h_loop_filter16_worstcase_c: 569.7
vc1dsp.vc1_h_loop_filter16_worstcase_neon: 186.7
vc1dsp.vc1_v_loop_filter4_bestcase_c: 20.2
vc1dsp.vc1_v_loop_filter4_bestcase_neon: 47.2
vc1dsp.vc1_v_loop_filter4_worstcase_c: 164.2
vc1dsp.vc1_v_loop_filter4_worstcase_neon: 68.5
vc1dsp.vc1_v_loop_filter8_bestcase_c: 43.5
vc1dsp.vc1_v_loop_filter8_bestcase_neon: 55.2
vc1dsp.vc1_v_loop_filter8_worstcase_c: 316.2
vc1dsp.vc1_v_loop_filter8_worstcase_neon: 72.7
vc1dsp.vc1_v_loop_filter16_bestcase_c: 62.2
vc1dsp.vc1_v_loop_filter16_bestcase_neon: 103.7
vc1dsp.vc1_v_loop_filter16_worstcase_c: 646.5
vc1dsp.vc1_v_loop_filter16_worstcase_neon: 110.7
Signed-off-by: Ben Avison <bavison@riscosopen.org>
Signed-off-by: Martin Storsjö <martin@martin.st>
checkasm benchmarks on 1.5 GHz Cortex-A72 are as follows. Note that the C
version can still outperform the NEON version in specific cases. The balance
between different code paths is stream-dependent, but in practice the best
case happens about 5% of the time, the worst case happens about 40% of the
time, and the complexity of the remaining cases fall somewhere in between.
Therefore, taking the average of the best and worst case timings is
probably a conservative estimate of the degree by which the NEON code
improves performance.
vc1dsp.vc1_h_loop_filter4_bestcase_c: 10.7
vc1dsp.vc1_h_loop_filter4_bestcase_neon: 43.5
vc1dsp.vc1_h_loop_filter4_worstcase_c: 184.5
vc1dsp.vc1_h_loop_filter4_worstcase_neon: 73.7
vc1dsp.vc1_h_loop_filter8_bestcase_c: 31.2
vc1dsp.vc1_h_loop_filter8_bestcase_neon: 62.2
vc1dsp.vc1_h_loop_filter8_worstcase_c: 358.2
vc1dsp.vc1_h_loop_filter8_worstcase_neon: 88.2
vc1dsp.vc1_h_loop_filter16_bestcase_c: 51.0
vc1dsp.vc1_h_loop_filter16_bestcase_neon: 107.7
vc1dsp.vc1_h_loop_filter16_worstcase_c: 722.7
vc1dsp.vc1_h_loop_filter16_worstcase_neon: 140.5
vc1dsp.vc1_v_loop_filter4_bestcase_c: 9.7
vc1dsp.vc1_v_loop_filter4_bestcase_neon: 43.0
vc1dsp.vc1_v_loop_filter4_worstcase_c: 178.7
vc1dsp.vc1_v_loop_filter4_worstcase_neon: 69.0
vc1dsp.vc1_v_loop_filter8_bestcase_c: 30.2
vc1dsp.vc1_v_loop_filter8_bestcase_neon: 50.7
vc1dsp.vc1_v_loop_filter8_worstcase_c: 353.0
vc1dsp.vc1_v_loop_filter8_worstcase_neon: 69.2
vc1dsp.vc1_v_loop_filter16_bestcase_c: 60.0
vc1dsp.vc1_v_loop_filter16_bestcase_neon: 90.0
vc1dsp.vc1_v_loop_filter16_worstcase_c: 714.2
vc1dsp.vc1_v_loop_filter16_worstcase_neon: 97.2
Signed-off-by: Ben Avison <bavison@riscosopen.org>
Signed-off-by: Martin Storsjö <martin@martin.st>
This test deliberately doesn't exercise the full range of inputs described in
the committee draft VC-1 standard. It says:
input coefficients in frequency domain, D, satisfy -2048 <= D < 2047
intermediate coefficients, E, satisfy -4096 <= E < 4095
fully inverse-transformed coefficients, R, satisfy -512 <= R < 511
For one thing, the inequalities look odd. Did they mean them to go the
other way round? That would make more sense because the equations generally
both add and subtract coefficients multiplied by constants, including powers
of 2. Requiring the most-negative values to be valid extends the number of
bits to represent the intermediate values just for the sake of that one case!
For another thing, the extreme values don't look to occur in real streams -
both in my experience and supported by the following comment in the AArch32
decoder:
tNhalf is half of the value of tN (as described in vc1_inv_trans_8x8_c).
This is done because sometimes files have input that causes tN + tM to
overflow. To avoid this overflow, we compute tNhalf, then compute
tNhalf + tM (which doesn't overflow), and then we use vhadd to compute
(tNhalf + (tNhalf + tM)) >> 1 which does not overflow because it is
one instruction.
My AArch64 decoder goes further than this. It calculates tNhalf and tM
then does an SRA (essentially a fused halve and add) to compute
(tN + tM) >> 1 without ever having to hold (tNhalf + tM) in a 16-bit element
without overflowing. It only encounters difficulties if either tNhalf or
tM overflow in isolation.
I haven't had sight of the final standard, so it's possible that these
issues were dealt with during finalisation, which could explain the lack
of usage of extreme inputs in real streams. Or a preponderance of decoders
that only support 16-bit intermediate values in their inverse transforms
might have caused encoders to steer clear of such cases.
I have effectively followed this approach in the test, and limited the
scale of the coefficients sufficient that both the existing AArch32 decoder
and my new AArch64 decoder both pass.
Signed-off-by: Ben Avison <bavison@riscosopen.org>
Signed-off-by: Martin Storsjö <martin@martin.st>
Note that the benchmarking results for these functions are highly dependent
upon the input data. Therefore, each function is benchmarked twice,
corresponding to the best and worst case complexity of the reference C
implementation. The performance of a real stream decode will fall somewhere
between these two extremes.
Signed-off-by: Ben Avison <bavison@riscosopen.org>
Signed-off-by: Martin Storsjö <martin@martin.st>
Upstream gained a new tone-mapping API, which we never switched to. We
don't need a version bump for this because it was included as part of
the v4.192 release we currently already depend on.
Some of the old options can be moderately approximated with the new API,
but specifically "desaturation_base" and "max_boost" cannot. Remove
these entirely, rather than deprecating them. They have actually been
non-functional for a while as a result of the upstream deprecation.
Signed-off-by: Niklas Haas <git@haasn.dev>
They are invalid in VP9. If any of the frames inside a superframe
had a size of zero, the code would either read into the next frame
or into the superframe index; so check for the length to stop this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Packets without data need to be handled specially in order to avoid
undefined reads. Pass these packets through unchanged in case there
are no cached packets* and error out in case there are cached packets:
Returning the packet would mess with the order of the packets;
if one returned the zero-sized packet before the superframe that will
be created from the packets in the cache, the zero-sized packet would
overtake the packets in the cache; if one returned the packet later,
the packets that complete the superframe will overtake the zero-sized
packet.
*: This case e.g. encompasses the scenario of updated extradata
side-data at the end.
Fixes: Out of array read
Fixes: 45722/clusterfuzz-testcase-minimized-ffmpeg_BSF_VP9_SUPERFRAME_fuzzer-5173378975137792
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
tiny_ssim is built for the build host, not for the target platform.
Therefore, it mustn't include the config.h header, which is set up
specifically for the target platform and compiler.
This fixes cross building for older WinStore platforms, where
config.h contains "#define getenv(x) NULL".
Signed-off-by: Martin Storsjö <martin@martin.st>
The existing x86 assembly for loop filters uses the stride as a
full register without clearing/sign extending the upper half
of the registers on x86_64.
This avoids crashes if the caller would have passed nonzero bits
in the previously undefined upper 32 bits of the parameters.
Signed-off-by: Martin Storsjö <martin@martin.st>
The upper limit of strlen(streamid) is 512. Use a larger buffer for
future proof, for example, deal with percent-encoding.
Reviewed-by: Zhao Jun <barryjzhao@tencent.com>
Signed-off-by: Steven Liu <liuqi05@kuaishou.com>
Fixes: Out of array write
Fixes: 45613/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-4539073606320128
Fixes: 46008/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-4681245747970048
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
So I can merge my own changes to this filter after they pass peer
review, as well as keeping it in sync with upstream API changes / new
features.
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: division by zero
Fixes: 45811/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VMDAUDIO_fuzzer-6412592581574656
Fixes: 45979/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VMDAUDIO_fuzzer-5362043060879360
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
av_buffersrc_parameters_set() can be called to set paramenters after the filter
was initialized with for example avfilter_graph_create_filter().
Signed-off-by: James Almer <jamrial@gmail.com>
This search takes alot of time especially when compared with small packets
46631 decicycles -> 15719 decicycles in read_frame_internal() for amr-nb in 3gp
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
No point running all 64 iterations in the loop to never write anything to ret.
Also make ambisonic layouts check its mask too while at it.
Signed-off-by: James Almer <jamrial@gmail.com>
This comment only applies to the scenario in which one uses
the AVCodecContexts embedded in AVStreams. Yet this code sample
stopped doing so in 9897d9f4e074cdc6c7f2409885ddefe300f18dc7;
and the last major version bump even removed the public
AVCodecContexts in AVStreams. So just remove this comment.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Modifying the main context by a slice thread is racy;
so constify the pointer to it in H264SliceContext.
The code itself was already compatible with this change.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since 7be2d2a70c only one context
is used. Moving it to H264Context from H264SliceContext is natural.
One could access the ERContext from H264SliceContext
via H264SliceContext.h264->er; yet H264SliceContext.h264 should
naturally be const-qualified, because slice threads should not
modify the main context. The ERContext is an exception
to this, as ff_er_add_slice() is intended to be called simultaneously
by multiple threads. And for this one needs a pointer whose
pointed-to-type is not const-qualified.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_er_frame_start() initializes ERContext.error_count
to three times the number of macroblocks to decode.
Later ff_er_add_slice() reduces this number by the amount
of macroblocks whose AC resp. DC resp. MV have been finished
(so every correctly decoded MB counts three times).
So the frame has been decoded correctly if error_count is zero
at the end.
The H.264 decoder uses multiple ERContexts when using
slice threading and therefore combines these error counts:
The first slice's ERContext is intended to be initialized
by ff_er_frame_start(), error_count of all the other
slice contexts is intended to be zeroed initially and
all afterwards all the error_counts are summed.
Yet commit 43b434210e
(probably unintentionally) changed the code to set
the first slice's error_count to zero as well.
This leads to bogus error messages in case one decodes
an input video using multiple slices with slice threading
with error concealment enabled (which is not the default)
("concealing 0 DC, 0 AC, 0 MV errors in [IPB] frame");
furthermore the returned frame is marked as corrupt as well
(ffmpeg reports "corrupt decoded frame in stream %d" for this).
This can be fixed easily given that only the first ERContext
is really used since 7be2d2a70c:
Don't reset the error_count; and don't sum the error counts as well.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Look for the generic "USR" labels instead of "?" to skip channels with no
known names, and actually print the decomposition of standard channel layouts.
Signed-off-by: James Almer <jamrial@gmail.com>
This patch is analogous to 20f9727018:
It hides the internal part of AVBitStreamFilter by adding a new
internal structure FFBitStreamFilter (declared in bsf_internal.h)
that has an AVBitStreamFilter as its first member; the internal
part of AVBitStreamFilter is moved to this new structure.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
All FF_QSCALE_TYPE values used by libavfilter originate
from libavfilter (namely from ff_qp_table_extract());
no value is exchanged between libavcodec and libavutil.
The values that are exchanged (and used in libavfilter)
are of type enum AVVideoEncParamsType.
Therefore this patch stops using said FF_QSCALE_TYPE_*
in libavfilter and uses enum AVVideoEncParamsType
directly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Especially useful when debugging subtitle output, but also shows
if values are set or not for demux and encoding.
Co-authored-by: Jan Ekström <jan.ekstrom@24i.com>
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
Otherwise get_pixel_format() will not be called when parsing a subsequent Sequence
Header in non hwaccel enabled scenarios, allowing frame parsing when it shouldn't.
This prevents the scenario seqhdr -> frame_hdr/redundant_frame_hdr -> seqhdr ->
redundant_frame_hdr from having the latter redundant frame header parsed as if it
was a frame header by the decoder because the former was discarded.
Since CBS did not discard it, the latter redundant frame header is output with a
zeroed AV1RawFrameHeader struct, which can have undesired results, like division
by zero with fields normally guaranteed to be anything else.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Due to a quirk of the ASS format some tags depend on the exact storage
resolution of the video, so tell libass via ass_set_storage_size.
Reviewed-by: Soft Works <softworkz@hotmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
It allocates a dummy sws/swr context and tries setting options on it,
apparently to check if they are valid. This is redundant, since the
options will be checked if/when they are later applied on a context that
is actually used for conversion.
It tries to process any unhandled options as AVOptions. Handle this
directly in cmdutils.c, without resorting to a confusing fake option
definition (which is currently visible to the users in -help output).
Fix below error message when timecode packet is written.
"Application provided duration: -9223372036854775808 / timestamp: -9223372036854775808 is out of range for mov/mp4 format"
try to reproduce by:
ffmpeg -y -f lavfi -i color -metadata "timecode=00:00:00:00" -t 1 test.mov
Note although error message is printed, the timecode packet will be written anyway. So
the patch 2/2 will try to change the log level to warning.
Fixes ticket #9488
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Deprecate the channels option, and ensure ch_layout has priority if set over
channels, until the latter is gone.
Signed-off-by: James Almer <jamrial@gmail.com>
It is a more fitting place for them.
Also move the definition of ff_log2_run to mathtables.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
bitstream.c is currently the disjoint union of three parts:
The first part is ff_log2_run, the second part are some auxiliary
functions for the PutBits-API; and the third part is the code
for creating VLCs. This commit moves the latter into a file of its own.
This has the advantage of making one of the hacks in tableprint_vlc.h
redundant as vlc.c does not include config.h (whereas the PutBits-API
part does).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: 42827/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-4900528511909888
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: division by zero
Fixes: 43769/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AV1_fuzzer-5392562205097984
Fixes: 43950/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AV1_fuzzer-5769210217758720
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avctx->ch_layout will be reinitialized using channel_mask later in the
function.
Fixes: 45736/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMAPRO_fuzzer-5769886813519872
Signed-off-by: James Almer <jamrial@gmail.com>
This is a workaround until avcodec_close() stops freeing ch_layout through
av_opt_fre(), or the former is removed.
Fixes a regression since 327efa6633.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: signed integer overflow: 11494 * 1073741824000000 cannot be represented in type 'long'
Fixes: 26586/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PIXLET_fuzzer-5752633970917376
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This structure is no longer declared in a public header,
so using an FF-prefix is more appropriate.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, codec.h contains both public and private parts
of AVCodec. This exposes the internals of AVCodec to users
and leads them into the temptation of actually using them
and forces us to forward-declare structures and types that
users can't use at all.
This commit changes this by adding a new structure FFCodec to
codec_internal.h that extends AVCodec, i.e. contains the public
AVCodec as first member; the private fields of AVCodec are moved
to this structure, leaving codec.h clean.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also move FF_CODEC_TAGS_END as well as struct AVCodecDefault.
This reduces the amount of files that have to include internal.h
(which comes with quite a lot of indirect inclusions), as e.g.
most encoders don't need it. It is furthemore in preparation
for moving the private part of AVCodec out of the public codec.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
No need to use a Custom layout when the non diegetic channels can be
described as a standard mask.
This fixes:
45684/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LIBOPUS_fuzzer-5039410989629440
Signed-off-by: James Almer <jamrial@gmail.com>
The IMF demuxer did not implement AVInputFormat::read_seek2(), resulting in
inefficient input seeking.
Addresses https://trac.ffmpeg.org/ticket/9648
Byte- and frame-seeking are not supported.
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
The CRI decoder is useless without the MJPEG-decoder
(its init-function always errors out).
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They return nicer error messages on error; furthermore,
they also use our allocation functions. It also stops
calling deflateEnd() on a z_stream that might not have been
successfully initialized.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They emit better error messages (it does not claim that inflateInit
failed upon an error from deflateInit!) and uses our allocation functions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The rationale is the same as for the wrappers for inflateInit(),
although the case for it is admittedly not so strong because
there are less users of deflateInit().
Also remove an unnecessary inclusion of config.h in
libavformat/protocols.c in order to trigger a request for reconfigure
(which is needed for CONFIG_DEFLATE_WRAPPER to take effect).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Instead reuse and reset a single z_stream.
Also use FFZStream in decode_zbuf(), because it has nicer error
messages.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This fixes the problem of potentially closing a z_stream
that has never been successfully initialized.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Returns better error messages in case of error and deduplicates
the inflateInit() code and also allows to cleanup generically
in case of errors as it is save to call ff_inflate_end() if
ff_inflate_init() has not been called successfully.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This fixes the problem of potentially closing a z_stream
that has never been successfully initialized.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This fixes the problem of potentially closing a z_stream
that has never been successfully initialized.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This fixes the problem of potentially closing a z_stream
that has never been successfully initialized.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This fixes the problem of potentially closing a z_stream
that has never been successfully initialized.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Returns better error messages in case of error and deduplicates
the inflateInit() code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This fixes the problem of potentially closing a z_stream
that has never been successfully initialized.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This fixes the problem of potentially closing a z_stream
that has never been successfully initialized.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Returns better error messages in case of error and deduplicates
the inflateInit() code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is not documented to be safe to call inflateEnd() on a z_stream
that has never been successfully been initialized by inflateInit(),
but just zeroed. It just happens to work and several codecs rely
on this (they have FF_CODEC_CAP_INIT_CLEANUP set and even call
inflateEnd() when inflateInit() failed or has never been called).
To avoid this, other codecs recorded whether their zstream has been
initialized successfully or not.
This commit adds wrappers for inflateInit() and inflateEnd() that
do what these other codecs do; furthermore, they also take care of
properly setting up the zstream before inflateInit() and emit
an error message in case of error.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
So use 64bits for max_packet_size instead of size_t which might be
32 bits; this is consistent with ff_alloc_packet().
Also remove a redundant size check (ff_alloc_packet() already
checks for that).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids unnecessary churn and build breakage for users, by
making sure the whole version.h is included like it has been so far,
while keeping the benefit of not needing to rebuild most files in
the ffmpeg tree on minor/micro bumps.
Signed-off-by: Martin Storsjö <martin@martin.st>
Fixes: signed integer overflow: -1094995529 * 24 cannot be represented in type 'int'
Fixes: 44436/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SONIC_fuzzer-4874459459223552
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array write
Fixes: 45624/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-6473487382872064
Fixes: 45626/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-4874997192065024
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array access
Fixes: 45497/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DFPWM_fuzzer-5239786212818944.fuzz
Fixes: 45510/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DFPWM_fuzzer-4947856883056640
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Floating point is evil, it would be better if duration was not a double
Fixes: Infinite loop
Fixes: 45123/clusterfuzz-testcase-minimized-ffmpeg_dem_WEBM_DASH_MANIFEST_fuzzer-6725052291219456
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Only index tables repeating previous index tables should use the same
InstaceUID. Use the index start position when generating the InstanceUID to fix
this.
Signed-off-by: Marton Balint <cus@passwd.hu>
Output buffer alignment might be different to ZIMG_ALIGNMENT or it may not be
aligned at all if a downstream filter (e.g. vf_pad) intentionally misaligns it.
Or maybe we should unconditionally always allocate output with
av_frame_get_buffer() instead of ff_get_video_buffer()?
Signed-off-by: Marton Balint <cus@passwd.hu>
Make sure it is between [1, MAX_THERADS] and also take into account the outlink
size in order not to request zero height output from zscale.
Signed-off-by: Marton Balint <cus@passwd.hu>
This avoids unnecessary rebuilds of most source files if only the
list of enabled components has changed, but not the other properties
of the build, set in config.h.
Signed-off-by: Martin Storsjö <martin@martin.st>
Also bump the minor versions of all libraries, to signify the
API change of splitting the version.h headers and adding the
new version_major.h header.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids including version.h in all source files, avoiding
unnecessary rebuilds when the version number is bumped. Only
version_major.h is included by the main header, which defines
availability of e.g. FF_API_* macros, and which is bumped much
less often.
This isn't done for libavutil/version.h, because that header needs
to be included essentially everywhere due to LIBAVUTIL_VERSION_INT
being used wherever an AVClass is constructed.
Signed-off-by: Martin Storsjö <martin@martin.st>
bp->len cannot be used to detect if try_describe_ambisonic was successful
because the bprint buffer might contain other data as well.
Also describing an invalid ambisonic layout should not return 0 but
AVERROR(EINVAL) instead, so change try_describe_ambisonic to actually return
error on invalid ambisonics. This also allows us to fix the first issue.
Signed-off-by: Marton Balint <cus@passwd.hu>
This reduces code duplication an allows printing AMBI%d channel names for
custom layouts for non-standard or partial ambisonic layouts.
Signed-off-by: Marton Balint <cus@passwd.hu>
Later we use av_channel_layout_copy, but that uninits the struct
unintentionally freeing the possibly allocated u.map pointer.
Signed-off-by: Marton Balint <cus@passwd.hu>
Reported by ASAN as memcpy-param-overlap when running
the filter-join FATE-test.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since the request_channel_layout is used only by a handful of codecs,
move the option to codec private contexts.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: James Almer <jamrial@gmail.com>
Mediates between old-style (de)muxers and new-style callers. Will be
removed once all the (de)muxers are converted to the new API.
Signed-off-by: James Almer <jamrial@gmail.com>
They are incompatible with the new channel layout scheme and no decoder
uses them.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The new API is more extensible and allows for custom layouts.
More accurate information is exported, eg for decoders that do not
set a channel layout, lavc will not make one up for them.
Deprecate the old API working with just uint64_t bitmasks.
Expanded and completed by Vittorio Giovara <vittorio.giovara@gmail.com>
and James Almer <jamrial@gmail.com>.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Currently priming the zlib decompressor involves compressing
data directly after having decompressed it and decompressing
it again in order to set the "dictionary" and to initialize
the adler32-checksum. Yet this is wasteful and can be simplified
by synthetizing the compressed data via non-compressed blocks.
This reduced the amount of allocations for the decoding part
of fate-vsynth1-flashsv2, namely from
total heap usage: 9,135 allocs, 9,135 frees, 376,503,427 bytes allocated
to
total heap usage: 2,373 allocs, 2,373 frees, 14,144,083 bytes allocated
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids build errors if such features are enabled while targeting
another binary format. (Using such features on other platforms
might require some other form of signaling/setup though, but
the ELF specific .note section isn't applicable at least.)
Signed-off-by: Martin Storsjö <martin@martin.st>
In libavfilter/vf_palettegen.c, the function get_avg_color requires
that box->len greater than zero to avoid dividing by zero. However,
the call sequence filter_frame -> get_palette_frame -> get_avg_color
may not satisfy this precondition. Fixes#9222.
Signed-off-by: Yiyuan GUO <yguoaz@gmail.com>
The muxer seems to have had one seemingly accidental use of
LIBAVCODEC_IDENT, while LIBAVFORMAT_IDENT probably is the
relevant one (which is used multiple times in the same file).
Signed-off-by: Martin Storsjö <martin@martin.st>
This patch removes all occurences of DNNReturnType from the DNN module.
This commit replaces DNN_SUCCESS by 0 (essentially the same), so the
functions with DNNReturnType now return 0 in case of success, the negative
values otherwise.
Signed-off-by: Shubhanshu Saxena <shubhanshu.e01@gmail.com>
Signed-off-by: Shubhanshu Saxena <shubhanshu.e01@gmail.com>
Switch to returning specific error codes or DNN_GENERIC_ERROR
when an error is encountered in the common DNN backend functions.
Signed-off-by: Shubhanshu Saxena <shubhanshu.e01@gmail.com>
Switch to returning specific error codes or DNN_GENERIC_ERROR
when an error is encountered.
Signed-off-by: Shubhanshu Saxena <shubhanshu.e01@gmail.com>
Switch to returning specific error codes or DNN_GENERIC_ERROR
when an error is encountered. For TensorFlow C API errors, currently
DNN_GENERIC_ERROR is returned.
Signed-off-by: Shubhanshu Saxena <shubhanshu.e01@gmail.com>
Switch to returning specific error codes or DNN_GENERIC_ERROR
when an error is encountered. For OpenVINO API errors, currently
DNN_GENERIC_ERROR is returned.
Signed-off-by: Shubhanshu Saxena <shubhanshu.e01@gmail.com>
This commit returns specific error codes from the functions in the
dnn_io_proc instead of DNN_ERROR.
Signed-off-by: Shubhanshu Saxena <shubhanshu.e01@gmail.com>
This commit returns specific error codes from the execution
functions in the Native Backend layers instead of DNN_ERROR.
Signed-off-by: Shubhanshu Saxena <shubhanshu.e01@gmail.com>
This commit prepares the filter side to handle specific error codes
from the DNN backends instead of current DNN_ERROR.
Signed-off-by: Shubhanshu Saxena <shubhanshu.e01@gmail.com>
In Gentoo and ChromeOS we want to allow pure LLVM builds without
using GNU tools, so we block any unwanted mixed GNU/LLVM usages
(GNU tools are still kept around in our chroots for projects
like glibc which cannot yet be built otherwise).
The default ${cross_prefix}${ranlib_default} points to GNU and
fails, so move the test a bit later - after the defaults are
set and the proper values get overriden - such that ffmpeg
configure calls the llvm-ranlib we desire. [1]
[1] https://gitweb.gentoo.org/repo/gentoo.git/tree/media-video/ffmpeg/ffmpeg-4.4.1-r1.ebuild?id=7a34377e3277a6a0e2eedd40e90452a44c55f1e6#n477
Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
This commit adds support for storing DFPWM audio in a WAV container.
It uses the WAVEFORMATEXTENSIBLE structure, following these conventions:
https://gist.github.com/MCJack123/90c24b64c8e626c7f130b57e9800962c
The implementation is very simple: it just adds the GUID to the list of
WAV GUIDs, and modifies the WAV muxer to always use WAVEFORMATEXTENSIBLE
format with that GUID.
This creates a standard container format for DFPWM besides raw data.
It will allow users to transfer DFPWM audio in a standard container
format, with the sample rate and channel count contained in the file
as opposed to being an external parameter as in the raw format.
This format is already supported in my AUKit library, which is the CC
analog to libav (albeit much smaller). Support in other applications is TBD.
Signed-off-by: Jack Bruienne <jackbruienne@gmail.com>
This patch builds on my previous DFPWM codec patch, adding a raw
audio format to be able to read/write the raw files that are most commonly
used (as no other container format supports it yet).
The muxers are mostly copied from the PCM demuxer and the raw muxers, as
DFPWM is typically stored as raw data.
Please see the previous patch for more information on DFPWM.
Signed-off-by: Jack Bruienne <jackbruienne@gmail.com>
From the wiki page (https://wiki.vexatos.com/dfpwm):
> DFPWM (Dynamic Filter Pulse Width Modulation) is an audio codec
> created by Ben “GreaseMonkey” Russell in 2012, originally to be used
> as a voice codec for asiekierka's pixmess, a C remake of 64pixels.
> It is a 1-bit-per-sample codec which uses a dynamic-strength one-pole
> low-pass filter as a predictor. Due to the fact that a raw DPFWM decoding
> creates a high-pitched whine, it is often followed by some post-processing
> filters to make the stream more listenable.
It has recently gained popularity through the ComputerCraft mod for
Minecraft, which added support for audio through this codec, as well as
the Computronics expansion which preceeded the official support. These
both implement the slightly adjusted 1a version of the codec, which is
the version I have chosen for this patch.
This patch adds a new codec (with encoding and decoding) for DFPWM1a.
The codec sources are pretty simple: they use the reference codec with
a basic wrapper to connect it to the FFmpeg AVCodec system.
To clarify, the codec does not have a specific sample rate - it is
provided by the container (or user), which is typically 48000, but has
also been known to be 32768. The codec does not specify channel info
either, and it's pretty much always used with one mono channel.
However, since it appears that libavcodec expects both sample rate and
channel count to be handled by either the codec or container, I have
made the decision to allow multiple channels interleaved, which as far
as I know has never been used, but it works fine here nevertheless. The
accompanying raw format has a channels option to set this. (I expect
most users of this will not use multiple channels, but it remains an
option just in case.)
This patch will be highly useful to ComputerCraft developers who are
working with audio, as it is the standard format for audio, and there
are few user-friendly encoders out there, and even fewer decoders. It
will streamline the process for importing and listening to audio,
replacing the need to write code or use tools that require very
specific input formats.
You may use the CraftOS-PC program (https://www.craftos-pc.cc) to test
out DFPWM playback. To use it, run the program and type this command:
"attach left speaker" Then run "speaker play <file.dfpwm>" for each file.
The app runs in a sandbox, so files have to be transferred in first;
the easiest way to do this is to simply drag the file on the window.
(Or copy files to the folder at https://www.craftos-pc.cc/docs/saves.)
Sample DFPWM files can be generated with an online tool at
https://music.madefor.cc. This is the current best way to encode DFPWM
files. Simply drag an audio file onto the page, and it will encode it,
giving a download link on the page.
I've made sure to update all of the docs as per Developer§7, and I've
tested it as per section 8. Test files encoded to DFPWM play correctly
in ComputerCraft, and other files that work in CC are correctly decoded.
I have also verified that corrupt files do not crash the decoder - this
should theoretically not be an issue as the result size is constant with
respect to the input size.
Signed-off-by: Jack Bruienne <jackbruienne@gmail.com>
This patch adds optional support for Arm Pointer Authentication Codes.
PAC support is turned on or off at compile time using additional
compiler flags. Unless any of these is enabled explicitly, no additional
code will be emitted at all.
Signed-off-by: André Kempe <andre.kempe@arm.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Fixes: signed integer overflow: 10 * 808464428 cannot be represented in type 'int'
Fixes: assertion failure
Fixes: ticket9651
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself
Fixes: Ticket8486
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes hang at end of input with this command:
ffmpeg -f lavfi -i testsrc2=d=50,format=yuv444p -lavfi \
"extractplanes=y+u+v[y][u][v];[y]tpad=start=0[y];[u]tpad=start=0[u];[v]negate[v];[y][u][v]vstack=3" -f null -
While swscale can be reconfigured with sws_setColorspaceDetails,
the in/out ranges also need to be set before calling
sws_init_context, otherwise the initialization might choose
fastpaths that don't take the ranges into account.
Therefore, look at in->color_range too, when deciding on whether
the scaler needs to be reconfigured.
Add a new member variable for keeping track of this, for being
able to differentiate between whether the scale filter parameter
"in_range" has been set (which should override whatever the input
frame has set) or whether it has been configured based on the
latest frame (which should trigger reconfiguring the scaler if
the input frame ranges change).
Fixes: Ticket #9576
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes building for arm after 10c2ef1ca4.
The argument to av_clip_uintp2 must be an assembly time immediate
constant.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by and commit message details-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The earlier code has ignored it for all stream types except
video and subtitles, probably because audio was presumed
to only consist of keyframes. Yet this assumption is not true
for e.g. TrueHD.
Reviewed-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This was tested with medias recorded from an iPhone XR and an iPhone 13.
Here is how a typical stream looks like in coding order:
┌────────┬─────┬─────┬──────────┐
│ sample | PTS | DTS | keyframe |
├────────┼─────┼─────┼──────────┤
┊ ┊ ┊ ┊ ┊
│ 53 │ 560 │ 510 │ No │
│ 54 │ 540 │ 520 │ No │
│ 55 │ 530 │ 530 │ No │
│ 56 │ 550 │ 540 │ No │
│ 57 │ 600 │ 550 │ Yes │
│ * 58 │ 580 │ 560 │ No │
│ * 59 │ 570 │ 570 │ No │
│ * 60 │ 590 │ 580 │ No │
│ 61 │ 640 │ 590 │ No │
│ 62 │ 620 │ 600 │ No │
┊ ┊ ┊ ┊ ┊
In composition/display order:
┌────────┬─────┬─────┬──────────┐
│ sample | PTS | DTS | keyframe |
├────────┼─────┼─────┼──────────┤
┊ ┊ ┊ ┊ ┊
│ 55 │ 530 │ 530 │ No │
│ 54 │ 540 │ 520 │ No │
│ 56 │ 550 │ 540 │ No │
│ 53 │ 560 │ 510 │ No │
│ * 59 │ 570 │ 570 │ No │
│ * 58 │ 580 │ 560 │ No │
│ * 60 │ 590 │ 580 │ No │
│ 57 │ 600 │ 550 │ Yes │
│ 63 │ 610 │ 610 │ No │
│ 62 │ 620 │ 600 │ No │
┊ ┊ ┊ ┊ ┊
Sample/frame 58, 59 and 60 are B-frames which actually depends on the
key frame (57). Here the key frame is not an IDR but a "CRA" (Clean
Random Access).
Initially, I thought I could rely on the sdtp box (independent and
disposable samples), but unfortunately:
sdtp[54] is_leading:0 sample_depends_on:1 sample_is_depended_on:0 sample_has_redundancy:0
sdtp[55] is_leading:0 sample_depends_on:1 sample_is_depended_on:2 sample_has_redundancy:0
sdtp[56] is_leading:0 sample_depends_on:1 sample_is_depended_on:2 sample_has_redundancy:0
sdtp[57] is_leading:0 sample_depends_on:2 sample_is_depended_on:0 sample_has_redundancy:0
sdtp[58] is_leading:0 sample_depends_on:1 sample_is_depended_on:0 sample_has_redundancy:0
sdtp[59] is_leading:0 sample_depends_on:1 sample_is_depended_on:2 sample_has_redundancy:0
sdtp[60] is_leading:0 sample_depends_on:1 sample_is_depended_on:2 sample_has_redundancy:0
sdtp[61] is_leading:0 sample_depends_on:1 sample_is_depended_on:0 sample_has_redundancy:0
sdtp[62] is_leading:0 sample_depends_on:1 sample_is_depended_on:0 sample_has_redundancy:0
The information that might have been useful here would have been
is_leading, but all the samples are set to 0 so this was unusable.
Instead, we need to rely on sgpd/sbgp tables. In my case the video track
contained 3 sgpd tables with the following grouping types: tscl, sync
and tsas. In the sync table we have the following 2 entries (only):
sgpd.sync[1]: sync nal_unit_type:0x14
sgpd.sync[2]: sync nal_unit_type:0x15
(The count starts at 1 because 0 carries the undefined semantic, we'll
see that later in the reference table).
The NAL unit types presented here correspond to:
libavcodec/hevc.h: HEVC_NAL_IDR_N_LP = 20,
libavcodec/hevc.h: HEVC_NAL_CRA_NUT = 21,
In parallel, the sbgp sync table contains the following:
┌────┬───────┬─────┐
│ id │ count │ gdi │
├────┼───────┼─────┤
│ 0 │ 1 │ 1 │
│ 1 │ 56 │ 0 │
│ 2 │ 1 │ 2 │
│ 3 │ 59 │ 0 │
│ 4 │ 1 │ 2 │
│ 5 │ 59 │ 0 │
│ 6 │ 1 │ 2 │
│ 7 │ 59 │ 0 │
│ 8 │ 1 │ 2 │
│ 9 │ 59 │ 0 │
│ 10 │ 1 │ 2 │
│ 11 │ 11 │ 0 │
└────┴───────┴─────┘
The gdi column (group description index) directly refers to the index in
the sgpd.sync table. This means the first frame is an IDR, then we have
batches of undefined frames interlaced with CRA frames. No IDR ever
appears again (tried on a 30+ seconds sample).
With that information, we can build an heuristic using the presentation
order.
A few things needed to be introduced in this commit:
1. min_sample_duration is extracted from the stts: we need the minimal
step between sample in order to PTS-step backward to a valid point
2. In order to avoid a loop over the ctts table systematically during a
seek, we build an expanded list of sample offsets which will be used
to translate from DTS to PTS
3. An open_key_samples index to keep track of all the non-IDR key
frames; for now it only supports HEVC CRA frames. We should probably
add BLA frames as well, but I don't have any sample so I prefered to
leave that for later
It is entirely possible I missed something obvious in my approach, but I
couldn't come up with a better solution. Also, as mentioned in the diff,
we could optimize is_open_key_sample(), but the linear scaling overhead
should be fine for now since it only happens in seek events.
Fixing this issue prevents sending broken packets to the decoder. With
FFmpeg hevc decoder the frames are skipped, with VideoToolbox the frames
are glitching.
sgpd means Sample Group Description Box.
For now, only the sync grouping type is parsed, but the function can
easily be adjusted to support other flavours.
The sbgp (Sample to Group Box) sync_group table built in previous commit
contains references to this table through the group_description_index
field.
By ffmpeg threading support implementation via frame slicing and doing
zimg_filter_graph_build that used to take 30-60% of each frame processig
only if necessary (some parameters changed)
the performance increase vs original version
in video downscale and color conversion >4x is seen
on 64 cores Intel Xeon, 3x on i7-6700K (4 cores with HT)
Signed-off-by: Victoria Zhislina <Victoria.Zhislina@intel.com>
If _FieldBased, _Matrix, _ColorRange, or _ChromaLocation haven't
been set, that absence would be interpreted as 0, leading to those
being set to case 0 instead of default. There is no case 0 for
_Primaries and _Transfer, so those were correctly falling back
to the default case.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
It appears this is not allowed "Each Segment Index box documents how a (sub)segment is divided into one or more subsegments
(which may themselves be further subdivided using Segment Index boxes)."
Fixes: Null pointer dereference
Fixes: Ticket9517
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The loongson_intrinsics.h file is updated from v1.0.3 version
to v1.1.0. Some spelling mistakes are fixed and new functions are added.
Signed-off-by: Hao Chen <chenhao@loongson.cn>
Reviewed-by: 殷时友 <yinshiyou-hf@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
They correspond to the relevant fields from the packet that follows the
one where the expressions are being applied.
Signed-off-by: James Almer <jamrial@gmail.com>
Bitstream filters inserted between the input and output were never drained,
resulting in packets being lost if the bsf had any buffered.
Signed-off-by: James Almer <jamrial@gmail.com>
And use a single AVPacket for the entire process.
This more closely follows the suggested API usage in the doxy.
Signed-off-by: James Almer <jamrial@gmail.com>
It's needed for avformat_get_mov_video_tags() and avformat_get_mov_audio_tags(),
both public symbols defined in avformat.h
Signed-off-by: James Almer <jamrial@gmail.com>
The variable AVFrame *frame could be a null pointer, now add a null
pointer check to avoid dereferencing the null pointer.
Signed-off-by: Tong Wu <tong1.wu@intel.com>
ChromaForamt for mjpeg-qsv is always set to yuv420, and this will be
wrong when encode other pixel format (for example yuyv422). ChromaFormat
is changed to be adaptive to pix_fmt.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Fix: #7706. After commit 5fdcf85bbf, vaapi encoder's performance
decrease. The reason is that vaRenderPicture() and vaSyncBuffer() are
called at the same time (vaRenderPicture() always followed by a
vaSyncBuffer()). Now I changed them to be called in a asynchronous way,
which will make better use of hardware.
Async_depth is added to increase encoder's performance. The frames that
are sent to hardware are stored in a fifo. Encoder will sync output
after async fifo is full.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Add vaSyncBuffer to VAAPI encoder. Old version API vaSyncSurface wait
surface to complete. When surface is used for multiple operation, it
waits all operations to finish. vaSyncBuffer only wait one channel to
finish.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Having optionally installed headers is a bad idea as there's no way to know
if they are present or not (unless a define is added to avconfig.h, but that's
just ugly).
Signed-off-by: James Almer <jamrial@gmail.com>
The range parameters need to be set up before calling
sws_init_context (which selects which fastpaths can be used;
this gets called by sws_getContext); solely passing them via
sws_setColorspaceDetails isn't enough.
This fixes producing full range YUV range output when doing
YUV->YUV conversions between different YUV color spaces.
Signed-off-by: Martin Storsjö <martin@martin.st>
xvmc.h used FF_API_* macros before, but they were removed in
1c63aed232, leaving the include
unused.
The ones in android_camera.c and mediacodec_wrapper.c have been
added due to a misunderstanding, fixed in
c0bce367e4 and
13b77af2f0.
The one in mediacodec.c seems to never have been used at all.
Signed-off-by: Martin Storsjö <martin@martin.st>
Some of these were made possible by moving several common macros to
libavutil/macros.h.
While just at it, also improve the other headers a bit.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is a remnant of an FF_API_* inclusion (back from when they were in
avutil.h and not in version.h).
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It has been added for an FF_API_* at a time when these were in avutil.h.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It has been included since af5f434f8c
for deprecation reasons, but removing it has been forgotten after
it had served is purpose. So remove it.
For convenience, include version.h instead as LIBAVUTIL_VERSION_INT
is supposed to be used when creating AVClasses.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since the check got simplified and stdbool was no longer necessary
to include, neither is that variable. Silences a warning.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
It need not be writable at all. Instead, use temporary buffers
for decorrelation.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is unnecessary and unchecked; the intention seems to be to ensure
that the frame's data is writable, but it does not provide this.
This will be fixed in a latter commit.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
A decoder is only opened if there is a decoder for the codec,
so every AVCodecContext here has AVCodecContext.codec set.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is a prerequisite to continue using the decoder at all
to decode the next interval (if any).
This fixes a regression introduced in commit
2a88ebd096 and reported in ticket #8657.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add support for hevc_qsv to input RGB format frame. It will
transform frame to yuv inside MediaSDK instead of using auto
scale. Now hevc_qsv supports directly encoding BGRA and X2RGB10
format. The X2RGB10 correspond to the A2RGB20 format and BGRA
correspond to RGB4 format in MediaSDK.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
MSDK recognizes both yuv420p10 and yuv420p9 as MFX_FOURCC_P010, but
parameters are different. When decode yuv420p9 video, ffmpeg-qsv will use
yuv420p10le to configure surface which is different with param from
DecoderHeader and this will lead to error. Now change it use
param from decoderHeader to configure surface.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
This commit added a sizeV option, integrated some identical operations
to a separate function, and updated the CGS for horizontal and vertical
respectively.
The following command is on how to apply sizeV option:
ffmpeg -init_hw_device vulkan -i input.264 -vf \
hwupload,gblur_vulkan=size=127:sigma=20:sizeV=3:sigmaV=0.5,hwdownload,format=yuv420p \
-y out.264
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
Use the commands below to test: (href: https://trac.ffmpeg.org/wiki/Blend)
I. make an image for test
ffmpeg -f lavfi -i color=s=256x256,geq=r='H-1-Y':g='H-1-Y':b='H-1-Y' -frames 1 \
-y -pix_fmt yuv420p test.jpg
II. blend in sw
ffmpeg -i test.jpg -vf "split[a][b];[b]transpose[b];[a][b]blend=all_mode=multiply,\
pseudocolor=preset=turbo" -y multiply_sw.jpg
III. blend in vulkan
ffmpeg -init_hw_device vulkan -i test.jpg -vf "split[a][b];[b]transpose[b];\
[a]hwupload[a];[b]hwupload[b];[a][b]blend_vulkan=all_mode=multiply,hwdownload,\
format=yuv420p,pseudocolor=preset=turbo" -y multiply_vulkan.jpg
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
mips has several headers that are only meant for inclusion in another
non-arch specific file; they do not even try to be standalone. So don't
test them in checkheaders.
Also fix vp9dsp_mips.h, an ordinary header missing some includes.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes make checkheaders on PPC, for which no arch-specific header
exists that indirectly includes attributes.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only include it if it is needed, namely if __MMX__ is undefined.
X86 is currently the only arch where lavu/cpu.h is basically
automatically included (for internal development): #if ARCH_X86
is true, lavu/internal.h (which is basically included everywhere)
includes lavu/x86/emms.h which can mask missing inclusions
of lavu/cpu.h if the developer works on x86/x64. This has happened
in 8e825ec3ab and also earlier
(see 6d2365882f).
By including said header only if necessary ordinary developer machines
will behave like non-x86 arches, so that missing inclusions of cpu.h
won't go unnoticed any more.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The IMF demuxer does not set the DTS and PTS of packets accurately in all
scenarios. Moreover, audio packets are not trimmed when they exceed the
duration of the underlying resource.
imf-cpl-with-repeat FATE ref file is regenerated.
Addresses https://trac.ffmpeg.org/ticket/9611
IMF CPLs can reference thousands of files, which can result in system limits
for the number of open files to be exceeded. The following patch opens and
closes files as needed.
Addresses https://trac.ffmpeg.org/ticket/9623
Trying to be clever about determining between interface version 8
and 8.1 ended up with pre-8.1 versions of AviSynth+ segfaulting.
The amount of time between interface version 8.1 and 9 is small,
so just restrict the frameprop awareness to version 9 and call it
a day.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
This automatically makes the remaining mpegvideo-decoders
(namely msmpeg4v[1-3], mss2, VC-1, VC-1 Image, WMV-[1-3]
and WMV-3 Image) init-threadsafe.
These were the last native codecs that were not init-threadsafe;
only wrappers for external libraries and for hardware accelerations
are now not init-threadsafe.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This automatically makes the FLV, H.263, H.263+, Intel H.263,
MPEG-4, RealVideo 1.0 and RealVideo 2.0 decoders init-threadsafe.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since the av_malloc() may fail and return NULL pointer,
it is needed that the 's->edge_emu_buffer' should be checked
whether the new allocation is success.
Fixes: d14723861b ("VP3: fix decoding of videos with stride > 2048")
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
When the fifo is grown by exactly the current write offset, it would end
up with offset_w = nb_elems. If av_fifo_write_from_cb() is called in
such a state, the user callback would get callled with *nb_elems=0,
which will then cause the write to return without writing anything.
The ID3v2.4.0 standard defines TIT1 as the "Content group description"
tag [1]. This frame is usually referred to as the "Grouping" tag and in
de-facto use under that name by Vorbis and APEv2 [2].
This commit introduces a mapping from "TIT1" to "grouping" in the
id3v2.4 metadata conversion table. This will enable software to access
it using that name. In particular, MPD will now read this tag correctly
when using the ffmpeg decoder plugin.
[1] https://id3.org/id3v2.4.0-frames (4.2.1)
[2] https://picard-docs.musicbrainz.org/en/appendices/tag_mapping.html#grouping-3
Signed-off-by: Wolfgang Müller <wolf@oriole.systems>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
We should use the systems crypto policy by default. If there is no
system policy, gnutls will use the "NORMAL" policy.
Signed-off-by: Andreas Schneider <asn@cryptomilk.org>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The exif.h header doesn't use anything from tiff.h. We also just need
to include tiff_common.h in .c files where it actually used.
Signed-off-by: Andreas Schneider <asn@cryptomilk.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
bytestream.h should be directly included for GetByteContext and not
rely on other headers to include it. It could be removed from there.
Signed-off-by: Andreas Schneider <asn@cryptomilk.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If a frame-threaded decoder with inter-frame dependencies
returns an error when decoding a frame and the returned frame
isn't clean, an error message is emitted claiming that this
is a bug. This seems to be based upon the thinking that
in this case a ThreadFrame has not been properly unreferenced.
Yet this is wrong, as decoders with inter-frame dependencies
don't use the frame for output for synchronization and therefore
don't use ThreadFrames at all for this. So unreferencing
this frame generically is fine and not a bug.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only unorthodox thing that this codec's init function does
is calling ff_get_format(). Yet this is supposed to be save,
as any get_format callback already has to deal with the scenario
of different AVCodecContext's calling it simultaneously.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The headers from version 3.7.1 are needed in order to support
parsing of frame properties. avs/version.h has been generated
as part of the AviSynth+ build process for a long time, but was
never installed with the includes until version 3.7.1a. Checking
for the presence of avs/version.h might have been sufficient,
but a version check mechanism might be useful in the future.
This does not change the version compatibility with the library
itself; previous 3.x versions of AviSynth+ as well as AviSynth 2.6
can still be used with the demuxer.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
* Field Order
* Chroma Location
* Color Transfer Characteristics
* Color Range
* Color Primaries
* Matrix Coefficients
The existing TFF/BFF detection is retained as a fallback for
older versions of AviSynth that can't access frame properties.
The other properties have no legacy equivalent to detect them.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
AviSynth works on frame-based video by default, which can
be either progressive or interlaced. Some filters can break
frames into half-height fields, at which point it considers
the clip to be field-based (avs_is_field_based can be used
to check for this situation).
To properly detect the field order of a typical video clip,
the frame needs to have been weaved back together already,
so avs_is_field_based should actually report 'false' when
checked.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
It is only used by the H.264 decoder (as well as the dirac decoder,
which already uses a local copy).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This piece of code has been added in an already commented-out state
in commit 158c7f059c. It certainly
doesn't make sense now (if ever) because new_picture_ptr it used
has been removed in 6571e41dcd
(and new_picture is only used for encoding).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
mpegvideo-based encoders supporting bframes implement this
by opening encoders of their own to test how long the chains
of bframes are supposed to be. The needed AVCodec was obtained
via avcodec_find_encoder(). This is complicated, as the current
encoder can be directly obtained. And it also is not guaranteed
that one actually gets the current encoder or not another encoder
for the same codec ID (the latter does not seem to be the case now).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MpegEncContext is used by many different codecs and
every one of these uses just a subset of its fields.
If one tries to separate this and e.g. add a real MpegContext
and extension structures (say MpegDecContext and MpegEncContext),
one runs into two difficulties:
a) Some code is shared between decoder and encoder of
the same format and they therefore use the same contexts,
either MpegEncContext itself or identical extensions thereof.
The latter is the case for H.261 as well as WMV2.
b) In case of slice threading, the generic code can only allocate
and initialize the structure it knows about; right now this is
an MpegEncContext. If the codec has an even more extensive structure,
it is only available for the main thread's MpegEncContext.
Fixing this would involve making ff_mpv_common_init() aware
of the size the size of slice context to allocate and would be
part of separating the main thread's context from the slice contexts
in general.
This commit only intends to tackle the first issue by adding
a pointer to MpegEncContext that codecs can set to a common
context so that the aforementioned codecs can use this context
(together with the MpegEncContext) in their common code.
This will allow to move fields only used by the main thread
to more specialized contexts.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes ticket 9086.
Since early 2021, some of YouTube's VP9 encodes have non-monotonous DTS.
This makes ffmpeg fatally fail when trying to copy or encode the V9 video.
ffmpeg already includes functionality to correct this, however it was
disabled without explanation for VP9 stream copies in
2e6636aa87
This patch restores the DTS correction logic, and allows ffmpeg to correctly
encode (invalid) videos produced by youtube.com. I have verified that frames
are NOT being cut (so it does not re-introduce 4313).
Reviwed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Nothing with static storage duration is initialized by these codecs.
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Suggested by zhilizhao, vlc project has solved the compatibility by
the same way, so I borrowed the comments from vlc project.
Fixes ticket #9449
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Zhao Zhili added a ttl upper bound in commit 9daac85da8,
but the check for ttl in url is missing still.
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Add command 'delays' to the adelay filter.
This command accepts same values as the option with one difference, to apply
delay to all channels prefix 'all:' to the argument.
Signed-off-by: David Lacko <deiwo101@gmail.com>
It is sane, but UB. It could happen in case of allocation errors
in vc2_encode_init().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Using Range allows for getting the full file size from the
Content-Range header in the response, even if the server sends
back the response using chunked Transfer-Encoding, which does not
allow using Content-Length.
When Transfer-Encoding:chunked is used, the client must ignore a
Content-Length header, if present. However, it should not ignore a
Content-Range header, which also includes the full size of the
entity.
As the potential failure of the av_mallocz(), the 's->alpha_context'
could be NULL and be dereferenced later.
Therefore, it should be better to check it and deal with it if fails
in order to prevent memory leak, same as the av_frame_alloc() in
ff_vp56_init().
Fixes: 39a3894ad5 ("lavc/vp6: Implement "slice" threading for VP6A decode")
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
bca30570d2 added a user option to set max_packet_size replacing
a hardcoded value. This had a side-effect of leaving the field
set to 0 when packet demuxing is carried out from another demuxer
using avpriv functions, which could lead to demux failure.
Hardcoded max_packet_size inside avpriv_mpegts_parse_open to
2048000 to avoid this. Value chosen to be 10x that of default value
to accommodate large payloads.
Use ff_thread_release_buffer() instead of av_frame_unref(),
as the former handles the case of non-thread-safe callbacks
properly. (This is possible now that ff_thread_release_buffer()
no longer requires a ThreadFrame.)
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The majority of frame-threaded decoders (mainly the intra-only)
need exactly one part of ThreadFrame: The AVFrame. They don't
need the owners nor the progress, yet they had to use it because
ff_thread_(get|release)_buffer() requires it.
This commit changes this and makes these functions work with ordinary
AVFrames; the decoders that need the extra fields for progress
use ff_thread_(get|release)_ext_buffer() which work exactly
as ff_thread_(get|release)_buffer() used to do.
This also avoids some unnecessary allocations of progress AVBuffers,
namely for H.264 and HEVC film grain frames: These frames are not
used for synchronization and therefore don't need a ThreadFrame.
Also move the ThreadFrame structure as well as ff_thread_ref_frame()
to threadframe.h, the header for frame-threaded decoders with
inter-frame dependencies.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These will be used by the codecs that need allocated progress
and is in preparation for no longer using ThreadFrame by the codecs
that don't.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is in preparation for further commits that will stop
using ThreadFrame for frame-threaded codecs that don't use
ff_thread_(await|report)_progress(); the API for those codecs
having inter-frame depdendencies will live in threadframe.h.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Several of our decoders support both frame- as well as slice-threading;
in case of the latter avctx->internal->thread_ctx points to
a SliceThreadContext, not to a frame-thread PerThreadContext.
So only treat avctx->internal->thread_ctx as the latter after
having checked that frame-threading is active.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: left shift of 32768 by 16 places cannot be represented in type 'int'
Fixes: Timeout
Fixes: 44219/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SMVJPEG_fuzzer-4679455379947520
Fixes: 44088/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SMVJPEG_fuzzer-4885976600674304
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Since e9b6617579 a codec's close
function is never ever called for a codec whose init function has not
been called; in particular, it is never ever called if the
AVCodecContext's private data has not been allocated.
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Before, seeking in hls streams would always seek to the next keyframe
after the given timestamp. With this fix, if seeking in videostream and
AVSEEK_FLAG_BACKWARD is set, seeking will be to the first keyframe of
the segment containing the given timestamp. This fixes#7485.
Signed-off-by: Gustav Grusell <gustav.grusell@gmail.com>
Otherwise nasm writes the full host-specific paths into .o
output, which breaks binary reproducibility.
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This is by definition the appropriate place for it.
Remove all the now unnecessary libavcodec/internal.h inclusions;
also remove other unnecessary headers from the affected files.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
avpriv_find_start_code() supports non-contiguous buffers
by maintaining a state that allows to find start codes
that span across multiple buffers; a consequence thereof
is that avpriv_find_start_code() is given a zero-sized
buffer, it does not modify this state, so that it appears
as if a start code was found if the state contained a start code.
This can e.g. happen with Sequence End units in MPEG-2 and
to counter this, cbs_mpeg2_split_fragment() reset the state
when it has already encountered the end of the fragment
in order to add the last unit (if it is only of the form 00 00 01 xy)
only once; it also used a flag to set whether this is the final unit.
Yet this can be improved by simply resetting state unconditionally
(thereby avoiding a branch); the flag can be removed by just checking
whether we have a valid start code (of the next unit to add)
at the end.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use -1 as the position in ff_cbs_insert_unit_data()
which implicitly reuses frag->nb_units as the counter.
Also switch to a do-while-loop, as it is more natural
than a for-loop now that the counter is gone.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use -1 as the position in ff_cbs_insert_unit_data()
which implicitly reuses frag->nb_units as the counter.
Also switch to a do-while-loop, as it is more natural
than a for-loop now that the counter is gone.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
getauxval is marginally faster, and works even when procfs is not mounted
support on Linux was added in glibc 2.16
support on Android was added in 4.4 (API 20)
fixes#6578
Signed-off-by: Aman Karmani <aman@tmm1.net>
This commit does some refactoring to make defining assembly codelets
smaller, and fixes compiler redefinition warnings. It also allows
for other assembly versions to reuse the same boilerplate code as
x86.
Finally, it also adds the out_of_place flag to all assembly codelets.
This changes nothing, as out-of-place operation was assumed to be
available anyway, but this makes it more explicit.
Users should switch to the superior AVFifo API.
Unfortunately AVFifoBuffer fields cannot be marked as deprecated because
it would trigger a warning wherever fifo.h is #included, due to
inlined av_fifo_peek2().
Many AVFifoBuffer users operate on fixed-size elements (e.g. pointers),
but the current FIFO API deals exclusively in bytes, requiring extra
complexity in all these callers.
Add a new AVFifo API creating a FIFO with an element size
that may be larger than a byte. All operations on such a FIFO then
operate on complete elements.
This API does not reuse AVFifoBuffer and its API at all, but instead uses
an opaque struct called AVFifo. The AVFifoBuffer API will be deprecated
in a future commit once all of its users have been switched to the new
API.
Not reusing AVFifoBuffer also allowed to use the full range of size_t
from the beginning.
The API currently allows creating FIFOs up to
- UINT_MAX: av_fifo_alloc(), av_fifo_realloc(), av_fifo_grow()
- SIZE_MAX: av_fifo_alloc_array()
However the usable limit is determined by
- rndx/wndx being uint32_t
- av_fifo_[size,space] returning int
so no FIFO should be larger than the smallest of
- INT_MAX
- UINT32_MAX
- SIZE_MAX
(which should be INT_MAX an all commonly used platforms).
Return an error on trying to allocate FIFOs larger than this limit.
Avoids code duplication. It furthermore properly checks
for buf_size to be > 0 before doing anything.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This reduces sibilance distortion when sibilance and bass are
present at the same time. Bringing the protection of high
frequencies up to about the same level as for low frequencies
should also make the quality less dependent on the frequency
balance of the playback system.
Signed-off-by: Jason Jang <jcj83429@gmail.com>
Ignore more samples that are near the edge of the block. The reason
is that the filtering tends to cause these samples to go above the
window more than the samples near the middle. If these samples are
included in the unwindowed peak estimation, the peak can be
overestimated. Because the block is windowed again before
overlapping, overshoots near the edge of the block are not very
important.
0.1 is the value from the version originally contributed to calf.
Signed-off-by: Jason Jang <jcj83429@gmail.com>
With a complex FFT instead of real FFT, the negative frequencies
are not dropped from the spectrum output, so they need to be scaled
when the positive frequencies are scaled. The location of the top
bin is also different.
Signed-off-by: Jason Jang <jcj83429@gmail.com>
In previous state, a new frame was allocated on each timestamp step,
i.e. each frame/field transition. However, for interlace, a new frame
should be allocated on 1st field, completed with the 2nd and finally
freed.
This commit fixes the frame allocation and the detection of missing RTP
markers.
Signed-off-by: Patrick Keroulas <patrick.keroulas@radio-canada.ca>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
The fdk-aac decoder can return decoded audio data with a delay.
(Whether it does this or not depends on the options set; by default
it does add some delay.) Previously, this delay was handled by
adjusting the timestamps of the decoded frames, but the last delayed
samples weren't returned.
Set the AV_CODEC_CAP_DELAY flag to indicate that the caller should
flush remaining samples at the end. Also trim off the corresponding
amount of samples at the start instead of adjusting timestamps.
Signed-off-by: Martin Storsjö <martin@martin.st>
At present, side data printing forces display for all levels i.e.
stream, packets and frames. This can bloat output and also force
decode of all frames in selected streams.
Now, stream_side_data[=type], packet_side_data[=type] &
frame_side_data[=type] can be used with -show_entries to specify carrier
element.
VkPhysicalDeviceVulkan12Features isn't implemented on MoltenVK yet.
VkPhysicalDeviceTimelineSemaphoreFeatures is less versatile but
simple. None of device_features_1_1 nor device_features_1_2 has real
usage yet, keep the code for future.
We still own it on failure, and there's no point trying to feed it again.
This should address the issue reported in dav1d #383 and part of VLC #26259.
Signed-off-by: James Almer <jamrial@gmail.com>
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Fixes: signed integer overflow: -9223372036854775808 - 8 cannot be represented in type 'long'
Fixes: 43542/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5237670148702208
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
av_dict_set() with AV_DICT_DONT_STRDUP_VAL takes ownership
of the string it is passed to as val; this includes freeing it
on error.
Fixes Coverity issue #1497468.
Reviewed-by: Eran Kornblau <eran.kornblau@kaltura.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
following 625ea2d, redirect caching is performed according to the http
response headers, there's no need to have it as an option -
always start from the original uri, and apply any redirects according
to the redirect_cache dictionary.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Since e1027aba68,
ALLOW_INTERLACED is no longer defined in h264_ps.c,
leading to a warning when encountering an SPS compatible
with MBAFF. This warning was always nonsense, because
ff_h264_decode_seq_parameter_set() is also used by the parser
and it makes no sense for the parser to warn about missing
decoder features; after all, it is not a parser's job
to warn when a feature is unsupported by a decoder
(and in this case it is even weirder, because even if the H.264
decoder is disabled, the warning will only be shown for MBAFF
sequence parameter sets). So remove the warning in h264_ps.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
use_intra_dc_vlc is currently kept in sync between frame threads
in mpeg4_update_thread_context(), yet it is set when decoding
blocks, i.e. after ff_thread_finish_setup(). This is a data race
and therefore undefined behaviour.
This race can be fixed easily by moving the variable from the context
to the stack: use_intra_dc_vlc is only read in
mpeg4_decode_block() and only if one is decoding an intra block.
There are three callsites for this function: One in
mpeg4_decode_partitioned_mb() which always sets use_intra_dc_vlc
before the call and two in mpeg4_decode_mb(). One of these callsites
is for intra blocks and use_intra_dc_vlc is set before it;
the last callsite is for non-intra blocks, where use_intra_dc_vlc
is ignored. So if it is used, it always uses a new value and can
therefore be moved to the stack.
The above also explains why this data race did not lead to
FATE-test failures.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
An offset has the advantage of not needing to be updated
when the buffer is reallocated. Furthermore, the way the pointer
is currently updated is undefined behaviour in case the pointer
is not already set (i.e. when not encoding MPEG-1/2), because
it calculates the nonsense NULL - s->pb.buf.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also use said function in mpegvideo.c and mpegvideo_enc.c;
and make ff_free_picture_tables() static as it isn't needed anymore
outside of mpegpicture.c.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible now that dealing with the Simple Studio Profile
has been moved to mpeg4videodec.c. It also allows to avoid
allocations, because one can simply put the required buffers
on the context (if one made these buffers part of MpegEncContext,
the memory would be wasted for every codec other than MPEG-4).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The sample mpeg4/mpeg4_sstp_dpcm.m4v existed in the FATE-suite,
but it was surprisingly unused.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In this case the macroblocks written to are smaller, yet
the MPEG-4 Simple Studio Profile code for 10bit DPCM ignored this;
e.g. in case of lowres = 2 or = 3, the sample mpeg4_sstp_dpcm.m4v
from the FATE-suite reads beyond the end of the buffer.
This commit fixes this by taking lowres into account.
The DPCM macroblocks of the aforementioned sample look
as good as can be expected after this patch; yet the non-DPCM
coded macroblocks are simply corrupt.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
jpeg2000_decode_tile() (which is run concurrently by several threads
when using slice threading) currently modifies some joint values
before doing its actual work. This is a data race that happens to work
because all threads set the same values; but it is nevertheless
undefined behaviour.
Fix this by performing said preparatory work in the main thread instead.
This fixes the vsynth(1|2|_lena)-jpeg2000(-97)? FATE-tests when using
TSAN and slice threading.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When AV_CODEC_EXPORT_DATA_FILM_GRAIN is present, AV1 decoder should
disable film grain application and export the corresponding side data
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
For vaapi if the init_pool_size is not zero, the pool size is fixed.
This means max surfaces is init_pool_size, but when mapping vaapi
frame to qsv frame, the init_pool_size < nb_surface. The cause is that
vaapi_decode_make_config() config the init_pool_size and it is called
twice. The first time is to init frame_context and the second time is to
init codec. On the second time the init_pool_size is changed to original
value so the init_pool_size is lower than the reall size because
pool_size used to initialize frame_context need to plus thread_count and
3 (guarantee 4 base work surfaces). Now add code to make sure
init_pool_size is only set once. Now the following commandline works:
ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 \
-hwaccel_output_format vaapi -i input.264 \
-vf "hwmap=derive_device=qsv,format=qsv" \
-c:v h264_qsv output.264
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Makes Bulldozer prefer AVX functions rather than AVX2,
which are 64% slower:
AVX: 117653 decicycles in av_tx (fft), 1048535 runs, 41 skips
AVX2: 193385 decicycles in av_tx (fft), 1048561 runs, 15 skips
The only difference between both is that vgatherdpd is used in
the former. We don't want to mark them with the new SLOW_GATHER
flag however, since gathers are still faster on Haswell/Zen 2/3
than plain loads.
If a codelet initializes 2 subtransforms, and the second one fails,
the failure would free all subcontexts.
Instead, if there are subcontexts still left, don't free the array.
If all initializations fail, the init() function will return,
and reset_ctx() from the previous step will clean up all contained
subtransforms.
Fix CID: 1497864
The control flow should return ENOSYS if nb_cd_matches is 0 at before
and the ret equal AVERROR(ENOMEM) or goto end label, so remove the last
control flow if (ret >= 0) before end label.
Signed-off-by: Steven Liu <liuqi05@kuaishou.com>
Add intra refresh support to hevc_qsv as well.
Add an new intra refresh type: "horizontal", and an new param
ref_cycle_dist. This param specify the distance between the
beginnings of the intra-refresh cycles in frames.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Add b_strategy option to hevc_qsv. By enabling this option, encoder can
use b frames as reference.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
This broke builds with --disable-mmx, which also disabled assembly
entirely, but ARCH_X86 was still true, so the init file tried to find
assembly that didn't exist.
Instead of checking for architecture, check if external x86 assembly
is enabled.
E.g. the inclusion of parser.h comes from a time when
the parser used a H264Context.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is only needed by h264_cabac.c and h264_cavlc.c.
Also fix up the other headers while at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only thing that is actually used directly from there is the
PART_NOT_AVAILABLE constant, which can be moved to h264pred.h.
Otherwise it only depends on other indirectly included headers.
RDFTs are full of conventions that vary between implementations.
What I've gone for here is what's most common between
both fftw, avcodec's rdft and what we use, the equivalent of
which is DFT_R2C for forward and IDFT_C2R for inverse. The
other 2 conventions (IDFT_R2C and DFT_C2R) were not used at
all in our code, and their names are also not appropriate.
If there's a use for either, we can easily add a flag which
would just flip the sign on one exptab.
For some unknown reason, possibly to allow reusing FFT's exp tables,
av_rdft's C2R output is 0.5x lower than what it should be to ensure
a proper back-and-forth conversion.
This code outputs its real samples at the correct level, which
matches FFTW's level, and allows the user to change the level
and insert arbitrary multiplies for free by setting the scale option.
This commit rewrites the internal transform code into a constructor
that stitches transforms (codelets).
This allows for transforms to reuse arbitrary parts of other
transforms, and allows transforms to be stacked onto one
another (such as a full iMDCT using a half-iMDCT which in turn
uses an FFT). It also permits for each step to be individually
replaced by assembly or a custom implementation (such as an ASIC).
This long-existing feature calculates subtitle durations by keeping
it around until the following subtitle is decoded, and then utilizes
the following subtitle's pts as the end point of the previous one.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
"qf->frame" ref to input frame but it isn't released. av_frame_unref()
is added before refering qf->frame to new frame to make sure the previous
reference is released.
Reported-by: Mark Samuelson <Mark.Samuelson@sonicfoundry.com>
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Inside a function an unnecessary ';' is just a null statement;
yet outside of it it is actually illegal (but compilers happen
to accept it without warning except when using -pedantic).
So modify the macros to always expect the user to add a ';'.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Peeking into the muxing queue can improve the estimate of
the lowest timestamp needed for avoid_negative_ts in case
the lowest timestamp is in a packet other than the first packet
to be muxed.
This fixes tickets #4536 and #5784 as well as the output from
the matroska-avoid-negative-ts FATE-test.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
write_packet() has code to shift the packets timestamps
to make them nonnegative or even make them start at ts zero;
this code inspects every packet that is written and if a packet
with negative timestamp (whether this is dts or pts depends upon
another flag; basically: Matroska uses pts, everyone else dts)
is encountered, this is offset to make the timestamp zero.
All further packets will be offset accordingly (with the offset
converted according to the streams' timebases).
This is based around an assumption, namely that the timestamps
are indeed non-decreasing, so that the first packet with negative
timestamps is the first packet with timestamps. This assumption
is often fulfilled given that the default interleavement function
by default interleaves per dts; yet there are scenarios in which
it may not be fulfilled:
a) av_write_frame() instead of av_interleaved_write_frame() is used.
b) The audio_preload option is used.
c) When the timestamps that are made nonnegative/zero are pts
(i.e. with Matroska), because the packet with the smallest dts
is not necessarily the packet with the smallest pts.
d) Possibly with custom interleavement functions.
In these cases the relative sync of the first few packet(s) is offset
relative to the later packets. This contradicts the documentation
("When shifting is enabled, all output timestamps are shifted by
the same amount").
Therefore this commit changes this: As soon as the first packet
with valid timestamps is output, it is checked and recorded whether
the timestamps need to be shifted. Further packets are no longer
checked for needing to be offset; instead they are simply offset.
In the cases above this leads to packets with negative timestamps
(and the appropriate warnings) instead of desync. This will mostly
be fixed in the next commit.
This commit also factors handling the avoid_negative_ts stuff out
of write_packet() in order to be able to return immediately.
Tickets #4536 and #5784 as well as the matroska-avoid-negative-ts-test
are examples of c); as has been said, some timestamps are now negative,
yet the ref file update does not show it because ffmpeg.c sanitizes
the timestamps (-copyts disables it; ffprobe and mkvinfo also show
the original timestamps).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This assert is based upon the wrong assumption that
the noninterleaved codepath is never used; if it is used,
max_interleave_delta is irrelevant. It furthermore
ignores audio_preload.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MOVAtom.type is always read as a little-endian number
(despite MOV/ISOBMFF being big-endian).
Fixes the matroska-dovi-write-config8 FATE-test on big-endian
arches (which runs into the "index out of range" warning message).
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add transform_skip option to hevc_qsv. By enabling this option,
the transform_skip_enabled_flag in PPS will be set to 1.
This option is supported on the platform equal or newer than ICL.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Add dblk_idc option to 264_qsv and hevc_qsv. Turining on this opion can
disable deblocking.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
According to the documentation, the ISOBMFF 'equi' box must
be present for equirectangular projections.
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Tests the parsing and writing of AVDOVIDecoderConfigurationRecord,
when it is present as a Dolby Vision configuration block addition mapping.
Signed-off-by: quietvoid <tcChlisop0@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids copying the data in small chunks (1024B) into
the dynamic buffer's small buffer before finally writing them
into the "big" buffer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, the WebM variant of WebVTT subtitles has been handled
specially: It had its own function to write it, because the data
had to be reformatted before writing. But given that other codecs
also need reformatting, this is no good reason to also duplicate the
generic stuff for writing Block(Group)s.
This commit therefore uses an ordinary reformatting function for
this task; writing WebVTT subtitles now uses the generic code
and therefore automatically uses the least amount of bytes
for its BlockGroup length fields whereas the earlier code used
an overestimation for the length of the Duration element.
This is the reason for the changes to the webm-webvtt-remux FATE-test.
(This commit does not implement support for Matroska's way of muxing
WebVTT; it also does not add checks to ensure that WebM-style subtitles
don't get muxed in Matroska. But the function for reformatting gets a
webm prefix to indicate that this is for WebM.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This commit uses the new EbmlWriter API to write the length fields
of the BlockGroup and its descendants that are themselves Master
elements (namely BlockAdditions and BlockMore) on the least amount of
bytes.
This fixes regressions introduced when the special code for writing
general subtitles was removed. Accordingly, the binsub-mksenc and
matroska-zero-length-block FATE-tests have now been reverted back
to their old state again; the advantages of this approach are evident
with the matroska-vp8-alpha-remux test which up until now wrote
all the length fields of all BlockGroups, BlockAdditions and BlockMore
on eight bytes.
Using the EbmlWriter API also allowed to improve locality in
mkv_write_block(): E.g. both DiscardPadding as well as the
BlockAdditional side-data are now directly used to add elements
to the writer whereas the earlier code had to first check
for whether a BlockGroup should be used and then check again
(after the place where a BlockGroup would be opened if one were
used) for whether there is DiscardPadding or BlockAdditional
side-data to write.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add a field to mkv_track that is set to the offset instead
of checking for whether the track is ProRes when writing
the Block. This makes writing the Block independent
of the AVCodecParameters.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This e.g. stops recalculating ts again.
Also pass the AVFormatContext as pointer to void as it is only used
for logging.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Once upon a time, mkv_write_block() only wrote a (Simple)Block,
not a BlockGroup which is needed for subtitles to convey
the duration. But with the introduction of support for writing
BlockAdditions and DiscardPadding (both of which require a BlockGroup),
mkv_write_block() can also open and close a BlockGroup of its own. This
naturally led to some code duplication which is removed in this commit.
This new code leads to one regression: It always uses eight bytes for
the BlockGroup's length field, whereas the earlier code usually used the
lowest amount of bytes needed. This will be fixed in a future commit.
This temporary regression is also the reason for changes to the
binsub-mksenc and matroska-zero-length-block fate tests.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do this by using the new NALUList API. This avoids an allocation
of a dynamic buffer per packet as well as the (re)allocation
of the actual buffer as well as copying the data around.
This improves performance: The time for one call to write_packet
decreased from 703501 to 357900 decicyles when remuxing a 5min
14000 kb/s H.264 transport stream.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This will allow to avoid the temporary buffer and memcpys
when repacketing annex B to mp4-style H.264/H.265 without
searching twice for start codes.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Matroska does not have different profiles that allow or disallow
in-band extradata, so one can just use the ordinary H.264 function
for H.265, too. (Both use ff_avc_parse_nal_units() internally anyway.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids allocations+copies in all cases, not only those
in which the desired OBUs are contiguous in the input buffer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Document that it can be used with a NULL AVIOContext to
get the output size in a first pass.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
WavPack's blocks use a length field, so that parsing them is fast.
Therefore it makes sense to parse the block twice, once to get
the length of the output packet and once to write the actual data
instead of writing the data into a temporary buffer in a single pass.
This speeds up muxing from 1597092 to 761850 Decicycles per
write_packet call for a 2000kb/s stereo WavPack file muxed to /dev/null
with writing CRC-32 disabled.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Matroska uses variable-length elements and in order not to waste
bytes on length fields, the length of the data to write needs to
be known before writing the length field. Annex B H.264/5 and
WavPack need to be reformatted to know this length and this
currently involves writing the data into temporary buffers;
AV1 sometimes suffers from this as well.
This commit aims to solve this by adding a callback that is called
twice per packet: Once to get the size and once to actually write
the data. In case of WavPack and AV1 (where parsing is cheap due
to length fields) both calls will just parse the data with only
the second function writing anything. For H.264/5, the position
of the NALUs will need to be stored to be written lateron.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Avoids the surprise of using pb for the main AVIOContext
at the beginning and end of mkv_write_header() and for
for the dynamic buffer opened for the Info element
in the middle of mkv_write_header().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Using start/end_ebml_master() to write an EBML Master element
uses seeks under the hood. This does not work if the output is
unseekable with the AVIOContext's buffer being very small
(the size of the currently written Matroska EBML header is 40)
or with the AVIOContext being in direct mode, because then
this seek can't be performed in the AVIOContext's buffer.
So using an approach that does not rely on seeking at all
is preferable; this is achieved by switching to EbmlWriter.
Also factor writing the EBML header out into a function of its own.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also check the (user-provided) tags for being overlong; the earlier
code had an implicit unchecked size_t->int conversion.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This muxer currently uses two ways to ensure that no bytes
are wasted by writing unnecessary long EBML length fields
for Master elements and the (Simple)Block element
(all the other elements are fine as one either already has
the right length or getting the actual length is easy
and necessary anyway):
Either use an upper bound that is good enough in case one
is available or write the data into a dynamic buffer first
to get the length; the former approach is impossible in
lots of cases, whereas the latter incurs allocations and
memcpying. It is therefore unfeasible to use the latter
for e.g. the attachments or the BlockGroups.
This patch adds a third alternative to complement the other two:
It consists of an EbmlWriter that one can add EBML elements to
that can be written later by calling ebml_writer_write();
the latter function first traverses the written elements recursively
and calculates the length of each element; then a second pass
is performed in which all the elements are written directly
(without any seeks).
This new API also performs checks for overlong elements;
this is in contrast to put_ebml_string() which simply performs
a size_t->int conversion even for strings originating from the user.
The new API is designed to have very low overhead: It uses
stack arrays and performs no allocations; this also comes
at a price: Right now, it can only be used in contexts in which
there is a compile-time upper bound for the number of elements.
It is also incompatible with storing the offset of an element
in order to update this field later. Furthermore, it puts
the onus of memory management (i.e. ensuring that pointers stay valid)
on the user.
These restrictions might be overcome in the future.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This would happen in case non-WebVTT-subtitles had BlockAdditional
or DiscardPadding side-data. Given that these are not accounted for
in the length of the outer BlockGroup (which is a quite sharp upper
bound) it is possible for the outer BlockGroup to use an insufficient
number of bytes which leads to an assert in end_ebml_master().
Fix this by not opening a second BlockGroup inside an already opened
BlockGroup.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
add a dictionary that maps "src_url" -> "expiry;dst_url", the dictionary
is checked before issuing an http request, and updated after getting a
3xx redirect response.
the cache expiry is determined according to the following (in desc
priority) -
1. Expires header
2. Cache-Control containing no-cache/no-store (disables caching)
3. Cache-Control s-maxage/max-age
4. Http codes 301/308 are cached indefinitely, other codes are not
cached
The SDK may insert picture timing SEI for hevc and the code to set mfx
parameter has been added in qsvenc, however the corresponding option is
missing in the hevc option array
Reviewed-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Overlay one video on the top of another.
It takes two inputs and has one output. The first input is the "main" video on
which the second input is overlaid. This filter requires same memory layout for
all the inputs.
An example command to use this filter to overlay overlay.mp4 at the top-left
corner of the main.mp4:
ffmpeg -init_hw_device vaapi=foo:/dev/dri/renderD128 \
-hwaccel vaapi -hwaccel_device foo -hwaccel_output_format vaapi -c:v h264 -i main.mp4 \
-hwaccel vaapi -hwaccel_device foo -hwaccel_output_format vaapi -c:v h264 -i overlay.mp4 \
-filter_complex "[0:v][1:v]overlay_vaapi=0:0:100:100:0.5[t1]" \
-map "[t1]" -an -c:v h264_vaapi -y out_vaapi.mp4
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Signed-off-by: Xinpeng Sun <xinpeng.sun@intel.com>
Signed-off-by: Zachary Zhou <zachary.zhou@intel.com>
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
To trigger this bug, use `paletteuse=dither=bayer:bayer_scale=0`; you will see
that adjacent pixel lines will use the same dither pattern, instead of being
shifted from each other by 32 units (0x20).
One way to demostrate the bug is:
$ convert -size 64x256 gradient:black-white -rotate 270 grad.png
$ echo 'P2 2 1 255 0 255' > bw.pnm
$ ffmpeg -i grad.png -filter_complex 'movie=bw.pnm,scale=256x1[bw]; [0:v][bw]paletteuse=dither=bayer:bayer_scale=0' gradbw.png
Previously: https://www.rm.cloudns.org/img/uploaded/0bd152c11b9cd99e5945115534b1bdde.png
Now: https://www.rm.cloudns.org/img/uploaded/89caaa5e36c38bc2c01755b30811f969.png
This was caused by passing inconsistent color vs (a,r,g,b) parameters to
color_get(), and NBITS being 5 meaning actually hitting the same cache node
does happen in this case, but ONLY if bayer_scale is zero.
The fix is passing the correct color value to color_get().
Also added a previous-failing FATE test; image comparison of the first frame:
Previously: https://www.rm.cloudns.org/img/uploaded/d0ff9db8d8a7d8a3b8b88bbe92bf5fed.png
Now: https://www.rm.cloudns.org/img/uploaded/a72389707e719b5cd1c58916a9e79ca8.png
(on this less synthetic test image, the bug basically causes noise from cache
hits vs misses)
Tested: FATE passes, which exercises this filter but at the default bayer_scale.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
This resulted in a dimmed tonemapping due to bad resulting luma
calculation.
Found by: Derek Buitenhuis
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
For high/main profile, user can choose to use cavlc by specify "-coder cavlc",
for default, it'll will use cabac, if it's baseline, we'll use cavlc by specs anyway.
ffmpeg -y -f lavfi -i testsrc -c:v libopenh264 -profile:v main -coder cavlc -frames:v 1 -bsf trace_headers -f null -
before the patch:
entropy_coding_mode_flag 0 = 1
after the patch:
entropy_coding_mode_flag 0 = 0
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
due to the limitations set in d3a7bdd4ac,
you weren't able to use main profile with OpenH264 1.8, or high profile
with older versions
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
This is similar to the faststart option of the mov muxer, yet
in contrast to it it works together with reserve_index_space
(the equivalent to reserved_moov_size): If the reserved space
does not suffice, the data is shifted; if not, the Cues are
written at the front without shifting the data.
Several tests that cover (not only) this have been added.
Implements #7017.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The current size is AV_NUM_DATA_POINTERS (i.e. eight).
This number is chosen in order to minimize the amount of allocations
for AVFrame.extended_(data|buf) for audio; it is meaningless
for video for which four is sufficient. So decrease this array
in order to minimize what is copied in ff_mpeg_ref_picture()
and at the places that copy a whole MpegEncContext.
Also do the same for snowenc.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These messages belong together, yet they can be torn apart
if some other call to av_log() happens between them.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
RV40, SVQ3 and VP7/VP8 are eight-bit only, so it makes no sense
to check for them in the codepath initializing > eight bit contexts.
Move the codec-specific code to a switch located after the eight-bit
init code where this is easily possible; and add checks to the macro
to enable the compiler to remove the remaining checks when initializing
bitdepths > 8 at compile-time.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
qHD is 960x540 (q stands for quarter) and QHD is 2560x1440 (Q is quad).
use quadhd for QHD for abbreviation.
Fix ticket#9591
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
For DeinterlacingBob mode with rate=field, the frame number of output
should equal 2x input total since only intra deinterlace is used.
Currently for "backward_ref = 0, rate = field", extra_delay is
introduced. Due to the async without flush, frame number of output is
[expected_number - 2].
Specifically, if the input only has 1 frame, the output will be empty.
Add deint_vaapi_request_frame for deinterlace_vaapi, send NULL frame
to flush the queued frame.
For 1 frame input in Bob mode with rate=field,
before patch: 0 frame;
after patch: 2 frames;
ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128
-hwaccel_output_format vaapi -i input.h264 -an -vf
deinterlace_vaapi=mode=bob:rate=field -f null -
Tested-by: Mark Thompson <sw@jkqxz.net>
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
MSDK vc1 and av1 sometimes output frame into the same suface, but
ffmpeg-qsv assume the surface will be used only once, so it will
unref the frame when it receives the output surface. Now change
it to unref frame according to queue count.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Trying to write too much will currently overwrite previous data. Trying
to read too much will either av_assert2() in av_fifo_drain() or return
old data. Trying to peek too much will either av_assert2() in
av_fifo_generic_peek_at() or return old data.
Return an error code in all these cases, which is safer and more
consistent.
It returns a pointer inside the fifo's buffer, which cannot be safely
used without accessing AVFifoBuffer internals. It is easier and safer to
use av_fifo_generic_peek_at().
FLAC parser currently uses AVFifoBuffer in a highly non-trivial manner,
modifying its "internals" (the whole struct is currently public, but no
other code touches its contents directly). E.g. it does not use any
av_fifo functions for reading the FIFO contents, but implements its own.
Reimplement the needed parts of the AVFifoBuffer API in the FLAC parser,
making it completely self-contained. This will allow us to make
AVFifoBuffer private.
mvhd and tkhd present the post-editlist duration, while mdhd should
have the pre-editlist duration. Regression since c2424b1f3.
Signed-off-by: Martin Storsjö <martin@martin.st>
This was accidentally comparing s->colorspace against out->colorspace,
which is wrong - the intent was to compare in->colorspace against
out->colorspace.
We also forgot to strip mastering metadata. Finally, the order is sort
of wrong - we should strip this side data *before* process_frames,
because otherwise it may end up being seen and used by libplacebo.
Signed-off-by: Niklas Haas <git@haasn.dev>
Commit 8b83dad825 introduced a
regression in a way that scaling via vpp_qsv doesn't work any longer
for devices with an MSDK runtime version lower than 1.19. This is true
for older CPUs which are stuck at 1.11.
The commit added checks for the compile-sdk version but it didn't test
for the runtime version.
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Return an error directly if pixfmt is not supported for encoding, otherwise
it may be hidden until query/check in MSDK.
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Channel reordering is removed from this patch because the new channel layout
API will support it properly.
Signed-off-by: Marton Balint <cus@passwd.hu>
Fixes decoding of sample https://streams.videolan.org/ffmpeg/incoming/720p60.mp4
on RPi4 after kernel driver commit:
staging: bcm2835-codec: Format changed should trigger drain
Reference:
linux/Documentation/userspace-api/media/v4l/dev-decoder.rst
"A source change triggers an implicit decoder drain, similar to the
explicit Drain sequence. The decoder is stopped after it completes.
The decoding process must be resumed with either a pair of calls to
VIDIOC_STREAMOFF and VIDIOC_STREAMON on the CAPTURE queue, or a call to
VIDIOC_DECODER_CMD with the V4L2_DEC_CMD_START command."
Reviewed-by: Andriy Gelman <andriy.gelman@gmail.com>
Signed-off-by: Ming Qian <ming.qian@nxp.com>
Reference:
linux/Documentation/userspace-api/media/v4l/dev-decoder.rst
"During the resolution change sequence, the OUTPUT queue must remain
streaming. Calling VIDIOC_STREAMOFF() on the OUTPUT queue would
abort the sequence and initiate a seek.
In principle, the OUTPUT queue operates separately from the CAPTURE
queue and this remains true for the duration of the entire
resolution change sequence as well."
Reviewed-by: Andriy Gelman <andriy.gelman@gmail.com>
Signed-off-by: Ming Qian <ming.qian@nxp.com>
avcodec_open2() is supposed to be thread-safe (those codecs
whose init functions are not thread-safe are guarded
by a global lock).
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since the MPEG-4 parser no longer initializes some MPEG-4 VLCs,
no VLC is initialized concurrently by multiple threads
(initializing static VLCs is guarded by locks and nonstatic VLCs
never posed an issue in this regard). So remove the code
in bitstream.c that only exists because of this possibility.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It can't any longer, because all users of ff_rl_init() are now
behind ff_thread_once() or the global codec lock. Therefore
the check for whether the RLTable is already initialized can be removed;
as can the stack buffers that existed to make sure that nothing is ever
set to a value different from its final value.
Similarly, it is not necessary to check whether the VLCs associated
with the RLTable are already initialized (they aren't).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Both the MPEG-4 parser as well as the decoder initialized
several VLCs. There is a "static int done = 0;" in order to
guard against initializing these multiple times, but this does
not work when several threads try to initialize these VLCs
concurrently, which can happen when initializing several parsers
at the same time (they don't use the global lock that is used
for codecs without the FF_CODEC_CAP_INIT_THREADSAFE cap; actually,
they don't use any lock at all).
Since ff_mpeg4_decode_picture_header() now aborts early when called
from the parser, it no longer needs to have these VLCs initialized
at all. This commit therefore does exactly this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Namely, skip some elements that are only useful for a decoder
when calling ff_mpeg4_decode_picture_header() from the MPEG-4 parser.
In particular, this ensures that the VLCs need no longer be
initialized by the parser.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In this case it means moving ff_h263_pred_dc() resp. ff_h263_pred_acdc()
to ituh263enc.c resp. ituh263dec.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
41f213c3bf accidentally added
an unused pixel_format option to the v210(x) demuxers.
Remove it before it really becomes part of the API.
Reviewed-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is possible here, because the values of ff_log2_run used
here are actually in the range 0..15 given that run_index is
in the range 0..31.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The Matroska muxer has quite a lot of dependencies and lots of them
are unnecessary for WebM. By disabling the Matroska-only code
at compile time one can get rid of them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
iec61883_parse_queue_hdv() is only called when the mpegts-demuxer
is available and can be optimized away when not. Yet this
optimization is not a given and it fails with e.g. GCC 11 when
using -O0 in which case one will get a compilation error
because the call to the unavailable avpriv_mpegts_parse_packet()
is not optimized away. Therefore #if the offending code away
in this case.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes build errors if libzvbi is enabled while libzvbi_teletextdec
is disabled.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
parse_rtsp_message() is only called if the rtsp demuxer is enabled
and so it is normally compiled away if said demuxer is disabled.
Yet this does not happen when compiling with -O0 and this leads
to a linking failure because parse_rtsp_message() calls functions
that may not be available if the rtsp demuxer is disabled.
Fix this by properly #if'ing the unused functions away.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
All the AMRWB samples are in a mov container.
Also use FATE_SAMPLES_FFMPEG instead of FATE_SAMPLES_AVCONV.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The AMR muxer doesn't have a private context, so it's priv_data
will be NULL. If it weren't, simply setting it to NULL would lead
to a memleak.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Forgotten in 1f447fd954.
Also only enable amr_probe() and amr_read_header() in case
the AMR demuxer is enabled; this avoids having to add
a rawdec.o dependency to the muxer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only allocate an audio stream if there is one in the data. Silicon
Graphics movie format will contain default values (16 bit samples, 2
audio channels, 22050 Hz sample rate) even when no audio is present in
the file. This confuses FFmpeg into thinking such an audio stream is
present with 0 samples in it.
There is a flag value in the format to indicate whether or not audio is
present. This patch checks that and behaves accordingly.
Signed-off-by: John-Paul Stewart <jpstewart@personalprojects.net>
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reviewed-by: Peter Ross <pross@xvid.org>
While this function on its own passes all of fate-hevc, there's
indications that the function might need to handle widths that
aren't a multiple of 8 (noted in commit
f63f9be37c, which later was
reverted).
Signed-off-by: Martin Storsjö <martin@martin.st>
Fixes: signed integer overflow: 1074134419 - -1075212485 cannot be represented in type 'int'
Fixes: 43273/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-4706880883130368
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In this case ff_isom_put_dvcc_dvvc() might not be available, leading
to linking failures. Given that WebM currently doesn't support DOVI,
this is fixed by #if'ing the offending code away if the Matroska
muxer is not enabled.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Split packed data in case of its contains multiple show frame in some
non-standard bitstream. This can benefit decoder which can decode
continuously instead of interrupt with unexpected error.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Most users only want to either read or write golomb codes, not both.
By splitting these headers one avoids having unnecesssary
(get|put)_hits.h inclusions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This fixes compilation errors in case nvenc is enabled
(e.g. autodected) with both nvenc-based encoders disabled
because nvenc uses ff_alloc_a53_sei(), yet only the nvenc-based
encoders require atsc_a53.
(This error does not manifest itself in case of static linking
(nothing pulls in nvenc.o), but it exists with shared builds.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This commit adds a blend_vulkan filter and a normal blend mode, and
reserves support for introducing the blend modes in the future.
Use the commands below to test: (href: https://trac.ffmpeg.org/wiki/Blend)
I. make an image for test
ffmpeg -f lavfi -i color=s=256x256,geq=r='H-1-Y':g='H-1-Y':b='H-1-Y' -frames 1 \
-y -pix_fmt yuv420p test.jpg
II. blend in sw
ffmpeg -i test.jpg -vf "split[a][b];[b]transpose[b];[a][b]blend=all_mode=normal,\
pseudocolor=preset=turbo" -y normal_sw.jpg
III. blend in vulkan
ffmpeg -init_hw_device vulkan -i test.jpg -vf "split[a][b];[b]transpose[b];\
[a]hwupload[a];[b]hwupload[b];[a][b]blend_vulkan=all_mode=normal,hwdownload,\
format=yuv420p,pseudocolor=preset=turbo" -y normal_vulkan.jpg
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
mpegaudiodec_template.c uses stuff from mpegaudiodata directly,
yet this dependency was only indirectly fulfilled via mpegaudio-headers
before 33e6d57f01. Since this commit,
the latter only needs (and therefore provides) mpegaudiotabs,
leading to compilation failures.
This commit adds this missing direct dependency directly.
(Sorry for not having checked indirect dependencies.)
Found-by: Zane van Iperen <zane@zanevaniperen.com>
Reviewed-by: Zane van Iperen <zane@zanevaniperen.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The string for AV_OPT_TYPE_STRING AVOption gets freed by av_opt_free()
when closing the AVCodecContext
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
The SDK checks Data.V when using system memory for VP9 encoding. This
fixed the error below:
$ ffmpeg -qsv_device /dev/dri/renderD129 -f lavfi -i yuvtestsrc -c:v
vp9_qsv -f null -
[vp9_qsv @ 0x55b8387cbe90] Error during encoding: NULL pointer (-2)
Video encoding failed
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
The test /libavutil/tests/hwdevice checks that when deriving a device
from a source device and then deriving back to the type of the source
device, the result is matching the original source device, i.e. the
derivation mechanism doesn't create a new device in this case.
Previously, this test was usually passed, but only due to two different
kind of flaws:
1. The test covers only a single level of derivation (and back)
It derives device Y from device X and then Y back to the type of X and
checks whether the result matches X.
What it doesn't check for, are longer chains of derivation like:
CUDA1 > OpenCL2 > CUDA3 and then back to OpenCL4
In that case, the second derivation returns the first device (CUDA3 ==
CUDA1), but when deriving OpenCL4, hwcontext.c was creating a new
OpenCL4 context instead of returning OpenCL2, because there was no link
from CUDA1 to OpenCL2 (only backwards from OpenCL2 to CUDA1)
If the test would check for two levels of derivation, it would have
failed.
This patch fixes those (yet untested) cases by introducing forward
references (derived_device) in addition to the existing back references
(source_device).
2. hwcontext_qsv didn't properly set the source_device
In case of QSV, hwcontext_qsv creates a source context internally
(vaapi, dxva2 or d3d11va) without calling av_hwdevice_ctx_create_derived
and without setting source_device.
This way, the hwcontext test ran successful, but what practically
happened, was that - for example - deriving vaapi from qsv didn't return
the original underlying vaapi device and a new one was created instead:
Exactly what the test is intended to detect and prevent. It just
couldn't do so, because the original device was hidden (= not set as the
source_device of the QSV device).
This patch properly makes these setting and fixes all derivation
scenarios.
(at a later stage, /libavutil/tests/hwdevice should be extended to check
longer derivation chains as well)
Reviewed-by: Lynne <dev@lynne.ee>
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Tested-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
libplacebo supports automatic dolby vision application, but it requires
us to switch to a new API. Also add some logic to strip the dolby vision
metadata from the output frames in any case where we end up changing the
colorimetry.
The libplacebo dependency bump is justified because neither 184 nor 192
are part of any stable libplacebo release, so users have to build from
git anyways for this filter to exist.
Signed-off-by: Niklas Haas <git@haasn.dev>
- No longer mixes u8 and u16 component accesses (this was UB)
- De-duplicated 8->16 conversion
- De-duplicated component -> plane+offset conversion
- De-duplicated planar + packed RGB
- No longer calls ff_fill_rgba_map
- Removed redundant comp_mask data member
- RGB0 and related formats no longer write an alpha value to the 0 byte
- Non-planar YA formats now work correctly
- High-bit-depth semi-planar YUV now works correctly
Same outputs, but computed instead of statically known, so new formats will be
supported more easily. Asserts in place to ensure we update this if we add
anything incompatible with its logic.
As suggested by Andreas Rheinhardt, most code of v210 demuxer is common code
which is duplicated from rawvideodec, so it's better to move v210/v210x
demuxer code to rawvideodec.c and reuse the common code.
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Please reproduced with the following minimal configure command:
./configure --enable-shared --disable-all --enable-avcodec --enable-decoder=h264 --enable-hwaccel=h264_videotoolbox
You'll get below error:
Undefined symbols for architecture x86_64:
"_ff_videotoolbox_vpcc_extradata_create", referenced from:
_videotoolbox_start in videotoolbox.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Reported-by: Cameron Gutman <aicommander@gmail.com>
Tested-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
MPEG-1 only supports 4:2:0, so one can optimize away the checks
for whether one encodes MPEG-1 in codepaths that encode 4:2:2.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_mpeg1_encode_mb() contains two inlined calls to
mpeg1_encode_mb_internal(); these calls are supposed
to inline the properties depending upon the color space
used. Yet inlining vertical chroma subsampling (which
allows to remove complete branches and blocks depending
upon them) has been forgotten.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
encode_mb() calls encode_mb_internal() three times, once
for each supported chroma format. The reason for this is
that some chroma format dependent parameters can then be
inlined as encode_mb_internal() is marked as av_always_inline.
Yet the most basic parameters based upon chroma format have
not been inlined: The chroma format itself and the chroma
subsampling parameters. This commit does so.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Forgotten in cf1e0786ed.
(Both mpegvideodec as well as mpegvideoenc use me_cmp,
so this doesn't affect them.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This allows to remove the spurious dependencies of mpegvideo encoders
on error_resilience; some other components that do not use mpegvideo
to its fullest turned out to not need it either.
Adding a new CONFIG_EXTRA needs a reconfigure to take effect.
In order to force this a few unnecessary headers from lavfi/allfilters.c
have been removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
An AVCodecContext's private data is always allocated
in avcodec_open2() and calling avcodec_flush_buffers()
on an unopened AVCodecContext (or an already closed one)
is not allowed (and will crash before the decoder's flush
function is even called).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is partially possible if it is inlined whether
we deal with MPEG-1/2, because no_rounding is never set
for MPEG-1/2.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Whether lowres is in use or not is inlined in
mpv_reconstruct_mb_internal(), so one can use the fact
that lowres is always zero during encoding to evaluate
the checks for whether one is encoding or not at compile-time
when one is in lowres mode.
Also reorder the main check to check for whether it is an encoder
first to shortcircuit it in the common case of a decoder.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The very first check in this if-else if-else if construct is
"if (s->encoding ||", i.e. in case of the WMV2 encoder the else
branches are never executed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The a53_cc option is only useful and meaningful for MPEG-2,
yet it was accidentally added for all mpegvideo-based encoders.
This means that it is possible for a53_cc to be set for other
encoders as well.
This commit changes this and reroutes a53_cc to the dummy field
in MpegEncContext for all codecs for which it is not supported.
This allows to avoid a check for the current codec in mpeg12enc.c.
Also add a compile-time check for whether the MPEG-2 encoder is
available while at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible now that MJpegContext is allocated jointly
with MpegEncContext as part of the AVCodecContext's private data.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This factors the translation from MpegEncContext out
and will enable further optimizations in the next commits.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The generic code ensures that only codecs with
the FF_CODEC_CAP_AUTO_THREADS internal cap ever have to
handle the case avctx->thread_count == 0 themselves;
moreover, it is also ensured generically that only codecs
that support some form of threading have thread_count set
to something else than one. So these checks are unnecessary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Currently, ff_mpv_encode_end() is the close function of
the two MJPEG-based encoders; it calls ff_mjpeg_encode_close()
for them which adds a check to the generic code.
This commit reverses the order of this relationship:
The MJPEG encoders directly use a custom close function
which in turn calls ff_mpv_encode_end(). This avoids the branch
in ff_mpv_encode_end() and makes the generic code more generic.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fix warning caused by this field changing from uint64_t to uint16_t.
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This reverts commit 2589060b92 which was
originally to fix the FATE test. The real cause of the test breakage was
fixed in 22b7c37275.
Signed-off-by: J. Dekker <jdek@itanimul.li>
The assembly is written assuming that the width is a multiple of 8.
However the real issue is the functions were errorneously assigned to
the 2, 4, 6 & 12 widths. This behaviour never broke the decoder as
samples which trigger the functions for these widths have not been found
in the wild. This relies on the mappings in ff_hevc_pel_weight[].
Signed-off-by: J. Dekker <jdek@itanimul.li>
2022-01-04 14:31:32 +01:00
2722 changed files with 92716 additions and 49229 deletions
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
