Calling av_frame_make_writable() from decoders is tricky, especially
when frame threading is used. It is much simpler and safer to just make
a private copy of the frame.
This is not expected to have a major performance impact, since
APNG_DISPOSE_OP_BACKGROUND is not used often and
av_frame_make_writable() would typically make a copy anyway.
Found-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit b593abda6c)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This data cannot be stored in PNGDecContext.picture, because the
corresponding chunks may be read after the call to
ff_thread_finish_setup(), at which point modifying shared context data
is a race.
Store intermediate state in the context and then write it directly to
the output frame.
Fixes exporting frame metadata after 5663301560Fixes#8972
Found-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 8d74baccff)
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Do not store the image buffer pointer/linesize in the context, just
access them directly from the frame.
Stop assuming that linesize is the same for the current and last frame.
(cherry picked from commit 89ea5057bf)
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The (deprecated) field AVCodecContext.mpeg_quant has no range
restriction; MpegEncContext.mpeg_quant is restricted to 0..1.
If the former is set, the latter is overwritten with it without
checking the range. This can trigger an av_assert2() with the MPEG-4
encoder when writing said field.
Fix this by just setting MpegEncContext.mpeg_quant to 1 if
AVCodecContext.mpeg_quant is set.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit d393c45051)
The pix_fmts of the LJPEG encoder already contain all supported pixel
formats (including the ones only supported when strictness is unofficial
or less); yet the check in ff_encode_preinit() ignored this list in case
strictness is unofficial or less. But the encoder presumed that it is
always applied and blacklists some of the entries in pix_fmts when
strictness is > unofficial. The result is that if one uses an entry not
on that list and sets strictness to unofficial, said entry passes both
checks and this can lead to segfaults lateron (e.g. when using gray).
Fix this by removing the exception for LJPEG in ff_encode_preinit().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 6e8e9b7633)
For both the RealMedia as well as the IVR demuxer (which share the same
context) each AVStream's priv_data contains an AVPacket that might
contain data (even when reading the header) and therefore needs to be
unreferenced. Up until now, this has not always been done:
The RealMedia demuxer didn't do it when allocating a new stream's
priv_data failed although there might be other streams with packets to
unreference. (The reason for this was that until recently rm_read_close()
couldn't handle an AVStream without priv_data, so one had to choose
between a potential crash and a memleak.)
The IVR demuxer meanwhile never ever called read_close so that the data
already contained in packets leaks upon error.
This patch fixes both demuxers by adding the appropriate cleanup code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 9a471c5437)
ff_vc1_decode_init_alloc_tables() had one error path that forgot to free
already allocated buffers; these would then be overwritten on the next
allocation attempt (or they would just not be freed in case this
happened during init, as the decoders for which it is used do not have
the FF_CODEC_CAP_INIT_CLEANUP set).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 98060a198e)
The RealVideo 3.0 and 4.0 decoders call ff_mpv_common_init() only during
their init function and not during decode_frame(); when the size of the
frame changes, they call ff_mpv_common_frame_size_change(). Yet upon
error, said function calls ff_mpv_common_end() which frees the whole
MpegEncContext and not only those parts that
ff_mpv_common_frame_size_change() reinits. As a result, the context will
never be usable again; worse, because decode_frame() contains no check
for whether the context is initialized or not, it is presumed that it is
initialized, leading to segfaults. Basically the same happens if
rv34_decoder_realloc() fails.
This commit fixes this by only resetting the parts that
ff_mpv_common_frame_size_change() changes upon error and by actually
checking whether the context is in need of reinitialization in
ff_rv34_decode_frame().
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 9abda1365c)
In case of resolution changes rv20_decode_picture_header() closes and
reopens its MpegEncContext; it checks the latter for errors, yet when
an error happens, it might happen that no new attempt at
reinitialization is performed when decoding the next frame; this leads
to crashes lateron.
This commit fixes this by making sure that initialization will always
be attempted if the context is currently not initialized.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 8ffd3ef9d9)
When slice-threading is used, ff_mpv_common_init() duplicates
the first MpegEncContext and allocates some buffers for each
MpegEncContext (the first as well as the copies). But the count of
allocated MpegEncContexts is not updated until after everything has
been allocated and if an error happens after the first one has been
allocated, only the first one is freed; the others leak.
This commit fixes this: The count is now set before the copies are
allocated. Furthermore, the copies are now created and initialized
before the first MpegEncContext, so that the buffers exclusively owned
by each MpegEncContext are still NULL in the src MpegEncContext so
that no double-free happens upon allocation failure.
Given that this effectively touches every line of the init code,
it has also been factored out in a function of its own in order to
remove code duplication with the same code in
ff_mpv_common_frame_size_change() (which was never called when using
more than one slice (and if it were, there would be potential
double-frees)).
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit ff0706cde8)
This mostly reverts commit 4b2863ff01.
Said commit removed the freeing code from ff_mpv_common_init(),
ff_mpv_common_frame_size_change() and ff_mpeg_framesize_alloc() and
instead added the FF_CODEC_CAP_INIT_CLEANUP to several codecs that use
ff_mpv_common_init(). This introduced several bugs:
a) Several decoders using ff_mpv_common_init() in their init function were
forgotten: This affected FLV, Intel H.263, RealVideo 3.0 and V4.0 as well as
VC-1/WMV3.
b) ff_mpv_common_init() is not only called from the init function of
codecs, it is also called from AVCodec.decode functions. If an error
happens after an allocation has succeeded, it can lead to memleaks;
furthermore, it is now possible for the MpegEncContext to be marked as
initialized even when ff_mpv_common_init() returns an error and this can
lead to segfaults because decoders that call ff_mpv_common_init() when
decoding a frame can mistakenly think that the MpegEncContext has been
properly initialized. This can e.g. happen with H.261 or MPEG-4.
c) Removing code for freeing from ff_mpeg_framesize_alloc() (which can't
be called from any init function) can lead to segfaults because the
check for whether it needs to allocate consists of checking whether the
first of the buffers allocated there has been allocated. This part has
already been fixed in 76cea1d2ce.
d) ff_mpv_common_frame_size_change() can also not be reached from any
AVCodec.init function; yet the changes can e.g. lead to segfaults with
decoders using ff_h263_decode_frame() upon allocation failure, because
the MpegEncContext will upon return be flagged as both initialized and
not in need of reinitialization (granted, the fact that
ff_h263_decode_frame() clears context_reinit before the context has been
reinited is a bug in itself). With the earlier version, the context
would be cleaned upon failure and it would be attempted to initialize
the context again in the next call to ff_h263_decode_frame().
While a) could be fixed by adding the missing FF_CODEC_CAP_INIT_CLEANUP,
keeping the current approach would entail adding cleanup code to several
other places because of b). Therefore ff_mpv_common_init() is again made
to clean up after itself; the changes to the wmv2 decoder and the SVQ1
encoder have not been reverted: The former fixed a memleak, the latter
allowed to remove cleanup code.
Fixes: double free
Fixes: ff_free_picture_tables.mp4
Fixes: ff_mpeg_update_thread_context.mp4
Fixes: decode_colskip.mp4
Fixes: memset.mp4
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit d4b9e117ce)
If only one of the two arrays used for the ICC profile could be
successfully allocated, it might be overwritten and leak when
the next ICC entry is encountered. Fix this by using a common struct,
so that one has only one array to allocate.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit a5b2f06b0c)
In this case it also fixes a potential for compilation failures:
Not all compilers can handle the case in which a function with
a forward declaration declared with an attribute to always inline it
is called before the function body appears. E.g. GCC 4.2.1 on OS X 10.6
doesn't like it.
Reviewed-by: Pavel Koshevoy <pkoshevoy@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit e5d6af7b35)
Up until now, initializing the mutexes/condition variables wasn't
checked by ff_frame_thread_init(). This commit changes this.
Given that it is not documented to be save to destroy a zeroed but
otherwise uninitialized mutex/condition variable, one has to choose
between two approaches: Either one duplicates the code to free them
in ff_frame_thread_init() in case of errors or one records which have
been successfully initialized. This commit takes the latter approach:
For each of the two structures with mutexes/condition variables
an array containing the offsets of the members to initialize is added.
Said array is used both for initializing and freeing and the only thing
that needs to be recorded is how many of these have been successfully
initialized.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit c85fcc96b7)
In case an error happened when setting up the child threads,
ff_frame_thread_init() would up until now call ff_frame_thread_free()
to clean up all threads set up so far, including the current, not
properly initialized one.
But a half-allocated context needs special handling which
ff_frame_thread_frame_free() doesn't provide.
Notably, if allocating the AVCodecInternal, the codec's private data
or setting the options fails, the codec's close function will be
called (if there is one); it will also be called if the codec's init
function fails, regardless of whether the FF_CODEC_CAP_INIT_CLEANUP
is set. This is not supported by all codecs; in ticket #9099 it led
to a crash.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit e9b6617579)
Some old DV AVI files have the DSF-Flag of frames set to 0, although it
is PAL (maybe rendered with an old Ulead Media Studio Pro) ... this causes
ffmpeg/VLC-player to produce/play corrupted video (other players/editors
like VirtualDub work fine).
Fixes ticket #8333 and replaces/extends hack for ticket #2177
Signed-off-by: Marton Balint <cus@passwd.hu>
(cherry picked from commit 6ef5d8ca86)
This avoids use of uninitialized data
also several checks are inside the band reading code
so it is important that it is run at least once
Fixes: out of array accesses
Fixes: 28209/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-5684714694377472
Fixes: 32124/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-5425980681355264
Fixes: 30519/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-4558757155700736
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit da8c86dd8b)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Previously the code skipped all security checks when these where encountered but prior data was incorrect.
Also replace an always true condition by an assert
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 3b88c88fa1)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array accesses
Fixes: 29754/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-6333598414274560
Fixes: 30519/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-6298424511168512
Fixes: 30739/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-5011292836462592
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 20473a93d2)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When using external Huffman tables fails during init, the decoder
reverts back to using the default Huffman tables; and when doing so,
the current VLC tables leak because init_default_huffman_tables()
doesn't free them before overwriting them.
Sample:
samples.ffmpeg.org/archive/all/avi+mjpeg+pcm_s16le++mjpeg-interlace.avi
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 3cc685b7bc)
render_charset() used static buffers that are always completely
initialized before every use, so that it is unnecessary for the
values in these arrays to be kept after leaving the function.
Given that this is not only unnecessary, but harmful due to the
possibility of data races if several instances of a64multi/a64multi5
run simultaneously these buffers have been replaced by ordinary buffers
on the stack (they are small enough for this).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 0ca09335aa)
The current code tries the access the codecpar of a nonexistent
audio stream when seeking. Stop that. Fixes ticket #9121.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit af867e59d9)
An AVMD5 struct would leak if an error happened after its allocation.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 56bd071e54)
A buffer may leak in case of YUVA444P10 with dimensions that are not
both divisible by 16.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit d789d72d30)
When allocating a BSF fails, it could happen that the BSF's close
function has been called despite a failure to allocate the private data.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 9bf2b32da0)
The DSS demuxer currently decrements a counter that should be positive
at the beginning of read_packet; should it become negative, it means
that the data to be read can't be read contiguosly, but has to be read
in two parts. In this case the counter is incremented again after the
first read if said read succeeded; if not, the counter stays negative.
This can lead to problems in further read_packet calls; in tickets #9020
and #9023 it led to segfaults if one tries to seek lateron if the seek
failed and generic seek tried to read from the beginning. But it could
also happen when av_new_packet() failed and the user attempted to read
again afterwards.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit afa511ad34)
Since the very beginning (since de6d9b6404)
the AC-3 encoder used AC3_MAX_CODED_FRAME_SIZE (namely 3840) for the
size of the output buffer (without any check at all).
This causes problems when encoding EAC-3 for which the maximum is too small,
smaller than the actual size of the buffer: One can run into asserts used
by the PutBits API. Ticket #8513 is about such a case and this commit
fixes it by using the real size of the buffer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 968c158abd)
Affected the FATE tests filter-gradfun-sample and sierra-vmd-video.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 566bf56791)
Affected the FATE tests vsynth*-zlib, mszh and zlib.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit dd9cbd1cc3)
Before commit f1e17eb446, the qtrle
encoder had undefined pointer arithmetic: Outside of a loop, two
pointers were set to point to the ith element (with index i-1) of
a line of a frame. At the end of each loop iteration, these pointers
were decremented, so that they pointed to the -1th element of the line
after the loop. Furthermore, one of these pointers can be NULL (in which
case all pointer arithmetic is automatically undefined behaviour).
Commit f1e17eb44 added a check in order to ensure that the elements
never point to the -1th element of the array: The pointers are only
decremented if they are bigger than the frame's base pointer
(i.e. AVFrame.data[0]). Yet this check does not work at all in case of
negative linesizes; furthermore in case the pointer that can be NULL is
NULL initializing it still involves undefined pointer arithmetic.
This commit fixes both of these issues: First, non-NULL pointers are
initialized to point to the element after the ith element and
decrementing is moved to the beginning of the loop. Second, if a pointer
is NULL, it is just made to point to the other pointer, as this allows
to avoid checks before decrementing it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 911fe69c5f)
If keeping a reference to an earlier frame failed, the next frame must
be an I frame for lack of reference frame. This commit implements this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit d5fc16a6a8)
Affected 26 FATE tests like swr-resample_async-s16p-44100-8000.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 64977ed7ae)
Affected ProRes without alpha; affected 32 FATE tests, e.g. prores-422,
prores-422_proxy, prores-422_lt or matroska-prores-header-insertion-bz2.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit f83976344e)
Affected the acodec-dca and acodec-dca2 FATE tests.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 659a925939)
When allocating the MJpegContext fails (or if the dimensions run afoul
of the 65500x65500 limit), an attempt to free a subbuffer of said
context leads to a segfault in ff_mjpeg_encode_close().
Seems to be a regression since 467d9e27e0.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 84ac35ecb8)
by keeping the variable uint32_t which in this situation is the natural
type anyway. This affected the FATE-test filter-paletteuse-sierra2_4a.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 797c2ecc8f)
by using a multiplication instead. The multiplication can never overflow
an int because the sin-factor is only an int16_t.
Affected the FATE-tests filter-concat and filter-concat-vfr.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 55b46902c1)
Affects the FATE-tests webm-dash-manifest-unaligned-video-streams,
webm-dash-manifest and webm-dash-manifest-representations.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit a42c47b77f)
Also free the gme_info_t structure immediately after its use.
This simplifies cleanup, because it might be unsafe to call
gme_free_info(NULL) (or even worse, gme_track_info() might even
on error set the pointer to the gme_info_t structure to something
else than NULL).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 05457a3661)
Up until now, the VC-1 decoders allocated an AVFrame for usage with
sprites during vc1_decode_init(); yet said AVFrame can be freed if
(re)initializing the context (which happens ordinarily during decoding)
fails. The AVFrame does not get allocated again lateron in this case,
leading to segfaults.
Fix this by moving the allocation of said frame immediately before it is
used (this also means that said frame won't be allocated at all any more
in case of a regular (i.e. non-image) stream).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit ea70c39dee)
If the numerical constants for colorspace, transfer characteristics
and color primaries coincide, the current code presumes the
corresponding names to be identical and prints only one of them obtained
via av_get_colorspace_name(). There are two issues with this: The first
is that the underlying assumption is wrong: The names only coincide in
the 0-7 range, they differ for more recent additions. The second is that
av_get_colorspace_name() is outdated itself; it has not been updated
with the names of the newly defined colorspaces.
Fix both of this by using the names from
av_color_(space|primaries|transfer)_name() and comparing them via
strcmp; don't use av_get_colorspace_name() at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit e65a5df4fa)
Our "get name" functions can return NULL for invalid/unknown
arguments. So check for this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 88b7d9fd36)
When the trailer is never written (or when a stream switches from
non-animation mode to animation mode mid-stream), a cached packet
(if existing) would leak. Fix this by adding a deinit function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 3903c139a9)
The WebP muxer sometimes caches a packet it receives to write it later;
yet if a cached packet is too small (so small as to be invalid),
it is cached, but not written and not unreferenced. Such a packet leaks,
either by being overwritten by the next packet or because it is never
unreferenced at all.
Fix this by not caching unusable packets at all; and error out on
invalid packets.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit f9043de99a)
Fixes: assertion failure
Fixes: out of array access
Fixes: 32664/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGMYUV_fuzzer-6533642202513408.fuzz
Fixes: 32669/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGMYUV_fuzzer-6001928875147264
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 79ac8d5546)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: 32121/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-4512973109460992
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 6055b93379)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array access
Fixes: 31640/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SGA_fuzzer-5630883286614016
Fixes: 31619/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SGA_fuzzer-5176667708456960
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit e8bd34fe4f)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Commit 003b5c800f introduced seeking in argo_asf,
but this was missed, leading to non-deterministic output.
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
(cherry picked from commit 660c14a9b9)
88d80cb975 changed the type of
PutBitContext.BitBuf to uint64_t; it used to be an uint32_t.
While said structure is not public, it is nevertheless used by
certain avpriv functions and therefore crosses library boundaries:
avpriv_align_put_bits and avpriv_copy_bits were used in other libraries
in release 4.3 (and at the time of 88d80cb9) and so this commit broke
ABI.
This commit mitigates the trouble caused by this by using an uint32_t
again, but only for the 4.4 release branch and not the master branch,
as doing so for master, would break the ABI of master again, although
it is very unlikely that anyone would be helped by this (there don't
seem to be any users that combine libavcodec built from master and
libavformat from an old release: otherwise we would have received bug
reports about said ABI break).
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is how it is supposed to happen, yet when using frame threading,
the codec's init function has been called before preinit. This can lead
to crashes when e.g. using unsupported lowres values for decoders
together with frame threading.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 746796ceb4)
When flushing, the parser receives a dummy buffer with padding
that lives on the stack of av_parser_parse2(). Certain parsers
(e.g. Dolby E) only analyze the input, but don't repack it. When
flushing, such parsers return a pointer to the stack buffer and
a size of 0. And this is also what av_parser_parse2() returns.
Fix this by always resetting poutbuf in case poutbuf_size is zero.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 9faf3f8bb0)
Commit 6973df1122 added support
for music tracks by outputting its two containing tracks
together in one packet. But the actual data is not contiguous
in the file and therefore one can't simply use av_get_packet()
(which has been used before) for it. Therefore the packet was
now allocated via av_new_packet() and read via avio_read();
and this is also for non-music files.
This causes problems because one can now longer rely on things
done automatically by av_get_packet(): It automatically freed
the packet in case of errors; this lead to memleaks in several
FATE-tests covering this demuxer. Furthermore, in case the data
read is less than the data desired, the returned packet was not
zero-allocated (the packet's padding was uninitialized);
for music files the actual data could even be uninitialized.
The former problems are fixed by using av_get_packet() for
non-music files; the latter problem is handled by erroring out
unless both tracks could be fully read.
Reviewed-by: Zane van Iperen <zane@zanevaniperen.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 8a73313412)
The test sample has to have no file extension, otherwise probing
happens to work, based off file extension alone, and we want to
test the actual probing function.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
(cherry picked from commit e668c55649)
When extended atom size support was added to probing in
fec4a2d232, the buffer
size check was backwards, but probing continued to work
because there was no minimum size check yet, so despite
size being 1 on these atoms, and failing to read the 64-bit
size, the tag was still correctly read.
When 0b78016b2d introduced a
minimum size check, this exposed the bug, and broke probing
any files with extended atom sizes, such as entirely valid
large files that start whith mdat atoms.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
(cherry picked from commit 85f397c828)
This field needs to be replaced altogether, not just its type changed.
This will be done in a separate change.
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit 34f4f57800)
Fixes: Null pointer dereference
Fixes: any mpeg4 testcase which fails the malloc at that exact spot
Found-by: Rafael Dutra <rafael.dutra@cispa.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 9223372036854775807 + 536870912 cannot be represented in type 'long'
Fixes: 31678/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5614204619980800
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 access
Fixes: 31733/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SPEEDHQ_fuzzer-4704307963363328
Fixes: 31736/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SPEEDHQ_fuzzer-6190960292790272
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
And forward it to the underlying UDP protocol.
Fixes ticket #7517.
Signed-off-by: Jiangjie Gao <gaojiangjie@live.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Add the "http_proxy" option and its handling to the "tls" protocol,
pass the option from the "https" protocol.
The "https" protocol already defines the "http_proxy" command line
option, like the "http" protocol does. The "http" protocol properly
honors that command line option in addition to the environment
variable. The "https" protocol doesn't, because the proxy is
evaluated in the underlying "tls" protocol, which doesn't have this
option, and thus only handles the environment variable, which it
has access to.
Fixes#7223.
Signed-off-by: Moritz Barsnick <barsnick@gmx.net>
Signed-off-by: Marton Balint <cus@passwd.hu>
This change supports the "HEVC Video with Alpha" profile introduced in WWDC 2019
<https://developer.apple.com/videos/play/wwdc2019/506/>. (This change is a
partial fix for Ticket #7965.)
For example, the following command converts an animation PNG file to an HEVC
with Alpha video:
./ffmpeg -i fate-suite/apng/clock.png -c:v hevc_videotoolbox -allow_sw 1 -alpha_quality 0.75 -vtag hvc1 clock.mov
(This change uses the "HEVC Video with Alpha" profile only when the
'-alpha_quality' value is not 0 for backward compatibility.)
Signed-off-by: Hironori Bono <bouno@rouge.plala.or.jp>
These files are technically a series of planar mono tracks.
If the "music" flag is set, merge the packets from the two
mono tracks, essentially replicating:
[0:a:0][0:a:1]join=inputs=2:channel_layout=stereo[a]
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
av_adler32_update() is used by av_hash_update() which will be switched
to size_t at the next bump. So it also has to be made to use size_t.
This is also necessary for framecrcenc.c, because the size of side data
will become a size_t, too.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
These are auxiliary side-data functions, so they should have been
switched to size_t in d79e0fe65c,
but this has been forgotten.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
64 bits are needed in order to retain the uid values of Matroska
chapters; the type is kept signed because the semantics of NUT chapters
depend upon whether the id is > 0 or < 0.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, there has been no check that each chapter has a unique id;
there was only a check for whether a chapter id is zero (this happens
often when the chapters originated from a format that lacks the concept
of chapter id and simply counts from zero) which is invalid in Matroska.
In this case the chapter ids are offset by 1 to make them nonnegative.
Yet offsetting won't fix duplicate ids, therefore this is changed to
simply create new chapter uids when the input chapter uids don't conform
to the requirements of Matroska (in which case it can be presumed that
they did not originate from Matroska, so that we don't need to bother
to preserve them).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The test program for the FIFO muxer allocates a buffer without padding
and wraps it into a packet via av_packet_from_data(). This is an API
violation. Furthermore, said buffer leaks in case av_packet_from_data()
fails. Fix both of these issues by using av_new_packet() instead.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If one of the two results of a ternary conditional is a pointer to void,
the type of the whole conditional operator is a pointer to void, even
when the other possible result is not a pointer to void. This loophole
in the type system has allowed mxf_read_local_tags to have a pointer of
type pointer to MXFMetadataSet that actually points to an MXFContext.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The next pointer is kept at the end for backwards compatability until the
major bump, when it should ideally be moved at the front.
Signed-off-by: James Almer <jamrial@gmail.com>
Use the tfra timestamp if it is available and sidx timestamp is not.
Fixes reading the entire file after seeking in a live-style DASH FMP4
with an MFRA.
This specifically fixes when use_mfra_for is set.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Commit 8c8e5d5286 added a way to reduce
seek time by waiting for the windowed tcp packets instead of creating a
new socket connection. It implemented this by overwriting
s->short_seek_threshold in avio_seek(). However,
s->short_seek_threshold could already be set and be higher than the
threshold set by the protocol (i.e. s->short_seek_threshold is set in
ff_configure_buffers_for_index()).
This new feature was only enabled for tls connections in
70d8077b79. As in Ticket #9148 it reduced
performance because instead of waiting to refill the AVIOContext buffers
with an existing connections, a new HTTP request was often made instead.
Fixes Ticket #9148.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Only one character is actually rewritten.
Fixes truncation warnings, such as
warning: ‘strncpy’ output truncated before terminating nul copying 3 bytes from a string of the same length [-Wstringop-truncation]
in gcc 10.2.0
This cap is currently used to mark multithreading-capable codecs that
wrap external libraries with their own multithreading code. The name is
highly confusing for our API users, since libavcodec ALWAYS handles
thread_count=0 (see commit message in previous commit). Therefore rename
the cap and update its documentation to make its meaning clear.
The old name is kept deprecated until next+1 major bump.
AV_CODEC_CAP_AUTO_THREADS was originally added in b4d44a45f9 to mark
codecs that spawn threads internally and are able to select an optimal
threads count by themselves (all such codecs are wrappers around
external libraries). It is used by lavc generic code to check whether it
should handle thread_count=0 itself or pass the zero directly to the
codec implementation. Within this meaning, it is clearly supposed to be
an internal cap rather than a public one, since from the viewpoint of a
libavcodec user, lavc ALWAYS handles thread_count=0. Whether it happens
in the generic code or within the codec internals is not a meaningful
difference for the caller.
External aspects of this flag will be dealt with in the following
commit.
In the meanwhile libx264 allows to be configured for including both 8/10 bit
support within a single library. The new libx264 interface was enabled in
2f96190732.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
open_url_keepalive() unsets the options when it uses them, this
includes the offsets for the Range: header. When using the HLS
tag #EXT-X-BYTERANGE along with multiple files, the range options
must be preserved after open_url_keepalive() returns EOF so that
the new file can be opened. Failure to do this results in ignoring
the #EXT-X-BYTERANGE tag and reading the wrong bytes of the file.
To fix it, reset the options before calling io_open() following
open_url_keepalive() reaching EOF
Reviewed-by: Steven Liu <liuqi05@kuaishou.com>
av_bprint_finalize() can still fail even when it has been checked that
the AVBPrint is currently complete: Namely if the string was so short
that it fit into the AVBPrint's internal buffer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The only caller to ff_h264_decode_init_vlc() already uses
ff_thread_once() for the call; ergo the check via a simple int with
static storage duration in ff_h264_decode_init_vlc() is redundant.
And if it were not redundant, it would be a potential for data races.
So remove it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: Integer overflow and division by 0
Fixes: poc-202102-div.mov
Found-by: 1vanChen of NSFOCUS Security Team
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Direct users to the callback that should be used to keep supporting user
provided buffers with the new encode API.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: signed integer overflow: -2272 + -2147483360 cannot be represented in type 'int'
Fixes: 30009/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-5005660322398208
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Also remove AV_LOG_SIMULATE from the list as it is not used directly, and do
not use panic level on unknown loglevel, but make them warn. Also fix mapping of
NOTICE/INFO/VERBOSE and add documentation about when the option should actually
be used.
Signed-off-by: Marton Balint <cus@passwd.hu>
Maximum packet size is 10000 (RIST_MAX_PACKET_SIZE, which is unfortunately
private) minus the RIST protocol overhead which is 28 bytes for the unencrypted
case, 36 for the encrypted case.
Signed-off-by: Marton Balint <cus@passwd.hu>
Queue tracking makes no difference so remove it, return EAGAIN of no data is
available and rist data block needs to be freed even for zero sized packets.
Signed-off-by: Marton Balint <cus@passwd.hu>
clang errors when compiling with C++11 about needing spaces between
literal and identifier
Signed-off-by: Christopher Degawa <ccom@randomderp.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Keep on reading fragments until we got fragment_size amount of data, otherwise
we might get frames with 1-2 samples only if pa_stream_peek is called slightly
less frequently than sample rate.
Note that fragments might contain a lot less data than fragment_size, so
reading multiple fragments to get fragment_size amount of data is intentional.
Signed-off-by: Marton Balint <cus@passwd.hu>
Otherwise we might return 1-2 samples per packet if av_read_frame() call rate is
only sligthly less than the stream sample rate.
Signed-off-by: Marton Balint <cus@passwd.hu>
This callback is functionally the same as get_buffer2() is for decoders, and
implements for the new encode API the functionality of the old encode API had
where the user could provide their own buffers.
Reviewed-by: Lynne <dev@lynne.ee>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>
The top-level GetBitContext is sized for the whole NAL unit, so it fails
to detect overflows where a payload continues into the following message.
To fix that, we make a new context on the stack for reading each payload.
Fixes: 29892/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_REDUNDANT_PPS_fuzzer-6310830956216320
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
In total, the number of short term references (from the selected short
term ref pic set), the number of long term references (combining both the
used candidates from the SPS and those defined in the slice header) and
the number of instances of the current picture (usually one, but can be
two if current picture reference is enabled) must never exceed the size
of the DPB. This is a generalisation of the condition associated with
num_long_term_pics in 7.4.7.1.
We use this to apply tighter bounds to the number of long term pictures
referred to in the slice header, and also to detect the invalid case where
the second reference to the current picture would not fit in the DPB (this
case can't be detected earlier because an STRPS with 15 pictures can still
be valid in the same stream when used with a different PPS which does not
require two DPB slots for the current picture).
Fixes: 24913/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_METADATA_fuzzer-6261760693370880
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
An AVBufferRef (and the corresponding AVBuffer and the underlying actual
buffer) would leak in ff_cbs_sei_add_message() on error in case an error
happened after its creation and before it has been attached to more
permanent storage. Fix this by only creating the AVBufferRef immediately
before attaching it to its intended target position.
(Given that no SEI message currently created is refcounted, the above
can't happen at the moment. But Coverity already nevertheless noticed:
This commit fixes Coverity issue #1473521.)
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(This affected only suffix SEI messages; yet no such SEI messages are
currently inserted.)
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Setting this field happens immediately after the allocation in
ff_cbs_init(), so the whole CBS code may presume that any
CodedBitstreamContext has this set. Lots of code already presumed this,
yet ff_cbs_close() did it inconsistently: It checked before checking
whether the CodedBitstreamType has a close function; yet it simply
unconditionally read ctx->codec->priv_class. Coverity complained about
this in issue #1473564, which this commit fixes.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If b-frames were enabled implicitly (if max_b_frames wasn't set by
the caller at all, since a0949d0bcb),
we wouldn't offset dts at all, producing invalid pts/dts combinations
(causing loud warnings by ffmpeg, or muxer errors if passed without
an extra cleanup pass).
Instead use frameIntervalP for offsetting, which should always be
accurate.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
The uspp filter uses a special option ("no_bitstream") of
the Snow encoder to suppress it from generating output.
The filter therefore did not unref the packet after usage,
believing it to be blank. But this is wrong, as the Snow encoder
attaches quality stats side data to the packet.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
av_get_packet() already makes sure that the packet size is accurate
and that the packet data is zero-padded even when one could not read as
much as desired.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This commit adds a "gophers" handler to the gopher protocol. gophers
is a community-adopted protocol that acts the same way like normal
gopher with the added TLS encapsulation.
The gophers protocol is supported by gopher servers like geomydae(8),
and clients like curl(1), clic(1), and hurl(1).
This commit also adds compilation guards to both gopher and gophers,
since now there are two protocols in the file it makes sense to
have this addition.
Signed-off-by: parazyd <parazyd@dyne.org>
Signed-off-by: Marton Balint <cus@passwd.hu>
In addition to the fact that av_image_copy() cannot handle hardware pixel formats,
h->short_ref[0]->f may not be writable at this point.
Based on a patch by Hendrik Leppkes.
Signed-off-by: James Almer <jamrial@gmail.com>
AviSynth+ outputs audio in the same format as the
OS, so assuming little endian formats as input
on big endian OSes results in nothing but static.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
avs_is_color_space provides a generic way of checking whether the
video is RGB, and has been available through AVSC_API since 2.6.
This means that GetProcAddress doesn't have to run on every frame.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
If an error happens when preparing the output data buffer, an already
allocated array would leak. Fix this by postponing its allocation.
Fixes Coverity issue #1473531.
Reviewed-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Also fixes a memleak in single-threaded mode when an error happens
in preparing the output data buffer; and also removes an unchecked
allocation.
Reviewed-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
asserts should not be used instead of ordinary input checks.
Yet the native DNN backend did it: get_input_native() asserted that
the first dimension was one, despite this value coming directly from
the input file without having been sanitized.
Reviewed-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Beginning with version 3.0, libiLBC switched the types of some parts
of their public API to size_t and renamed some types; the old names
continue to work as typedefs, but are deprecated. It furthermore
added version macros.
This commit uses said version macro to use the new types when using
newer libiLBC versions.
Reviewed-by: Timothy Gu <timothygu99@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
av_stream_add_side_data() already defines size as a size_t, so this makes it
consistent across all side data functions.
Signed-off-by: James Almer <jamrial@gmail.com>
av_packet_add_side_data() already defines size as a size_t, so this makes it
consistent across all side data functions
Signed-off-by: James Almer <jamrial@gmail.com>
If the window is resized it was possible that xpos pointed outside the
visualization texture. By rearranging the overflow check we make sure this (and
a crash) does not happen.
We also don't have to use xleft for start position, as that is 0 anyways, and
if we ever want to take into account xleft then the texture should be
positioned accordingly when rendering.
Signed-off-by: Marton Balint <cus@passwd.hu>
AVCodecInternal.last_pkt_props is not used when decoding subtitles;
ergo it makes no sense to set it at all.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Use AVCodecInternal.buffer_pkt (previously only used in
avcodec_send_packet) instead of stack packets when decoding subtitles.
Also stop sharing side-data between packets and use the user-supplied
packet directly for decoding when possible (no subtitle decoder ever
modifies the packet it is given).
Reusing AVCodecInternal.buffer_pkt is based upon an idea from James
Almer.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: 1515225320 + 759416059 cannot be represented in type 'int'
Fixes: 29256/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DCA_fuzzer-5719088561258496
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: negation of -2147483648 cannot be represented in type 'INTFLOAT' (aka 'int'); cast to an unsigned type to negate this value to itself
Fixes: 29057/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_FIXED_fuzzer-5642758933053440
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Timeout (too long -> 241ms)
Fixes: 29083/clusterfuzz-testcase-minimized-ffmpeg_dem_SWF_fuzzer-6273684478230528
The source of the magic number is
A very quick simulation of the best case compression for "compress"
below is not nice written code as i did not expect I or anyone else
would ever see it again
I would have preferred some nicer expression or course, but thats
what it seems to be asymptotically. For smaller amounts of data a
tighter bound is possible but i saw no nice way to consider that
and it seems also overkill to try to do it more fine grained for
just this
main(){
int64_t bits = 0;
int bank = 256;
int bitbank = 8;
for(unsigned i = 0; i<1024*1024*1024*4U-100000;) {
int word_size = bank-255;
i += word_size;
bits += bitbank;
if (!(bank & (bank-1)))
bitbank ++;
bank++;
if (bitbank > 16) {
printf("BEST %f \n", 8.0 * i / bits );
bank = 256;
bitbank = 8;
}
}
}
above assumes i remembered correctly how the algorithm works but the
value was close to what actual compession of zeros gave
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The effective lifetime of the buffer used to build the VLCs and
the buffer containing the bitstream is disjoint, so that one can use
a common buffer for both.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Having only one allocation that is not automatically freed in particular
means that one does not need to free the already allocated buffers
when allocating another one fails.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This state is currently allocated and freed for every packet; but it can
just be moved to the stack instead.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ls_encode_line() encodes one line of input from left to right and
to do so it uses the values of the left, upper left, upper and upper
right pixels for prediction (i.e. the values that a decoder gets when it
decodes the already encoded part of the picture). So a simple algorithm
would use a buffer that can hold two lines, namely the current line as
well as the last line and swap the pointers to the two lines after
decoding each line. Yet if one is currently encoding the pixel with
index k of a line, one doesn't need any pixel with index < k - 1 of the
last line at all and similarly, no pixels with index >= k have been
written yet. So the overlap in the effective lifetime is pretty limited
and since the last patch (which stopped reading the upper left pixel and
instead reused the value of the upper pixel from the last iteration of
the loop) it is inexistent. Ergo one only needs one line and doesn't
need to swap the lines out.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ls_encode_line() encodes a line of input, going from left to right. In
order to calculate a predicted value it uses the left and upper-left
value of the output picture (that is, it uses how a decoder would see
the already encoded part of the picture), unless this is the very first
pixel of this line in which case one uses the first pixel of the last
(upper) line and the line before the last line. Therefore the loop
contained a check for whether this is the beginning of a new line. This
commit moves said check out of the loop by initializing these values
before the loop and by updating these values at the end of the loop
body; already read/calculated values are reused for this (the prediction
also needs the value of the upper pixel and this can be reused for the
upper left value of the next iteration of the loop).
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The jpegls encoder uses three buffers (as well as its state) to perform
its function: A copy of the last encoded line as a decoder would decode it,
the part of the current line that has been encoded (again, as a decoder
would decode it) and the part of the current line that is not yet encoded.
The encoder solves this by modifying the input frame as it encodes the
output (it also zero-allocates a line to serve as last line for the
first line where no preceding line exists); yet this is wrong as said
frame is not owned by the encoder, so it must not be modified (and it is
given to the encoder as const AVFrame *) without making it writable.
This patch solves this bug by allocating two lines, one for the last and
one for the currently encoded line of output (as a decoder would decode it).
Notice that the frame is only modified if the encoder is in the
non-default non-lossless mode.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Despite avcodec_register and avcodec_register_all being deprecated,
their documentation still said that one of them has to be called
before doing anything else. Clarify this confusing situation.
Furthermore, don't use avcodec_register_all in sample code for
a non-deprecated function.
Reviewed-by: mypopy@gmail.com <mypopy@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This field hasn't been used to return the output frame size since
avcodec_decode_audio4() was introduced.
Signed-off-by: James Almer <jamrial@gmail.com>
The packet passed as argument to this function hasn't contained
a user-provided buffer since 93016f5d1d.
Signed-off-by: James Almer <jamrial@gmail.com>
They have been deprecated in 61097535cd,
yet this was less than two years ago. Removing them will therefore have
to wait.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When the deprecated option "user-agent" was set to something different
than its default value, said option would always precede and overwrite
the ordinary user_agent option (regardless of whether it was explicitly
set) which leads to a leak of the user_agent option (which has a default
value, so the leak happens always).
Fix this by setting the same destination for both options; the last
option applied wins then.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Enables writing TTML documents or encoded TTML paragraphs as such
documents.
Additionally, a test for the combined TTML encoder and muxer has
been added to validate that the components still work.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
Enables the usage of such values as AV_EF_EXPLODE in encoders, which
can be useful in cases such as subtitle encoders where they have the
responsibility to validate the correctness of an incoming ASS dialog line.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
Base escaping only escapes values required for base character data
according to part 2.4 of XML, and if additional flags are added
single and double quotes can additionally be escaped in order
to handle single and double quoted attributes.
Co-authored-by: Jan Ekström <jan.ekstrom@24i.com>
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
Some FATE tests use files created by other FATE tests as input files;
this mostly affects the seek tests which use files from vsynth_lena as
well as acodec-pcm as input files. In order to make this possible the
temporary files of all the vsynth* and all acodec-pcm tests are kept.
Yet only a fraction of these files are actually used. This commit
changes this to only keep the files that are actually needed for other
tests. This reduces the size of the tests/data/fate folder after a full
FATE run from 2024727441B to 138739312B.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
While this usage of strncpy is correct, said function nevertheless has
the disadvantage of not automatically ensuring that the destination
string is zero-terminated. So av_strlcpy should be preferred.
This also removes a -Wstringop-truncation warning from GCC (it doesn't
matter whether the buffer is truncated, as long as it can fit all
the names of the supported codecs).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It only got added recently, and the new name makes it consistent with
product_version_num in the next patch.
Signed-off-by: Marton Balint <cus@passwd.hu>
Fixes: signed integer overflow: -9223372036854775808 + -242 cannot be represented in type 'long'
Fixes: 26910/clusterfuzz-testcase-minimized-ffmpeg_dem_MCC_fuzzer-6723018395090944
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: -9223372053736 * 1000000 cannot be represented in type 'long'
Fixes: 26910/clusterfuzz-testcase-minimized-ffmpeg_dem_CONCAT_fuzzer-6607924558430208
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The fourccs used by the Megalux Frame format to determine the pixel
format are actually no fourccs at all as they are a single byte.
Furthermore, their range is continuous (1-5), so they are actually
ordinary indices. So treat them as such and don't use PixelFormatTags
for them.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This flag was added in 492026209b
in conjunction with av_demuxer_open() to allow to pass private
options to demuxers. It worked as follows: av_open_input_stream()
(the predecessor of avformat_open_input()) would not call the
read_header function if this flag is set. Instead the user could set
private options of the demuxer via the format's private class after
avformat_open_input() and then call av_demuxer_open() which called
the format's read_header function.
This approach was abandoned in e37f161e66
and av_demuxer_open() deprecated; instead the AVDictionary based way of
passing private options to the demuxer was choosen. Yet
AVFMT_FLAG_PRIV_OPT has never been deprecated and av_demuxer_open()
never removed. This commit implements the deprecation of the flag and
schedules av_demuxer_open for removal on the next major bump.
Given that av_demuxer_open() has been deprecated in 2012 and that this
flag is useless without it, the flag will be ignored after the next
major version bump.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: 1 + 2147483647 cannot be represented in type 'int'
Fixes: 30877/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOBICLIP_fuzzer-4775601145774080
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
strncpy only ensures that one does not write beyond the end of the
destination buffer; in case of truncation it does not zero-terminate
the destination buffer. This makes using it the way it is now in the
DASH demuxer dangerous. So use av_strlcpy instead.
Also don't write anything if there is no id: The buffer has already been
zeroed initially.
The DASH testset from the Universität Klagenfurt contains samples with
ids that are too long. E.g.
http://ftp.itec.aau.at/datasets/DASHDataset2014/TearsOfSteel/1sec/TearsOfSteel_1s_simple_2014_05_09.mpd
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The obstacle to do so was in filter_codec_opts: It uses searches
the AVCodec for options via the AV_OPT_SEARCH_FAKE_OBJ method, which
requires using a void * that points to a pointer to a const AVClass.
When using const AVCodec *, one can not simply use a pointer that points
to the AVCodec's pointer to its AVClass, as said pointer is const, too.
This is fixed by using a temporary pointer to the AVClass.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Needs a CountedElement in order to distinguish the case of the element
not being present and the element being present with a value of zero.
(It has been argued by Ridley Combs that one should only ever use the
AV_DISPOSITION_DUB field for audio tracks. Yet given that there is no
definition for the disposition flags, one can also interpret it to mean
that e.g. a subtitle track is meant to be used with the dubbed audio
track or the original audio track. This commit interprets this flag in
this sense, which also allows to maintain it on remuxing.)
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is possible because their size is known at compile-time; so they
can be put directly into the context and don't need to be allocated for
every frame.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
In case of the cel evaluators it even allows to perform the
initialization of the source coordinates only once instead of for each
frame.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the RoQ video decoder and encoder used the same context;
and said context contained several fields that are only used by the
encoder. This commit changes this and uses a dedicated context for the
encoder; it contains the common context as first element in order to use
functions common to the de- and encoder.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
x264 versions >= 153 can support multiple bitdepths; they also don't
export x264_bit_depth any more. The actual check whether a bitdepth
is supported is therefore performed at runtime in x264_encoder_open.
Ergo it is unnecessary to use init_static_data for these versions:
One can already set ff_libx264_encoder.pix_fmts to the value that
X264_init_static always sets it to.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Also make the macro used for the demuxers spec-compliant. The earlier
macro was not, because the ... argument of a variadic macro must not be
left out. GCC and Clang warn about this when using -pedantic.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It only affects the old and deprecated avcodec_decode_(video2|audio4)
API which is no longer used here.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Memory for auxillary_info was not freed after usage.
Leak can be reproduced with following commands:
Optionally, generate input video:
ffmpeg -f lavfi -i testsrc=duration=10:size=1280x720:rate=30 input.mp4
Run ffmpeg with valgrind:
valgrind --leak-check=full --show-leak-kinds=all \
ffmpeg -y -i input.mp4 -vcodec copy -acodec copy \
-encryption_scheme cenc-aes-ctr \
-encryption_key 00000000000000000000000000000000 \
-encryption_kid 00000000000000000000000000000000 \
ffmpeg_encrypted.mp4
For test video which has duration of 10 sec, leak is 4 Kb.
For 100 sec video, leak will be 33 Kb. Most likely,
leaked memory will grow linearly to the number of input frames.
Signed-off-by: Vadym Bezdushnyi <vadim.bezdush@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
av_gettime_relative() is using the monotonic clock therefore more suitable for
elapsed time calculations. Packet timestamps are still kept absolute, although
that should be configurable in the future.
Related to ticket #9089.
Signed-off-by: Marton Balint <cus@passwd.hu>
av_gettime_relative() is using the monotonic clock therefore more suitable for
relative time calculations.
Signed-off-by: Marton Balint <cus@passwd.hu>
AVFrame hasn't been a struct defined in libavcodec for a decade now, when
it was moved to libavutil.
Found-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This code was written when the allocation functions used parameters of
type unsigned. This is no longer true today and therefore we only need
to check whether the multiplication of the array's size stays within
a size_t -- and this can be offloaded to av_realloc_array.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the wav muxer used a reallocation of the form ptr =
av_realloc(ptr, size); that leaks upon error. Furthermore, if a
failed reallocation happened when writing the trailer, a segfault
would occur due to avio_write(NULL, size) because the muxer only
prints an error message upon allocation error, but does not return
the error.
Moreover setting the pointer to the buffer to NULL on error seems to
be done on purpose in order to record that an error has occured so that
outputting the peak values is no longer attempted. This behaviour has
been retained by simply disabling whether peak data should be written
if an error occurs.
Finally, the reallocation is now done once per peak block and not once
per peak block per channel; it is also done with av_fast_realloc and not
with a linear size increase.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
out[lut[i]] = in[i] lookups were 4.04 times(!) slower than
out[i] = in[lut[i]] lookups for an out-of-place FFT of length 4096.
The permutes remain unchanged for anything but out-of-place monolithic
FFT, as those benefit quite a lot from the current order (it means
there's only 1 lookup necessary to add to an offset, rather than
a full gather).
The code was based around non-power-of-two FFTs, so this wasn't
benchmarked early on.
avcodec_find_best_pix_fmt2 has been deprecated and replaced by
avcodec_find_best_pix_fmt_of_2 in 2a54ae9df8.
avcodec_find_best_pix_fmt_of_2 and avcodec_get_pix_fmt_loss meanwhile
were deprecated in 617e866e25 when these
functions were de facto moved to libavutil; this has been mentioned in
APIchanges in f7a1c5e4d2. Yet the
attribute_deprecated was never set for the latter two functions and they
were not wrapped in an FF_API define. This commit does this.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The whole old next API has been deprecated in commit
7e8eba2d87, yet deprecating the next
pointer has been forgotten (the next pointers of other structures are
below the public API delimiter, but such a delimiter doesn't exist for
AVCodecParser).
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
These functions were never deprecated. The merge from commit 6988cf2969
included them by mistake.
Found-by: mkver
Signed-off-by: James Almer <jamrial@gmail.com>
This reverts commit 0191f2d29c.
These functions were never deprecated. The merge from commit 6988cf2969
included them by mistake.
Found-by: mkver
Signed-off-by: James Almer <jamrial@gmail.com>
GIF palette entries are not compressed, and writing 256 entries,
which can be up to every frame, uses a significant amount of
space, especially in extreme cases, where palettes can be very
small.
Example, first six seconds of Tears of Steel, palette generated
with libimagequant, 320x240 resolution, and with transparency
optimization + per frame palette:
* Before patch: 186765 bytes
* After patch: 77895 bytes
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This option will disable the writing of the global palette in global
GIF header if it is set to 0, causing only the frame-level palette
to ever be written.
This will be useful later on when further frame-level palette
optimizations are introduced.
The default is 1, which maintains current default behavior.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
AVID streams - currently handled by the AVRN decoder - can be (depending
on extradata contents) either MJPEG or raw video. To decode the MJPEG
variant, the AVRN decoder currently instantiates a MJPEG decoder
internally and forwards decoded frames to the caller (possibly after
cropping them).
This is suboptimal, because the AVRN decoder does not forward all the
features of the internal MJPEG decoder, such as direct rendering.
Handling such forwarding in a full and generic manner would be quite
hard, so it is simpler to just handle those streams in the MJPEG decoder
directly.
The AVRN decoder, which now handles only the raw streams, can now be
marked as supporting direct rendering.
This also removes the last remaining internal use of the obsolete
decoding API.
src/libavfilter/vf_vif.c: In function ‘process_frame’:
src/libavfilter/vf_vif.c:542:20: warning: ‘main’ is usually a function [-Wmain]
AVFrame *out, *main = NULL, *ref = NULL;
^~~~
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
The build warning message:
src/libavfilter/vf_ssim.c: In function ‘ssim_plane_16bit’:
src/libavfilter/vf_ssim.c:246:24: warning: ‘main’ is usually a function [-Wmain]
const uint8_t *main = td->main_data[c];
^~~~
src/libavfilter/vf_ssim.c: In function ‘ssim_plane’:
src/libavfilter/vf_ssim.c:289:24: warning: ‘main’ is usually a function [-Wmain]
const uint8_t *main = td->main_data[c];
^~~~
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Current code is very confused and confusing. It uses two different
reference frames - "previous" and "last" - when only one is really
necessary. It also confuses the two, leading to incorrect output with
APNG_DISPOSE_OP_PREVIOUS mode.
Fixes#9017.
FF_CODEC_CAP_ALLOCATE_PROGRESS makes no sense because the decoder does
not support frame threading.
FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM makes no sense because the decoder
does not handle skip_frame.
No buffer will be fetched from the pool after it's uninitialized, so there's
no benefit from waiting until every single buffer has been returned to it
before freeing them all.
This should free some memory in certain scenarios, which can be beneficial in
low memory systems.
Based on a patch by Jonas Karlman.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: James Almer <jamrial@gmail.com>
The last user of g15Mask, r15Mask, g16Mask and r16Mask was disabled
in 77a416e8aa and finally removed in
36e8de07ed62609df45d064b56501e3084d25723; b15Mask and b16Mask were
apparently always unused (except for in_asm_used_var_warning_killer,
a function that only existed to make the compiler not optimize ASM
constants away).
w10 is unused since d604bab901, w02
since ef423a6618.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The code using ff_exp2 (namely ff_acelp_decode_gain_code) use it only if
G729_BITEXACT is defined. So disable it if not.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This allowed to remove forward declarations. Because compilers expect
declarations for all functions they encounter even when it is within
blocks disabled via "if (0 && foo)", one has to use a real #if in
ff_diracdsp_init_x86.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Unused since a1f3b18bf5, yet as nonstatic
functions the compiler can't detect this, so that these functions aren't
stripped and no warning is emitted.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ff_acelp_decode_8bit_to_1st_delay3, ff_acelp_decode_4bit_to_2nd_delay3
and ff_acelp_decode_5_6_bit_to_2nd_delay3 are all only used once (by
g729dec) whereas ff_acelp_decode_9bit_to_1st_delay6 and
ff_acelp_decode_6bit_to_2nd_delay6 are completely unused; with the
possible exception of ff_acelp_decode_4bit_to_2nd_delay3, these
functions are so small that inlining them is appropriate; and as long as
ff_acelp_decode_4bit_to_2nd_delay3 is only called once, this is also
true for it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Clang infers from the existence of a default case that said case can be
taken. In case of libavcodec/bitstream.c said default case consisted of
an av_assert1 that evaluates to nothing in case of the ordinary assert
level. In this case (that doesn't happen) a variable wouldn't be
initialized, so Clang emitted Wsometimes-uninitialized warnings.
Solve this by making sure that the default path also initializes
the aforementioned variable.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The counter for the number of styles is written on two bytes, ergo
anything > UINT16_MAX is invalid. This also fixes a compiler warning
because of a tautologically true check on 64bit systems.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Commit 0d1229f1d2 factored the main part
of the voc demuxer's read_packet function out; yet when this Libav
commit was merged in f99195d56f, the
dependency of the other users of this function on vocdec.o was
unnecessarily kept. This commit fixes this.
While just at it, also disable the data only used by the voc demuxer
and muxer in voc.c if both of them are disabled.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
tiff.c is the only user of the data from tiff_data.c (the dependency of
the tiff encoder of it is spurious). Therefore this commit moves all the
data from tiff_data.c to tiff_data.h (which is only included by tiff.c)
and makes the objects declared therein static.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The options of the w64 demuxer are a proper subset of the options for
the wav demuxer, making it possible to reuse a part of the options for
the wav demuxer for the w64 demuxer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The NUT and avi demuxers only need ff_codec_movvideo_tags and so this
removes a dependency on the rest of isom.c as well as on mpeg4audio.c
(which isom depends on); it is similar for the Matroska demuxer and
muxers, except that the mpeg4audio.c dependency can't be avoided.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is a result of the mov channel parsing stuff being factored out
of mov.c twice: Once in 91b782720f
to isom.c and later in 3bab7cd128.
Also remove the isom.h header; and while just at it, remove an unused
mathematics.h inclusion.
(isom.c actually depends upon mpeg4audio from libavcodec for
avpriv_mpeg4audio_get_config2 and avpriv_mpa_freq_tab; yet there is
no configure dependency for iso_media which leads to failure of shared
builds.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It only existed because some code in mjpegenc_common.c relied on it;
yet said code was actually only used by mjpegenc.c and has been moved
there.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This allows to make ff_init_uni_ac_vlc static;
ff_mjpeg_encode_picture_frame has also been made static, but it could
always have been made static.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Since g2meet.c doesn't use it any more, only encoders use it and
the place for their common code is mjpegenc_common.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
While just at it, remove the nb_codes parameter: It is redundant
(the number of codes is implicitly contained in the array containing how
many entries of a specific size there are) and for this reason it might
even be wrong, so it is better to check what is actually used instead.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The MJPEG decoder is already activated by configure whenever the tiff
decoder is selected; ergo it is unnecessary to add a dependency in the
Makefile.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The avrn decoder actually only needs one thing: The MJPEG decoder.
Instead the Makefile made it compile mjpegdec and configure required
some of the prerequisites of the MJPEG decoder (exif and jpegtables).
Even if all the prerequisites of the MJPEG decoder were required, it
would still not make the MJPEG decoder usable, because for that
the MJPEG decoder needs to be in the list of codecs in codec_list.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Add inline function for vec_xl if VSX is not supported. vec_xl intrinsic
is only available on POWER 7 or higher.
Fixes ticket #8750.
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Neither the feature, public fields, or AVOptions were ever truly deprecated,
nor will have been removed if this FF_API_ define was left in place, so
get rid of it as it's misleading.
Signed-off-by: James Almer <jamrial@gmail.com>
Zero is the recommended value in Nvidia coding samples for low latency use-cases.
Signed-off-by: Michal Novotny <michal.novotny@comprimato.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
The FF_API macros are private and must not be used by external callers.
As the fields in question are to be removed without replacement, just
drop them.
The fields are:
AVPacket.convergence_duration
AVCodecContext.time_base
AVCodecContext.timecode_frame_start
AV_PIX_FMT_FLAG_PSEUDOPAL pixel descriptor flag
The current behaviour ends up squaring the avg_frame_rate if the conter mode flag is set.
This messes up the timecode calculation, and looks to me as a regression that
seems to have been introduced 428b4aac.
Upon further testing is seems that no special case is need for having the counter flag set.
av_timecode_init appears to handles the timecode correctly, at least in the sample files
I have.
Here is a sample mov file with the counter flag set
https://www.dropbox.com/s/5l4fucb9lhq523s/timecode_counter_mode.mov
before the patch ffmpeg will report the timecode as:
00:37:11:97 and warns that the timecode framerate is 576000000/1002001
after patch:
14:50:55:02
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This provides coverage for writing BlockGroups with BlockAdditional
and ReferenceBlock elements. It also tests setting the hearing impaired
disposition (it fits given that this video has no audio so one needs to
be able to read lips to understand anything).
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is the Matroska equivalent of D_WEBVTT_DESCRIPTIONS and is
therefore only enabled for subtitles.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is the equivalent of the WebM "D_WEBVTT/DESCRIPTIONS" and is
therefore only exported for subtitles.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Given that our disposition flags provide no way to distinguish the
cases of "track is unsuitable for hearing impaired users" and "it is
unknown whether the track is suitable for hearing impaired users" we do
not need to use a CountedElement for these flags.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Hint: Matroska actually provides a way to distinguish the cases of
"track is no commentary track" and "it is unknown whether the track
is a commentary track", but our disposition flags do not. Therefore
we need not use a CountedElement.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
For a very long time, the payload of integer and float elements had to
have a length > 0. Our parser treated such invalid elements as having a
value zero. But now it has been defined what an EBML element with length
zero means: It is a shorthand for the default value. This has also been
defined for strings (both ASCII and UTF-8). This commit modifies our
parser to support this.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This has been done in order to find out whether this element is present
at all; but this can now be done in a cleaner way by using a CountedElement
for it.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
According to the new EBML specifications, a string element of length
zero would be read as the default value by a compliant parser.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
In the absence of an explicitly coded minimal luminance, the current
code inferred it to be -1, an invalid value. Yet it did not check the
value lateron at all, so that if a valid maximum luminance is
encountered, but no minimal luminance, an invalid minimal luminance of
-1 is exported. If an minimal luminance element with a negative value is
present, it is exported, too. This can be simply fixed by adding a check
for the value of the element.
Yet given that a minimal luminance of zero Cd/m² is legal and can be
coded with a length of zero, we must not use a fake default value to
find out whether the element is present or not. Therefore this patch
uses an explicit counter for it.
While just at it, also check for max_luminance > min_luminance.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the generic EBML reader used by the Matroska demuxer did
not have the capability to record whether an element was actually
present or not; instead, in cases where it mattered one typically added
an invalid default value and checked whether the value is valid (in
which case it is guaranteed to be present). This worked pretty well so
far, yet the EBML specifications have evolved: It is now legal to use
zero-length elements for floats, ints, uints and strings (both ASCII and
UTF-8); the value of these elements is the default value of the element
(if it has one) or zero for scalar types and an empty string for
strings. Furthermore, having a default value does no longer imply that
the element may be presumed to be present (with its default value) if it
is absent; this is only true if the element is mandatory, too.
These rules are designed to allow size savings as follows: Consider the
newly added FlagOriginal: It being zero means the track is not in its
original language, it being one means it is. For backward compatibility
reasons, neither of the two values may be inferred automatically in the
absence of the element. But one can still save a byte when one wants to
write the element with a value of zero, as one can write the integer with
a length of zero: 0x55AE 80 instead of 0x55AE 81 00. In the former case,
a parser has to infer the value of the element to be zero (which is the
element's default value).
When encountering an element with length zero, our parser always infers
a value of zero (or an empty string); this is wrong for values with
a different default value. It needs to infer the default value (or zero
in its absence) and this precludes using an invalid default value for
elements like FlagOriginal. Ergo one needs to be able to record whether
an element is present or not by other means. This patch allows to use a
simple counter for this. While just at it, some invalid and unnecessary
default values have been removed (mastering metadata elements used
default values of -1.0, despite these elements only being used if they
are > 0).
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The FATE suite already contains a file containing mastering display
and content light level metadata: Meridian-Apple_ProResProxy-HDR10.mxf
This file is used to test both the Matroska muxer and demuxer.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is much less precise than the cycle counter register, but
the cycle counter register is not available on apple platforms
(and on linux, it requires a kernel module for allowing user mode
access).
Signed-off-by: Martin Storsjö <martin@martin.st>
This commit adds support for in-place FFT transforms. Since our
internal transforms were all in-place anyway, this only changes
the permutation on the input.
Unfortunately, research papers were of no help here. All focused
on dry hardware implementations, where permutes are free, or on
software implementations where binary bloat is of no concern so
storing dozen times the transforms for each permutation and version
is not considered bad practice.
Still, for a pure C implementation, it's only around 28% slower
than the multi-megabyte FFTW3 in unaligned mode.
Unlike a closed permutation like with PFA, split-radix FFT bit-reversals
contain multiple NOPs, multiple simple swaps, and a few chained swaps,
so regular single-loop single-state permute loops were not possible.
Instead, we filter out parts of the input indices which are redundant.
This allows for a single branch, and with some clever AVX512 asm,
could possibly be SIMD'd without refactoring.
The inplace_idx array is guaranteed to never be larger than the
revtab array, and in practice only requires around log2(len) entries.
The power-of-two MDCTs can be done in-place as well. And it's
possible to eliminate a copy in the compound MDCTs too, however
it'll be slower than doing them out of place, and we'd need to dirty
the input array.
Fixes: out of array access
Fixes: 29345/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HAP_fuzzer-5401813482340352
Fixes: 30745/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HAP_fuzzer-5762798221131776
Suggested-by: Anton
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>
Getting rid of unnecessary use of AVDictionary object in parsing
vpx_svc_ref_frame_config.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: James Zern <jzern@google.com>
Inside a function a superfluous ';' is just a null-statement; yet
outside it is invalid, even though compilers happen to accept them.
They (at least GCC and Clang) only warn about this when on -pedantic.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The MPEG-PS muxer uses a custom queue of custom packets. To keep track
of it, it has a pointer (named predecode_packet) to the head of the
queue and a pointer to where the next packet is to be added (it points
to the next-pointer of the last element of the queue); furthermore,
there is also a pointer that points into the queue (called premux_packet).
The exact behaviour was as follows: If premux_packet was NULL when a
packet is received, it is taken to mean that the old queue is empty and
a new queue is started. premux_packet will point to the head of said
queue and the next_packet-pointer points to its next pointer. If
predecode_packet is NULL, it will also made to point to the newly
allocated element.
But if premux_packet is NULL and predecode_packet is not, then there
will be two queues with head elements premux_packet and
predecode_packet. Yet only elements reachable from predecode_packet are
ever freed, so the premux_packet queue leaks.
Worse yet, when the predecode_packet queue will be eventually exhausted,
predecode_packet will be made to point into the other queue and when
predecode_packet will be freed, the next pointer of the preceding
element of the queue will still point to the element just freed. This
element might very well be still reachable from premux_packet which
leads to use-after-frees lateron. This happened in the tickets mentioned
below.
Fix this by never creating two queues in the first place by checking for
predecode_packet to know whether the queue is empty. If premux_packet is
NULL, then it is set to the newly allocated element of the queue.
Fixes tickets #6887, #8188 and #8266.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This patch also fixes a -Wtautological-constant-out-of-range-compare
warning from Clang and a -Wtype-limits warning from GCC on systems
where size_t is 64bits and unsigned 32bits. The reason for this seems
to be that variable (whose value derives from sizeof() and can therefore
be known at compile-time) is used instead of using sizeof() directly in
the comparison.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Makes SIMD-optimized 8x8 and 16x16 idcts for 8 and 10 bit depth
available on aarch64.
For a UHD HDR (10 bit) sample video these were consuming the most time
and this optimization reduced overall decode time from 19.4s to 16.4s,
approximately 15% speedup.
Test sample was the first 300 frames of "LG 4K HDR Demo - New York.ts",
running on Apple M1.
Signed-off-by: Josh Dekker <josh@itanimul.li>
the data type and order together decide the color format, we could
not use AVPixelFormat directly because not all the possible formats
are covered by it.
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
So the backend knows the usage of model is for frame processing,
detect, classify, etc. Each function type has different behavior
in backend when handling the input/output data of the model.
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
once we mark done for the task in function infer_completion_callback,
the task is possible to be release in function ff_dnn_get_async_result_ov
in another thread just after it, so we need to record request queue
first, instead of using task->ov_model->request_queue later.
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
x86_32 ABI does not pass float arguments directly on xmm regs, and the Win64
ABI uses only the first four regs for this purpose.
Signed-off-by: James Almer <jamrial@gmail.com>
A standard text file ends with a final LF.
Without this change, it is interpreted as an empty final line,
and visible with the box option.
The current behavior can be achieved by actually having
an empty line at the end of the file.
Fix trac ticket #7948.
Normally, video packets are muxed before audio packets for mxf (there is
a dedicated interleave function for this); furthermore the first (video)
packet triggers writing the actual header. Yet when the first video packet
fails the checks performed on it, it will be an audio packet that leads
to writing the header and codec_ul (a value set based upon
properties of the bitstream which necessitates actually inspecting
packets) may be wrong. Therefore this commit discards audio packets until
a valid video packet has been received.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The md5 test up until now ignored errors from ffmpeg (the cli) and just
md5'ed whatever ffmpeg has output; while testing scenarios in which
ffmpeg fails has its merits, errors should not be overlooked by default;
doing so also reduces the effectiveness of sanitizers as errors from
them are ignored. This has happened with a memleak in the AV1 decoder.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The mxf_d10 muxer is very picky regarding the input it accepts:
The only video accepted is MPEG-2 with absolutely constant bitrate,
i.e. all packets need to have exactly the same size; and only a few
bitrates are accepted.
The sample file used did not abide by this: Writing the first packet
(a video packet) errors out and afterwards an audio packet from the
muxing queue has been written. That's all besides metadata (which this
test is about). The FFmpeg cli returned an error, but said error has
been ignored by the md5 test.
This commit changes the test to actually send a compliant stream to the
muxer, so that it does not error out; furthermore, the test is changed
to explicitly check the metadata instead of it only being implicitly
included in the md5 checksum. The compliant stream is created by our
encoder at runtime.
Finally, the test now also covers writing user-specified
product/company/version identification.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
mxf distinguishes codec profiles by different UIDs and therefore needs
to check that the input is actually compatible with mxf (i.e. if there
is a defined UID for it). If not, then sometimes the UID would be set to
NULL and writing the (video) packet would fail. Yet the following audio
packet would trigger writing the header (which has been postponed because
the UID is not known at the start) and if the UID is NULL, this can lead
to segfaults. This commit therefore stops setting the UID to NULL if the
input is incompatible with mxf (it has initially been set to a generic
value in mxf_write_header()).
Fixes#7993.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, when using frame threaded encoding, an AVFrame would be
allocated for every frame to be encoded. These AVFrames would reach the
worker threads via a FIFO of tasks, a structure which contained the
AVFrame as well as an index into an array which gives the place where
the worker thread shall put the returned packet; in addition to that,
said structure also contained several unused fields.
This commit changes this: The AVFrames are now allocated during init in
the array that is up until now only used to return the packets. The
contents to be encoded are put into the AVFrame in the same array
element that is also used to return the packets.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, when doing frame thread encoding, each worker thread
tried to allocate an AVPacket for every AVFrame to be encoded; said
packets would then be handed back to the main thread, where the content
of said packet is copied into the packet actually destined for output;
the temporary AVPacket is then freed.
Besides being wasteful this also has another problem: There is a risk of
deadlock, namely if no AVPacket can be allocated at all. The user
doesn't get an error at all in this case and the worker threads will
simply try to allocate a packet again and again. If the user has
supplied enough frames, the user's thread will block until a task has
been completed, which just doesn't happen if no packet can ever be
allocated.
This patch instead modifies the code to allocate the packets during
init; they are then reused again and again.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes a segfault from av_fifo_size(NULL) that happens in
ff_frame_thread_encoder_free if the fifo couldn't be allocted;
furthermore the mutexes and conditions that are destroyed in
ff_frame_thread_encoder_free are not even initialized at this point,
so don't call said function.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is Visual Information Fidelity (VIF) filter and one of the component
filters of VMAF. It outputs the average VIF score over all frames.
Signed-off-by: Ashish Singh <ashk43712@gmail.com>
Also, test modifying colorspace properties and the default_mode
passthrough which is used here to create a file that has no default
track at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It furthermore tests the demuxer's handling of chained SeekHeads,
level 1-elements after the Clusters and the muxer's capability of
writing huge TrackNumbers as well as expanding the Cues' length field
by one byte if necessary to fill the reserved space. It also tests
propagation of metadata.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is undefined behaviour in C, so use data = len ? data + len : data
instead of data += len. GCC optimizes the branch away in this case;
Clang unfortunately doesn't.
Fixes ticket #8592.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It has been added in 6db42a2b6b,
yet since then none of the necessary create/free_device_capabilities
functions has been implemented, making this API completely useless.
Because of this one can already simplify
avdevice_capabilities_free/create and can already remove the function
pointers at the next major bump; given that the documentation explicitly
states that av_device_capabilities is not to be used by a user, it's
options can already be removed (save for the sentinel).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: 9223372036854775807 - -30069403896 cannot be represented in type 'long'
Fixes: 30046/clusterfuzz-testcase-minimized-ffmpeg_dem_FITS_fuzzer-5807144773484544
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The choosen value is arbitrary. I am not sure if this is a good idea
but i dont immedeately see an alternative better way, it seems either
an arbitrary limit or OOM
Fixes: OOM
Fixes: 27492/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6194970578649088
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Although rare, extradata can be present but empty and extraction will fail.
However Android also supports passing codec-specific data inline and
will likely play such a stream anyway. So there's no reason to abort
initialization before we know for sure.
And make it const, so the caller doesn't attempt to change it.
ff_get_muxer_ts_offset() should be used to get the muxer timestamp offset.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: signed integer overflow: -4611686024827895807 + -4611686016279904256 cannot be represented in type 'long'
Fixes: 30161/clusterfuzz-testcase-minimized-ffmpeg_dem_R3D_fuzzer-5694406713802752
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: out of array access
Fixes: 30135/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PBM_fuzzer-4997145650397184
Fixes: 30208/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGMYUV_fuzzer-5605891665690624.fuzz
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>
Since the decoder is not flagged as init cleanup capable, hevc_decode_free()
is being called manually if the hevc_decode_extradata() call fails at the end
of hevc_decode_init().
In a frame threading scenario, however, if AVCodec->init() returns an error,
ff_frame_thread_free() will be called regardless of the above flag being set
or not, resulting in hevc_decode_free() being called a second time for the
same context.
Workaround this by ensuring pointers are not dereferenced if they are NULL,
and set the decoder as init cleanup capable while at it.
Fixes ticket #9099.
Signed-off-by: James Almer <jamrial@gmail.com>
libavutil/common.h is a public header that provides generic math
functions whereas libavutil/intmath.h is a private header that contains
plattform-specific optimized versions of said math functions. common.h
includes intmath.h (when building the FFmpeg libraries) so that the
optimized versions are used for them.
This interdependency sometimes causes trouble: intmath.h once contained
an inlined ff_sqrt function that relied upon av_log2_16bit. In case there
was no optimized logarithm available on this plattform, intmath.h needed
to include common.h to get the generic implementation and this has been
done after the optimized versions (if any) have been provided so that
common.h used the optimized versions; it also needed to be done before
ff_sqrt. Yet when intmath.h was included from common.h and if an ordinary
inclusion guard was used by common.h, the #include "common.h" in intmath.h
was a no-op and therefore av_log2_16bit was still unknown at the end of
intmath.h (and also in ff_sqrt) if no optimized version was available.
Before a955b59658 this was solved by
duplicating the #ifndef av_log2_16bit check after the inclusion of
common.h in intmath.h; said commit instead moved these checks to the
end of common.h, outside the inclusion guards and made common.h include
itself to get these unguarded defines. This is still the current
state of affairs.
Yet this is unnecessary since 9734b8ba56
as said commit removed ff_sqrt as well as the #include "common.h" from
intmath.h. Therefore this commit moves everything inside the inclusion
guards and makes common.h not include itself.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Several compile-time checks can be improved because mcsel is not used
for MPEG-1/2 (it is only used for MPEG-4) and because MPEG-1/2 is the
only user of ff_mpv_motion that uses MV_TYPE_16X8 and MV_TYPE_DMV.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: left shift of 255 by 24 places cannot be represented in type 'int'
Fixes: 27516/clusterfuzz-testcase-minimized-ffmpeg_dem_KUX_fuzzer-5152854660349952
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
These made sense before 3ebf449766
when the creation of these boxes was specifically requested by the
user, but now they have become unnecessary as they are just like
many other boxes: If the input has the information required, they
are written, otherwise they are not.
They were moved to verbose verbosity level (which happens to be
the last level still relatively usable), and now appear either once
(normal MP4 muxing), or thrice (with the faststart flag set) in
any normal MP4 usage, without giving much useful information. Thus,
remove them in their current form.
Fixes: signed integer overflow: 0 - -9223372036854775808 cannot be represented in type 'long'
Fixes: 29743/clusterfuzz-testcase-minimized-ffmpeg_dem_SAMI_fuzzer-5499256859394048
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: 2 * 1073741952 cannot be represented in type 'int'
Fixes: 26765/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOBICLIP_fuzzer-6594926936326144
Fixes: 29663/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOBICLIP_fuzzer-5169789012148224
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Timeout
Fixes: left shift of 33046 by 16 places cannot be represented in type 'int'
Fixes: 29258/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MJPEG_fuzzer-4889231489105920
Fixes: 29515/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MJPEG_fuzzer-6161940391002112
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: negation of -9223372036854775808 cannot be represented in type 'int64_t' (aka 'long'); cast to an unsigned type to negate this value to itself
Fixes: 29437/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-4748510022991872
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
A new key & value API lets us gain access to newly added parameters
without adding explicit support for them in our wrapper. Add an
option utilizing this functionality in a similar manner to other
encoder libraries' wrappers.
Signed-off-by: Bohan Li <bohanli@google.com>
In case trellis is outside of 0..23, an invalid shift and/or a signed
integer overflow happens; furthermore, it can lead to the request to
allocate nonsense amounts of memory. So validate first.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
MJPEG does not have a single quantiser scale, so this does not fit into
the intended API use.
This removes the last use of the long-deprecated QP table API.
The way SRT's async / epoll-based IO works is that the event status is stored
in the epoll containers. That is, if an event occurs on an SRT socket, and that
SRT socket isn't part of any epoll container, then that event is lost. If we
later add that socket to an epoll container, we still won't receive the event
even if it wasn't serviced.
Therefore we create the epoll and put the fd into it right after the connection
is established.
See http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2021-January/275334.html
Signed-off-by: Marton Balint <cus@passwd.hu>
Sometimes there was a confusion between srt_*() function return values and
libavformat-style return values.
Signed-off-by: Marton Balint <cus@passwd.hu>
Both AC-3 encoder share the same options, yet they are nevertheless
duplicated in the binary; and the options applying to the EAC-3 encoder
are a proper subset of the options for the AC-3 encoders, so that it can
use the same options as the former by putting the options specific to
AC-3 at the front. This commit implements this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The fixed-point AAC decoder is the only user of the fixed-point sinewin
tables from sinewin; and it only uses a few of them (about 10% when
counting by size). This means that guarding initializing these tables by
an AVOnce (as done in 3719122065) is
unnecessary for them. Furthermore the array of pointers to the
individual arrays is also unneeded.
Therefore this commit moves these tables directly into aacdec_fixed.c;
this is done by ridding the original sinewin.h and sinewin_tablegen.h
headers completely of any fixed-point code at the cost of a bit of
duplicated code (the alternative is an ugly ifdef-mess).
This saves about 58KB from the binary when using hardcoded tables (as
these tables are hardcoded in this scenario); when not using hardcoded
tables, most of these savings only affect the .bss segment, but the rest
(< 1KB) contains relocations (i.e. savings in .data.rel.ro).
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If a target to be built includes a template file, the target's .d file
includes the template file as a prerequisite; if the code were changed so
that the template file no longer exists, one would get an error from
make that it has no rule for the template file target. Therefore add a
dummy rule for template files to make deleting them possible.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
xserver defines the endianness of the grabbed images. Use this information
to set the correct pixel format.
This also fixes format selection in configuration depth=32/bpp=32 with
xserver on a little endian machine. Before the patch, the big endian
layout 0RGB was always selected which is incorrect because BGR0 should
be used. RGB24 was also incorrectly assumed (but this format was removed
in xserver 1.20).
The big-endian settings can be tested using docker+qemu from a little-endian
machine:
$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
$ docker run --rm -it -v /tmp:/tmp powerpc64/debian /bin/bash
In docker container
$ apt-get update
$ apt-get install xvfb
$ apt-get install x11-apps
To test AV_PIX_FMT_0RGB32
$ Xvfb :2 -screen 0 720x480x24 &
$ export DISPLAY=:2
$ xclock -geometry 720x480 -bg green #test different colors
On your host machine grab the frames using the following
command. View output to check that colors are rendered correctly
$ ./ffmpeg -y -f x11grab -i :2.0 -codec:v mpeg2video out.mp4
Other pixel formats can be tested by modifying how Xvfb is started in the docker
container:
AV_PIX_FMT_RGB565
$ Xvfb :2 -screen 0 720x480x16
AV_PIX_FMT_RGB555
$ Xvfb :2 -screen 0 720x480x15
AV_PIX_FMT_BGR24 / AV_PIX_FMT_RGB24
This is difficult to test because bpp=24 support was removed in xserver 1.20
https://lists.x.org/archives/xorg-devel/2018-February/056175.html?hmsr=joyk.com&utm_source=joyk.com&utm_medium=referral
However, I was able to run previous version of Xvfb (with some
modifications to force 24bpp) to check that images are rendered correctly.
Reviewed-by: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
This ensures that needed arrays are always allocated and properly initialized.
Previously if code would use only avfilter_init_dict() to set options for filters
it would not allocate arrays for timeline processing thus it would crash if
user supplied enable option for filter(s).
The metadata company_name, product_name, product_version from input
file will be deleted to avoid overwriting information
Please to test with below commands:
./ffmpeg -i ../fate-suite/mxf/Sony-00001.mxf -c:v copy -c:a copy out.mxf
and
./ffmpeg -i ../fate-suite/mxf/Sony-00001.mxf -c:v copy -c:a copy \
-metadata company_name="xxx" \
-metadata product_name="xxx" \
-metadata product_version="xxx" \
out.mxf
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
This isn't supposed to happen, but unfinished support for non-templated
manifests and lack of e.g. presentationTimeOffset handling can provoke
such a situation even with well-formed input.
Rename is_init_section_common_audio to is_init_section_common_subtitle
for is_common_init_section_exist(c->subtitles, c->n_subtitles).
Because it is checked to subtitles, not audio.
Signed-off-by: liuqi05 <liuqi05@kuaishou.com>
because there have no Initialization in SegmentTemplate,
so it will have no init_section for init segment file.
but in the is_common_init_section_exist function it will be used for
check to url, url_offset and size, so check init_section
before use init_section.
And fix code style in is_common_init_section_exist,
make the code block short when it too long.
fix ticket: 9062
Signed-off-by: liuqi05 <liuqi05@kuaishou.com>
rtsp.c uses a check of the form "if (CONFIG_RTSP_DEMUXER && ...) {}"
with the intent to make the code compilable even though the part guarded
by this check contains calls to functions that don't exist when the RTSP
demuxer is disabled. Yet even then compilers still need a declaration of
all the functions in the dead code block and error out if not (due to
our usage of -Werror=implicit-function-declaration) and no such
declaration exists for a static function in rtsp.c. Simply adding a
declaration leads to a "used but never defined" warning, therefore this
commit resorts to an #if.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Replace av_isxdigit(*ptr) and convert(*ptr) with get_nibble(*ptr) which
returns a valid nibble=={0x00..0x0f} or false==255 for all other values.
This way we only need to work with *ptr once instead of twice.
Removing inline av_isxdigit(x) functions also shrinks executable size.
Signed-off-by: Joe Da Silva <digital@joescat.com>
If we test for {0..9} first, we have tested for 10/16th of all possible
characters first and avoid testing the remaining 6/16th of all possible
characters, which can be either 6/16th lowercase or 6/16th uppercase.
Signed-off-by: Joe Da Silva <digital@joescat.com>
Some compilers are very intuitive, and others are not so much, so let's
pre-compute the variables e and keylen outside the for loop. Ensuring a
minor speed increase regardless of if compiler is smart enough to solve
this improvement for itself, or not.
Signed-off-by: Joe Da Silva <digital@joescat.com>
Minor speed increase, end is calculated before entering parse_str_int(),
so let's take advantage of the value and avoid recalculating twice more.
This also allows parse_str_int() to work with file size larger than int.
Signed-off-by: Joe Da Silva <digital@joescat.com>
(This is actually the second time the encoder stuff is removed;
the first was in 8b4119187b62d6932e07aded11d33d3b24e1b42f.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: -1498310196 - 902891776 cannot be represented in type 'int'
Fixes: 28445/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1IMAGE_fuzzer-5075163389493248
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
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: 26910/clusterfuzz-testcase-minimized-ffmpeg_dem_SMACKER_fuzzer-6705429132476416
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It is only valid for the target, not the host and therefore it must not
be included when building the tables when hardcoded tables are enabled.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Tags can be marked "not used" upfront, saving some space in the primer.
av_asserts0() is used to enforce that only tags that are in the primer can actually be written.
Sharing of MasteringDisplay ULs is now done via macros.
Fixes: signed integer overflow: 7279992792120000000 + 4611686018427387904 cannot be represented in type 'long long'
Fixes: 29744/clusterfuzz-testcase-minimized-ffmpeg_dem_SBG_fuzzer-6434060249464832
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Besides avoiding allocations this also fixes a design defect of
ff_rtp_send_punch_packets: It did not return an error in case of
these allocations failed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Set the sample rate when parsing the header instead and only copy the
value in the decoder and the parser.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
convert_input, a nontrivial auxiliary function used by both the general
parsing code as well as the decoder itself, has been duplicated in
c7016e35a624a75bb5b82bee932ddfe28d013b3f; this commit removes said
duplication.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
These two functions are always called after another; after all, what
ff_dolby_e_parse_init does is obviously part of parsing the frame header.
Also move the DolbyEHeaderInfo into DBEContext so that parsing the frame
header only needs one struct (both users used a DBEContext immediately
followed by a separate DolbyEHeaderInfo).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Parsers are not forced to use a ParseContext and the other stuff from
parser.h which is just designed to help parsers recombining frames. But
this parser does not do this at all, i.e. the ParseContext is unused.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: index 26981 out of bounds for type 'ASFStreamData [128]'
Fixes: 27334/clusterfuzz-testcase-minimized-ffmpeg_dem_ASF_O_fuzzer-6197611002068992
Alternatively the array could be increased in size or the cases not fitting be ignored
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: 9223372036854710272 - -541165944832 cannot be represented in type 'long'
Fixes: 27000/clusterfuzz-testcase-minimized-ffmpeg_dem_IVF_fuzzer-5643670608674816
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: 1111111111111111111 * 10 cannot be represented in type 'long'
Fixes: 26892/clusterfuzz-testcase-minimized-ffmpeg_dem_TEDCAPTIONS_fuzzer-5756045055754240
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ff_init_ff_cos_tabs is only used for the floating point FFT and only
if hardcoded tables are disabled.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ff_fill_line_with_color and ff_draw_rectangle are unused since
19c8f2271423281c9b876b984076a6467c455904; ff_copy_rectangle
is unused since 53b7a3fe08.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Both motion vector tables have the same number of elements, hence one
can inline said number and remove the field containing the number of
elements from the structure.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: -3468545475927866368 * 4 cannot be represented in type 'long'
Fixes: 28879/clusterfuzz-testcase-minimized-ffmpeg_dem_NUV_fuzzer-6303367307591680
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The entry read is not used in subsequent computation, thus its
value is not important.
Fixes: out of array read
Fixes: 28578/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SIREN_fuzzer-6332019122503680
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
I've run into some bugs where I was downloading a bunch of data and began
seeing weird hiccups. For example, javascript promises to allow you to push
some very long lines of data, but the hiccups I saw was with data larger
than 2k in length (windows) pushed out of a child process stdout piped into
the stdin of the calling parent program.
Soo much for smooth promises, this was broken and would run into similar
problems on a linux PC with 32k line limits.
The solution was to break the data into smaller chunks than 2k - and then
these data hiccups disappeared (windows PC).
It would be expected to be similar for linux PCs (32k I think) and other
OSes with different sizes.
If the ANSI required minimum needs to be 509 chars or larger (assuming
509+<CR>+<LF>+<0>=512), then 509 was chosen as the shortest worst-case
scenario) in this patch.
Most small pictures will go output looking pretty much the same data out
until you get to about 84bytes (672 pixels wide), where lines out begin to
be split. For example a UW 4K will exceed a 2k readln and a UW 10K picture
approaches an 8k readln
The purpose for this patch is to ensure that data remains below the
readline limits (of 509 chars), so that programs (like javascript) can push
data in large chunks without breaking into hiccups because the data length
is too long to be pushed cleanly in one go.
Subject: [PATCH 3/3] avcodec/xbmenc: Allow for making UW images
Worst-case ANSI must allow for 509 chars, while Windows allows for 2048
and Linux for 32K line length. This allows an OS with a small readline
access limitation to fetch very wide images (created from ffmpeg).
Two minor memory improvements.
First bug reduces memory needed to about 6/7 the needed amount, which
allows you to host almost 7 pictures in the same memory needed for 6
Second is a recalculation of the total additional memory for headers etc.
size = avctx->height x (linesize * 6 + 1) + (31+32+38+4+1)
Subject: [PATCH 2/3] avcodec/xbmenc: xbm Lower memory use
Small 6/7th size memory reduction.
size = avctx->height x (linesize * 6 + 1) + (31+32+38+4+1)
Signed-off-by: Joe Da Silva <digital@joescat.com>
There is a minor bug in xbm encode which adds a trailing comma at the end
of data. This isn't a big problem, but it would be nicer to be more
technically true to an array of data (by not including the last comma).
This bug fixes the output from something like this (having 4 values):
static unsigned char image_bits[] = { 0x00, 0x11, 0x22, }
to C code that looks like this instead (having 3 values):
static unsigned char image_bits[] = { 0x00, 0x11, 0x22 }
which is the intended results.
Subject: [PATCH 1/3] avcodec/xbmenc: Do not add last comma into output array
xbm outputs c arrays of data.
Including a comma at the end means there is another value to be added.
This bug fix changes something like this:
static unsigned char image_bits[] = { 0x00, 0x11, 0x22, }
to C code like this:
static unsigned char image_bits[] = { 0x00, 0x11, 0x22 }
Signed-off-by: Joe Da Silva <digital@joescat.com>
Before 257a83b969, certain buffers were
zero-allocated in the init function and only reallocated lateron if they
turned out to be too small; now they are only allocated during init,
leading to use-of-uninitialized values lateron. The same could happen
before if the dimensions are big enough so that the buffers would be
reallocated, as the new part of the reallocated buffer would not be
zeroed (happened for 960x960). So always zero the buffers in the
function designed to init them.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The VLC for the macroblock address increment uses nine bits;
yet there is no code with this length: All codes are either shorter or
longer. So one can make the table smaller without changing the amount of
codes that need more than one round of parsing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This reverts commit 6ac0e78183.
The mpeg4video parser can reach code that presumes that a certain VLC
has been initialized; yet Libav did not ensure this and Libav bug #1012
[1] is about an ensuing crash.
Instead of fixing the root cause a simple check for whether said VLC
has already been initialized was added; said check is inherently racy.
The proper fix is of course to ensure that the VLC is initialized and
commit 7c76eaeca2 already ensured this,
so there was no need to merge 6ac0e78183
at all. This commit therefore reverts said commit.
[1]: https://bugzilla.libav.org/show_bug.cgi?id=1012
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
1b373b41d9 made it a bit harder to find
out that a call to avpriv_dv_produce_packet is dead when the DV demuxer
is disabled; too hard for GCC on -O0. So simplify the check a bit.
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: 234080282628234040 * 100 cannot be represented in type 'long long'
Fixes: 26910/clusterfuzz-testcase-minimized-ffmpeg_dem_REALTEXT_fuzzer-6649867065753600
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Note, the value is checked a few lines later already
Fixes: signed integer overflow: -440402016 - 1879048064 cannot be represented in type 'int'
Fixes: 26910/clusterfuzz-testcase-minimized-ffmpeg_dem_NUT_fuzzer-6603876618469376
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: -9223372036853488158 - 90000000 cannot be represented in type 'long long'
Fixes: 26910/clusterfuzz-testcase-minimized-ffmpeg_dem_MPSUB_fuzzer-6696625298866176
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: 9223372036850000000 + 9000000 cannot be represented in type 'long long'
Fixes: 26910/clusterfuzz-testcase-minimized-ffmpeg_dem_MPSUB_fuzzer-665448017480908
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
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: 29053/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-4814432697974784
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
A macro that expands to a function definition might look like a
declaration, but it isn't and therefore an extra ';' at the end is
unnecessary and actually invalid (both GCC and Clang warn about this
when using -pedantic).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It has been deprecated for 4 years and certain new codecs do not work
with it.
Also include AVCodecContext.refcounted_frames, as it has no effect with
the new API.
Also fix the indentation of decode_studio_vol_header while at it;
it was wrong since 177133a0f4.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
All callers only use the index into ff_dnxhd_cid_table to get a pointer
to the desired entry.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Neither module should depend on the other.
Move shared functions to its own file for this purpose, and ensure
source files are compiled only when the required modules are enabled.
Signed-off-by: James Almer <jamrial@gmail.com>
Up until now, ff_h263_rl_inter was initialized by both ituh263dec and
ituh263enc; this is an obstacle in making the codecs that use this code
init-threadsafe.
This obstacle is eliminated by only initializing this RLTable from
a single place that is guarded by a dedicated AVOnce.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The RLTable ff_rl_intra_aic is only used by ituh263dec and ituh263enc;
the former only uses the RLTable's VLC, the latter only index_run,
max_level and max_run. Yet ituh263dec also initializes the latter.
This commit stops doing so.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is easy now that the H.261 encoder is the only user that
initializes the non-VLC parts of ff_h261_rl_tcoeff.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The H.261 decoder only uses an RLTable's VLC table, yet it also
initializes its index_run, max_level and max_run. This commit stops
doing so; it will also simplify making this decoder init-threadsafe,
as the H.261 decoder and encoder now initialize disjoint parts of their
common RLTable.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is a prerequisite for making any encoder that uses
ff_mpv_encode_init() init-threadsafe; it already makes the AMV,
the MJPEG and the MPEG-1/2 encoders init-threadsafe.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
msmpeg4dec and ituh263dec both create VLCs with identical parameters out
of ff_mvtab. Given that ff_msmpeg4_decode_init() always (indirectly) calls
ff_h263_decode_init_vlc(), the VLC initialized by the latter can be
directly used by msmpeg4dec. Doing so saves a bit more than 2KB from the
.bss segment as well as the code to initialize a VLC.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Some of the RLTables used by msmpeg4dec actually coincide with other
RLTables: ff_rl_table[5] coincides with ff_h263_rl_inter (and
ff_rl_table[2] with ff_mpeg4_rl_intra). Given that ff_h263_rl_inter is
always initialized before msmpeg4dec's RLTables are initialized, one can
just reuse the VLC tables by copying the pointers; after all, there are
no ownership issues for static data. This saves 70912B from the .bss
segment, translating into actual memory savings when this decoder is
actually used.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The ff_rl_intra_aic RLTable is only used by ituh263dec and ituh263enc;
the former is the only user of its RL VLC tables. It uses only the very
first one of these VLC tables, but up until now all 32 are initialized,
wasting 68696B from the .bss segment (or that amount of memory if this
decoder has actually been used). This commit changes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The RLTables whose VLC tables are only used for intra blocks only use
the very first VLC table; yet all 32 have been initialized. This commit
stops this by switching to INIT_FIRST_VLC_RL. This saves 201624B from
the .bss segment; in case the decoder is actually used, this translates
into less memory used.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
For the RLTables ff_rl_table[0..2] only the very first VLC is only ever
used, so it makes no sense to create 32 of them. This saves 285200B from
the .bss segment; this amount of memory is actually saved when this
decoder is used.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The H.261 decoder uses only the very first VLC of ff_h261_rl_tcoeff,
so only initialize this one. Saves 68448B from the .bss segment; in case
the decoder is actually used, this amount of memory is saved.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It is not uncommon that only the first one is used; this is similar to
ff_init_2d_vlc_rl().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
FFmpeg does not support POST, so there is no difference between a
308 and 301 request (see [RFC7538] section 3).
Signed-off-by: Josh Dekker <josh@itanimul.li>
Setting the defaults for $arch happens only later, so
the current code would not set AS correctly if --arch
was not specified on the command-line.
Fix it by adding an explicit fallback to $arch_default.
Signed-off-by: Josh Dekker <josh@itanimul.li>
Since c737f6edce prescreening is
nevertheless run because of a wrong check: "if (s->prescreen > 0)".
s->prescreen is an array of two function pointers that is contained in
the context and comparing it with 0 (i.e. NULL) is actually undefined
behaviour, because NULL and s->prescreen do not point to the same
object (NULL after all never points to any object). Nevertheless both
Clang as well as GCC compile this to code that treat s->prescreen > 0 as
true, leading to segfaults, because the code then tries to access the
-1th member of an array.
This commit fixes the check as well as another such check a few lines
below.
(Found via compiler warnings enabled by -pedantic:
"ordered comparison between pointer and zero is an extension".)
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Forgotten in 6197453761 (notice that
RTPDynamicProtocolHandler is not a public struct, so one can remove
the linked-list pointer immediately (unlike in most other patches of
this kind)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fix atoi() overflow for large EXT-X-MEDIA-SEQUENCE.
The spec says the type of sequence number is uint64_t. Use int64_t
here since current implementation requires it to be signed integer,
and hlsenc use int64_t too.
The patch changes the init function to initialize block dimensions to fixed
64x64 instead of the previously used image width/height based value.
This should not cause any actual change in behaviour because block dimensions
are recalculated on every keyframe in optimum_block_width() and
optimum_block_height() functions and in the current code the result is always
64x64 regardless of the image dimensions used.
Signed-off-by: Marton Balint <cus@passwd.hu>
This reverts commit 6696a07ac6.
It is wrong to restrict timecodes to always contain leading zeros or for hours
or frames to be 2 chars only.
Signed-off-by: Marton Balint <cus@passwd.hu>
Dump iopattern mode and the SDK error/warning desciptions for qsv based
filters and iopattern mode for qsvenc
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Signed-off-by: Linjie Fu <linjie.justin.fu@gmail.com
It is a copy of the relevant part in lavc/qsv but use different function
names to avoid multiple definition when linking lavc and lavf statically.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Signed-off-by: Linjie Fu <linjie.justin.fu@gmail.com
Fixes: signed integer overflow: -9223372036854767583 + -65536 cannot be represented in type 'long'
Fixes: 26910/clusterfuzz-testcase-minimized-ffmpeg_dem_FLV_fuzzer-6734549467922432
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: -9223372036842389247 - 2147483648 cannot be represented in type 'long long'
Fixes: 26910/clusterfuzz-testcase-minimized-ffmpeg_dem_FLV_fuzzer-4845007531671552
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 access
Fixes: 26819/clusterfuzz-testcase-minimized-ffmpeg_dem_FITS_fuzzer-5634559355650048
Fixes: 26820/clusterfuzz-testcase-minimized-ffmpeg_dem_FITS_fuzzer-5760774955597824
Fixes: 27379/clusterfuzz-testcase-minimized-ffmpeg_dem_FITS_fuzzer-5129775942991872.fuzz
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: 9223372036854775723 + 8192 cannot be represented in type 'long'
Fixes: 29072/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-4812604904177664
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
tableprint.h does not declare anything as aligned; it just prints
DECLARE_ALIGNED. So it can be removed; in fact, it needs to be removed,
because mem_internal.h includes config.h which leads to warnings when
building with hardcoded tables enabled because of redefinitions of
CONFIG_HARDCODED_TABLES.
(Furthermore, config.h is only valid for the target, not the host,
so HAVE_LOCAL_ALIGNED might even be wrong here.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
fixes http://trac.ffmpeg.org/ticket/9055
The hw decoder may allocate a large frame from AVHWFramesContext, and adjust width and height based on bitstream.
We need to use resolution from src frame instead of AVHWFramesContext.
test command:
ffmpeg -loglevel debug -hide_banner -hwaccel vaapi -init_hw_device vaapi=va:/dev/dri/renderD128 -hwaccel_device va -hwaccel_output_format vaapi -init_hw_device vulkan=vulk -filter_hw_device vulk -i 1920x1080.264 -c:v libx264 -r:v 30 -profile:v high -preset veryfast -vf "hwmap,chromaber_vulkan=0:0,hwdownload,format=nv12" -map 0 -y vaapiouts.mkv
expected:
No green bar at bottom.
from proc_from_frame_to_dnn to ff_proc_from_frame_to_dnn, and
from proc_from_dnn_to_frame to ff_proc_from_dnn_to_frame.
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
The OpenVINO model file format changes when OpenVINO goes to a new
release, it does not work if the versions between model file and
runtime are mismatched.
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
The usage of a static variable presents a potential for data races and
means that this function can't be used in init functions of codecs with
FF_CODEC_CAP_INIT_THREADSAFE (unless of course one presumes that
everything is alright in which case the error is not triggered; but then
the whole function is pointless...). This makes the Snow decoder
init-threadsafe as it already claims.
Notice that this function has been removed in 2014 by Libav in commit
9103185bd1, because only some codepaths
are checked this way and because it only affects legacy compilers. The
latter is of course even more true today.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The only call to ff_intel_h263_decode_picture_header() is already behind
"if (CONFIG_H263I_DECODER)".
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
2ef2496cd1 used ff_vorbis_channel_layouts
in flac.c, but added a dependency to the FLAC decoder only; lateron
aba0278e9f added the dependency of the
FLAC parser and encoder on vorbis_data.o. Yet when the original commit
was reverted in aba0278e9f, the two other
dependencies were not removed. This commit fixes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The st->codec values are updated based on the lowres factor by
avformat_find_stream_info() when it runs an instance of the decoder internally,
and the same thing happens in ffmpeg.c when we open ist->dec_ctx with
avcodec_open2(), so these assignments are redundant.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: signed integer overflow: 2314885530818453566 + 7503032301549264928 cannot be represented in type 'long'
Fixes: 26639/clusterfuzz-testcase-minimized-ffmpeg_dem_ASF_O_fuzzer-6024222100684800
Alternatively this could be ignored but then the end condition of the loop
would be hard to reach as avio_tell() is int64_t
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: 8833900919969684211 - -9223372036854775808 cannot be represented in type 'long'
Fixes: 26726/clusterfuzz-testcase-minimized-ffmpeg_dem_AVI_fuzzer-5669377724383232
Fixes: 27587/clusterfuzz-testcase-minimized-ffmpeg_dem_AVI_fuzzer-6294562263531520
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: 64 + 9223372036854775799 cannot be represented in type 'long'
Fixes: 27563/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6244650163372032
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
OpenVINO APIs require specify input size to run the model, while some
OpenVINO model does accept different input size. To enable this feature
adding input_resizable option here for easier use.
Setting bool variable input_resizable to specify if the input can be resizable or not.
input_resizable = 1 means support input resize, aka accept different input size.
input_resizable = 0 (default) means do not support input resize.
Please make sure the inference model does accept different input size
before use this option, otherwise the inference engine may report error(s).
eg: ./ffmpeg -i video_name.mp4 -vf dnn_processing=dnn_backend=openvino:\
model=model_name.xml:input=input_name:output=output_name:\
options=device=CPU\&input_resizable=1 -y output_video_name.mp4
Signed-off-by: Ting Fu <ting.fu@intel.com>
Move openvino model/inference request creation and initialization steps
from ff_dnn_load_model_ov to new function init_model_ov, for later input
resize support.
Signed-off-by: Ting Fu <ting.fu@intel.com>
Fixes#1941
Currently the media control uri is not correctly assigned when mpegts is
signalled in the media description.
The code checks whether at least one AVStream has been setup before
assigning to the media's uri. With mpegts the AVStreams are setup when
parsing packets and so the media's uri is skipped. This is fixed by
using rt->nb_rtsp_streams in the check which counts all medias in the
sdp.
Reviewed-by: Andriy Gelman <andriy.gelman@gmail.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
avcodec has no facilities to generate timestamps properly from
output frame numbers (and it would be wrong for VFR anyway),
so pass through the timestamps using rav1e's opaque user data
feature, which was added in v0.4.0.
This bumps the minimum librav1e version to 0.4.0.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
As per signal() help (man 2 signal) the semantics of using signal may
vary across platforms. It is suggested to use sigaction() instead.
Reviewed-by: Zane van Iperen <zane@zanevaniperen.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
If the edit lists remove parts of the output timeline, or add a
delay to it, this should be included in the mvhd/tkhd/mdhd durations,
which should correspond to the edit lists.
For tracks starting with pts < 0, the edit list trims out the segment
before pts=0. For tracks starting with pts > 0, a delay element is
added in the edit list, delaying the start of the track data.
In both cases, the practical effect is that the post-edit output
is as if the track had started with pts = 0. Thus calculate the range
from pts=0 to end_pts, for the purposes of mvhd/tkhd/mdhd, unless
edit lists explicitly are disabled.
mov_write_edts_tag needs to operate on the actual pts duration of
the track samples, not the duration that already takes the edit
list effect into account.
Signed-off-by: Martin Storsjö <martin@martin.st>
In order to fine-control referencing schemes in VP9 encoding, there
is a need to use VP9E_SET_SVC_REF_FRAME_CONFIG method. This commit
provides a way to use the API through frame metadata.
DAV files may contain a variable length padding in between chunks
filled with 0xff bytes. The current skipping logic is incorrect as it
may skip over DHAV chunks not appearing sequentially in the file.
We now look for the 'DHAV' tag using a byte-by-byte search in order
to handle such situations. Also the dhav->last_good_pos field will
not be updated while skipping unrecognized data.
No longer used by anything.
Unfortunately the old FFT_FLOAT/FFT_FIXED_32 is left as-is. It's
simply too much work for code meant to be all removed anyway.
In either encoder, its impossible for the coefficients to go past 25 bits
right after the MDCT. Our MDCT is numerically stable.
For the floating point encoder, in case a NaN is contained, lrintf() will
raise a floating point exception during the conversion.
The AC3 encoder used to be a separate library called "Aften", which
got merged into libavcodec (literally, SVN commits and all).
The merge preserved as much features from the library as possible.
The code had two versions - a fixed point version and a floating
point version. FFmpeg had floating point DSP code used by other
codecs, the AC3 decoder including, so the floating-point DSP was
simply replaced with FFmpeg's own functions.
However, FFmpeg had no fixed-point audio code at that point. So
the encoder brought along its own fixed-point DSP functions,
including a fixed-point MDCT.
The fixed-point MDCT itself is trivially just a float MDCT with a
different type and each multiply being a fixed-point multiply.
So over time, it got refactored, and the FFT used for all other codecs
was templated.
Due to design decisions at the time, the fixed-point version of the
encoder operates at 16-bits of precision. Although convenient, this,
even at the time, was inadequate and inefficient. The encoder is noisy,
does not produce output comparable to the float encoder, and even
rings at higher frequencies due to the badly approximated winow function.
Enter MIPS (owned by Imagination Technologies at the time). They wanted
quick fixed-point decoding on their FPUless cores. So they contributed
patches to template the AC3 decoder so it had both a fixed-point
and a floating-point version. They also did the same for the AAC decoder.
They however, used 32-bit samples. Not 16-bits. And we did not have
32-bit fixed-point DSP functions, including an MDCT. But instead of
templating our MDCT to output 3 versions (float, 32-bit fixed and 16-bit fixed),
they simply copy-pasted their own MDCT into ours, and completely
ifdeffed our own MDCT code out if a 32-bit fixed point MDCT was selected.
This is also the status quo nowadays - 2 separate MDCTs, one which
produces floating point and 16-bit fixed point versions, and one
sort-of integrated which produces 32-bit MDCT.
MIPS weren't all that interested in encoding, so they left the encoder
as-is, and they didn't care much about the ifdeffery, mess or quality - it's
not their problem.
So the MDCT/FFT code has always been a thorn in anyone looking to clean up
code's eye.
Backstory over. Internally AC3 operates on 25-bit fixed-point coefficients.
So for the floating point version, the encoder simply runs the float MDCT,
and converts the resulting coefficients to 25-bit fixed-point, as AC3 is inherently
a fixed-point codec. For the fixed-point version, the input is 16-bit samples,
so to maximize precision the frame samples are analyzed and the highest set
bit is detected via ac3_max_msb_abs_int16(), and the coefficients are then
scaled up via ac3_lshift_int16(), so the input for the FFT is always at least 14 bits,
computed in normalize_samples(). After FFT, the coefficients are scaled up to 25 bits.
This patch simply changes the encoder to accept 32-bit samples, reusing
the already well-optimized 32-bit MDCT code, allowing us to clean up and drop
a large part of a very messy code of ours, as well as prepare for the future lavu/tx
conversion. The coefficients are simply scaled down to 25 bits during windowing,
skipping 2 separate scalings, as the hacks to extend precision are simply no longer
necessary. There's no point in running the MDCT always at 32 bits when you're
going to drop 6 bits off anyway, the headroom is plenty, and the MDCT rounds
properly.
This also makes the encoder even slightly more accurate over the float version,
as there's no coefficient conversion step necessary.
SIZE SAVINGS:
ARM32:
HARDCODED TABLES:
BASE - 10709590
DROP DSP - 10702872 - diff: -6.56KiB
DROP MDCT - 10667932 - diff: -34.12KiB - both: -40.68KiB
DROP FFT - 10336652 - diff: -323.52KiB - all: -364.20KiB
SOFTCODED TABLES:
BASE - 9685096
DROP DSP - 9678378 - diff: -6.56KiB
DROP MDCT - 9643466 - diff: -34.09KiB - both: -40.65KiB
DROP FFT - 9573918 - diff: -67.92KiB - all: -108.57KiB
ARM64:
HARDCODED TABLES:
BASE - 14641112
DROP DSP - 14633806 - diff: -7.13KiB
DROP MDCT - 14604812 - diff: -28.31KiB - both: -35.45KiB
DROP FFT - 14286826 - diff: -310.53KiB - all: -345.98KiB
SOFTCODED TABLES:
BASE - 13636238
DROP DSP - 13628932 - diff: -7.13KiB
DROP MDCT - 13599866 - diff: -28.38KiB - both: -35.52KiB
DROP FFT - 13542080 - diff: -56.43KiB - all: -91.95KiB
x86:
HARDCODED TABLES:
BASE - 12367336
DROP DSP - 12354698 - diff: -12.34KiB
DROP MDCT - 12331024 - diff: -23.12KiB - both: -35.46KiB
DROP FFT - 12029788 - diff: -294.18KiB - all: -329.64KiB
SOFTCODED TABLES:
BASE - 11358094
DROP DSP - 11345456 - diff: -12.34KiB
DROP MDCT - 11321742 - diff: -23.16KiB - both: -35.50KiB
DROP FFT - 11276946 - diff: -43.75KiB - all: -79.25KiB
PERFORMANCE (10min random s32le):
ARM32 - before - 39.9x - 0m15.046s
ARM32 - after - 28.2x - 0m21.525s
Speed: -30%
ARM64 - before - 36.1x - 0m16.637s
ARM64 - after - 36.0x - 0m16.727s
Speed: -0.5%
x86 - before - 184x - 0m3.277s
x86 - after - 190x - 0m3.187s
Speed: +3%
As we get a new set of objects each frame anyway, we
do not gain anything by keeping the modifier constant.
This helps with capturing when switching your setup a
bit, e.g. from ingame to desktop or from X11 to wayland.
Signed-off-by: Mark Thompson <sw@jkqxz.net>
The kernel defaults to initializing the field to 0 when modifiers
are not used and this happens to be linear. If we end up actually
passing the modifier to a driver, tiling issues happen.
So if the kernel doesn't return a modifier set it explicitly to
INVALID. That way later processing knows there is no explicit
modifier.
Signed-off-by: Mark Thompson <sw@jkqxz.net>
This patch adds support for arbitrary-point FFTs and all even MDCT
transforms.
Odd MDCTs are not supported yet as they're based on the DCT-II and DCT-III
and they're very niche.
With this we can now write tests.
Two tests check the opposite pointer before using it. If only one of these
is set to a valid pointer, one of these functions will crash, the other will
ignore the pointer.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: shift exponent 64 is too large for 64-bit type 'unsigned long long'
Fixes: 26497/clusterfuzz-testcase-minimized-ffmpeg_dem_AVI_fuzzer-5690188355076096
Fixes: 26903/clusterfuzz-testcase-minimized-ffmpeg_dem_LUODAT_fuzzer-5641466929741824
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
CBS doesn't change its contents in any way whatsoever internally, and most
users already set it to a const array.
Signed-off-by: James Almer <jamrial@gmail.com>
These fields were added to support -merge_pmt_versions, but the mpegts demuxer
is also keeping track its programs internally, so that should be a better place
to handle it.
Also it is not a very good idea to keep fields like program_num or
pmt_stream_idx in an AVStream, because a single stream can be part of multiple
programs, multiple PMTs, so the stream attributes can refer to any program the
stream is part of.
Since they are not part of public API, lets simply remove them, or rather
replace them with placeholders for ABI compatibility with libavdevice.
Signed-off-by: Marton Balint <cus@passwd.hu>
Also make sure we are checking the old state of the streams because otherwise
some streams might already have the newly parsed stream identifiers which
corrupts matching.
Fixes streams having the same identifier mixed up on pmt version change.
Fixes ticket #9006.
Signed-off-by: Marton Balint <cus@passwd.hu>
Otherwise there can be a small period when the programs only contain the PMT
pid.
Also make sure skip_clear only affects AVProgram clear, and that pmt_pid is
always kept as the first entry of the PID list of the programs. Also reject
PMTs for programs on the wrong PID.
Signed-off-by: Marton Balint <cus@passwd.hu>
PID 0 was removed from the pid list when then PMT was parsed, it is better
to explictly avoid it from being discarded instead of keeing it in the list of
every program.
Signed-off-by: Marton Balint <cus@passwd.hu>
av_new_program returns the existing program if that already exists, in that
case it makes no sense to overwrite existing attributes.
Signed-off-by: Marton Balint <cus@passwd.hu>
INT32_MAX (2147483647) isn't exactly representable by a floating point
value, with the closest being 2147483648.0. So when rescaling a value
of 1.0, this could overflow when casting the 64-bit value returned from
lrintf() into 32 bits.
Unfortunately the properties of integer overflows don't match up well
with how a Fourier Transform operates. So clip the value before
casting to a 32-bit int.
Should be noted we don't have overflows with the table values we're
currently using. However, converting a Kaiser-Bessel window function
with a length of 256 and a parameter of 5.0 to fixed point did create
overflows. So this is more of insurance to save debugging time
in case something changes in the future.
The macro is only used during init, so it being a little slower is
not a problem.
Commit bdd31feec9 changed the SBC decoder to only set the output
sample format on init, instead of setting it explicitly on each frame,
which is correct. But the SBC parser overrides the sample format to S16,
which triggers a crash when combining the parser and the decoder.
Fix the issue by not setting the sample format anymore in the parser,
which is wrong.
Signed-off-by: James Almer <jamrial@gmail.com>
The function is not used anywhere else and is causing mingw-w64 clang
builds to fail with
ffmpeg-git/libavdevice/decklink_dec.cpp:792:5: error: no previous prototype for function 'get_bmd_timecode' [-Werror,-Wmissing-prototypes]
int get_bmd_timecode(AVFormatContext *avctx, AVTimecode *tc, AVRational frame_rate, BMDTimecodeFormat tc_format, IDeckLinkVideoInputFrame *videoFrame)
Signed-off-by: Christopher Degawa <ccom@randomderp.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Currently skip_samples is set to start_pad if sample_time is lesser or
equal to 0. This can cause issues if the stream starts with packets that
have negative pts. Calling avformat_seek_file() with ts set to 0 on such
streams makes the mov demuxer return the right corresponding packets
(near the 0 timestamp) but set skip_samples to start_pad which is
incorrect as the audio decoder will discard the returned samples
according to skip_samples from the first packet it receives (which has
its timestamp near 0).
For example, considering the following audio stream with start_pad=1344:
[PKT pts=-1344] [PKT pts=-320] [PKT pts=704] [PKT pts=1728] [...]
Calling avformat_seek_file() with ts=0 makes the next call to
av_read_frame() return the packet with pts=-320 and a skip samples
side data set to 1344 (start_pad). This makes the audio decoder
incorrectly discard (1344 - 320) samples.
This commit makes the move demuxer adjust skip_samples according to the
stream start_pad, seek timestamp and first sample timestamp.
The above example will now result in av_read_frame() still returning the
packet with pts=-320 but with a skip samples side data set to 320
(src_pad - (seek_timestamp - first_timestamp)). This makes the audio
decoder only discard 320 samples (from pts=-320 to pts=0).
Signed-off-by: Marton Balint <cus@passwd.hu>
Runtime checks for whether the encoder is fixed-point or not are
unnecessary here as this is a template; furthermore, there is no
fixed-point EAC-3 encoder, so some checks for whether one is in EAC-3
mode can be omitted when doing fixed-point encoding.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ff_eac3_exponent_init() set values twice when initializing a static
table; ergo the initialization code must not run concurrently with
a running EAC-3 encoder. Yet this code is executed every time an EAC-3
encoder is initialized. So use ff_thread_once() for this and also for a
similar initialization performed for all AC-3 encoders to make them all
init-threadsafe.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: 9223372036854775807 + 32768 cannot be represented in type 'long'
Fixes: 27744/clusterfuzz-testcase-minimized-ffmpeg_dem_DHAV_fuzzer-5179319491756032
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Also do it for FFT_FLOAT only, as this is the only combination for which
it can be set.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The Opus header initial padding preskip amount is always to be expressed
relative to 48kHz. However, the encoder delay returned from querying
libopus is relative to the encoding samplerate. Multiply by the
samplerate conversion factor to correct.
Signed-off-by: Arthur Taylor <art@ified.ca>
This implements the function drop_obu() as defined in Setion 6.2.1 from the
spec.
In a reading only scenario, units that belong to an operating point the
caller doesn't want should not be parsed.
Signed-off-by: James Almer <jamrial@gmail.com>
The caller may not need all units in a fragment in reading only scenarios.
They could in fact alter global state stored in the private CodedBitstreamType
fields in an undesirable way.
With this change, unit decomposition can be skipped based on parsed values
within the unit.
Signed-off-by: James Almer <jamrial@gmail.com>
The standalone version of Kvazaar sets a default ratecontrol algorithm when
bitrate is set. Mirror this behaviour.
Signed-off-by: Joose Sainio <joose.sainio@tuni.fi>
Signed-off-by: Linjie Fu <linjie.justin.fu@gmail.com>
It's required by the 9.3.1 TableStatCoeff* section.
Following clips have this feature:
WPP_HIGH_TP_444_8BIT_RExt_Apple_2.bit
Bitdepth_A_RExt_Sony_1.bin
Bitdepth_B_RExt_Sony_1.bin
EXTPREC_HIGHTHROUGHPUT_444_16_INTRA_10BIT_RExt_Sony_1.bit
EXTPREC_HIGHTHROUGHPUT_444_16_INTRA_12BIT_RExt_Sony_1.bit
EXTPREC_HIGHTHROUGHPUT_444_16_INTRA_8BIT_RExt_Sony_1.bit
EXTPREC_MAIN_444_16_INTRA_10BIT_RExt_Sony_1.bit
EXTPREC_MAIN_444_16_INTRA_12BIT_RExt_Sony_1.bit
EXTPREC_MAIN_444_16_INTRA_8BIT_RExt_Sony_1.bit
WPP_AND_TILE_10Bit422Test_HIGH_TP_444_10BIT_RExt_Apple_2.bit
WPP_AND_TILE_AND_CABAC_BYPASS_ALIGN_0_HIGH_TP_444_14BIT_RExt_Apple_2.bit
WPP_AND_TILE_AND_CABAC_BYPASS_ALIGN_1_HIGH_TP_444_14BIT_RExt_Apple_2.bit
WPP_AND_TILE_HIGH_TP_444_8BIT_RExt_Apple_2.bit
you can download them from:
https://www.itu.int/wftp3/av-arch/jctvc-site/bitstream_exchange/draft_conformance/RExt/
Signed-off-by: Xu Guangxin <oddstone@gmail.com>
Signed-off-by: Linjie Fu <linjie.justin.fu@gmail.com>
Add 2 new options:
- reconnect_on_http_error - a list of http status codes that should be
retried. the list can contain explicit status codes / the strings
4xx/5xx.
- reconnect_on_network_error - reconnects on arbitrary errors during
connect, e.g. ECONNRESET/ETIMEDOUT
the retry employs the same exponential backoff logic as the existing
reconnect/reconnect_at_eof flags.
related tickets:
https://trac.ffmpeg.org/ticket/6066https://trac.ffmpeg.org/ticket/7768
Signed-off-by: Marton Balint <cus@passwd.hu>
Do it only when requested with the AV_CODEC_EXPORT_DATA_VIDEO_ENC_PARAMS
flag.
Drop previous code using the long-deprecated AV_FRAME_DATA_QP_TABLE*
API. Temporarily disable fate-filter-pp, fate-filter-pp7,
fate-filter-spp. They will be reenabled once these filters are converted
in following commits.
Besides being more natural it also avoids allocations for separate
arrays of decoded samples/output buffers/....
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The sbr_qmf_window_us array is basically symmetric around its middle
element and therefore the latter half is currently initialized from the
first half at runtime. Yet because the first half is initialized, the
array can't be placed in .bss at all, so that one gains nothing from not
already initializing the whole array statically. Therefore this commit
does exactly this.
(There are two exceptions to the symmetry: Elements 384 and 512 are the
negations of their mirror element; for the fixed-point decoder, Q31(-x)
does not equal -Q31(x). In order to keep the array exactly the same, the
latter form has been used for these two elements.)
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Finding the best codebook involves comparing different paths, where each
path is a sequence of several decisions (namely which codebook to use).
Up until now, these sequence was encoded in a NUL-terminated string and
the actual decisions were encoded as ’\0'..'\3' (which encoded 0..3).
This commit modifies this to actually encode it via 0..3 by switching
away from a C-string to a simple array with an explicit length field.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The celt_delay AVAudioFifo is always allocated during init, so checking
for its existence in .flush is unnecessary.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Modifying static storage must not happen because of multithreading
(except initialization of course), so add const to the pointed-to type
for pointers that point to static storage.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
These two are always called directly after each other (with the
exception of the calls in mpeg_decode_init() where some irrelevant
modifications of the avctx (which could just as well be done before
ff_mpv_decode_defaults(), because it doesn't have a pointer to the
AVCodecContext at all and therefore can't see these modifications at
all) are performed in between), so merge ff_mpv_decode_defaults() in
ff_mpv_decode_init().
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This automatically makes the eamad, eatqi, ipu and mdec decoders
init-threadsafe; in addition to the actual mpeg[12]video decoders,
of course.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ff_mpeg12_init_vlcs() currently initializes index_run, max_level and
max_run of ff_rl_mpeg1/2; yet the only user of these fields is the
MPEG-1/2 encoder which already initializes these tables on its own.
So remove the initializations in ff_mpeg12_init_vlcs(); this also
simplifies making ff_mpeg12_init_vlcs() thread-safe.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The prefix for symbols not exported from the library and not
local to one translation unit is ff_ (or FF for types).
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
This was introduced in version 4.6. And may not exist all without an
optional package. So to prevent a hard dependency on needing the Linux
kernel headers to compile, make this optional.
Also ignore the status of the ioctl, since it may fail on older kernels
which don't support it. It's okay to ignore as its not fatal and any
serious errors will be caught later by the mmap call.
'void *' is too flexible, since we can derive info from
AVFilterContext*, so we just unify the interface with this data
structure.
Signed-off-by: Xie, Lin <lin.xie@intel.com>
Signed-off-by: Wu Zhiwen <zhiwen.wu@intel.com>
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
function fill_model_input_ov and infer_completion_callback are
extracted, it will help the async execution for reuse.
Signed-off-by: Xie, Lin <lin.xie@intel.com>
Signed-off-by: Wu Zhiwen <zhiwen.wu@intel.com>
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
This can be used to receive the raw mpegts stream from a SAT>IP
server, by letting avformat handle the RTSP/RTP/UDP negotiation
and setup, but then simply passing the MP2T stream through
instead of demuxing it further.
For example, this command would demux/remux the mpegts stream:
SATIP_URL='satip://192.168.1.99:554/?src=1&freq=12188&pol=h&ro=0.35&msys=dvbs&mtype=qpsk&plts=off&sr=27500&fec=34&pids=0,17,18,167,136,47,71'
ffmpeg -i $SATIP_URL -map 0 -c copy -f mpegts -y remux.ts
Whereas this command will simply write out the raw stream, with
the original PAT/PMT/PIDs intact:
ffmpeg -rtsp_flags satip_raw -i $SATIP_URL -map 0 -c copy -f data -y raw.ts
Signed-off-by: Aman Karmani <aman@tmm1.net>
strips + tiles is not allowed in TIFF
DNG uses a separate codepath
Regression since da5b3d0028.
Fixes: NULL pointer dereference
Fixes: poc1
Fixes: Ticket8960
Found-by: 1vanChen of NSFOCUS Security Team
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When targeting a recent enough macOS/iOS version that has clock_gettime
it won't be a weak symbol, in which case clang warns for this check
as it's always true:
warning: address of function 'clock_gettime' will always
evaluate to 'true'
This warning is silenced by using the address-of operator to make
the intent explicit.
because hls_enc_key and hls_enc_iv get 16byte char
for example:
-hls_enc_key 0123456789abcdef -hls_enc_iv abcdefghijklmnop
Reviewed-by: Gyan Doshi <ffmpeg@gyani.pro>
Signed-off-by: Steven Liu <liuqi05@kuaishou.com>
The first stats is printed after the initial stats_period has elapsed. With a large period,
it may appear that ffmpeg has frozen at startup.
The initial stats is now printed after the first transcode_step.
At present, progress stats are updated at a hardcoded interval of
half a second. For long processes, this can lead to bloated
logs and progress reports.
Users can now set a custom period using option -stats_period
Default is kept at 0.5 seconds.
Derive input parameters from correct inlink when using ppsrc.
Previously both input frames would use dimensions of first inlink,
causing crash if first inlink w/h was smaller than second one.
Fixes a decoding regression introduced by e9a2a87773, and as a side effect also
fixes bogus values set to certain audio frames that had some samples discarded,
where the offsets added to pts, pkt_dts and pkt_duration were not reflected in
best_effort_timestamp.
Signed-off-by: James Almer <jamrial@gmail.com>
One of the inputs to the fate test has an rgba pixel format which needs
to be converted to rgb32 (argb on big-endian) for the hqx filter. Because auto
scaling in the fate test is disabled, this needs a separate scale
filter.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Fixes fate-qtrle-32bit on big-endian.
The macro does a simple byte swap on uint8 array without any casts, so
it's valid on big-endian arches.
The mentioned test was failing because the byteswap function
shuffle_bytes_3210_c() is used in the pixel format conversion
(argb->bgra).
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Up until now, the SpeedHQ encoder called a wrong function for init:
void ff_init_uni_ac_vlc(const uint8_t huff_size_ac[256],
uint8_t *uni_ac_vlc_len);
Yet the first argument actually used is of type RLTable; the size of
said struct is less than 256 if the size of a pointer is four, leading
to an access beyond the end of the RLTable.
This commit fixes this by calling the actually intended function:
init_uni_ac_vlc() from mpeg12enc.c. It was intended to use this
function [1], yet doing so was forgotten when the patch was actually
applied.
[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-July/266187.html
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The earlier code would not complain if the remaining size was one byte
short of the desired size; and the way it performed the check could run
into signed integer overflow.
Fixes: signed integer overflow: 9223372036854775807 + 1 cannot be represented in type 'long'
Fixes: Timeout
Fixes: 26434/clusterfuzz-testcase-minimized-ffmpeg_dem_MV_fuzzer-5752845451919360
Fixes: 26444/clusterfuzz-testcase-minimized-ffmpeg_dem_BINK_fuzzer-4697773380993024
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: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The decoders in this set either have a fixed channel count, or read it
from the bitstream, and thus do not require the channel count as
external information.
Fixes various regressions since
81503ac58a, which requires a valid channel
count for decoders which do not set this capability.
Signed-off-by: Hendrik Leppkes <h.leppkes@gmail.com>
SMVJPEG stores frames as slices of a big JPEG image. The decoder is
implemented as a wrapper that instantiates a full internal MJPEG
decoder, then forwards the decoded frames with offset data pointers.
This is unnecessarily complex and fragile, not supporting useful decoder
capabilities like direct rendering.
Re-implement the decoder inside the MJPEG decoder, which is accomplished
by returning each decoded frame multiple times, setting cropping
information appropriately on each instance.
One peculiar aspect of the previous design is that since
- the smvjpeg decoder returns one frame per input packet
- there are multiple frames in each packets (the aformentioned slices)
the demuxer needs to return each packet multiple times.
This is now also eliminated - the demuxer now returns each packet
exactly once, with the duration set to the number of frames it decodes
to.
This also removes one of the last remaining internal uses of the old
video decoding API.
It depends on the muxer generating the timestamps, which is deprecated
and scheduled for removal on next bump.
A bunch of tests change timestamps, because of ffmpeg.c is not
generating them correctly. This should be fixed later.
Factor out the code into a separate muxing-specific function.
Stop accessing the deprecated AVStream-embedded codec context, use the
average framerate (if specified) instead.
following comandline will crash the ffmpeg
ffmpeg -threads 17 -thread_type slice -i WPP_A_ericsson_MAIN_2.bit out.yuv -y
the HEVCContext->sList size is MAX_NB_THREADS(16), any > 16 thread number will crash the application
Signed-off-by: Anton Khirnov <anton@khirnov.net>
ff_snow_common_init() currently initializes static data every time it is
invoked; given that both the Snow encoder and decoder have the
FF_CODEC_CAP_INIT_THREADSAFE flag set, this can lead to data races (and
therefore undefined behaviour) even though all threads write the same
values. This commit fixes this by using ff_thread_once() for the
initializations.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The cropdetect filter, at present, skips the first two frames. This
behaviour is hardcoded.
New option 'skip' allows users to change this. Convenient for when
input is a single image or a trimmed video stream.
Default is kept at 2 to preserve current behaviour.
Monochrome encoding with libaom was buggy for a long time, but this was
finally sorted out in libaom 2.0.1 (2.0.0 is almost there but was still
buggy in realtime mode).
We'll keep support for libaom 1.x around until the LTS distros that
include it are EOL (which is still a long time from now).
Fixes: https://trac.ffmpeg.org/ticket/7599
Nothing guarantees that the size of side data containing a palette
is actually divisible by four (although it should be); but for
big-endian systems, an algorithm is used that presupposed this.
So switch to an algorithm that does not overread: It processes
four bytes at a time, but only if all of them are contained in
the side data.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
By switching from ff_init_vlc_sparse() to ff_init_vlc_from_lengths() one
can replace a table of codes of type uint16_t by a table of symbols of
type uint8_t, saving space.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Commit 1a29804558 guarded several
initializations of static data in the AAC decoders with an AVOnce and
set the FF_CODEC_CAP_INIT_THREADSAFE flag, believing the former to be
sufficient for the latter. It wasn't, because several of these static
tables are shared with other components, so that there might be data
races if they are initialized from multiple threads. This affected
initializing the ff_sine_* tables as well as initializing the
ff_aac_pow*sf_tab tables (shared between both decoders and encoder) as
well as ff_aac_kbd_* tables (shared between encoder and floating point
decoder).
Commit 3d62e7a30f set the
FF_CODEC_CAP_INIT_THREADSAFE flag for the AAC encoder. More explicitly,
this commit used the same AVOnce to guard initializing ff_aac_pow*sf_tab
in the encoder and to guard initializing the static data of each
decoder; the ensuing catastrophe was "fixed" in commit
ec0719264c by using a single AVOnce
for each codec again. But the codec cap has not been removed and
therefore the encoder claimed to be init-threadsafe, but wasn't, because
of the same tables as above.
The ff_sine_* tables as well as ff_aac_pow*sf_tab tables have already
been fixed; this commit deals with the ff_aac_kbd_* tables, making the
encoder as well as the floating-point decoder init-threadsafe (the
fixed-point decoder is it already).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The floating point kbd tables for 120 and 960 samples are only used by
the floating point decoder whereas the fixed point kbd tables for 128
and 1024 samples are only used by the fixed point AAC decoder. So move
these tables to their only users. This ensures that they are not
accidentally used somewhere else without ensuring that initializing
these tables stays thread-safe (as it is now because the only place from
where they are initialized is guarded by an AVOnce).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The floating point AAC decoder is the only user of these tables, so it
makes sense to move them there. Furthermore, initializing the ordinary
power-of-two sinetables is currently not thread-safe and if the 120- and
960-point sinetables were not moved, one would have to choose whether
to guard initializing these two tables with their own AVOnces or not.
Doing so would add unnecessary AVOnces as the AAC decoder already guards
initializing its static data by an AVOnce; not doing so would be fragile
if a second user of these tables were to be added.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
There are no ff_sine_windows for 2^i, 0 <= i < 5, so one should check
for the index being >= 5.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Both the fixed as well as the floating point mpegaudio decoders use
LUTs of type int8_t and uint32_t with 32K entries each; these tables
are completely the same, yet they are not shared. This commit makes
them shared. When both fixed as well as floating point decoders are
enabled, this saves 160KiB from the bss segment for a normal build
(translating into 160KiB less memory usage if both a shared as well as
a floating point decoder have actually been used) and 160KiB from the
binary for a build with hardcoded tables.
It also means that the code to create said LUTs is no longer duplicated
(for a normal build).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The csa_tables (which always consist of 32 entries of four byte each,
but the type depends upon whether the decoder is fixed or
floating-point) are currently initialized once during decoder
initialization; yet it turns out that this is actually no benefit: The
code used to initialize these tables takes up 153 (fixed point) and 122
(floating point) bytes when compiled with GCC 9.3 with -O3 on x64, so it
is better to just hardcode these tables.
Essentially the same applies to the is_tables: They have a size of 128B
each and the code to initialize them occupies 149 (fixed point) resp.
140 (floating point) bytes. So hardcode them, too.
To make the origin of the tables clear, references to the code used to
create them have been added.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Each invocation of this function is only entered once, so using a static
array makes no sense (and given that the whole array is reinitialized at
the beginning of this function, it wouldn't even make sense if the
function were called multiple times).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The mpegaudio_tablegen header contains code to initialize several
tables; it is included in both the fixed as well as the floating point
mpegaudio decoders and some of these tables are only used by the fixed
resp. floating point decoders; yet both types are always initialized,
leaving the compiler to figure out that one of them is unused.
GCC 9.3 fails at this (even with -O3):
$ readelf -s mpegaudiodec_fixed.o|grep _float
28: 0000000000001660 32768 OBJECT LOCAL DEFAULT 4 expval_table_float
An actually unused table (expval_table_fixed/float) of size 32KiB is kept
and initialized (the reason for this is probably that this table is read
from, namely to initialize another table: exp_table_fixed/float; of course
the float resp. fixed tables are not used in the fixed resp. floating point
decoder).
Therefore #ifdef the unneeded tables away.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, there were several indiviual tables which were accessed
via pointers to them; by combining the tables, one can avoid said
pointers, saving space.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
By switching from ff_init_vlc_sparse() to ff_init_vlc_from_lengths() one
can replace tables of codes of type uint16_t by tables of symbols of
type uint8_t; this saves about 1.3KB for both the fixed and floating
point decoders (if enabled).
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
By switching from ff_init_vlc_sparse() to ff_init_vlc_from_lengths() one
can remove the array of codes of type uint16_t here; given that the
symbols are the default ones (0,1,2,...), no explicit symbols table
needs to be added.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
By switching from ff_init_vlc_sparse() to ff_init_vlc_from_lengths() one
can remove arrays of codes in cases where there were already symbols
tables.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Expressions like array[get_vlc2()] can be optimized by using a symbols
table if the array is always the same for a given VLC. This requirement
is fulfilled for several VLCs used by the AAC decoders.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is possible by switching to ff_init_vlc_from_lengths() which allows
to replace tables of codes of size uint16_t or uint32_t by tables of
symbols of size uint8_t; in case there already were symbols tables the
savings are even bigger.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
MagicYUV transmits its Huffman trees by providing the length of the code
corresponding to each symbol; then the decoder has to assemble the table
in such a way that (i) longer codes are to the left of the tree and (ii)
for codes of the same length the symbols are ascending from left to right.
Up until now the decoder did this as follows: It counted the number of
codes of each length and derived the first code of a given length via
(ii). Then the array of lengths is traversed a second time to create
the codes; there is one running counter for each length to do so. This
process creates a default symbol table (that is omitted).
This commit changes this as follows: Everything is indexed by the
position in the tree (with codes to the left first); given (i), we can
calculate the ranges occupied by the codes of each length; and with (ii)
we can derive the actual symbols of each code; the running counters for
each length are now used for the symbols and not for the codes.
Doing so allows us to switch to ff_init_vlc_from_lengths(); this has the
advantage that the codes table needs only be traversed once and that the
codes need not be sorted any more (right now, the codes that are so long
that they will be put into subtables need to be sorted so that codes
that end up in the same subtable are contiguous).
For a sample produced by our encoder (natural content, 4000 frames,
YUV420p, ten iterations, GCC 9.3) this decreased the amount of
decicycles for each call to build_huffman() from 1336049 to 1309401.
Notice that our encoder restricts the code lengths to 12 and our decoder
only uses subtables when the code is longer than 12 bits, so the sorting
that can be avoided does not happen at the moment. If one reduces the
decoder's tables to nine bits, the performance improvement becomes more
apparent: The amount of decicycles for build_huffman() decreased from
1165210 to 654055.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The Huffman trees used by Ut Video have two important characteristics:
(i) Longer codes are on the left of the tree and (ii) for codes of the
same length, the symbol is descending from left to right in the tree.
Therefore all the information that needs to be transmitted is how long
the code corresponding to a given symbol is; and this is also all that
is transmitted.
Before 341914495e, the decoder used qsort
to sort the (length, symbol) pairs by ascending length and for equal
lengths by ascending symbol. Since said commit, the decoder uses
a first pass over the lengths table to count how many symbols of each
length there are; with (i) one can then easily calculate the code of
the left-most code with a given length in the tree and from there one
can calculate the codes for all entries, using one running counter for
each possible length. This eliminated the explicit qsort in
build_huff().
Yet ff_init_vlc_sparse() sorts the table itself as it has to ensure that
all the entries that will be placed in the same subtable are contiguous.
The tables created now are non-contiguous (they are ordered by symbol
and codes of different length aren't ordered at all; only codes of the
same length are ordered according to (ii)).
This commit therefore modifies the algorithm used to automatically create
tables whose codes are sorted from left to right in the tree. The key to
do so is the observation that the counts obtained in the first pass can
be used to contain the range of the codes of each length in the second
pass: If counts[i] is the count of codes with length i, then the first
counts[32] codes are of length 32, the next counts[31] codes are of
length 31 etc. So one knows the index of the lowest symbol whose code
has length 32 (if any): It is counts[32] - 1 due to (ii), whereas the
index of the lowest symbol whose code has length 31 (if any) is
counts[32] + counts[31] - 1; the index of the second-to-lowest symbol of
length 32 (if existing) is counts[32] - 2 etc.
If one follows the algorithm outlined above, one can switch to
ff_init_vlc_from_lengths() which has no implicit qsort; it also means
that one can offload the computation of the codes.
This turned out to be beneficial for performance: For the sample from
ticket #4044 it decreased the decicycles spent on one call to
build_huff() from 508480 to 340688 (GCC 9.3, looping 10 times over the
file to get enough runs and then repeating this ten times); for another
sample (YUV420p, natural content, 5500 frames, also ten iterations)
the time went down from 382346 to 275533 decicycles.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Expressions like array[get_vlc2()] can be optimized by using a symbols
table if the array is always the same for a given VLC. This requirement
is fulfilled for several VLCs used by ATRAC3, therefore this commit
implements this. This comes without any additional costs when using
ff_init_vlc_from_lengths() as one can then remove the codes tables.
While at it, remove the arrays of pointers to the individual arrays and
put all lengths+symbol pairs in one big array.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
By switching from ff_init_vlc_sparse() to ff_init_vlc_from_lengths() one
can replace an array of codes of type uint16_t with an array of symbols
of type uint8_t, saving space.
Also remove some more code duplication while at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
theora_init_huffman_tables() does essentially the same as
ff_init_vlcs_from_lengths().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Expressions like array[get_vlc2()] can be optimized by using a symbols
table if the array is always the same for a given VLC. This requirement
is fulfilled for the VLC used for VP3 motion vectors. The reason it
hasn't been done before is probably that the array in this case
contained entries in the range -31..31; but this is no problem with
ff_init_vlc_from_lengths(): Just apply an offset of 31 to the symbols
before storing them in the table used to initialize VP3 motion vectors
and apply an offset of -31 when initializing the actual VLC.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is possible by switching to ff_init_vlc_from_lengths() because it
allows to replace codes of type uint16_t by symbols of type uint8_t; in
some cases (like here) it also allows to replace explicitly coded
codes by implicitly coded symbols.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
By switching to ff_init_vlc_from_lengths() one can apply both positive
as well as negative offsets for free; in this case it even saves space
because one replaces codes tables that don't fit into an uint8_t by
symbols tables that fit into an uint8_t or can even be completely
avoided as they are trivial.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Also remove code duplication and use a named constant for the number of
VLC bits while just at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The ATRAC9 decoder creates VLCs with parameters contained in
HuffmanCodebooks; some of these HuffmanCodebooks are empty and yet
VLCs (that were completely unused*) were created from them. Said VLC
contained a single table with 512 VLC_TYPE[2] entries, each of which
indicated that this is an invalid code. This commit stops creating said
VLCs.
*: read_coeffs_coarse() uses the HuffmanCodebook
at9_huffman_coeffs[cb][prec][cbi]. prec is c->precision_coarse[i] + 1
and every precision_coarse entry is in the 1..15 range after
calc_precision(), so prec is >= 2 (all codebooks with prec < 2 are
empty). The remaining empty codebooks are those with cb == 1 and cbi ==
0, yet this is impossible, too: cb is given by c->codebookset[i] and
this is always 0 if i < 8 (because those are never set to anything else
in calc_codebook_idx()) and cbi is given by at9_q_unit_to_codebookidx[i]
which is never zero if i >= 8.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Using separate tables has the downside that one needs a big number of
pointers to the separate tables (currently 77); unifying them avoids
this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The ATRAC9 decoder uses VLCs which are currently initialized with
static length tables of type uint8_t and code tables of type uint16_t.
Furthermore, in one case the actually desired symbols are in the range
-16..15 and in order to achieve this an ad-hoc symbols table of type
int16_t is calculated.
This commit modifies this process by replacing the codes tables by
symbols tables and switching to ff_init_vlc_from_lengths(); the signed
symbols are stored in the table after having been shifted by 16 to fit
into an uint8_t and are shifted back when the VLC is created. This makes
all symbols fit into an uint8_t, saving space. Furthermore, the earlier
tables had holes in them (entries with length zero that were inserted
because the actually used symbols were not contiguous); these holes are
unnecessary in the new approach, leading to further saving.
Finally, given that now both lengths as well as symbols are of the same
type, they can be combined; this saves a pointer for each VLC.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is very beneficial for the scale factor tables where 4*64+4*15
bytes of length information can be replaced by eight codebooks of 12
bytes each; furthermore the number of codes as well as the maximum
length of a code can be easily derived from said codebooks, making
tables containing said information superfluous. This and combining the
symbols into one big array also made an array of pointers to the tables
redundant.
For the wordlen and code table tables the benefits are not that big
(given these tables don't contain that many elements), but all in all
using codebooks is also advantageouos for them. Therefore it has been
done.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ATRAC3+ uses VLCs whose code lengths are ascending from left to right in
the tree; ergo it is possible (and done) to run-length encode the
lengths into so-called codebooks. These codebooks were variable-sized:
The first byte contained the minimum length of a code, the second the
maximum length; this was followed by max - min + 1 bytes containing the
actual numbers. The minimal min was 1, the maximal max 12.
While one saves a few bytes by only containing the range that is
actually used, this is more than offset by the fact that there needs
to be a pointer to each of these codebooks.
Furthermore, since 5f8de7b741 the content
of the Atrac3pSpecCodeTab structure (containing data for spectrum
decoding) can be cleanly separated into fields that are only used during
initialization and fields used during actual decoding: The pointers to
the codebooks and the field indicating whether an earlier codebook should
be reused constitute the former category. Therefore the new codebooks are
not placed into the Atrac3pSpecCodeTab (which is now unused during
init), but in an array of its own. The information whether an earlier
codebook should be reused is encoded in the first number of each
spectrum codebook: If it is negative, an earlier codebook (given by the
number) should be reused.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This allows to remove lots of pointers (130) to small symbol tables;
it has the downside that some of the default tables must now be coded
explicitly, but this costs only 6 + 4 + 8 + 16 + 8 bytes and is therefore
dwarfed by the gains.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The earlier code used several different offset parameters that were
initialized to magic values. This is unnecessary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The ATRAC3+ decoder currently uses ff_init_vlc_sparse() to initialize
several VLCs; sometimes a symbols table is used, sometimes not; some of
the codes tables are uint16_t, some are uint8_t. Because of these two
latter facts it makes sense to switch to ff_init_vlc_from_lengths()
because it allows to remove the codes at the cost of adding symbols
tables of type uint8_t in the cases where there were none before.
Notice that sometimes the same codes and lengths tables were reused with
two different symbols tables; this could have been preserved (meaning
one could use a lengths table twice), but hasn't, because this allows
to use only one pointer to both the symbols and lengths instead of two
pointers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ff_init_vlc_from_lengths() can be used to offload the computation
of the codes; it also allows to omit the check whether the codes
are already properly ordered (they are). In this case, this also allows
to avoid the allocation of the buffer for the codes.
This improves performance: The amount of decicycles for one call to
tm2_build_huff_tables() when decoding tm20.avi from the FATE-suite
decreased from 46239 to 40035. This test consisted of looping 50 times
over the file and iterating the test ten times.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Switching from ff_init_vlc_sparse() to ff_init_vlc_from_lengths()
allows to replace codes which are so long that they need to be stored
in an uint16_t by symbols which fit into an uint8_t; and even these can
be avoided in case of the sprite trajectory VLC.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Switching from ff_init_vlc_sparse() to ff_init_vlc_from_lengths()
allows to replace codes which are so long that they need to be stored
in an uint16_t by symbols which fit into an uint8_t; furthermore, it is
also easily possible to already incorporate the offset (the real range
of Indeo 2 symbols starts at one, not zero) into the symbols.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ff_init_vlc_from_lengths() can be used to offload the computation
of the codes; it also allows to omit the check whether the codes
are already properly ordered (they are).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ff_init_vlc_from_lengths() can be used to offload the computation
of the codes; it also needn't check whether the codes are already
properly ordered (they are).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The lengths of the codes used by the mss4 decoder are ascending from
left to right and therefore the lengths can be run-length encoded and
the codes can be easily derived from them. And this is how it is indeed
done. Yet some things can nevertheless be improved:
a) The number of entries of the current VLC is implicitly contained in
the run-length table and needn't be externally prescribed.
b) The maximum length of a code is just the length of the last code
(given that the lengths are ascending), so there is no point in setting
max_bits in the loop itself.
c) One can offload the actual calculation of the codes to
ff_init_vlc_from_lengths().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Besides removing code duplication the method for determining the offset
of each VLC table in the VLC_TYPE buffer also has the advantage of not
wasting space for skipped AIC mode 1 VLCs.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
RealVideo 4.0 has a VLC that encodes two intra types per code; each
intra type is in the range 0..8 (inclusive) and up until now the VLC
used symbols in the range 0..80; one type was encoded as the remainder
when dividing the symbol by 9 whereas the other type was encoded as
symbol / 9. This is suboptimal; a better way would be to use the high
and low nibble to encode each symbol. But an even better way is to use
16bit symbols so that the two intra types can be directly written as
a 16bit value.
This commit implements this; in order to avoid huge tables the symbols
are stored as uint8_t with high and low nibbles encoding one type each;
they are only unpacked to uint16_t during initialization.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
After permuting the codes, symbols and lengths tables used to initialize
the VLC so that the codes are ordered from left to right in the Huffman
tree, the codes become redundant as they can be easily computed from the
lengths at runtime; in this case one has to use explicit symbol tables,
but all the symbols used here fit into an uint8_t, whereas some codes
needed uint16_t. This saves about 1.6KB.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
After permuting the codes, symbols and lengths tables used to initialize
the VLCs so that the codes are ordered from left to right in the Huffman
tree, the codes become redundant as they can be easily computed from the
lengths at runtime (or at compile time with --enable-hardcoded-tables);
in this case one has to use explicit symbol tables, but all the symbols
used here fit into an uint8_t, whereas some codes needed uint16_t.
Furthermore, the codes had holes because the range of the symbols was not
contiguous; these have also been removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If both codes, lengths and symbols tables are ordered so that the codes
are sorted from left to right in the tree, the codes can be easily
derived from the lengths and therefore become redundant. This is
exploited in this commit to remove the codes tables for the mobiclip
decoder; notice that tables for the run-length VLC were already ordered
correctly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, VLCs that were part of an array of VLCs were often not
initialized in a loop, but separately. The probable reason for this
was that these VLCs differed slightly in the parameters to be used for
them (i.e. the number of codes or the number of bits to be used
differs), so that one would have to provide these parameters e.g. via
arrays.
Yet these problems have actually largely been solved by now: The length
information is contained in a run-length encoded form that is the same
for all VLCs and both the number of codes as well as the number of bits
to use for each VLC can be easily derived from them.
There is just one problem to be solved: When the underlying tables have
a different number of elements, putting them into an array of arrays
would be wasteful; using an array of pointers to the arrays would
also be wasteful. Therefore this commit combines the tables into bigger
tables. (Given that all the length tables have the same layout this
applies only to the symbols tables.)
Finally, the array containing the offset of the VLC's buffer in the big
buffer has also been removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Several of the quantisation VLCs come in pairs and up until now the
number of bits used for each VLC was set to the same value for both VLCs
in such a pair even when one of the two required only a lower number.
This is a waste given that the get_vlc2() call is compatible with these
two VLCs using a different number of bits (it uses vlc->bits).
Given that the code lengths are descending it is easily possible to know
the length of the longest code for a given VLC: It is the length of the
first one. With this information one can easily use the least amount of
bits.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
After permuting both length, code as well as symbol tables so that
the codes are ordered from left to right in the tree, it became apparent
that the length of the codes decreases from left to right. Therefore one
can run-length encode the lengths to save space. This commit implements
this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
By switching to ff_init_vlc_from_lengths() one can make a table of
codes of type uint8_t superfluous, saving space.
Other VLCs (those without dedicated symbols table and with codes of
type uint8_t) have been made to use ff_init_vlc_from_lengths(), too,
because it reduces codesize (ff_init_vlc_from_lengths() has two
parameters less than ff_init_vlc_sparse()) and because it allows to
use the offset parameter in future commits.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
By switching to ff_init_vlc_from_lengths() one can replace tables of
codes of type uint16_t with tables of symbols of type uint8_t, saving
space.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
By using ff_init_vlc_from_lengths(), we do not have to keep track of the
codes themselves, but can offload this to ff_init_vlc_from_lengths().
Furthermore, the old code presumed sizeof(int) == 4; this is no longer
so.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
By switching to ff_init_vlc_from_lengths() one can replace a table of
codes of type uint32_t with a table of symbols of type uint8_t saving
space. The old tables also had holes in it (because of the symbols) which
are now superfluous, saving ever more space.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The VLC tables to be used for parsing RealVideo 1.0 DC coefficients are
weird: The luma table contains a block of 2^11 codes beginning with the
same prefix and length that all have the same symbol (i.e. value only
depends upon the prefix); the same goes for the chroma block (except
it's only 2^9 codes). Up until now, these entries (which generally could
be parsed like ordinary entries with subtables) have been treated
specially: They have been treated like open ends of the tree, so that
get_vlc2() returned a value < 0 upon encountering them; afterwards it
was checked whether the right prefix was used and if so, the appropriate
number of bytes was skipped.
But there is actually an easy albeit slightly hacky way to support them
directly without pointless subtables: Just modify the VLC table so that
all the entries sharing the right prefix have a length that equals the
length of the whole entry.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
These tables were huge (14 bits) because one needed 14 bits in order to
find out whether a code is valid and in the VLC table or a valid code that
required hacky workarounds due to RealVideo 1.0 using multiple codes
for the same symbol and the code predating the introduction of symbols
tables for VLCs.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The RealVideo 1.0 decoder uses VLCs to parse DC coefficients. But the
values returned from get_vlc2() are not directly used; instead
-(val - 128) (which is in the range -127..128) is. This transformation
is unnecessary as it can effectively be done when initializing the VLC
by modifying the symbols table used. There is just one minor
complication: The chroma table is incomplete and in order to distinguish
an error from get_vlc2() (due to an invalid code) the ordinary return
range is modified to 0..255. This is possible because the only caller of
this function is (on success) only interested in the return value modulo
256.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
RealVideo 1.0 uses an insane way to encode DC coefficients: There are
several symbols that (for no good reason whatsoever) have multiple
encodings, leading to longer codes than necessary.
More specifically, the tree for the 256 luma symbols contains 255 codes
belonging to 255 different symbols on the left; going further right,
the tree consists of two blocks of 128 codes each of length 14 encoding
consecutive numbers (including two encodings for the symbol missing among
the 255 codes on the left); this is followed by two blocks of codes of
length 16 each containing 256 elements with consecutive symbols (i.e.
each of the blocks allows to encode all symbols). The rest of the tree
consists of 2^11 codes that all encode the same symbol.
The tree for the 256 chroma symbols is similar, but is missing the
blocks of length 256 and there are only 2^9 consecutive codes that
encode the same symbol; furthermore, the chroma tree is incomplete:
The right-most node has no right child.
All of this caused problems when parsing these codes; the reason is that
the code for this predates commit b613bacca9
which added support for explicit symbol tables and thereby removed the
requirement that different codes have different symbols. In order to
address this, the trees used for parsing were incomplete: They contained
the 255 codes on the left and one code for the remaining symbol. Whenever
a code not in these trees was encountered, it was dealt with in
special cases (one for each of the blocks mentioned above).
This commit reduces the number of special cases: Using a symbols table
allows to treat the blocks of consecutive symbols like ordinary codes;
only the blocks encoding a single symbol are still treated specially
(in order not to waste memory on tables for them).
In order to not increment the size of the tables used to initialize the
VLCs both the symbols as well as the lengths are now run-length encoded.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This can be achieved by switching to ff_init_vlc_from_lengths() which
allows to replace two uint16_t tables for codes with uint8_t tables for
the symbols by permuting the tables so that the codes are ordered from
left to right in the tree in which case they can be easily computed from
the lengths at runtime.
And after doing so, it became apparent that the tables for the symbols
are actually the same for luma and chroma, so that one can even omit one
of them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Permuting the tables used to initialize the Cook VLCs so that the code
tables are ordered from left to right in the tree revealed that the
length of the codes are ascending from left to right. Therefore one can
run-length encode them to avoid the big length tables; this saves a bit
more than 1KB.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the Cook decoder used tables for the lengths of codes and
tables of the codes itself to initialize VLCs; the tables for the codes
were of type uint16_t because the codes were so long. It did not use
explicit symbol tables. This commit instead reorders the tables so that
the code tables are sorted from left to right in the tree. Then the
codes can be easily derived from the lengths and therefore be omitted.
This comes at the price of explicitly coding the symbols, but this is
nevertheless a net win because most of the symbols tables can be coded
on one byte. Furthermore, Cook actually does not use a contiguous range
of symbols for its main VLC tables and the old code compensated for that
by adding holes (codes of length zero) to the tables (that are skipped by
ff_init_vlc_sparse()). This is no longer necessary with the new
approach. All in all, this saves about 1.7KB.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is possible by switching to ff_init_vlc_from_lengths() which allows
to replace the table for the codes (which need an uint16_t) by a table
of symbols which fit into an uint8_t. Also switch to an ordinary
INIT_VLC macro while just at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Both the motion vector as well as the bias VLCs have an escape code;
for the motion vectors, this value depended on the specific VLC table,
whereas all the bias VLCs used the same value; the escape value has not
been inlined in the latter case.
But for both kinds of VLCs there are lots of values that are unused for
all the VLCs of each kind and each of these can be used as common escape
value, thus allowing to inline the escape value. This commit implements
this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
After the motion vector and bias values tables have been reordered so
that the codes are ordered from left to right, it emerged that the
length of these entries are actually ascending for every table.
Therefore it is possible to encode them in a run-length style and create
the actual length tables during runtime. This commit implements this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The ClearVideo decoder uses VLC tables that are initialized at runtime
from static length, symbol and codes tables. Yet the code tables can be
omitted by subjecting all of these tables to the permutation that orders
the codes from left to right in the tree. After this is done, the codes
can be easily computed at runtime from the lengths and therefore
omitted. This saves about 10KB.
Only one minor complication is encountered when doing so: The tree
corresponding to the AC VLC codes is incomplete; but this can be
handled by adding an entry with negative length.
Furthermore, there are also VLCs that are only initialized with lengths
and codes tables with codes of type uint16_t. These have also been
switched to ff_init_vlc_from_lengths() as this means that one can
replace the uint16_t codes tables with uint8_t symbols tables.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The IMC decoder uses Huffman tables which are created at runtime from
length tables of type uint8_t and code tables of type uint16_t together
with an implicit symbols table (i.e. symbol[i] == i). This commit
changes this: All three tables are subjected to the same permutation to
order the codes from left to right in the tree; afterwards the codes can
be omitted because they are easily computable at runtime from the
lengths, whereas the symbols need to be explicitly coded now. But said
symbols fit into an uint8_t, so one saves space.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Using one big table for the codebook symbols and lengths makes it
possible to remove the pointers to the individual tables.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The On2 audio decoder uses huge tables to initialize VLC tables. These
tables (mostly) use symbols tables in addition to the codes tables and
the lengths tables. This commit makes the codes tables redundant and
removes them: If all tables are permuted so that the codes are ordered
from left to right in the Huffman tree, the codes become redundant and
can be easily calculated at runtime from the lengths
(via ff_init_vlc_from_lengths()); this also avoids sorting the codes in
ff_init_vlc_sparse()*.
The symbols tables are always 16bit, the codes tables are 32bit, 16bit
or (rarely) 8bit, the lengths tables are always 8bit. Even though some
symbols tables have been used twice (which is no longer possible now
because different permutations need to be performed on the code tables
sharing the same symbol table in order to order them from left to right),
this nevertheless saves about 28KB.
*: If the initializations of the VLCs are repeated 2048 times
(interleaved with calls to free the VLCs which have not been timed), the
number of decicycles spent on each round of initializations improves
from 27669656 to 7356159.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The Smacker Huffman tables are already stored in a tree-like structure;
in particular, they are naturally ordered from left to right in the
tree and are therefore suitable to be initialized by
ff_init_vlc_from_lengths() which avoids traversing the data twice in
order to sort only the codes that are so long that they need into a
subtable.
This improves performance (and reduces codesize): For the sample from
ticket #2425 the number of decicycles for parsing and creating the VLCs
in smka_decode_frame() decreased from 412322 to 359152 (tested with
10 runs each looping 20 times over the file).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
One can offload the computation of the codes to
ff_init_vlc_from_lengths(); this also improves performance: The number
of decicycles for one call to read_code_table() decreased from 198343
to 148338 with the sample sample-cllc-rgb.avi from the FATE suite; it
has been looped 100 times and the test repeated ten times to test it
sufficiently often.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Right now the allocated size of the VLC table of a static VLC has to
exactly match the size actually used for the VLC: If it is not enough,
abort is called; if it is more than enough, an error message is
emitted. This is no problem when one wants to initialize an individual
VLC via one of the INIT_VLC macros as one just hardcodes the needed
size. Yet it is an obstacle when one wants to initialize several VLCs
in a loop as one then needs to add an array for the sizes/offsets of
the VLC tables (unless max_depth of all arrays is one in which case
the sizes are derivable from the number of bits used).
Yet said size array is not necessary if one disables the warning for too
big buffers. The reason is that the amount of entries needed for the
table is of course generated as a byproduct of initializing the VLC.
To this end a flag that disables the warning has been added.
So one can proceed as follows:
static VLC vlcs[NUM];
static VLC_TYPE vlc_table[BUF_SIZE][2];
for (int i = 0, offset = 0; i < NUM; i++) {
vlcs[i].table = &vlc_table[offset];
vlcs[i].table_allocated = BUF_SIZE - offset;
init_vlc(); /* With INIT_VLC_STATIC_OVERLONG flag */
offset += vlcs[i].table_size;
}
Of course, BUF_SIZE should be equal to the number of entries actually
needed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Using one big table for the symbols and lengths makes it
possible to remove the pointers to the individual tables.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
After permuting both the codes, lengths and symbols tables so that
the codes tables are ordered from left to right in the tree, the codes
tables can be easily computed from the lengths tables at runtime and
therefore omitted. This saves about 2KB from the binary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When using ff_init_vlc_sparse() to create a VLC, three input tables are
used: A table for lengths, one for codes and one for symbols; the latter
one can be omitted, then a default one will be used. These input tables
will be traversed twice, once to get the long codes (which will be put
into subtables) and once for the small codes. The long codes are then
sorted so that entries that should be in the same subtable are
contiguous.
This commit adds an alternative to ff_init_vlc_sparse():
ff_init_vlc_from_lengths(). It is based upon the observation that if
lengths, codes and symbols tables are permuted (in the same way) so that
the codes are ordered from left to right in the corresponding tree and
if said tree is complete (i.e. every non-leaf node has two children),
the codes can be easily computed from the lengths and are therefore
redundant. This means that if one initializes such a VLC with explicitly
coded lengths, codes and symbols, the codes can be avoided; and even if
one has no explicitly coded symbols, it might still be beneficial to
remove the codes even when one has to add a new symbol table, because
codes are typically longer than symbols so that the latter often fit
into a smaller type, saving space.
Furthermore, given that the codes here are by definition ordered from
left to right, it is unnecessary to sort them again; for the same
reason, one does not have to traverse the input twice. This function
proved to be faster than ff_init_vlc_sparse() whenever it has been
benchmarked.
This function is usable for static tables (they can simply be permuted
once) as well as in scenarios where the tables are naturally ordered
from left to right in the tree; the latter e.g. happens with Smacker,
Theora and several other formats.
In order to make it also usable for (static) tables with incomplete trees,
negative lengths are used to indicate that there is an open end of a
certain length.
Finally, ff_init_vlc_from_lengths() has one downside compared to
ff_init_vlc_sparse(): The latter uses tables that can be reused by
encoders. Of course, one could calculate the needed table at runtime
if one so wishes, but it is nevertheless an obstacle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
the init.mp4 can be expanded with strftime the same way as
hls_segment_filename.
Signed-off-by: Nikola Pajkovsky <nikola@pajkovsky.cz>
Signed-off-by: liuqi05 <liuqi05@kuaishou.com>
fix ticket: 8989
This is is due to the following behavior in the current code:
1. The initial_prog_date_time gets set to the current local time
2. The existing playlist (.m3u8) file gets parsed and the segments
present are added to the variant stream
3. The new segment is created and added
4. The existing segments and the new segment are written to the
playlist file. The initial_prog_date_time from point 1 is used
for calculating "#EXT-X-PROGRAM-DATE-TIME" for the segments,
which results in incorrect "#EXT-X-PROGRAM-DATE-TIME" values
for existing segments
The following approach fixes this bug:
1. Add a new variable "discont_program_date_time" of type double
to HLSSegment struct
2. Store the "EXT-X-PROGRAM-DATE-TIME" value from the existing
segments in this variable
3. When writing to playlist file if "discont_program_date_time"
is set, then use that value for "EXT-X-PROGRAM-DATE-TIME" else
use the value present in vs->initial_prog_date_time
Signed-off-by: Vignesh Ravichandran <vignesh.ravichandran02@gmail.com>
Signed-off-by: liuqi05 <liuqi05@kuaishou.com>
Create a local one instead from a byte buffer input argument.
This prevents skipping bytes that may belong to another SEI message.
Signed-off-by: James Almer <jamrial@gmail.com>
As this is a meta muxer and the same flag is set with the fifo
meta muxer, there is really no reason not to have this set here
as well.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
The nvidia hardware explicitly supports decoding monochrome content,
presumably for the AVIF alpha channel. Supporting this requires an
adjustment in av1dec and explicit monochrome detection in nvdec.
I'm not sure why the monochrome path in av1dec did what it did - it
seems non-functional - YUV440P doesn't seem a logical pix_fmt for
monochrome and conditioning on chroma sub-sampling doesn't make sense.
So I changed it.
I've tested 8bit content, but I haven't found a way to create a 10bit
sample, so that path is untested for now.
Fixes: signed integer overflow: -2105540608 - 2105540608 cannot be represented in type 'int'
Fixes: 26870/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5656647567147008
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
By using the frame counter (and the video time base) for audio pts we lose some
timestamp precision but we ensure that video and audio coming from the same DV
frame are always in sync.
This patch also makes timestamps after seek consistent and it should also fix
the timestamps when the audio clock is unlocked and have a completely
indpendent clock source. (E.g. runs on fixed 48009 Hz which should have been
exact 48000 Hz)
Fixes out of sync timestamps in ticket #8762.
Signed-off-by: Marton Balint <cus@passwd.hu>
./ffmpeg -list_devices true -f decklink -i dummy
[Blackmagic DeckLink indev @ 0x2f96d00] The "list_devices" option is deprecated: list available devices
[decklink @ 0x2f96400] The -list_devices option is deprecated and will be removed. Please use ffmpeg -sources decklink instead.
->
[Blackmagic DeckLink indev @ 0x306ed00] The "list_devices" option is deprecated: use ffmpeg -sources decklink instead
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
A reference to an AV1RawFrameHeader and consequently the
AV1RawFrameHeader itself and everything it has a reference to leak
if the hardware has no AV1 decoding capabilities or if some other error
happens. It happens e.g. in the cbs-av1-av1-1-b8-02-allintra FATE-test;
it has just been masked because the return value of ffmpeg (which
indicates failure when using Valgrind or ASAN) is ignored when doing
tests of type md5.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: 18 + 9223372036854775799 cannot be represented in type 'long'
Fixes: 26731/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5696846019952640
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The image center wasn't preserved, the output image was mirror reversed,
and rotations were made around wrong axes.
I did also remove the vector normalization, because it's sure that the vector
is already normalized if it's calculated from sin() and cos() terms.
This function existed to enable codecs with non-threadsafe init functions
to initialize other codecs despite the fact that normally no two codecs
with non-threadsafe init functions can be initialized at the same time
(there is a mutex guarding this). Yet there are no users of this
function any more as all users have been made thread-safe (switching
away from ff_codec_open2_recursive() was required for this as said
function requires the caller to hold the lock to the mutex guarding the
initializations and this is only true for codecs with the
FF_CODEC_CAP_INIT_THREADSAFE flag unset); so remove it.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The only thing that stands in the way of adding the
FF_CODEC_CAP_INIT_THREADSAFE flag to the TIFF decoder is its usage
of ff_codec_open2_recursive(): This function requires its caller to hold
the lock for the mutex that guards initialization of AVCodecContexts
whose codecs have a non-threadsafe init function and only callers whose
codec does not have the FF_CODEC_CAP_INIT_THREADSAFE flag set hold said
lock (the others don't need to care about said lock). But one can set
the flag if one switches to avcodec_open2() at the same time.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This will allow to make the TIFF decoder's init function thread-safe.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The only thing that stands in the way of adding the
FF_CODEC_CAP_INIT_THREADSAFE flag to the SMV JPEG decoder is its usage
of ff_codec_open2_recursive(): This function requires its caller to hold
the lock for the mutex that guards initialization of AVCodecContexts
whose codecs have a non-threadsafe init function and only callers whose
codec does not have the FF_CODEC_CAP_INIT_THREADSAFE flag set hold said
lock (the others don't need to care about said lock). But one can set
the flag if one switches to avcodec_open2() at the same time.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The only thing that stands in the way of adding the
FF_CODEC_CAP_INIT_THREADSAFE flag to the Cintel RAW decoder is its usage
of ff_codec_open2_recursive(): This function requires its caller to hold
the lock for the mutex that guards initialization of AVCodecContexts
whose codecs have a non-threadsafe init function and only callers whose
codec does not have the FF_CODEC_CAP_INIT_THREADSAFE flag set hold said
lock (the others don't need to care about said lock). But one can set
the flag if one switches to avcodec_open2() at the same time.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Normally no two codecs with FF_CODEC_CAP_INIT_THREADSAFE unset
can be initialized at the same time: a mutex in avcodec_open2()
ensures this. This implies that one cannot simply open a codec
with a non-threadsafe init-function from the init function of
a codec whose own init function is not threadsafe either as the child
codec couldn't acquire the lock.
ff_codec_open2_recursive() exists to get around this limitation:
If the init function of the child codec to be initialized is not
thread-safe, the mutex is unlocked, the child is initialized and
the mutex is locked again. This of course has as a prerequisite that
the parent AVCodecContext actually holds the lock, i.e. that the
parent codec's init function is not thread-safe. If it is, then one
can (and has to) just use avcodec_open2() directly (if the child's
init function is not thread-safe, then avcodec_open2() will have to
acquire the mutex itself (and potentially wait for it), so that it is
perfectly fine for an otherwise thread-safe init function to open
a codec with a potentially non-thread-safe init function via
avcodec_open2()).
Yet several of the users of ff_codec_open2_recursive() have the
FF_CODEC_CAP_INIT_THREADSAFE flag set; this only worked because
all the child codecs' init functions were thread-safe themselves
so that ff_codec_open2_recursive() didn't touch the mutex at all.
But of course the real solution to this is to directly use
avcodec_open2().
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This affected all decoders that used ff_mjpeg_decode_init() as init
function; and it also affected decoders that open jpeg decoders via
ff_codec_open2_recursive() as well as MxPEG.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ff_slice_thread_init() uses a static variable to hold a function
pointer, although the value of said pointer needn't be saved between
different runs of this function at all.
The reason for this being so is probably that said pointer points to
a static function (if used); but storage class specifiers like "static"
are not part of the type of an object and so including it in the pointer
declaration is wrong (anyway, "static" means different things in both
contexts: for the function declaration it affects linkage, for the
variable storage duration).
Using a static variable here can lead to races, e.g. when initializing
VP9 (for which said function pointer was added) and H.264 with slice
threading. The latter has the FF_CODEC_CAP_INIT_THREADSAFE flag set and
is therefore unaffected by the lock guarding initializations of
decoders.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Using MPEG-2 intra VLC tables is spec-incompliant for MPEG-1 and given
that an MPEG-1 bitstream can't signal whether MPEG-2 intra VLC tables
have been used the output is broken. Therefore this option is removed
immediately without any deprecation period.
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: Marton Balint <cus@passwd.hu>
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
They are not always coded in the bistream for each frame. In some cases, the
values need to be taken from a reference frame.
See section 6.8.20 from the AV1 spec.
Signed-off-by: James Almer <jamrial@gmail.com>
This reverts commit f9eec62983.
This does not effectively cover all cases. The values for some frames need
to be inferred by the decoder.
Signed-off-by: James Almer <jamrial@gmail.com>
The max depth is 16bps, the max allowed coefficient depth is depth+6
Fixes: signed integer overflow: 1074266112 + 1073725439 cannot be represented in type 'int'
Fixes: 26493/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5657763331702784
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
These fields are not signed in the spec (1.0) so they cannot be negative
Changing bytes_per_packet to unsigned would not solve this as it is exported
as block_align which is signed
Fixes: Infinite loop
Fixes: 26492/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-5632087614554112
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is a pathological case where the fuzzer provides only 2 bytes per iteration.
Fixes: Timeout (>30 -> 0.9sec)
Fixes: 26488/clusterfuzz-testcase-minimized-ffmpeg_dem_MPEGTS_fuzzer-5911031077142528
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Also changes some default values for options after this change.
This makes distinction between feedback and wet option.
Before they would produce same output if values were swapped.
Currently a repeating setup request (with the same stream id) will
simply overwrite rtp_handle/transport_priv without freeing the
resources first. This is fixed by closing the previous setup request.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
This avoids per codec checks for channels not being 0
Fixes: division by 0
Fixes: 25419/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FASTAUDIO_fuzzer-5632544761184256
Fixes: 25433/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FASTAUDIO_fuzzer-6215671900536832
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Suggested-by: Paul B Mahol <onemda@gmail.com>
See: [FFmpeg-devel] [PATCH 1/3] avcodec/fastaudio: Check channel
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
They add considerable complexity to frame-threading implementation,
which includes an unavoidably leaking error path, while the advantages
of this option to the users are highly dubious.
It should be always possible and desirable for the callers to make their
get_buffer2() implementation thread-safe, so deprecate this option.
Fixes: signed integer overflow: -4683718486770919638 * 2 cannot be represented in type 'long'
Fixes: 26704/clusterfuzz-testcase-minimized-ffmpeg_dem_MPC8_fuzzer-6327056939614208
Fixes: 27550/clusterfuzz-testcase-minimized-ffmpeg_dem_MPC8_fuzzer-6259212652642304
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The FLAC muxer currently stores an attached picture corresponding to an
AVStream in AVStream.priv_data. The AVPacket contained therein is
unreferenced after it has been written. The AVPacket structure itself is
then freed generically as AVStream.priv_data.
And this can lead to memleaks if an attached picture is not written:
It might be because the trailer is never written or because writing
a previous attached picture failed in case error_recognition is set
to explode.
Therefore free the packets properly (i.e. with av_packet_free())
in the muxer's deinit function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
These two extensions and two features are both optionally used by
libplacebo to speed up rendering, so it makes sense for libavutil to
automatically enable them as well.
Vulkan formats with a PACK suffix define native endianess.
Vulkan formats without a PACK suffix are in bytestream order.
Pixel formats with a LE/BE suffix define endianess.
Pixel formats without LE/BE suffix are in bytestream order.
This relies on the fact that host memory is always going to be required
to be aligned to the platform's page size, which means we can adjust
the pointers when we map them to buffers and therefore skip an entire
copy. This has already had extensive testing in libplacebo without
problems, so its safe to use here as well.
Speeds up downloads and uploads on platforms which do not pool their
memory hugely, but less so on platforms that do.
We can pool the buffers ourselves, but that can come as a later patch
if necessary.
Allows us to uninit cleanly.
This assert was also somewhat pointless as we assert every other
function, so another assert would be triggered long before this
one is.
This patch is relatively straightforward with one exception:
the decoder option flag.
The option was introduced to troubleshoot but its existence is conflicting
and redundant now that we have a codec-generic flag.
Hence this patch deprecates it.
The way it interacts with AV_CODEC_EXPORT_DATA_FILM_GRAIN is as follows:
If filmgrain is unset and AV_CODEC_EXPORT_DATA_FILM_GRAIN is
present, disable film grain application and export side data.
If filmgrain is set to 0, disable film grain and export side data.
If filmgrain is set to 1, apply film grain but export side data if
the AV_CODEC_EXPORT_DATA_FILM_GRAIN flag is set. This may result in
double film grain application, but the user has requested it by setting
both.
This patch introduces a new frame side data type AVFilmGrainParams for use
with video codecs which support it.
It can save a lot of memory used for duplicate processed reference frames and
reduce copies when applying film grain during presentation.
The MPEG-1/2 encoders initialize several tables once during the first
time one of the encoders is initialized; the table for MPEG-2 intra VLC
lengths is only initialized if it is used for this encoder instance.
This implies that if the first MPEG-1/2 encoder to be initialized does
not use it, it will never be initialized even if a later encoder
instance makes use of them. Fix this by initializing this table
unconditionally.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
I was having an issue where, using a filter chain of xfade -> ass, the
colors on the subtitles were incorrect only on the frames where xfade
was being used. This resolves that issue for me.
Signed-off-by: Musee Ullah <lae@lae.is>
This table is currently initialized up to three times: Once by the
encoder and twice by the decoders (once by the fixed and once by the
floating-point decoder); each of these initializations is guarded by an
AVOnce, yet the fact that there are three of them implies that there
might be data races (the fact that each entry is only written to once
(to its final value) when initializing means that this is safe in
practice, yet it is still undefined behaviour). Fix this by only
initializing the table from one place that is guarded by a single AVOnce.
This also avoids unnecessary duplications of the init code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The whole point of VLCs with their tables is to read more than one bit
at a time; therefore max_depth, the number of times one has to
(maximally) read further bits is given by ceil(max_code_length / table_bits)
which in the case of ATRAC9's coefficient VLCs gives an upper bound of
two. Instead the maximum length of a code of the given VLC has been used
(which is not even a compile-time constant). Use two instead.
Furthermore, given that this was the only usage of the field containing
the maximum of all the code lengths of a given VLC the field has been
removed from its containing struct.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The longest AC codes of the standard JPEG tables are 16 bits long; for
the DC tables, the maximum is 11, so using max_depth of two is
sufficient.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
These arrays are used by the Musepack decoders, the MPEG audio decoders
as well as qdm2 and up until now, these arrays might be initialized more
than once, leading to potential data races as well as unnecessary
initializations. Therefore this commit ensures that each array will only
be initialized once.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The only thing missing for this is to make ff_mpadsp_init_x86()
thread-safe; it currently isn't because a static table is initialized
every time ff_mpadsp_init() is called (when ARCH_X86 is true). Solve
this by initializing this table only once, namely together with the
ordinary not-arch specific tables. This also allows to reuse their AVOnce.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Commit 1af615683e put initializing
the ff_fft_offsets_lut (which is typically used if FFT_FIXED_32)
behind an ff_thread_once() to make ff_fft_init() thread-safe; yet
there is a second place where said table may be initialized which
is not guarded by this AVOnce: ff_fft_init_mips(). MIPS uses this LUT
even for ordinary floating point FFTs, so that ff_fft_init() is not
thread-safe (on MIPS) for both 32bit fixed-point as well as
floating-point FFTs; e.g. ff_mdct_init() inherits this flaw and
therefore initializing e.g. the AAC decoders is not thread-safe (on
MIPS) despite them having FF_CODEC_CAP_INIT_CLEANUP set.
This commit fixes this by moving the AVOnce to fft_init_table.c and
using it to guard all initializations of ff_fft_offsets_lut.
(It is not that bad in practice, because every entry of
ff_fft_offsets_lut is never read during initialization and is only once
ever written to (namely to its final value); but even these are
conflicting actions which are (by definition) data races and lead to
undefined behaviour.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This avoids code duplication in the functions used to initialize them
and allows to remove an AVOnce.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If allows us to directly store the deltas in the VLC table and therefore
avoids a level of indirection.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The algorithm used here always creates a complete VLC, so it is
unnecessary to check this again.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This ensures that the number of leafs in the Huffman tree equals the
number it is supposed to be and therefore ensures that the VLC tree is
complete, allowing us to remove checks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If the Huffman tree consists of only one entry (which has length zero),
no tree is used at all for parsing as the VLC API currently can't handle
this. So it makes no sense to create a VLC in this case.
Commit 41b7389cad added a check for
whether creating the VLC should be skipped, but it also skipped decoding
the packet and it used the wrong check: It checked max_codes_bits,
the maximum length of a code; but this value is only updated iff there is
more than one Huffman entry. So if there is only one Huffman entry, and
there was a previous frame with more than one entry, then a VLC was
created unnecessarily; yet if there was no previous frame with more than
one entry, then this frame will be skipped which is probably
spec-incompliant. I have no sample for the latter.
This commit improves the check to create a VLC iff it is going to be
used.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This lets us re-utilize the extradata-related checks in the CBS
to add support for passing the AV1CodecConfigurationRecord
as extradata as-is without further filtering.
For the document(indevs.texi and outdevs.texi) used it as boolean.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Fixes: signed integer overflow: 1633771809 * 32960 cannot be represented in type 'int'
Fixes: 26532/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-5613925708857344
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 access
Fixes: 26532/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-5613925708857344
Fixes: 27443/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-5631239813595136
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: 9223372036854775807 - -1 cannot be represented in type 'long'
Fixes: 26549/clusterfuzz-testcase-minimized-ffmpeg_dem_AVS_fuzzer-4844306424397824
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The 'alac' identifier has been registered to ISO and thus towards
ISOBMFF at the MP4 registration authority. The existing non-MOV
mux mode matches the official ALAC-in-MP4 specification.
Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
Fixes: 27369/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOBICLIP_fuzzer-5083469356728320
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: 2110302399 + 39074947 cannot be represented in type 'int'
Fixes: 27330/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MV30_fuzzer-5664923153334272
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In sdp_read_header() some ff_network_close() calls were missed.
Also in rtp_read_header() update comment to explain why a single
call to ff_network_close() is enough to cover all cases even if
sdp_read_header() returns an error.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
In this error path ret still stores the number of bytes read in
ffurl_read().
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
As per the docs network initialization is required before ff_url_join().
Furthermore, because the ff_network_init() was skipped, this makes
one additional call to ff_network_close() if the stream exits without
errors.
The was forgotten in the origin commit of the listen mode:
a8ad6ffafe
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
The patch will change the numerical values for the string constants so bump
micro version.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
The Block timestamp read in matroska_parse_block() is in track timebase and is
passed on as such to the AVPacket which uses this timebase.
In the normal case the Cluster and Track timebases are the same because the
track->time_scale is 1.0. But when it is not the case, the values in Cluster
timebase need to be transformed in Track timebase so they can be added
together.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
When the check was added (in 3668701f96, in 2015), some IO
functions returned 0 on EOF (in particular, the TCP protocol
did, but the TLS protocol returned AVERROR_EOF). Since
0e1f771d22 in 2017, the TCP protocol also returns AVERROR_EOF
instead of 0, making the check for premature end never have the
intended effect.
Signed-off-by: Martin Storsjö <martin@martin.st>
mpegts_read_header stops parsing the file at the first PMT. However the check
that ensured this was wrong because streams can also be added before the first
PMT is received (e.g. EIT).
So let's make sure we are in the header reading phase by checking if ts->pkt is
unset instead of checking if the number of streams found so far is 0.
Signed-off-by: Marton Balint <cus@passwd.hu>
A variable has been assigned a value twice consecutively; essentially
the same happens when one performs av_init_packet on an AVPacket after
a call to av_packet_unref.
Found via PVS-Studio (see ticket #8156).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The ASF specification of Metadata Objects' stream number is as follows:
"Specifies whether the entry applies to a specific digital media stream
or whether it applies to the whole file. A value of 0 in this field
indicates that it applies to the whole file; otherwise, the entry
applies only to the indicated stream number and must be between 1 and
127."
Yet the asf_o demuxer (the one originating from Libav) has always
treated such metadata as if it applied to a stream even though no stream
with a stream number may exist in a valid ASF file. This is fixed in
this commit; it affected e.g. the file
wma_with_metadata_library_object_tag_trimmed.wma from the FATE suite.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The ASF file format has a limit of 127 streams and the "asf_o" demuxer
(the ASF demuxer from Libav) has an array of pointers for a structure
called ASFStream that is allocated on demand for every stream. Attached
pictures are not streams in the sense of the ASF specification, yet the
demuxer created an ASFStream for them; and in one codepath it also
forgot to check whether the array of ASFStreams is already full. The
result is a write beyond the end of the array and a segfault lateron.
Fixing this is easy: Don't create ASFStreams for attached picture
streams.
(Other results of the current state of affairs are unnecessary allocations
(of ASFStreams structures), the misparsing of valid files (there might not
be enough ASFStreams left for the valid streams if attached pictures take
up too many); furthermore, the ASFStreams created for attached pictures all
have the stream number 0, an invalid stream number (the valid range is
1-127). This means that invalid data (packets for a stream with stream
number 0) won't get rejected lateron.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The other branch already covers cases where enable_order_hint is true
and frame is of type Inter.
Regression since ddb0e4fecd
Fixes Coverity issues #1469194 and #1469195.
Signed-off-by: James Almer <jamrial@gmail.com>
The spec in section 6.8.20 states the parameters should be loaded from a
reference frame indexed by film_grain_params_ref_idx.
Signed-off-by: James Almer <jamrial@gmail.com>
The previous threshold, 4 KB, maybe was reasonable when it was set
(in 2010), but in today's settings and with typical network speeds
and data sizes, it's pretty small. 32 KB probably is a more reasonable
default now, regardless of input.
This changes the test references for two seek tests.
When using the normal seek function, which boils down to the lseek(2)
function, a seek to an out of bounds position doesn't return an error,
but that condition is only reported when doing the subsequent read
(which returns EOF). When doing more seeks by fast forwarding, the
fact that the seeked to destination is out of bounds is noticed and
reported sooner in these cases.
Signed-off-by: Martin Storsjö <martin@martin.st>
Fixes: signed integer overflow: -9223372036854775808 + -5279949906739200 cannot be represented in type 'long'
Fixes: 26908/clusterfuzz-testcase-minimized-ffmpeg_dem_SBG_fuzzer-6329610851319808
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Section 6.10.1 of the AV1 spec states:
It is a requirement of bitstream conformance that the value of tg_start is
equal to the value of TileNum at the point that tile_group_obu is invoked.
It is a requirement of bitstream conformance that the value of tg_end is
greater than or equal to tg_start.
Signed-off-by: James Almer <jamrial@gmail.com>
move comments for the size of SDP_MAX_SIZE here:
Some SDP lines, particularly for Realmedia or ASF RTSP streams,
contain long SDP lines containing complete ASF Headers (several
kB) or arrays of MDPR (RM stream descriptor) headers plus
"rulebooks" describing their properties. Therefore, the SDP line
buffer is large.
The Vorbis FMTP line can be up to 16KB - see xiph_parse_sdp_line
in rtpdec_xiph.c.
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
At the end of its decode function, the decoder sets *got_frame to 1 and
then checks whether ret is < 0; if so, it is returned, otherwise
avpkt->size is. But it is impossible for ret to be < 0 here and if it
were, it would be nonsense to set *got_frame to 1 before this. Therefore
just return avpkt->size unconditionally.
Fixes Coverity issue #1439730.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This ensures no queued timestamps or side data are kept and used after
seeking, preventing potential desyncs.
Signed-off-by: James Almer <jamrial@gmail.com>
AMV is a hard-coded (and broken) subset of AVI. It's not worth sullying
the existing AVI muxer with its filth.
Fixes ticket #747.
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Without this metadata section the ffmpeg utility thinks that the AMF encoder
does not support input from D3D11 and DXVA2 hardware surfaces, causing
hardware pipelines to fail.
Fixes#8953.
Fixes: signed integer overflow: 9223372036854775807 + 564 cannot be represented in type 'long'
Fixes: 26494/clusterfuzz-testcase-minimized-ffmpeg_dem_VOC_fuzzer-576754158849228
Fixes: 26549/clusterfuzz-testcase-minimized-ffmpeg_dem_AVS_fuzzer-4844306424397824
FIxes: 26875/clusterfuzz-testcase-minimized-ffmpeg_dem_C93_fuzzer-5996226782429184
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Is incorrect behaviour. Was covering for an encoder bug where it produced frames
of the wrong size.
This reverts commit e9dd73d30d.
Fixes: out of array write
Fixes: 26821/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ADPCM_SWF_fuzzer-5764465137811456
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
This patch adds a select_region option to the xcbgrab input device.
If set to 1, the user will be prompted to select the grabbing area
graphically by clicking and dragging. A rectangle will be drawn to
mark the grabbing area. A single click with no dragging will select
the whole screen. The option overwrites the video_size, grab_x, and
grab_y options if set by the user.
For testing, just set the select_region option as follows:
ffmpeg -f x11grab -select_region 1 -i :0.0 output.mp4
The drawing happens directly on the root window using standard rubber
banding techniques, so it is very efficient and doesn't depend on any
X extensions or compositors.
Reviewed-by: Andriy Gelman <andriy.gelman@gmail.com>
Signed-off-by: Omar Emara <mail@OmarEmara.dev>
During init the mts2 decoder allocates several VLCs and then several
buffers in a loop; if one of the latter allocations fails, only the VLCs
are freed, not any buffers that might already have been successfully
allocated. This commit fixes this by setting the
FF_CODEC_CAP_INIT_CLEANUP flag.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The AAXC container format is the same as the (already supported) Audible
AAX format but it uses a different encryption scheme.
Note: audible_key and audible_iv values are variable (per file) and are
externally fed.
It is possible to extend https://github.com/mkb79/Audible to derive the
audible_key and audible_key values.
Relevant code:
def decrypt_voucher(deviceSerialNumber, customerId, deviceType, asin, voucher):
buf = (deviceType + deviceSerialNumber + customerId + asin).encode("ascii")
digest = hashlib.sha256(buf).digest()
key = digest[0:16]
iv = digest[16:]
# decrypt "voucher" using AES in CBC mode with no padding
cipher = AES.new(key, AES.MODE_CBC, iv)
plaintext = cipher.decrypt(voucher).rstrip(b"\x00") # improve this!
return json.loads(plaintext)
The decrypted "voucher" has the required audible_key and audible_iv
values.
Update (Nov-2020): This patch has now been tested by multiple folks -
details at the following URL:
https://github.com/mkb79/Audible/issues/3
Signed-off-by: Vesselin Bontchev <vesselin.bontchev@yandex.com>
Causes a divide-by-zero in the rare case where:
- the file has an audio stream,
- the first audio frame isn't within the first BRP_BASF_LOOKAHEAD frames,
- an audio frame is encountered later, and
- its chunk header (except num_blocks) contains all zeros
(matching the uninitialised structure in the context)
The decoder will discard any garbage data, so the check isn't really needed.
Fixes: division by 0
Fixes: 26667/clusterfuzz-testcase-minimized-ffmpeg_dem_ARGO_BRP_fuzzer-5645146928185344.fuzz
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Follow the same pattern as the previous commits for H.264 and H.265.
Reviewed-By: Jan Ekström <jeebjp@gmail.com>
Tested-By: Xu, Yefeng <yefengx.xu@intel.com>
The properties should always be set; only the presence flags want to be
conditional.
Fixes#8959.
Reviewed-By: Jan Ekström <jeebjp@gmail.com>
Tested-By: Xu, Yefeng <yefengx.xu@intel.com>
Reading the header terminates when an fcTL chunk is encountered in which
case read_header returned success without checking the length of said
chunk. Yet when read_packet processes this chunk, it checks for the
length to be 26 and errors out otherwise. So do so when reading the header,
too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
apng data consists of parts containing a small header (including a
four-byte size field) and a data part; the size field does not account
for everything and is actually twelve bytes short of the actual size. In
order to make sure that the size fits into an int, the size field is
checked for being > INT_MAX; yet this does not account for the + 12 and
upon conversion to int (which happens when calling append_extradata()),
the size parameter can still wrap around. In this case the currently
used check would lead to undefined signed integer overflow.
Furthermore, append_extradata() appends the new data to the already
existing extradata and therefore needs to make sure that the combined
size of new and old data as well as padding fits into an int. The check
used for this is "if (old_size > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE -
new_size)". If new_size is > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE
the right side becomes negative if the types are signed (as they are
now); yet changing this to "if (new_size > INT_MAX -
AV_INPUT_BUFFER_PADDING_SIZE - old_size)" is better as this also works
for unsigned types (where it is of course presumed that INT_MAX is
replaced by the corresponding maximum for the new type).
Both of these issues have been fixed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If avio_read() could read anything, it returns the number of bytes read,
even if it could not read as much as the caller desired.
apng_read_header() only checked the return value of its avio_read() calls
for being negative and this meant that it was possible for an incomplete
header to not be detected. The return value of the last successfull call
has been returned instead. This commit changes this.
Fixes: OOM
Fixes: 26608/clusterfuzz-testcase-minimized-ffmpeg_dem_APNG_fuzzer-4839491644424192
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
While the FATE suite contains a sample file for Musepack 8, it did not
use it to test the decoder; it is only used in the mpc8-demux test that
tests the demuxer via streamcopy. Therefore this commit adds an actual
encoder test.
The test uses the framecrc output, because Musepack SV8 is an encoder
that returns multiple frames for a single packet, so that timing
information in the test output is valueable. Output seeking has been
used in order to limit the size of the ref file as well as to test this
codepath for the first time.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is the simplest fix for the problem, it is possible to instead check
this when the variables are set and propagate errors and then fail earlier
Fixes: out of array access
Fixes: 26490/clusterfuzz-testcase-minimized-ffmpeg_dem_VIVIDAS_fuzzer-5723367078100992
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: shift exponent 95 is too large for 32-bit type 'int'
Fixes: 26590/clusterfuzz-testcase-minimized-ffmpeg_dem_SMACKER_fuzzer-5120609937522688
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
We now have the possibility of getting AVFrames here, and we should
not touch the muxer's codecpar after writing the header.
Results of FATE tests change as the MXF and Matroska muxers actually
write down the field/frame coding type of a stream in their
respective headers. Before this change, these values in codecpar
would only be set after the muxer was initialized. Now, the
information is also available for encoder and muxer initialization.
Additionally, reap the first rewards by being able to set the
color related encoding values based on the passed AVFrame.
The only tests that seem to have changed their results with this
change seem to be the MXF tests. There, the muxer writes the
limited/full range flag to the output container if the encoder
is not set to "unspecified".
- For video, this means a single initialization point in do_video_out.
- For audio we unfortunately need to do it in two places just
before the buffer sink is utilized (if av_buffersink_get_samples
would still work according to its specification after a call to
avfilter_graph_request_oldest was made, we could at least remove
the one in transcode_step).
Other adjustments to make things work:
- As the AVFrame PTS adjustment to encoder time base needs the encoder
to be initialized, so it is now moved to do_{video,audio}_out,
right after the encoder has been initialized. Due to this,
the additional parameter in do_video_out is removed as it is no
longer necessary.
This way the old max queue size limit based behavior for streams
where each individual packet is large is kept, while for smaller
streams more packets can be buffered (current default is at 50
megabytes per stream).
For some explanation, by default ffmpeg copies packets from before
the appointed seek point/start time and puts them into the local
muxing queue. Before, it getting utilized was much less likely
since as soon as the filter chain was initialized, the encoder
(and thus output stream) was also initialized.
Now, since we will be pushing the encoder initialization to when the
first AVFrame is decoded and filtered - which only happens after
the exact seek point is hit as packets are ignored until then -
this queue will be seeing much more usage.
In more layman's terms, this attempts to fix cases such as where:
- seek point ends up being 5 seconds before requested time.
- audio is set to copy, and thus immediately begins filling the
muxing queue.
- video is being encoded, and thus all received packets are skipped
until the requested time is hit.
The Canopus Lossless decoder uses several VLCs and if initializing the
ith VLC fails, all the VLCs 0..i have been freed; the ith VLC's table is
initialized to NULL for this purpose. Yet it is totally unnecessary to
free the ith VLC table at all: ff_init_vlc_sparse() cleans up after
itself on error and if an error happens before ff_init_vlc_sparse(),
the ith VLC hasn't been touched yet and doesn't need freeing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This disallows the usage of ? and # in libavformat specific scheme options
(e.g. subfile,,start,32815239,end,0,,:video.ts) but this change was considered
acceptable.
Signed-off-by: ruiquan.crq <caihaoning83@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
It's only used in the codec2 demuxers, and can be simplified with an AV_RB16()
call instead.
Suggested-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Partially implements setup_past_independence() and load_previous().
These ensures they are always set, even if the values were not coded
in the input bitstream and will not be coded in the output bitstream.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>
Partially implements setup_past_independence() and load_previous().
These ensures they are always set, even if the values were not coded
in the input bitstream and will not be coded in the output bitstream.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>
Those are private fields, no reason to have them exposed in a public
header. Since there are some (semi-)public fields located after these,
even though this section is supposed to be private, keep some dummy
padding there until the next major bump to preserve ABI compatibility.
This struct is for internal use of avformat_find_stream_info(), so it
should not be exposed in public headers. Keep a stub pointer in its
place to avoid changing AVStream layout, since e.g. ffmpeg.c accesses
some fields located after it (even though they are marked as private).
This function is so extremely simple that it is preferable to make it
inline rather than deal with all the complications arising from it being
an exported symbol.
Keep avpriv_align_put_bits() around until the next major bump to
preserve ABI compatibility.
Allocating one temporary entry more than needed was made necessary by
the COPY loop below writing an element before having checked that it
should be written at all. But given that this behaviour changed, the
need for overallocating is gone.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
fix ticket: 8932
For poc 2, we have tile boundary at x = 640.
When we predict cu(640,912),the top left pixel is not avaliable to the cu.
So, we can not check it's intra or not. We need set top[-1] = top[0] directly.
see 8.4.4.2.1 for details
Signed-off-by: Xu Guangxin <oddstone@gmail.com>
Signed-off-by: Linjie Fu <linjie.justin.fu@gmail.com>
Neither the auxiliary VLC table nor the code_lengths array need to be
freed if creating the auxiliary VLC table fails.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
They are always in the range 0..15, so using an int is not necessary.
Furthermore, using an int would not work if sizeof(int) != 4 as
ff_init_vlc_sparse() can only handle uint8_t, uint16_t and uint32_t
lengths.
Reviewed-by: zhilizhao(赵志立) <quinkblack@foxmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
now first_pts assume dts will start from zero, if it's not true(copyts is enable),
too many null packet will be inserted for cbr output.
Please test with below command, you'll get huge test.ts without the patch:
./ffmpeg -y -copyts -i ../fate-suite/mpegts/loewe.ts -c:v libx264 -x264opts \
nal-hrd=cbr:force-cfr=1 -b:v 3500k -minrate 3500k -maxrate 3500k -bufsize \
1000k -c:a mp2 -muxrate 4500k -vframes 1000 test.ts
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
If a static VLC table gets initialized a second time (or concurrently by
two threads) and if said VLC table uses symbols that have the sign bit
of VLC_TYPE (a typedef for int16_t) set, initializing the VLC fails. The
reason is that the type of the symbol in the temporary array is an
uint16_t and so comparing it to the symbol read from the VLC table will
fail, because only the lower 16bits coincide. Said failure triggers an
assert.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The longest code of any of the VLC tables used is eight bits long, so
using nine bits long VLC tables is wasteful. Furthermore, there are only
seven VLC tables used, yet the code up until now made it look like there
should be eight. This has been corrected, too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Even though the length of these codes is > 8, only the lowest seven bits
are ever set (because the long codes are on the left of the tree), so
one can use an uint8_t for them, saving space.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The longest motion vector VLC for mobiclip is six bits long, so using
eight bits for the VLC table is wasteful. Furthermore, the length can be
inlined.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
For both RealVideo 3.0 as well as RealVideo 4.0 the VLC table to use
depends upon the slice's quantization parameter; these are coded on five
bits in the bitstream and are therefore in the range of 0..31; yet the
last element here is not valid and therefore the quantizer is clipped to
the range 0..30 to get the index. But this is unnecessary: One can just
add one element more to the relevant array to avoid the clipping.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Most of the VLCs used by RealVideo 3 and 4 obey three simple rules:
Shorter codes are on the left of the tree, for each length, the symbols
are ascending from left to right and the symbols either form a
permutation of 1..size or 0..(size - 1). For the latter case, one just
needs to store the length of each symbol and create the codes according
to the other rules; no explicit code or symbol array must be stored.
The former case is also treated in much the same way by artificially
assigning a length of zero to the symbol 0; when a length of zero was
encountered, the element was ignored except that the symbol counter was
still incremented. If the length was nonzero, the symbol would be
assigned via the symbol counter and the length copied over into a new
array.
Yet this is unnecessary, as ff_init_vlc_sparse() follows exactly the
same pattern: If a length of zero is encountered, the element is ignored
and only the symbol counter incremented. So one can directly forward the
length array and also need not create a symbol table oneself, because
ff_init_vlc_sparse() will infer the same symbol table in this case.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Theora allows to use custom Huffman tables which are coded in the
bitstream as a tree: Whether the next node is a leaf or not is coded
in a bit; each node itself contains a five bit token. Each tree can
contain at most 32 leafs; typically they contain exactly 32 with the 32
symbols forming a permutation of 0..31. Yet the standard does not impose
either of these requirements. It explicitly allows less than 32 leafs
and multiple codes with the same token.
But our decoder used an algorithm that required the codes->token mapping
to be injective and that also presumed that there be at least two leafs:
Instead of using an array for codes, tokens and code lengths, the
decoder only had arrays for codes and code lengths. The code and length
for a given token were stored in entry[token]. As no symbols table was
used when initializing the VLC, the default one applied and therefore
the entry[token] got the symbol token (if the length of said entry is >0).
Yet if multiple codes had the same token, the codes and lengths from the
later token would overwrite the earlier codes and lengths.
Furthermore, less than 32 leafs could also lead to problems: Namely if
this was not the first time Huffman tables have been parsed in which
case the array is not zeroed initially so that old entries could make
the new table invalid.
libtheora seems to always use 32 leafs and no duplicate tokens; I am not
aware of any existing valid files that do not.
This is fixed by using a codes, symbols and lengths array when
initializing the VLC. In order to reduce the amount of stuff kept in the
context only the symbols and lengths (which both fit into an uint8_t)
are kept in the context; the codes are derived from the lengths
immediately before creating the tables.
There is now only one thing left which is not spec-compliant: Trees with
only one node (which has length zero) are not supported by
ff_init_vlc_sparse() yet.
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
the warning message:
warning: using floating point absolute value function
'fabs' when argument is of integer type
use FFABS to set the absolute value.
Signed-off-by: liuqi05 <liuqi05@kuaishou.com>
Fixes: signed integer overflow: 7111111111111531010 - -7335632962598013506 cannot be represented in type 'long'
Fixes: 26463/clusterfuzz-testcase-minimized-ffmpeg_dem_LRC_fuzzer-6015558333759488
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: 9223372036854770375 + 5450 cannot be represented in type 'long'
Fixes: 26471/clusterfuzz-testcase-minimized-ffmpeg_dem_MXG_fuzzer-6229617557635072
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
With a IO block size of 1 byte potentially megabytes are quite slow to read, thus
limit the number
Fixes: 26511/clusterfuzz-testcase-minimized-ffmpeg_dem_NUV_fuzzer-5679249073373184
Fixes: 26517/clusterfuzz-testcase-minimized-ffmpeg_dem_XMV_fuzzer-6316634501021696
Fixes: 26518/clusterfuzz-testcase-minimized-ffmpeg_dem_WSVQA_fuzzer-485568285324083
Fixes: 26525/clusterfuzz-testcase-minimized-ffmpeg_dem_MSNWC_TCP_fuzzer-5121987011411968
Fixes: 26538/clusterfuzz-testcase-minimized-ffmpeg_dem_DHAV_fuzzer-5441800598454272
Fixes: OOM
Fixes: Timeout
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
No benchmark because this is not used in any speed relevant pathes nor is it
used where __builtin_add_overflow is available.
So I do not know how to realistically benchmark it.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Now the listen timeout is hardcoded(10s).
How to test(30s timeout):
./ffprobe -listen_timeout 30 -protocol_whitelist rtp,udp,file -i test.sdp
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
then we can set the rtp read timeout instead of infinite timeout.
How to test(5s timeout):
./ffprobe -i rtp://192.168.1.67:1234?timeout=5000000
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
During operation, the user exits and interrupts,
causing pls->segment to be released,
resulting in a null pointer crash
Signed-off-by: bevis <javashu2012@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
The longest codes of any VLC codebooks are 18 bits long and the VLC
tables itself use 9 bits; therefore it is sufficient to read twice from
the table, yet this has been done thrice.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, quad VLCs are initialized with codes of type uint32_t,
pair VLCs with codes of type uint16_t. There were two separate loops in
the decoder's init function for each type of VLC. This commit unifies
this: The type of the codes are now passed in as void * and the actual
size of the codes is obtained from a table. This approach also allows to
use the smallest type for each VLC code table: some quad tables actually
fitted in uint16_t. This allows to remove about 7KB from the binary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, there was no cleanup in case initializing the Theora VLC
tables failed, leading to memleaks. This commit gets rid of them by
setting the FF_CODEC_CAP_INIT_CLEANUP flag for all decoders in vp3.c;
this also allows to remove some (now redundant) cleanup code.
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Prefer to error than to create a broken file. Closes ticket #5829.
Effectively disables remuxing adpcm_swf from flv -> wav.
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
6f69f7a8bf introduced this and it was part
of a very large merging of refactoring. Current behaviour is what is
reflected by this indenting change, however my understanding of timing
is such that this correct behaviour.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: division by zero
Fixes: 26293/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ADPCM_PSX_fuzzer-5176665237618688
Fixes: 26331/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ADPCM_PSX_fuzzer-5632330364092416
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: 536870912 + 1610612736 cannot be represented in type 'int'
Fixes: 26288/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOBICLIP_fuzzer-6194364759670784
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: 553590816 - -2145378049 cannot be represented in type 'int'
Fixes: 26315/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-5938755121446912
Fixes: 26340/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-5644316208529408
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: 241173056 + 1953511200 cannot be represented in type 'int'
Fixes: 26086/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5068366420901888
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Commit a2b1dd0ce3 added support for
parsing annex B HEVC extradata to extract profile and level information.
Yet it only checks for there to be enough data left for the startcode
and the first byte of the NAL unit header and not for the full NAL unit
header; it simply presumes the second byte of the NAL unit header to be
present and skips it. Then the remaining size of the extradata is calculated
which ends up negative if the second byte of the NAL unit header is not
present. Yet when calling ff_nal_unit_extract_rbsp() it
will be converted to an uint32_t and end up as UINT32_MAX which
will cause mayhem.
This is solved by making sure that there is always enough remaining
extradata that could (pending 0x03 escapes) contain the data that we
are interested in.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: 3458015007900000256 + 6425686373040000000 cannot be represented in type 'long'
Fixes: 26430/clusterfuzz-testcase-minimized-ffmpeg_dem_BRSTM_fuzzer-5761175004119040
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
fix ticket: 8636
When write keyframe and the keyframe is the frist packet of the segment,
then compute the size of the keyframe which have been write into segment
first packet. and set the start position of the segment, should not use
avio_tell(vs->out) to get the keyframe position, because it can be set
to 0 if close at above of the workflow, that maybe inaccurate, but the
start_pos can be used here, because start_pos is set after write
the previous packet.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: liuqi05 <liuqi05@kuaishou.com>
if the length of the root url is 0, unnecessary process the root_url
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: liuqi05 <liuqi05@kuaishou.com>
The target duration will be a negative value when there are
some b frames after prevous frame, the pts after current packet
is large than the pts of current packet, so the target duration
will compute as 0.040000 - 0.080000, then the value of the target
duration will be -0.040000. so hls muxer should check the pts after
current packet minus the pts of current packet, hls muxer can split
the stream as a segment if the target duration is neither negative nor
zero, hls muxer cannot split the stream as a segment if the
target duration is either negative or zero then get the next packet
until the target duration is not negative or zero.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Suggested-by: Zhili Zhao <quinkblack@foxmail.com>
Signed-off-by: liuqi05 <liuqi05@kuaishou.com>
It makes no sense to call the functions to write styl, hlit or hclr boxes
with a different box name than "styl", "hlit" or "hclr". Therefore this
commit inlines these values in the functions, removes the function
parameter containing the box's name and removes the (non obsolete) box
names from the list of boxes.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The mov_text encoder uses an AVBPrint to assemble the subtitles;
yet mov_text subtitles are not pure text; they also have a binary
portion that was mostly handled as follows:
uint32_t size = /* calculation */;
size = AV_RB32(&size);
av_bprint_append_data(bprint, (const char*)&size, 4);
Here AV_RB32() is a no-op on big-endian systems and a LE-BE swap
on little-endian systems, making the output endian-independent.
Yet this is ugly and unclean: On LE systems, the variable size from
the snippet above won't contain the correct value any more. Furthermore,
using this pattern leads to lots of small writes to the AVBPrint.
This commit therefore changes this to using a temporary buffer instead:
uint8_t buf[4];
AV_WB32(buf, /* size calculation */);
av_bprint_append_data(bprint, buf, 4);
This method also allows to use bigger buffers holding more than one
element, saving calls to av_bprint_append_data() and reducing codesize.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the mov_text encoder used the dynamic array API for its
list of style attributes; it used the (horrible) av_dynarray_add() which
works with an array of pointers; on error it frees its array but not
the buffers referenced by the pointers said array contains. It also
returns no error code, encouraging not to check for errors.
These properties imply that this function may only be used if the buffers
referenced by the list either need not be freed at all or if they are
freed by other means (i.e. if the list contains non-ownership pointers).
In this case, the style attributes are owned by the pointers of the
dynamic list. Ergo the old style attributes leak on a subsequent
reallocation failure. But given that the (re)allocation isn't checked
for success, the style attribute intended to be added to the list also
leaks because the only pointer to it gets overwritten in the belief that
it is now owned by the list.
This commit fixes this by switching to av_fast_realloc() and an array
containing the styles directly instead of pointers to individually
allocated style attributes. The current style attributes are now no longer
individually allocated, instead they are part of the context.
Furthermore, av_fast_realloc() allows to easily distinguish between
valid and allocated elements, thereby allowing to reuse the array
(which up until now has always been freed after processing an
AVSubtitleRect).
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes segfaults in the absence of fonts; this can happen because the
file didn't contain any or because the allocation of the font-string
failed.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Otherwise the mov_text encoder can segfault when given subtitles with more
than one AVSubtitleRect if one of the first nb_rects - 1 rects contained
a style attribute.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Background colour was never initialized if no style was available.
Use a sane default of zero (i.e. completely transparent).
Fixes Coverity issue #1461471.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
TensorFlow C library accepts config for session options to
set different parameters for the inference. This patch exports
this interface.
The config is a serialized tensorflow.ConfigProto proto, so we need
two steps to use it:
1. generate the serialized proto with python (see script example below)
the output looks like: 0xab...cd
where 0xcd is the least significant byte and 0xab is the most significant byte.
2. pass the python script output into ffmpeg with
dnn_processing=options=sess_config=0xab...cd
The following script is an example to specify one GPU. If the system contains
3 GPU cards, the visible_device_list could be '0', '1', '2', '0,1' etc.
'0' does not mean physical GPU card 0, we need to try and see.
And we can also add more opitions here to generate more serialized proto.
script example to generate serialized proto which specifies one GPU:
import tensorflow as tf
gpu_options = tf.GPUOptions(visible_device_list='0')
config = tf.ConfigProto(gpu_options=gpu_options)
s = config.SerializeToString()
b = ''.join("%02x" % int(ord(b)) for b in s[::-1])
print('0x%s' % b)
style_active doesn't do anything any more: It is already assured
that style_active is one when one reaches the end of a style.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The checks for whether a style should be opened/closed at the current
character position are as follows: A variable entry contained the index
of the currently active or potentially next active style. If the current
character position coincided with the start of style[entry], the style
was activated; this was followed by a check whether the current
character position coincided with the end of style[entry]; if so, the
style was deactivated and entry incremented. Afterwards the char was
processed.
The order of the checks leads to problems in case the endChar of style A
coincides with the startChar of the next style (say B): Style B was never
opened. When we are at said common position, the currently active style
is A and so the start pos check does not succeed; but the end pos check
does and it closes the currently active style A and increments entry.
At the next iteration of the loop, the current character position is
bigger than the start position of style B (which is style[entry]) and
therefore the style is not activated.
The solution is of course to first check for whether a style needs to be
closed (and increment entry if it does) before checking whether the next
style needs to be opened.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
They would either lead to unnecessary ASS tags being emitted (namely
tags that are reset immediately thereafter) or would lead to problems
when parsing: e.g. if a zero-length style immediately follows another
style, the current code will end the preceding style and set the
zero-length style as the next potentially active style, but it is only
tested for activation when the next character is parsed at which point
the current offset is already greater than both the starting as well
as the end offset of the empty style. It will therefore neither be
opened nor closed and all subsequent styles will be ignored.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the 3GPP Timed Text decoder used av_dynarray_add()
for a list of style entries. Said entries are individually allocated
and owned by the pointers in the dynamic array and are therefore
unsuitable for av_dynarray_add() which simply frees the array,
but not the entries on error. In this case the intended new entry
also leaks because it has been forgotten to free it.
This commit fixes this. It is now allocated in one go and not
reallocated multiple times (and it won't be overallocated any more).
After all, the final number of elements (pending errors) is already
known in advance.
Furthermore, the style entries are now the entries of the new array,
i.e. they are no longer allocated separately. This also removes one
level of indirection.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Every font entry occupies at least three bytes, so checking early
whether there is that much data available is a low-effort way to exclude
invalid extradata. Doing so leads to an overall simplification.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the 3GPP Timed Text decoder used av_dynarray_add()
for a list of font entries, a structure which contains an allocated
string. The font entries are owned by the pointers in the dynamic array
and are therefore unsuitable for av_dynarray_add() which simply frees
the array, but not the font entries and of course not the strings. The
latter all leak if reallocating the dynamic array fails.
This commit fixes this. It stops reallocating the array altogether:
After all, the final number of elements (pending errors) is already
known in advance.
Furthermore, the font entries are now the entries of the new array,
i.e. the font entries are no longer allocated separately. This also
removes one level of indirection.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If allocating fonts fails when reading the header, all fonts are freed,
yet the counter of fonts is not reset and no error is returned; when
subtitles are decoded lateron, the inexistent list of fonts is searched
for the matching font for this particular entry which of course leads to
a segfault.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Alternatively the POC could be changed to 64bit. the large values seem to be within what is allowed.
Fixes: signed integer overflow: 2147483646 + 2 cannot be represented in type 'int'
Fixes: 26076/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5711127201447936
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
We do not know how many samples these produce as its not exported.
Alternatively we could export that but as long as its not we better
assume its more than 0 as otherwise the thresholds would not work
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is more than 10 times the size of the largest i found. And also alot more
than our encoder could handle (our encoder is limited to max 31)
Without any limit megabyte+ sized blocks can be reallocated millions of times.
Sadly the SCTE-20 spec does not seem to contain any hard limit directly, so this limit here
is arbitrary
Fixes: Timeout (25sec -> 152ms)
Fixes: 25714/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG2VIDEO_fuzzer-5713633336885248
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The ASUS V2 format is designed for a little-endian bitstream reader, yet
our encoder used an ordinary big-endian bitstream writer to write it;
the bits of every byte were swapped at the end and some data (namely the
numbers not in static tables) had to be bitreversed before writing it at
all, so that it would be reversed twice.
This commit stops doing so; instead, a little-endian bitstream writer is
used. This also necessitated to switch certain static tables, which
required trivial modifications to the decoder (that uses the same
tables).
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now the ASV2 decoder used an ordinary big-endian bitreader to
read data actually destined for a little-endian bitreader; this is done
by reversing the whole input packet bitwise, using the big-endian
bigreader and reversing (and shifting) the result again. This commit
stops this and instead uses a little-endian bitreader directly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: off by 1 error
Fixes: index 5 out of bounds for type 'COOKSubpacket [5]'
Fixes: 25772/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_COOK_fuzzer-5762459498184704.fuzz
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This takes the used values from ISO/IEC 13818-1 Table 2-45 and adds
them to the mpegts.h header. No functional changes.
Signed-off-by: Brad Hards <bradh@frogmouth.net>
Signed-off-by: Marton Balint <cus@passwd.hu>
- Call srt_epoll_release() to avoid fd leak on libsrt_setup() error.
- Call srt_cleanup() on libsrt_open() failure.
- Fix return value and method on mode parsing failure.
Based on a patch by Nicolas Sugino <nsugino@3way.com.ar>.
Signed-off-by: Marton Balint <cus@passwd.hu>
Fixes fate-binsub-movtextenc on PPC64
Currently tags are written in reverse order on BE arches. This is fixed
by using MKBETAG() and AV_RB32() to be arch agnostics.
Also s->font_count is of type int. On BE arches with 32bit int,
count = AV_RB16(&s->font_count) will read two most significant bytes
instead of the least significant bytes. This is fixed by assigning
s->font_count to count first.
The final change is modifying the type of len. On BE arches
the most significant byte of the int was written instead of the least
significant byte.
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
The MV checks did not consider the width and height of the block, also they
had some off by 1 errors. This resulted in undefined behavior and crashes.
This commit instead errors out on these
Fixes: out of array read
Fixes: 26080/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOBICLIP_fuzzer-5758146355920896
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Such values are not supported by ff_subtitles_queue*
Fixes: signed integer overflow: 10 - -9223372036854775808 cannot be represented in type 'long'
Fixes: 24193/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5714901855895552
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Memory allocation for AVIOContext should be checked. In this code,
all error conditions are sent to the "goto error".
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The WebP format uses Huffman tables and the decoder therefore uses
VLC tables. Given that WebP is a LE format, a LE bitreader is used;
yet the VLC table is not created for a LE reader (the process used to
create the tables puts the last bit to be read in the lowest bit) and
therefore custom code for reading the VLCs that reverses the bits
read is used instead of get_vlc2(). This commit changes this to use
a table designed for LE bitreader which allows to use get_vlc2() directly.
The necessary reversing of the codes is delegated to
ff_init_vlc_sparse() (and is therefore only done during init and not
when actually reading the VLCs).
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is easily possible because ff_init_vlc_sparse() already transforms
both LE as well as BE codes to a normal form internally before
processing them further. This will be used in subsequent commits.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It can't, because the tables used don't have any loose ends. This also
fixes a bug in the only caller of decode_dc_le(): It didn't check the
return value.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Before the LE bitstream reader was used in the Indeo 2 decoder,
a standard BE bitstream reader with swapped bits was used; when the LE
bitstream reader was added, the old code was only #ifdef'ed away and not
removed. Said code has several problems: It modifies the input packet
without ensuring that the packet is indeed writable; and it doesn't work
since 09c4e5c598 because said commit
removed the BE table used to initialize the VLC table. So just remove
this cruft from the actual decoder, too.
Also use INIT_LE_VLC_STATIC while at it.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It can't because the corresponding trees don't have any loose ends.
Removing the checks also removed an instance of av_log(NULL (with a
nonsense message) from the codebase.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It currently uses 9 bits per table, but there are no codes with
nine bits at all, while there are codes with eight, ten and eleven bits.
So reducing the table size to eight bits will not reduce the amount of
codes that can be parsed in the first step, but it allows to reduce the
size of the motion-vector VLC.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: 872415232 * 7 cannot be represented in type 'int'
Fixes: signed integer overflow: -2013265888 + -1744830464 cannot be represented in type 'int'
Fixes: 25834/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOBICLIP_fuzzer-5471406434025472
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The mfra has enough information to enable seeking, and reading it is
behind an AVOption flag, so we shouldn't require that sidx information
also be present in order to seek using the fragment index.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Fixes vf_scale outputting RGB AVFrames with limited range flagged
in case either input or output specifically sets the range.
This is the reverse of the logic utilized for RGB and PAL8 content
in sws_setColorspaceDetails.
ccca62ef99 added new VP9 VDPAU profiles
and as a consequence AV_PIX_FMT_VDPAU can now be twice in the list of
pixel formats used for format negotiation by ff_thread_get_format(); yet
there is only one entry in said list reserved for VDPAU, leading to a
stack-buffer overflow. This commit fixes this by making sure that
AV_PIX_FMT_VDPAU will not occur twice in said list.
Fixes Coverity ticket 1468046.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The SheerVideo decoder uses two VLC tables and these are in turn created
from structures (called SheerTable) that are naturally paired. This
commit unifies these pairs of SheerTables to arrays and unifies creating
the VLC tables.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The SheerVideo decoder uses VLC tables which are currently stored in
large arrays that contain the length of each leaf of the corresponding
tree from left to right, taking 15.5KB of space. But all these arrays
follow a common pattern: First the entries are ascending and then they
are descending with lots of successive entries have the same value.
Therefore it makes sense to use a run-length encoding to store them, as
this commit does. Notice that the length 16 has to be treated specially
because there are arrays with more than 256 consecutive entries with
value 16 and because the length of the entries start to descend from
this length onward.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This has happened if the format changed midstream and if the new packet
is so small that it is instantaneously rejected: In this case the VLC
tables were for the new format, although the context says that they are
still the ones for the old format. It can also happen if the format
changed midstream and the allocation of the new tables fails. If the
next packet is a packet for the old format, the decoder thinks it
already has the correct VLC tables, leading to a segfault.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Don't needlessly copy an array around; don't create a table with
default symbols; and use smaller types to save stack space: The longest
code here is 16 bits, so one can store the codes in this type.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself
Fixes: 25675/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_G729_fuzzer-4786580731199488
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Said escape code is only six bits long, so that one has at least 25 - 6
bits in the bitstream reader's cache after reading it; therefore the
whole following 18 bits (containing the actual code) are already in the
bitstream reader's cache, making it unnecessary to reload the cache.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This should increase the effectiveness of ffio_ensure_seekback by reducing the
number of buffer reallocations and memmoves/memcpys because even a small
seekback window requires max_buffer_size+window_size buffer space.
Signed-off-by: Marton Balint <cus@passwd.hu>
Previously ffio_ensure_seekback never flushed the buffer, so successive
ffio_ensure_seekback calls were all respected. This could eventually cause
unlimited memory and CPU usage if a demuxer called ffio_ensure_seekback on all
it's read data.
Most demuxers however only rely on being able to seek back till the position of
the last ffio_ensure_seekback call, therefore we change the semantics of
ffio_ensure_seekback so that a new call can invalidate seek guarantees of the
old. In order to support some level of "nested" ffio_ensure_seekback calls, we
document that the function only invalidates the old window (and potentially
discards the already read data from the IO buffer), if the newly requested
window does not fit into the old one.
This way we limit the memory usage for ffio_ensure_seekback calls requesting
consecutive data windows.
Signed-off-by: Marton Balint <cus@passwd.hu>
It was possible for the old code to seek back before the most recently read
data if start of a new multipart was across read boundaries. Now we read some
small sections multiple times to avoid this, but that is OK.
Signed-off-by: Marton Balint <cus@passwd.hu>
The new buf_size was detemined too conservatively, maybe because of the
off-by-one issue which was fixed recently in fill_buffer. We can safely
substract 1 more from the new buffer size, because max_buffer_size space must
only be guaranteed when we are reading the last byte of the requested window.
Comparing the new buf_size against filled did not make a lot of sense, what
makes sense is that we want to reallocate the buffer if the new buf_size is
bigger than the old, therefore the change in the check.
Signed-off-by: Marton Balint <cus@passwd.hu>
Existing code did not check if the requested seekback buffer is
already read entirely. In this case, nothing has to be done to guarantee
seekback.
Signed-off-by: Marton Balint <cus@passwd.hu>
There was an off-by-one error when checking if the IO buffer still has enough
space till the end. One more byte can be safely written.
Signed-off-by: Marton Balint <cus@passwd.hu>
ad73b32d29 added some code for freeing in
the input's config_props function, yet this is unnecessary as uninit is
called anyway if config_props fails.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This has happened when initializing the motion estimation context if
width or height of the video was smaller than the block size used
for motion estimation and if the motion interpolation mode indicates
not to use motion estimation.
The solution is of course to only initialize the motion estimation
context if the interpolation mode uses motion estimation.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The latter code relies upon the dimensions to be not too small;
otherwise one will call av_clip() with min > max lateron which aborts
in case ASSERT_LEVEL is >= 2 or one will get a nonsense result that may
lead to a heap-buffer-overflow/underflow. The latter has happened in
ticket #8248 which this commit fixes.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
There is one general rtsp connection plus two connections per stream (rtp/rtcp).
Reviewed-by: Zhao Zhili <zhilizhao@tencent.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
There is no need to cast const away (even if it was harmless) and to
copy the object at all.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Now that the correct number of codes is used, it is no longer necessary
to initialize the lengths of the codes at all any more as the length of
the actually used codes is set later anyway.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Commit bbc0d0c1fe made the mjpeg decoder
use default Huffman tables when none are given, yet when initializing
the default Huffman tables, it did not use the correct number of entries
of the arrays used to initialize the tables, but instead it used the
biggest entry + 1 (as if it were a continuous array 0..biggest entry).
This worked because the ff_init_vlc_sparse() (and its predecessors)
always skipped entries with a length of zero and the length of the
corresponding elements was always initialized to zero with only the
sizes of the actually existing elements being set to a size > 0 lateron.
Yet since commit 1249698e1b this is no
longer so, as build_vlc() actually read the array containing the values
itself. This implies that the wrong length now leads to a read beyond
the end of the given array; this could lead to crashs (but usually
doesn't); it is detectable by ASAN* and this commit fixes it.
*: AddressSanitizer: global-buffer-overflow on address xy
...
xy is located 0 bytes to the right of global variable 'avpriv_mjpeg_val_ac_luminance'
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Commit 1249698e1b made
ff_mjpeg_decode_dht() call build_vlc() with a wrong (too hight)
number of codes. The reason it worked is that the lengths of the extraneous
entries is initialized to zero and ff_init_vlc_sparse() ignores codes
with a length of zero. But using a too high number of codes was
nevertheless bad, because a) the assert in build_vlc() could have been
triggered (namely if the real amount of codes is 256) and b) the loop in
build_vlc() uses initialized data (leading to Valgrind errors [1]).
Furthermore, the old code spend CPU cycles in said loop although the
result won't be used anyway.
[1]: http://fate.ffmpeg.org/report.cgi?slot=x86_64-archlinux-gcc-valgrind&time=20201008025137
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Added VDPAU to list of supported formats for VP9 420 10 and 12 bit
formats. Add VP9 10/12 Bit support for VDPAU
Signed-off-by: Philip Langdale <philipl@overt.org>
This is currently safe here, because the effective lifetime of
adaptionset_lang is parse_manifest_adaptationset() (i.e. the pointer
gets overwritten each time on entry to the function and gets freed
before exiting the function), but it is nevertheless safer to reset the
pointer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Use xmlFree instead of av_freep
snip from libxml2:
* xmlGetProp:
...
* Returns the attribute value or NULL if not found.
* It's up to the caller to free the memory with xmlFree().
According to libxml2, you are supposed to use xmlFree instead of free
on the pointer returned by it, and also using av_freep on Windows will
call _aligned_free instead of normal free, causing _aligned_free to raise
SIGTRAP and crashing ffmpeg and ffplay.
Signed-off-by: Christopher Degawa <ccom@randomderp.com>
Even if such files are invalid, they can be decoded just fine.
Also stored tiles may have bigger dimensions than displayed ones,
so do not abort decoding in such cases.
These conversion appears to be exhibiting the same rounding error as the rgbf32 formats where.
I seperated the rounding value from the 16 and 128 offsets, I think it makes it a little more clear.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
av1dec should no longer attempt to output empty frames if another decoder
was used for probing and it sucessfully set a pix_fmt ever since 05872c67a4,
so we can re-add the AV_CODEC_CAP_AVOID_PROBING cap.
Signed-off-by: James Almer <jamrial@gmail.com>
The buffers used when fragmented output is enabled have up until now not
been freed in the deinit function; they leak e.g. if one errors out of
mov_write_trailer() before one reaches the point where they are normally
written out and freed. This can e.g. happen if allocating new vos_data
fails at the beginning of mov_write_trailer().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Otherwise the old data leaks whenever extradata needs to be rewritten
(e.g. when encoding FLAC with our encoder that sends an updated
extradata packet at the end).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When remuxing an rtp hint stream (or any stream with the tag "rtp "),
the mov muxer treats this as one of the rtp hint tracks it creates
internally when ordered to do so; yet this track lacks the
AVFormatContext for the hinting rtp muxer, leading to segfaults in
mov_write_udta_sdp() if a "trak" atom is written for this stream; if not,
the stream's codecpar is freed by mov_free() as if the mov muxer owned
it (it does for the internally created "rtp " tracks), but without
resetting st->codecpar, leading to double-frees lateron. This commit
therefore ignores said tag which makes rtp hint streams unremuxable.
This fixes tickets #8181 and #8186.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The earlier code was based on the assumption that AVFrame.linesize can
not be negative.
Fixes ticket #8280.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: member access within null pointer of type 'TileGroupInfo' (aka 'struct TileGroupInfo')
Fixes: 25725/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AV1_fuzzer-5166692706287616
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: James Almer <jamrial@gmail.com>
The manual states "there is virtually no reason to use that encoder.".
It supports less sample formats than the native encoder, is less efficient
than the native encoder and is also slower and pretty much remains untested.
libwavpack also isn't being fuzzed, which given that we plug the parameters
without any sanitizing them looks concerning.
Fixes: signed integer overflow: 20 * 5184056935931942919 cannot be represented in type 'long'
Fixes: 25466/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-4798660247552000
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
changes since v1:
- made into fate test
- fixed c90 warnings
- tests more intermediate formats
- tested on BE mips too
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
1. Remove the assumption that the message method is TEARDOWN.
2. Don't ignore the error code of ff_rtsp_parse_streaming_commands.
Signed-off-by: Martin Storsjö <martin@martin.st>
In listen mode with UDP transport, once the sender has sent
the TEARDOWN and closed the connection, poll will indicate that
one can read from the connection (indicating that the socket has
reached EOF and should be closed by the receiver as well). In this
case, parse_rtsp_message won't try to parse the command (because
it's no longer in state STREAMING), but previously just returned
zero.
Prior to f6161fccf8, this caused
udp_read_packet to return zero, which is treated as EOF by
read_packet. But after that commit, udp_read_packet would continue
if parse_rtsp_message didn't return an explicit error code.
To keep the original behaviour from before that commit, more
explicitly return an error in parse_rtsp_message when in the wrong
state.
Fixes: #8840
Signed-off-by: Martin Storsjö <martin@martin.st>
There are two possible kinds of timecode tracks (with tag "tmcd") in the
mov muxer: Tracks created internally by the muxer and timecode tracks
sent by the user. If any of the latter exists, the former are
deactivated. The former all belong to another track, the source
track; the latter don't have a source track set, but the index of the
source track is initially zeroed by av_mallocz_array(). This is a
problem since 3d894db700: Said commit added
a function that calculates the duration of tracks and the duration of
timecode tracks is calculated by rescaling the duration (calculated by
the very same function) of the source track. This gives an infinite
recursion if the first track (the one that will be treated as source
track for all timecode tracks) is a timecode track itself, leading to a
stack overflow.
This commit fixes this by not using the nonexistent source track
when calculating the duration of timecode tracks not created internally
by the mov muxer.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Allocating an AVCodecContext's priv_data used to be the first object
allocated in avcodec_open2(), so it was unnecessary to goto free_and_end
(which does the cleanup) upon error here. But this is no longer so since
f3a29b750a.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Don't check for AVCodec.priv_data_size (which is always true if
AVCodec.priv_class is set). Instead check for AVCodecContext.priv_data
to actually exist.
(Note: av_opt_free(NULL) is a no-op.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The first thing avcodec_open2() allocates is the AVCodecInternal. If
allocating it fails, a jump to end occurs; but if an error happens after
its allocation, a jump to free_and_end happens which frees all
allocations performed so far and then jumps to end. Yet free_and_end
contained a check for AVCodecInternal (after having already dereferenced
it to check whether ff_thread_free() needs to be called) which is of
course always true. So remove it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Filters mostly work in native endianness, but they must output
a specified endianness, usually little: that requires a final
conversion for big endian.
I do not know what's the deal with gif-deal: inserting explicitly
the filters that are implicitly inserted result in less frames in
output. Probably a strange problem of duration.
avcodec_open2() also called the AVCodec's close function if an error
happened before init had ever been called if the AVCodec has the
FF_CODEC_CAP_INIT_CLEANUP flag set. This is against the documentation of
said flag: "The codec allows calling the close function for deallocation
even if the init function returned a failure."
E.g. the SVQ3 decoder is not ready to be closed if init has never been
called.
Fixes: NULL dereference
Fixes: 25762/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SVQ3_fuzzer-5716279070294016
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This reverts commit 5bbf58ab87.
The setparams filters are not hwframe aware, so the default context
passthrough behaviour is needed to allow using them with hardware frames.
In the VT encoding insertion by FFmpeg,
and vtenc_q_push is callback to add the encoded data
to the singly linked list group in VTEncContext,
and consumers are notified to fetch it.
However, because it first informs consumers of pthread_cond_signal,
and then inserts the data into the tail,
there is a multi-thread safety hazard.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Rick Kern <kernrj@gmail.com>
because there is run in thread mode, few times will block
the workflow at the wait, so check the status is flushing data,
don't wait when flushing data.
Signed-off-by: Tian Qi <tianqi@kuaishou.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Rick Kern <kernrj@gmail.com>
bool a53_cc is accessed as int:
src/libavutil/opt.c:129:9: runtime error: store to misaligned
address 0x7fbf454121a3 for type 'int', which requires 4 byte alignment
Signed-off-by: Rick Kern <kernrj@gmail.com>
Fixes: signed integer overflow: -1846510390 + -361755993 cannot be represented in type 'int'
Fixes: 23941/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MV30_fuzzer-5654696631730176
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
A common pattern e.g. in libavcodec is replacing/updating buffer
references: unref old one, ref new one. This function allows simplifying
such code and avoiding unnecessary refs+unrefs if the references are
already equivalent.
Add AC-3/EAC-3 to allowed extensions file list.
From HTTP Live Streaming 2nd Edition draft-pantos-hls-rfc8216bis-07
section 3.1.3.Packed Audio, HLS demuxer need to support MP3/AC-3/EAC-3.
Reviewd-by: Steven Liu <liuqi05@kuaishou.com>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
This patch adds the coefficients for the linear gamma function (1,0,1,0)
to the colorspace filter.
Signed-off-by: Andrew Klaassen <clawsoon@yahoo.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Otherwise the result of such tests will not accurately reflect the
current state.
Reviewed-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It seems that in files where the BASF block isn't first, v1.1 ASF streams are
allowed to be non-22050. Either this format is really inconsistent, or
FX Fighter and Croc just ignored the sample rate field, requiring the v1.1
restriction in the first place.
This bumps the version to 1.2 in these streams so they're not "corrected".
Found in Alien Odyssey games files in:
./GRAPHICS/COMMBUNK/{{COMADD1,COMM2_{1,2,3E},COMM3_{2,3,4,5,6}},FADE{1,2}}.BRP
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
This proved beneficial for performance: For the sample [1] the number
of decicycles in one decode call decreased from 155851561 to 108158037
for Clang 10 and from 168270467 to 128847479 for GCC 9.3. For x86-32
compiled with GCC 9.3 and run on an x64 Haswell the number increased
from 158405517 to 202215769, so that the cached bitstream reader is only
enabled if HAVE_FAST_64BIT is set. These values are the average of 10
runs each looping five times over the input.
[1]: samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2593/fraps_flv1_decoding_errors.avi
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The fraps decoder already checked for overreads manually (and errored
out in this scenario), yet it still enabled implicit checks, leading to
worse performance and more code size.
This commit disables the implicit bitstream reader checks. For the
sample [1] this improves performance from 195105896 to 155851561
decicycles for Clang 10 and from 222801887 to 168270467 decicycles when
compiled with GCC 9.3. These values are the average of 10 runs each
looping ten times over the input.
[1]: samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2593/fraps_flv1_decoding_errors.avi
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The Ut video format uses Huffman trees which are only implicitly coded
in the bitstream: Only the lengths of the codes are coded, the rest has
to be inferred by the decoder according to the rule that the longer
codes are to the left of shorter codes in the tree and on each level the
symbols are descending from left to right.
Because longer codes are to the left of shorter codes, one needs to know
how many non-leaf nodes there are on each level in order to know the
code of the next left-most leaf (which belongs to the highest symbol on
that level). The current code does this by sorting the entries to be
ascending according to length and (for entries with the same length)
ascending according to their symbols. This array is then traversed in
reverse order, so that the lowest level is dealt with first, so that the
number of non-leaf nodes of the next higher level is known when
processing said level.
But this can also be calculated without sorting: Simply count how many
leaf nodes there are on each level. Then one can calculate the number of
non-leaf nodes on each level iteratively from the lowest level upwards:
It is just half the number of nodes of the level below.
This improves performance: For the sample from ticket #4044 the amount
of decicycles for one call to build_huff() decreased from 1055489 to
446310 for Clang 10 and from 1080306 to 535155 for GCC 9.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The Ut Video format stores Huffman tables in its bitstream by coding
the length of a given symbol; it does not code the actual code directly,
instead this is to be inferred by the rule that a symbol is to the left
of every shorter symbol in the Huffman tree and that for symbols of the
same length the symbol is descending from left to right. With one
exception, this is also what our de- and encoder did.
The exception only matters when there are codes of length 32, because
in this case the first symbol of this length did not get the code 0,
but 1; this is tantamount to pretending that there is a (nonexistent)
leaf of length 32. This is simply false. The reference software agrees
with this [1].
[1]: 2700a471a7/utv_core/HuffmanCode.cpp (L280)
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Now that the HuffEntries are no longer sorted by the MagicYUV decoder,
their symbols are trivial: The symbol of the element with index i is i.
They can therefore be removed. Furthermore, despite the length of the
codes being in the range 1..32 bits, the actual value of the codes is
<= 4096 (for 12 bit content). The reason for this is that the longer
codes are on the left side of the tree, so that the higher bits of
these codes are simply zero. By using an uint16_t for the codes and
removing the symbols entry, the size of each HuffEntry is decreased from
eight to four, saving 16KB of stack space.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The MagicYUV format stores Huffman tables in its bitstream by coding
the length of a given symbol; it does not code the actual code directly,
instead this is to be inferred by the rule that a symbol is to the left
of every shorter symbol in the Huffman tree and that for symbols of the
same length the symbol is ascending from left to right.
Our decoder implemented this by first sorting the array containing
length and symbol of each element according to descending length and
for equal length, according to ascending symbol. Afterwards, the current
state in the tree got encoded in a variable code; if the next array entry
had length len, then the len most significant bits of code contained
the code of this entry. Whenever an entry of the array of length
len was processed, code was incremented by 1U << (32 - len). So two
entries of length len have the same effect as incrementing code by
1U << (32 - (len - 1)), which corresponds to the parent node of length
len - 1 of the two nodes of length len etc.
This commit modifies this to avoid sorting the entries before
calculating the codes. This is done by calculating how many non-leaf
nodes there are on each level of the tree before calculating the codes.
Afterwards every leaf node on this level gets assigned the number of
nodes already on this level as code. This of course works only because
the entries are already sorted by their symbol initially, so that this
algorithm indeed gives ascending symbols from left to right on every
level.
This offers both speed- as well as (obvious) codesize advantages. With
Clang 10 the number of decicycles for build_huffman decreased from
1561987 to 1228405; for GCC 9 it went from 1825096 decicyles to 1429921.
These tests were carried out with a sample with 150 frames that was
looped 13 times; and this was iterated 10 times. The earlier reference
point here is from the point when the loop generating the codes was
traversed in reverse order (as the patch reversing the order led to
performance penalties).
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The MagicYUV format stores Huffman tables in its bitstream by coding
the length of a given symbol; it does not code the actual code directly,
instead this is to be inferred by the rule that a symbol is to the left
of every shorter symbol in the Huffman tree and that for symbols of the
same length the symbol is ascending from left to right. With one
exception, this is also what our decoder did.
The exception only matters when there are codes of length 32, because
in this case the first symbol of this length did not get the code 0,
but 1; e.g. if there were exactly two nodes of length 32, then they
would get assigned the codes 1 and 2 and a node of length 31 will get
the 31-bit code 1 which is a prefix of the 32 bit code 2, making the
Huffman table invalid. On the other hand, if there were only one symbol
with the length 32, the earlier code would accept this un-Huffman-tree.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The MagicYUV decoder currently sets both the length and the symbol field
of an array of HuffEntries; hereby the symbol of the ith entry (0-based)
is just i. Then said array gets sorted so that entries with greater
length are at the end and entries with the same length are ordered so
that those with smaller symbols are at the end. Afterwards the newly
sorted array is traversed in reverse order. This commit instead inverts
the ordering and traverses the array in its ordinary order in order to
simplify understanding.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Every plane of each slice has to contain at least two bytes for flags
and the type of prediction used.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
AV1 decoder is supported on Tiger Lake+ platforms since libmfx 1.34
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Signed-off-by: Zhong Li <zhongli_dev@126.com>
Since release 4.2, FFmpeg fails to detect the correct streams in an RTMP
stream that contains a |RtmpSampleAccess AMF object prior to the
onMetaData AMF object. In the debug log it would show "[flv] Unknown
type |RtmpSampleAccess".
This functionality broke in commit d7638d8dfc
as unknown metadata packets now result in an opaque data stream, and the
|RtmpSampleAccess packet was an "unknown" metadata packet type.
With this change the RTMP streams are correctly detected when there
is a |RtmpSampleAccess object prior to the onMetaData object.
Signed-off-by: Peter van der Spek <p.vanderspek@bluebillywig.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fix the issue: https://github.com/intel/media-driver/issues/317
the root cause is update_dimensions will be called multple times
when decoder thread number is not only 1, but update_dimensions
call get_pixel_format in each decode thread will trigger the
hwaccel_uninit/hwaccel_init more than once. But only one hwaccel
should be shared with all decode threads.
in current context,
there are 3 situations in the update_dimensions():
1. First time calling. No matter single thread or multithread,
get_pixel_format() should be called after dimensions were
set;
2. Dimention changed at the runtime. Dimention need to be
updated when macroblocks_base is already allocated,
get_pixel_format() should be called to recreate new frames
according to updated dimension;
3. Multithread first time calling. After decoder init, the
other threads will call update_dimensions() at first time
to allocate macroblocks_base and set dimensions.
But get_pixel_format() is shouldn't be called due to low
level frames and context are already created.
In this fix, we only call update_dimensions as need.
Signed-off-by: Wang, Shaofei <shaofei.wang@intel.com>
Reviewed-by: Jun, Zhao <jun.zhao@intel.com>
Reviewed-by: Haihao Xiang <haihao.xiang@intel.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
As it was brought up that the current documentation leaves things
as specific to YCbCr only, ICtCp and RGB are now mentioned.
Additionally, the specifications on which these definitions of
narrow and full range are defined are mentioned.
This way, the documentation of AVColorRange should now match how
most people seem to read interpret it at this point, and thus
flagging RGB AVFrames as full range is valid not only according to
common sense, but also the enum definition.
The earlier code would first attempt to allocate two buffers, then
attempt to allocate an AVIOContext, using one of the new buffers I/O
buffer, then check the allocations. On success, a z_stream that is used
in the AVIOContext's read_packet callback is initialized afterwards.
There are two problems with this: In case the allocation of the I/O
buffer fails avio_alloc_context() will be given a NULL read buffer
with a size > 0. This works right now, but it is fragile. The second
problem is that the z_stream used in the read_packet callback is not
functional when avio_alloc_context() is allocated (it might be that
avio_alloc_context() might already fill the buffer in the future). This
commit fixes both of these problems by reordering the operations.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Causes some error as the ADPCM predictors aren't known, but
the difference is negligible and not audible.
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
If the average bit rate cannot be calculated, such as in the case
of streamed fragmented mp4, utilize various available parameters
in priority order.
Tests are updated where the esds or btrt or ISML manifest boxes'
output changes.
This is utilized by various media ingests to figure out the bit
rate of the content you are pushing towards it, so write it for
video, audio and subtitle tracks in case at least one nonzero value
is available. It is only mentioned for timed metadata sample
descriptions in QTFF, so limit it only to ISOBMFF (MODE_MP4) mode.
Updates the FATE tests which have their results changed due to the
20 extra bytes being written per track.
for some cases (for example, super resolution), the DNN model changes
the frame size which impacts the filter behavior, so the filter needs
to know the out frame size at very beginning.
Currently, the filter reuses DNNModule.execute_model to query the
out frame size, it is not clear from interface perspective, so add
a new explict interface DNNModel.get_output for such query.
suppose we have a detect and classify filter in the future, the
detect filter generates some bounding boxes (BBox) as AVFrame sidedata,
and the classify filter executes DNN model for each BBox. For each
BBox, we need to crop the AVFrame, copy data to DNN model input and do
the model execution. So we have to save the in_frame at DNNModel.set_input
and use it at DNNModule.execute_model, such saving is not feasible
when we support async execute_model.
This patch sets the in_frame as execution_model parameter, and so
all the information are put together within the same function for
each inference. It also makes easy to support BBox async inference.
Currently, every filter needs to provide code to transfer data from
AVFrame* to model input (DNNData*), and also from model output
(DNNData*) to AVFrame*. Actually, such transfer can be implemented
within DNN module, and so filter can focus on its own business logic.
DNN module also exports the function pointer pre_proc and post_proc
in struct DNNModel, just in case that a filter has its special logic
to transfer data between AVFrame* and DNNData*. The default implementation
within DNN module is used if the filter does not set pre/post_proc.
get_content_url() allocates two buffers for temporary strings and when
one of them couldn't be allocated, it simply returns, although one of
the two allocations could have succeeded and would leak in this
scenario. This can be fixed by avoiding one of the temporary buffers.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
1. Perform the necessary reindentations after the last few commits.
2. Adapt switches to the ordinary indentation style.
3. Now that the effective lifetimes of the variables containing
the freshly allocated strings used when parsing the representation
are disjoint, the variables can be replaced by a single variable.
Doing so has the advantage of making it more clear that these are
throwaway variables, hence it has been done.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This allows to reduce the level of indentation for parsing the supported
representations (audio, video and subtitles). It also allows to avoid
some allocations and frees for unsupported representations.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This commit removes two always-true checks as well as a dead default
case of a switch. The check when parsing manifests is always true,
because we now jump to the cleaning code in case the format of the
representation is unknown. The default case of the switch is dead,
because the type of the representation is already checked at the
beginning of parse_manifest_representation(). The check when reading
the header is dead, because we error out if an error happened before.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the DASH demuxer used av_dynarray_add() to add
audio/video/subtitles representations to arrays. Yet av_dynarray_add()
frees the array upon failure, leading to leaks of its elements;
furthermore, the element to be added leaks, too.
This has been fixed by using av_dynarray_add_nofree() instead and by
freeing the elements that could not be added to the list. Furthermore,
errors from this are now checked and returned.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
These languages are normally freed after having been added as metadata
to their respective AVStreams. Yet if one never reaches said point, they
leak. This can happen as a result of an error when reading the header or
as a result of refreshing the manifests.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The DASH demuxer currently extracts several strings at once from an xml
document before processing them one by one; these strings are allocated,
stored in local variables and need to be freed by the demuxer itself.
So if an error happens when processing one of them, all strings need to
be freed before returning. This has simply not been done, leading to
leaks.
A simple fix would be to add the necessary code for freeing; yet there is
a better solution: Avoid having several strings at the same time by
extracting a string, processing it and immediately freeing it. That way
one only has to free at most one string on error.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If parsing a representation fails, it is not added to the list of
representations and is therefore not freed in dash_close(); it therefore
leaked in most error paths in parse_manifest_representation() (some
error paths had (incomplete) code for freeing). This commit fixes
freeing the representation in this case.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
open_url() in the DASH as well in the hls demuxer share a common bug:
They modify an AVDictionary (i.e. set a new entry) given to them as
AVDictionary *, yet if this new entry leads to reallocation and
relocation of the AVDictionary, the caller's pointer will become
dangling, leading to use-after-frees. So pass an AVDictionary **.
(With the current implementation of AVDictionary the above can only
happen if the AVDictionary was empty initially (in which case the
new AVDictionary leaks); furthermore if the I/O is ordinary (i.e. opened
by avio_open2() or ffio_open_whitelist()), the dict is never empty (it
contains an rw_timeout entry from save_avio_options()). So this issue
could only happen if the caller sets a nondefault io_open callback, but
no AVIOContext (the AVFMT_FLAG_CUSTOM_IO flag won't be set in this
case). In case of the HLS demuxer, it was also necessary that setting
the "seekable" entry failed. Yet one should simply not rely on internals
of the AVDict API.)
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Just postpone the allocation of the dict until it is really needed
(after the checks that can fail).
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This currently doesn't cause any trouble, because the only caller did
not clean up the representation upon error at all; but fixing this is
a prerequisite for doing so.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The code in question seems to have been copied from about 70 lines
above; yet the code here is only executed if some of the variables
(namely representation_segmenttemplate_node and fragment_template_node)
are NULL, so it makes no sense to check them for a child element.
Also remove a redundant resetting of a pointer to an AVFormatContext
after avformat_close_input() (which already sets the pointer to NULL).
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When using one of the AV_DICT_DONT_STRDUP_KEY/VAL flags, av_dict_set()
already frees the key/value on error, so that freeing it again would
lead to a double free.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The AAX demuxer reads a 32bit number containing the amount of entries
of an array and stores it in an uint32_t. Yet when iterating over this
array, a loop counter of type int is used. This leads to undefined
behaviour if the amount of entries is not in the range of int; to avoid
this, it is generally good to use the same type for the loop counter as
for the variable it is compared to. This is done in one of the two loops
affected by this.
In the other loop, the undefined behaviour can begin even earlier: Here
the loop counter is multiplied by an uint16_t which can overflow as soon
as the loop counter is > 2^15. Using an unsigned type would avoid the
undefined behaviour, but truncation would still be possible, so use an
uint64_t.
Also use an uint32_t for a variable containing an index in said array.
This fixes Coverity issue #1466767.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
There was almost no overlap between them: The only field used by both
was an int named samples_per_frame. Therefore this commit separates
them.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The tedcaptions demuxer uses an AVBPrint whose string is not restricted
to its internal buffer; it therefore needs to be cleaned up, yet this is
not done on error, as parse_file() returned simply returned directly.
This is fixed by going to fail first in such cases.
Furthermore, there is also a second way how this string can leak: By
having more than one subtitle per subtitle block, as the new one simply
overwrites the old one in this case as the AVBPrint is initialized each
time upon encountering a subtitle line. The code has been modified to
simply append the new subtitle to the old one, so that the old one can't
leak any more.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Turns out that there are files with multiple (reasonably-sized) BASF
blocks. Some of the files just have particularly large frames (~10s).
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Enforcing num_chunks == 1 only makes sense when demuxing from an ASF
file. When embedded in a BRP file, an ASF stream can have multiple chunks.
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
The SWF muxer accepts at most one mp3 audio and at most one VP6F, FLV1
or MJPEG stream. Upon encountering an mp3 stream, a fifo is allocated
that leaks if one of the subsequent streams is incompliant with the
restrictions mentioned above or if the framerate or samplerate are
invalid. This is fixed by adding a deinit function to free said fifo.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Before patch, fate test for dnn may fail in some Windows environment
while succeed in my Linux. The bug was caused by a wrong loop boundary.
After patch, fate test succeed in my windows mingw 64-bit.
Signed-off-by: Xu Jun <xujunzz@sjtu.edu.cn>
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
The RealMedia demuxer uses the priv_data of its streams to store a
structure containing an AVPacket. These packets are unreferenced in the
read_close function, yet said function simply presumed that the
priv_data has been successfully allocated. This implies that it mustn't
be called when an allocation of priv_data fails; but this can happen
since commit 35bbc1955a if one has a
stream with multiple substreams (also exported as AVStream) and if
allocating the priv_data for one of these substreams fails.
This has been fixed by making sure that read_close can handle the case
in which priv_data has not been successfully allocated.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The RealMedia demuxer's read_header function initially initializes ret,
the variable designated for the return variable to -1. Afterwards, chunks
of the file are parsed in a loop until an error happens or until the actual
frame data is encountered. If the first function whose return
value is put into ret doesn't fail, then ret contains a value >= 0
(actually == 0) and this is what will be returned if an error is
encountered afterwards.
This is a regression since 35bbc1955a.
Before that, ret had never been overwritten with a nonnegative value.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Do this by only keeping the only function pointer from the
AVFloatDSPContext that is needed lateron. This also allows to remove the
decoders' close function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The lossless JPEG encoder allocates one buffer in its init function
and freeing said buffer is the only thing done in its close function.
Despite this the init function called the close function if allocating
said buffer fails, although there is nothing to free in this case.
This commit stops doing this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The JPEG2000 encoder did not clean up after itself on error.
This commit fixes this by modifying the cleanup function to be able to
handle only partially allocated structures and by setting the
FF_CODEC_CAP_INIT_CLEANUP flag.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Do this by only keeping the only function pointer from
the AVFloatDSPContext that is needed lateron.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The HNM 4 video decoder's init function claimed that an allocation
failed if the image dimensions are wrong. This is fixed in this commit:
The dimensions are checked before the allocations are attempted.
The check whether width * height is zero is redundant as
av_image_check_size() already checks for this; it has been removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This encoder uses the compress2 utility function provided by zlib
instead of using a z_stream.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the flashsv encoder tried to allocate two buffers in its
init function; if only one of these allocations succeeds, the other
buffer leaks. Fix this by making one of these buffers part of the
context (its size is a compile-time constant).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
According to the spec bits per sample should be used
Fix invalid shift with bpp=32
Fixes: shift exponent 32 is too large for 32-bit type 'unsigned int'
Fixes: 23507/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-4815432665268224
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: negation of -2147483648 cannot be represented in type 'int32_t' (aka 'int'); cast to an unsigned type to negate this value to itself
Fixes: 23760/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-604209011412172
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: 0 - -2147483648 cannot be represented in type 'int'
Fixes: 23646/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_FIXED_fuzzer-5480991098667008
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This reverts commit 61669b7c40.
This commit broke building with MSVC due to its spec-incompliant handling
of ',' in __VA_ARGS__: These are not treated as argument separators for
further macros, so that in our case the init_vlc2() macro is treated as
having only one argument whenever the init_vlc() macro is used. See [1]
for further details.
[1]: https://reviews.llvm.org/D69626
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The AC-3 encoders (both floating- as well as fixed-point) as well as
the EAC-3 encoder share code: All use ff_ac3_encode_init() as well as
ff_ac3_encode_close(). Until ee726e777b
ff_ac3_encode_init() called ff_ac3_encode_close() to clean up on error.
Said commit removed this and instead set the FF_CODEC_CAP_INIT_CLEANUP
flag; but it did the latter only for the fixed-point AC-3 encoder and
not for the other two users of ff_ac3_encode_init(). This caused any
already allocated buffer to leak upon a subsequent error for the two
other encoders.
This commit fixes this by adding the FF_CODEC_CAP_INIT_CLEANUP flag
to the other two encoders using ff_ac3_encode_init().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The ac3 encoders (fixed- and floating-point AC-3 as well as the EAC-3
encoder) all allocate an array whose elements are pointers to other
buffers. The array is not zeroed initially so that if an allocation of
one of the subbuffers fails, the other pointers are uninitialized.
This causes problems when cleaning, so zero the array initially.
(Only the fixed-point AC-3 encoder was affected by this, because
the other two don't clean up at all in case of errors during init.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Do this by only keeping the only function pointer from
the AVFloatDSPContext that is needed lateron.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Do this by only keeping the only function pointer from
the AVFloatDSPContext that is needed lateron.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The init function of the ALAC encoder calls its own close function
if a call to ff_lpc_init() fails; yet nothing has been allocated before
that point (except extradata which is freed generically) and ff_lpc_init()
can be expected to clean up after itself on error (the documentation does
not say anything to the contrary and the current implementation can only
fail if the only allocation fails, so there is nothing to clean up on
error anyway), so this is unnecessary.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Tiles have a size field with a length from one to four bytes. As such it
is not possible to read it all at once with a call to get_bits() as this
only allows to read up to 25 bits; this is guarded by an av_assert2. Yet
this is done by the AV1 decoder in get_tiles_info(). It has been done
despite said size fields being byte-aligned. This commit fixes this by
using the bytestream2 API instead.
Furthermore, it is now explicitly checked whether the data is
consistent, i.e. whether the data that is supposed to be there extends
beyond the end of the data actually present.
Reviewed-by: Wang, Fei W <fei.w.wang@intel.com>
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Besides the obvious advantage of less code this also has a performance
impact: For GCC 9 the time spent on one call to smka_decode_frame() for
the sample from ticket #2425 decreased from 1693619 to 1498127
decicycles. For Clang 9, it decreased from 1369089 to 1366465
decicycles.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the Smacker decoder has pretended that the prediction
values are signed in code like 'pred[0] += (unsigned)sign_extend(val, 16)'
(the cast has been added to this code later to fix undefined behaviour).
This has been even done in case the PCM format is u8.
Yet in case of 8/16 bit samples, only the lower 8/16 bit of the predicition
values are ever used, so one can just as well just use unsigned and
remove the sign extensions. This is what this commit does.
For GCC 9 the time for one call to smka_decode_frame() for the sample from
ticket #2425 decreased from 1709043 to 1693619 decicycles; for Clang 9
it went up from 1355273 to 1369089 decicycles.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
by using buffers on the stack instead. The fact that the effective
lifetime of most of the allocated buffers doesn't overlap enables one to
limit the stack space used to a fairly modest size (about 1.5 KiB).
That all the buffers used in HuffContexts have always the same number of
elements (namely 256) makes it possible to include the buffers directly
in the HuffContext. Doing so also makes the length field redundant; it has
therefore been removed.
This is beneficial for performance: For GCC 9 the time for one call to
smka_decode_frame() for the sample in ticket #2425 went down from
1794494 to 1709043 decicyles; for Clang 9 it decreased from 1449420 to
1355273 decicycles.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the return value of get_vlc2() has been used as an index
in an array that contained the value one is really interested in. Yet
since b613bacca9 this is no longer
necessary, as one can store the value that is right now stored in the
array in the VLC internal table.
This also means that all the information from the eight bit Huffman trees
are now stored in the corresponding VLC table; this will enable us to
remove several allocations lateron.
This improved performance: For GCC 9 the time for one call of
smka_decode_frame() for the sample from ticket #2425 decreased from
1811706 to 1794494 decicycles; for Clang 9 the number went from 1471663
to 1449420 decicycles.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This will mean that we will need less stack space lateron when these
arrays are no longer heap-allocated.
No discernible speed impact.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Smacker uses two types of Huffman trees: Those for eight bit values and
those for 16 bit values. Given that both return their values via arrays
and that both need to check not to overrun their array, the context for
parsing eight bit values (HuffContext) will necessarily exhibit certain
similarities with the context used for parsing 16 bit values (DBCtx).
These similarities led to using a HuffContext in addition a DBCtx for
parsing 16 bit trees.
This stands in the way of further developments for the HuffContext struct
(when parsing eight bit trees, the length of the arrays are always 256,
so that one can inline said value and move the currently heap-allocated
tables directly in the structure).
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Using explicit checks has the advantage that one can combine several
checks into one and does not have to check every time. E.g. reading a
16bit PCM sample involves two calls to get_vlc2(), each of which may
read up to three times up to SMKTREE_BITS (= 9) bits. But given that the
padding that the input packet is supposed to have is large enough, it is
no problem to only check once for each sample.
This turned out to be beneficial for performance: For GCC 9, the time for
one call of smka_decode_frame() for the sample from ticket #2425 went down
from 2055905 to 1804751 decicycles; for Clang 9 it went down from 1510538
to 1479680 decicycles.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The VLC codes in question originate from a Huffmann tree and so every
sequence of bits that is longer than the longest code contains an
initial sequence that is a valid code. Given that it has been checked
during reading said tree (and once again in ff_init_vlc_sparse()) that
the length of each code is <= 3 * the number of bits read at once when
reading codes, get_vlc2() will always find a matching entry.
These checks have been added in 71d3c25a7e
at a time when the length of the codes had not been checked when parsing
the tree.
For GCC 9 and the sample from ticket #2425 this led to a slight
performance regression: The time for one call to smka_decode_frame()
increased from 2053671 to 2064529 decicycles; for Clang 9, performance
improved from 1521288 to 1508459 decicycles.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When length is zero for a leaf node (which happens iff the Huffman tree
consists of one leaf node only), prefix is also automatically zero.
Performance impact is negligible: For GCC 9 and the sample from #2425,
the time for one call to smka_decode_frame() decreased from 2053758 to
2053671 decicycles; for Clang 9 it went from 1523153 to 1521288.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
With the possible exception of the "last" values when decoding video,
only the part that is actually initialized with values derived from the
bitstream is used afterwards, so it is unnecessary to zero everything at
the beginning. This is also no problem for the "last" values at all,
because they are reset for every frame anyway.
While at it, use sizeof(variable) instead of sizeof(type).
Performance increased slightly: For GCC, from 2068389 decicycles per call
to smka_decode_frame() when decoding the sample from ticket #2425 to 2053758
decicycles; for Clang, from 1534188 to 1523153 decicycles.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Using the real number of read codes allows to leave a loop in
ff_init_vlc_sparse earlier; notice that all codes not explicitly
set by reading data have been set to zero earlier (i.e. they are
zero-length codes) and such codes are ignored by ff_init_vlc_sparse.
This improves performance: When compiled with GCC 9, the time spent on
one call to smka_decode_frame() for the sample from ticket #2425
decreased from 2195367 decicycles to 2068389 decicycles. For Clang 9,
it improved from 1602075 to 1534188 decicycles. These tests have been
performed 20 times and each times the input file has been looped
32 times to get a sufficient number of frames.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Given that the code currently accepts only 27 bits long Huffman codes,
the shift 1 << (length - 1) with length in 1..28 that is performed when
parsing the tree is safe. Yet if this limit were ever expanded to the
full 32 bits, this shift would be potentially undefined. So simply use
unsigned.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
smacker_decode_header_tree() uses different variables for return values
(res) and for errors (err) leading to code like
res = foo(bar);
if (res < 0) {
err = res;
goto error;
}
Given that no positive return value is ever used at all one can simplify
the above by removing the intermediate res.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The earlier version did not error out directly in case an error happens,
because it would lead to a leak: An allocated array is only reachable
via a local variable at that time; it is only attached to more permanent
storage at the end. While it would be possible to add custom code for
freeing on error (instead of reusing the ordinary code for doing so),
this commit takes the opposite approach and attaches the newly allocated
array to its permanent place immediately after its allocation.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The extradata for Smacker video contains Huffman trees as well as a
field containing the size (in bytes) of said Huffman tree when stored
as a table. Due to three special values the decoder allocates more than
the size field indicates; yet when it parses the table it only errors
out if the number of elements exceeds the number of allocated elements
and not the number of elements as indicated by the size field. As a
consequence, there might be less than three elements available at the
end, so that another check for this is necessary.
This commit changes this: It is always made sure that the three elements
reserved to (potentially) use them to store the special values are not
used to store ordinary tree entries. This allows to remove the extra
check at the end.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ff_init_vlc_sparse() supports arrays of uint8_t, uint16_t and uint32_t
as input (and it also supports padding/other elements in between the
elements). This makes the typical case in which the input is a simple
array more cumbersome. E.g. for an array of uint8_t one would either
need to call the function with arguments like "array, sizeof(array[0]),
sizeof(array[0])" or with "array, 1, 1". The former is nicer, but
longer, so that the latter is mostly used. Therefore this commit adds a
macro that expands to the sizeof() construct.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The Huffmann tables used by Smacker can consist of exactly one leaf only
in which case the length of the corresponding code is zero; there is
then exactly one value encoded. Our VLC can't handle this and therefore
this case needs to be treated separately; it has been implemented in
commit 48cbdaea15. Yet said commit also
made the decoder emit an error message (despite not erroring out) in this
case, although it seems that this is rather a limitation of our VLC API.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The AV1 decoder has the FF_CODEC_CAP_INIT_CLEANUP flag set and yet
the decoder's close function is called manually on some error paths.
This is unnecessary and has been removed in this commit.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the AV1 decoder always checks before calling its wrapper
around ff_thread_release_buffer() whether the ThreadFrame was used at
all, i.e. it checked whether the first data buffer of the AVFrame
contained therein is NULL or not. Yet this presumes that the AVFrame has
been successfully allocated, even though this can of course fail; and if
it did, one would encounter a segfault.
Fix this by removing the checks altogether: ff_thread_release_buffer()
can handle both unallocated as well as empty frames (since commit
f6774f905f).
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Before patch, memory was allocated in each thread functions,
which may cause more than one time of memory allocation and
cause crash.
After patch, memory is allocated in the main thread once,
an index was parsed into thread functions. Bug fixed.
Signed-off-by: Xu Jun <xujunzz@sjtu.edu.cn>
Freeing a buffer allocated in the VBLE decoder's init function
is the only thing the decoder's close function does and this implies
that it is unnecessary to call it in case said allocation fails. Yet
this is what has been done.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the SVQ3 decoder allocated several refcounted buffers,
despite no sharing/refcounting happening at all: Their refcount never
exceeds one and they are treated like ordinary buffers (with the
exception that the pointer used to access them is in the middle of the
allocated buffer, but this does not warrant using the AVBuffer API at
all). Given that using the AVBuffer API incurs overhead, it is no longer
used at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Commit b2361cfb94 made all of the
error paths in svq3_decode_init() call svq3_decode_end(); yet several
new error paths that were added later (in merges from Libav) returned
directly without cleaning up properly. This commit fixes the resulting
potential memleaks by setting the FF_CODEC_CAP_INIT_CLEANUP flag. This
also allows to simplify freeing by returning directly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The very first thing the SVQ3 decoder currently does is allocating several
SVQ3Frames, a structure which contains members that need to be freed on
their own. If one of these allocations fails, the decoder calls its own
close function to not leak the already allocated SVQ3Frames. Yet said
function presumes that the SVQ3Frames have been successfully allocated
as there is no check before freeing the members that need to be freed.
This commit fixes this by making these frames part of the SVQ3Context,
thereby avoiding the allocations altogether. Notice that the pointers
to the frames have been retained in order to allow to just swap them as
the code already does.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The Sonic decoder and encoders allocate several buffers in their init
function and return immediately if one of these allocations fails; this
will lead to leaks if there was an earlier successfull allocation. Fix
this by setting the FF_CODEC_CAP_INIT_CLEANUP flag.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If allocating a buffer in RoQ DPCM encoder's init function failed,
the close function would be called manually; all this function does is
freeing said buffer, but given that it has not been allocated at all,
this is unnecessary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Do this by only keeping the only function pointer from the
AVFloatDSPContext that is needed lateron. This also allows to remove the
decoders' close function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Do this by only keeping the only function pointer from the
AVFloatDSPContext that is needed lateron. This also allows to remove the
decoder's close function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The init function of the real_144 encoder calls its own close function
if a call to ff_lpc_init() fails; yet nothing has been allocated before
that point and ff_lpc_init() can be expected to clean up after itself on
error (the documentation does not say anything to the contrary and the
current implementation can only fail if the only allocation fails, so
there is nothing to clean up on error anyway), so this is unnecessary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The qtrle encoder allocates several buffers and an AVFrame in its init
function. If one of these allocations fails, but others succeed, the
successfully allocated objects leak. This is fixed by setting the
FF_CODEC_CAP_INIT_CLEANUP flag.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Now that ff_ffv1_close() is called upon failure for both the FFV1 encoder
and decoder, the code contained therein can be used to free the partially
allocated slice contexts if allocating the slice contexts failed. One just
has to set the correct number of slice contexts on error. This allows to
remove the code for freeing partially allocated slice contexts in
ff_ffv1_init_slice_contexts().
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The FFV1 encoder has so far not cleaned up after itself in this case;
but it can be done easily by setting the FF_CODEC_CAP_INIT_CLEANUP flag.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When allocating FFV1 slice contexts fails, ff_ffv1_init_slice_contexts()
frees everything that it has allocated, yet it does not reset the
counter for the number of allocated slice contexts. This inconsistent
state leads to segfaults lateron in ff_ffv1_close(), because said
function presumes that the slice contexts have been allocated.
Fix this by making sure that the number of slice contexts on error is
consistent (namely zero).
(This issue only affected the FFV1 decoder, because the encoder does not
clean up after itself on init failure.)
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Garbage was left-over in the ArgoASFFileHeader::name field if the url
was too short. This zero-initialises it.
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
The Musepack decoder uses static VLC tables to parse the bitstream.
There are 14 different quant tables VLCs and each of them has a varying
number of codes. The maximum number is 63, the average number is 25.3.
Up until now, the array containing the raw data was of type
uint16_t [7][2][64 * 2] (the 14 tables come in pairs of two, hence [7][2]
instead of [14]) and from this it follows that there were large gaps in
said array. This commit changes this by making it a continuous array
instead. Doing so saves about 2KB.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
For the VLC table arrays in mpc7_decode_init() this fixes
a regression introduced in 1e40dc920a.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Apparently bmdFormatUnspecified needs SDK 11.0. It is just a fancy way of
checking for zero, so let's do that instead.
Fixes build issue since f1b908d20a.
Signed-off-by: Marton Balint <cus@passwd.hu>
It can't if one hasn't made a mistake at calculating the sizes;
and this is checked by asserts/aborts.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The MobiClip decoder uses adjacent pixels for prediction; yet when
accessing the left pixel, it was forgotten to clip the x coordinate.
This results in an heap-buffer-overflow. It can e.g. be reproduced with
the sample from https://samples.ffmpeg.org/V-codecs/MOHD/crap.avi when
forcing the video decoder to mobiclip.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If an error happens during init after an allocation has succeeded,
the already allocated data leaked up until now. Fix this by setting the
FF_CODEC_CAP_INIT_CLEANUP flag.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ff_ivi_init_planes() might error out after having allocated some arrays.
Set the FF_CODEC_CAP_INIT_CLEANUP flag in order to free these arrays in
this case.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If allocating the tiles array for indeo 4/5 fails, the context is in an
inconsistent state, because the counter for the number of tiles is > 0.
This will lead to a segfault when freeing the tiles' substructures.
Fix this by setting the number of tiles to zero if the allocation was
unsuccessful.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If an error happens during init after an allocation has succeeded,
the already allocated data leaked up until now. Fix this by setting the
FF_CODEC_CAP_INIT_CLEANUP flag.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If an error happens during init after an allocation has succeeded,
the already allocated data leaked up until now. Fix this by setting the
FF_CODEC_CAP_INIT_CLEANUP flag.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If one of several allocations the gif encoder performs in its init
function fails, the successful allocations leak. Fix this by adding the
FF_CODEC_CAP_INIT_CLEANUP flag.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The dsicinvideo decoder already has the FF_CODEC_CAP_INIT_CLEANUP flag
set, so it is unnecessary to directly clean up some already allocated
buffers in case another one could not be allocated in the init function,
as all buffers will be freed anyway later in the decoder's close
function.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If ff_codec_open2_recursive() fails, the already allocated
AVCodecContext leaks. Fix this by setting the FF_CODEC_CAP_INIT_CLEANUP
flag.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Keeping only the latest packet fed to the decoder works only for decoders that
return a frame immediately after every consumed packet. Decoders that consume
several packets before they return a frame will fill said frame with properties
taken from the last consumed packet instead of the earliest.
Signed-off-by: James Almer <jamrial@gmail.com>
And replace the flags parameter with a function callback that can be used to
copy the contents of the packet (e.g, av_packet_ref and av_packet_copy_props).
Signed-off-by: James Almer <jamrial@gmail.com>
Also check that segment delta pts is always bigger than input pts.
There is nothing much currently that can be done to recover from
this situation so just return AVERROR_INVALIDDATA error code.
The CineForm HD encoder attempts to allocate several buffers in its init
function; yet if only some of these allocations succeed, the
successfully allocated buffers leak. This is fixed by setting the
FF_CODEC_CAP_INIT_CLEANUP flag.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Used in FMVs for FX Fighter and Croc. Supports BVID and BASF streams,
requests samples for anything else.
Due to the way BASF streams are contained in the file, only one is
supported. I have yet to see a BRP file with multiple.
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
SMPTE 12M timecode can only count frames up to 39, because the tens-of-frames
value is stored in 2 bit. In order to resolve this 50/60 fps SMPTE timecode is
using the field bit (which is the same bit as the phase correction bit) to
signal the least significant bit of a 50/60 fps timecode. See SMPTE ST
12-1:2014 section 12.1.
Therefore we slightly change the format of the return value of
av_timecode_get_smpte_from_framenum and AV_FRAME_DATA_S12M_TIMECODE and start
using the previously unused Phase Correction bit as Field bit. (As the SMPTE
standard suggests)
We add 50/60 fps support to av_timecode_get_smpte_from_framenum by calling the
recently added av_timecode_get_smpte function in it which already handles this
properly.
This change affects the decklink indev and the DV and MXF muxers. MXF has no
fate test for 50/60fps content, DV does, therefore the changes.
MediaInfo (a recent version) confirms that half-frame timecode must be inserted
to DV. MXFInspect confirms valid timecode insertion to the System Item of MXF
files. For MXF, also see EBU R122.
Note that for DV the field flag is not used because in the HDV specs (SMPTE
370M) it is still defined as biphase mark polarity correction flag. So it
should not matter that the DV muxer overrides the field bit.
Signed-off-by: Marton Balint <cus@passwd.hu>
Fill the array with the software pix_fmt and move the avctx->hwaccel
check back to the proper place.
Also remove the avoid probing flag to ensure an external av1 decoder
will not set a pix_fmt we don't want during format probing.
Signed-off-by: James Almer <jamrial@gmail.com>
Let the internal decoder take care of it, as frame reordering
may result in different values exported by either module.
Signed-off-by: James Almer <jamrial@gmail.com>
This AV1 decoder is currently only used for hardware accelerated decoding.
It can be extended into a native decoder in the future, so set its name to
"av1" and temporarily give it the lowest priority in the codec list.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: -2.4187e+09 is outside the range of representable values of type 'int'
Fixes: signed integer overflow: -14512205 + -2147483648 cannot be represented in type 'int'
Fixes: 20492/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPC7_fuzzer-5747263166480384
Fixes: 23528/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPC7_fuzzer-5747263166480384
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: index -1 out of bounds for type 'const uint8_t [6][16]'
Fixes: out of array read
Fixes: shift exponent -21 is negative
Fixes: 25422/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOBICLIP_fuzzer-5748258226569216
Fixes: shift exponent 8039082 is too large for 32-bit type 'int'
Fixes: 25430/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOBICLIP_fuzzer-5698567770210304
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>
show all input/output names when the input or output name not correct
Signed-off-by: Ting Fu <ting.fu@intel.com>
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
ff_formats_ref() takes a pointer to an AVFilterFormats and a pointer to
a pointer to an AVFilterFormats as arguments and adds the latter as an
owner to the list pointed to by the former; the latter is hereby always
the address of a list contained in an AVFilterFormatsConfig and can
therefore not be NULL. So remove the check for whether it is NULL; also
do the same for ff_channel_layouts_ref().
Also do the same for the unref functions where argument is never NULL
because it is always the address of an existing lvalue.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Before commit 2f76476549, avfilter.h
contained no typedef for AVFilterChannelLayouts; all references to it
were done using its struct tag. formats.h meanwhile contained the
definition of the struct and a typedef for it. Said commit now added a
typedef in avfilter.h, too, bringing it in line with AVFilterFormats;
yet this means that there are two typedefs for AVFilterChannelLayouts
(in contrast to AVFilterFormats which is only typedef'ed in avfilter.h).
The problem is that older versions of GCC don't like this and error out:
http://fate.ffmpeg.org/history.cgi?slot=x86_64-openbsd5.6-gcc4.2-conf2
is one of the FATE boxes that now fail to compile. So just remove the
typedef in formats.h.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
init_subtitles() sometimes returned directly upon error without cleaning
up after itself. The easiest way to trigger this is by using
picture-based subtitles; it is also possible to run into this in case of
missing decoders or allocation failures.
Furthermore, return the proper error code in case of missing decoder.
Reviewed-by: Nicolas George <george@nsup.org>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Happened on several error conditions, e.g. if there is just no decoder
for the format (like with svg images).
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Instead move the extradata contained in packet side-data to its
destination. This is possible because the side data already has zeroed
padding.
Notice that the check for FF_MAX_EXTRADATA_SIZE has been dropped,
because said constant is from libavcodec/internal.h. If libavcodec
wanted to enforce this, it should do so in the extract_extradata BSF
instead.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If a sequence header has already been found, it is certain that next
startcode (being disjoint from the sequence header startcode) can begin
at index four at the earliest.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
There are compiler and runtime check for MSA and MMI.
Remove the redundant setting of MSA and MMI for cores specified by "--cpu".
Signed-off-by: Shiyou Yin <yinshiyou-hf@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Test case fate-checkasm-h264pred failed in latest community code.
This patch fixed the bug.
Signed-off-by: Shiyou Yin <yinshiyou-hf@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If allocating the AVFrame to contain a decoded frame fails, the AVPacket
containing the data intended to be decoded leaks. This commit fixes
this.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The movie and amovie filters currently use two packets. One of the two,
pkt0, is the owner of the returned packet; it is also the destination
packet for av_read_frame(). The other one pkt is initially (i.e. after
av_read_frame()) a copy of pkt0; copy means that the contents of both
are absolutely the same: They both point to the same AVBufferRef and the
same side data. This violation of the refcounted packet API is only
possible because pkt is not considered to own its data. Only pkt0 is
ever unreferenced.
The reason for pkt's existence seems to be historic:
The API used for decoding audio (namely avcodec_decode_audio4()) could
consume frames partially, i.e. it could return multiple frames for one
packet and therefore it returned how much of the input buffer had been
consumed. The caller was then supposed to update the packet's data and
size pointer to reflect this and call avcodec_decode_audio4() again with
the updated packet to get the next frame.
But before the introduction of refcounted AVPackets where knowledge and
responsibility about what to free lies with the underlying AVBuffer such
a procedure required a spare packet (or one would need to record the
original data and size fields separately to restore them before freeing
the packet; notice that this code has been written when AVPackets still
had a destruct field). But these times are long gone, so just remove the
secondary AVPacket.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This code mostly duplicates code in the deinit function; the only
exception is av_opt_free(): The options are freed generically lateron.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
seg_init() and seg_write_header() currently contain a few error paths
in which an already opened AVIOContext for the child muxer leaks (namely
if there are unrecognized options for the child muxer or if writing the
header of the child muxer fails); the reason for this is that this
AVIOContext is not closed in the deinit function. If all goes well, it
is closed when writing the trailer. From this it also follows that the
AVIOContext also leaks when the trailer is never written, even when
writing the header succeeds.
But simply freeing said AVIOContext in the deinit function is
complicated by the fact that the AVIOContext may or may not have been
opened via the io_open callback: If options are set to discard header
and trailer, said AVIOContext can also be a null context which must not
be closed via the io_close callback. This may lead to crashes, as
io_close may presume the AVIOContext's opaque to be set. It currently
works with the default io_close callback which simply calls avio_close(),
because avio_close() doesn't care about opaque being NULL since commit
6e8e8431e1. Therefore this commit records
which of the two kinds of AVIOContext is currently in use to use the
right way to close it.
Finally there was one instance (namely if initializing the child muxer
fails with no unrecognized options) where the AVIOContext was always
closed via the io_close callback. The above remark applies to this; it
has been fixed, too.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
A string containing the segment's filename that the segment muxer
allocates got only freed in its write_trailer function. This implies
that it leaks if write_trailer is never called, e.g. if initializing
the child muxer fails. This commit fixes this by freeing the string
in the deinit function instead.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The segment muxer has an option to output a file containing a list of
the segments written. The AVIOContext used for writing this file is
opened via the main AVFormatContext's io_open callback; seg_free()
meanwhile unconditionally closes this AVIOContext by calling
ff_format_io_close() with the child muxer (the one for the actual output
format) as AVFormatContext.
The problem hereby is that the child AVFormatContext need not exist,
even when the AVIOContext does. This leads to a segfault in
ff_format_io_close() when the child muxer's io_close callback is called.
Situations in which the AVFormatContext can be NULL range from an
invalid reference stream parameter to an unavailable/bogus/unsupported
output format to inability to allocate the AVFormatContext.
The solution is to simply close the AVIOContext with the AVFormatContext
that was used to open it: The main AVFormatContext.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If the user has set none of the options specifying the segments'
durations, a default value of 2s is used by duplicating a "2" string and
using av_parse_time() on it. Yet duplicating the string was unchecked
and if the allocation failed, one would get a segfault in
av_parse_time().
This commit solves this by turning said option into an option of type
AV_OPT_TYPE_DURATION (which also uses av_parse_time() internally),
avoiding duplicating the string altogether.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The code to free them is not in the segment muxer's deinit function,
but in its write_trailer function which means that these lists leak if
write_trailer isn't called after their allocation. This happens e.g. if
the given lists are invalid (e.g. consisting only of ',' (which delimit
entries)), so that parsing them fails and so does the muxer's init
function; write_trailer is then never called.
This has been fixed by moving the code to free them to the deinit
function.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The segment muxer copies the user-provided AVCodecParameters to the
newly created child streams in its init function before initializing the
child muxer; and since commit 8e6478b723,
it does this again before calling avformat_write_header() if that is
called from seg_write_header(). The reason for this is complicated:
At that time writing the header was delayed, i.e. it was not triggered
by avformat_write_header() (unless the AVFMT_FLAG_AUTO_BSF was unset),
but instead by writing the very first packet. The rationale behind this
was to allow to run bitstream filters on the packets in the interleavement
queue in order to generate missing extradata from them before the muxer's
write_header function is actually called.
The segment muxer went even further: It initialized the child muxer and
ran the child muxer's check_bitstream functions on the packets in its
own muxing queue and stole any bitstream filters that got inserted. The
reason for this is that the segment muxer has an option to write the
header to a separate file and for this it is needed to write the child
muxer's header without delay, but with correct extradata. Unsetting
AVFMT_FLAG_AUTO_BSF for the child muxer accomplished the first goal and
stealing the bitstream filters the second; and in order for the child
muxer to actually use the updated extradata, the old AVCodecParameters
(set before avformat_init_output()) were overwritten with the new ones.
Updating the extradata proceeded as follows: The bitstream filter itself
simply updated the AVBSFContext's par_out when processing a packet, in
violation of the new BSF API (where par_out may only be set in the init
function); the muxing code then simply forwarded the updated extradata,
overwriting the par_in of the next BSF in the BSF chain with the fresh
par_out of the last one and the AVStream's par with the par_out of the
last BSF. This was an API violation, too, of course, but it made
remuxing ADTS AAC into mp4/matroska work.
But this no longer serves a useful purpose since the aac_adtstoasc BSF
was updated to propagate new extradata via packet side data in commit
f63c3516577d605e51cf16358cbdfa0bc97565d8; the next commit then removed
the code in mux.c passing new extradata along the filter chain. This
alone justifies removing the code for setting the AVCodecParameters a
second time.
But there is even another reason to do so: It is harmful. The ogg muxer
parses the extradata of Theora and Vorbis in its init function and keeps
pointers to parts of it. Said pointers become dangling when the
extradata is overwritten by the segment muxer, leading to
use-after-frees as has happened in ticket #8881 which this commit fixes.
Ticket #8517 is about another issue caused by this: Immediately after
having overwritten the old AVCodecParameters the segment muxer checks
whether the codec_tag is ok (the codec_tag is set generically when
initializing the child muxer based upon muxer-specific lists). The check
used is: If the child output format has such a list and if the codec tag
of the non-child stream does not match the codec id given the list of
codec tags and if there is a match for the codec id in the codec tag
list, then set the codec tag to zero (and not to the existing match),
otherwise set the codec tag of the child stream to the codec tag
of the corresponding stream of the main AVFormatContext (which is btw
redundant given that the child AVCodecParameters have just been
overwritten with the AVCodecParameters of the corresponding stream of
the main AVFormatContext).
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
buffer_length is a power-of-two and modulo is buffer_length - 1, so that
buffer_length & modulo is zero.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Also unify incrementing the variable containing the pointer
to the currently used HRIR data.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The headphone filter uses an array with as many elements as the
filter has inputs to store some per-input information; yet actually it
only stores information for all inputs except the very first one (which
is special for this filter). Therefore this commit modifies the code to
remove this unused element.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Despite the headphone filter only using one AVFrame at a time, it kept
an array each of whose entries contained a pointer to an AVFrame at all
times; the pointers were mostly NULL. This commit instead replaces them
by using a single pointer to an AVFrame on the stack of the only
function that actually uses them.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The headphone filter allocates a pair of buffers to be used as
intermediate buffers lateron: Before every use they are zeroed, then
some elements of the buffer are set and lateron the complete buffers are
copied into another, bigger buffer. These intermediate buffers are
unnecessary as the data can be directly written into the bigger buffer.
Furthermore, the whole buffer has been zeroed initially and because no
piece of this buffer is set twice (due to the fact that duplicate
channel map entries are skipped), it is unnecessary to rezero the part
of the big buffer that is about to be written to.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Before this commit, the headphone filter called
av_channel_layout_extract_channel() in a loop in order to find out
the index of a channel (given via its AV_CH_* value) in a channel layout.
This commit changes this to av_get_channel_layout_channel_index()
instead.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The documentation of the map argument of the headphone filter states:
"Set mapping of input streams for convolution. The argument is a
’|’-separated list of channel names in order as they are given as
additional stream inputs for filter."
Yet this has not been honoured at all. Instead for the kth given HRIR
channel pair it was checked whether there was a kth mapping and if the
channel position so given was present in the channel layout of the main
input; if so, then the given HRIR channel pair was matched to the kth
channel of the main input. It should actually have been matched to the
channel given by the kth mapping. A consequence of the current algorithm
is that if N additional HRIR channel pairs are given, a permutation of
the first N entries of the mapping does not affect the output at all.
The old code might even set arrays belonging to streams that don't exist
(i.e. whose index is >= the number of channels of the main input
stream); these parts were not read lateron at all. The new code doesn't
do this any longer and therefore the number of elements of some of the
allocated arrays has been reduced (in case the number of mappings was
bigger than the number of channels of the first input stream).
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When the headphone filter is configured to perform its processing in the
frequency domain, it allocates (among other things) two pairs of
buffers, all of the same size. One pair is used to store data in it
during the initialization of the filter; the other pair is only
allocated lateron. It is zero-initialized and yet its data is
immediately overwritten by the content of the other pair of buffers
mentioned above; the latter pair is then freed.
This commit eliminates the pair of intermediate buffers.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The headphone filter has two modes; in one of them (say A), it needs
certain buffers to store data. But it allocated them in both modes.
Furthermore when in mode A it also allocated intermediate buffers of the
same size, initialized them, copied their contents into the permanent
buffers and freed them.
This commit changes this: The permanent buffer is only allocated when
needed; the temporary buffer has been completely avoided.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The delay arrays were never properly initialized, only zero-initialized;
furthermore these arrays duplicate fields in the headphone_inputs
struct. So remove them.
(Btw: The allocations for them have not been checked.)
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The string given by an AVOption that contains the channel assignment
is used only once; ergo it doesn't matter that parsing the string via
av_strtok() is destructive. There is no need to make a copy.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When parsing the channel mapping string (a string containing '|'
delimited tokens each of which is supposed to contain a channel name
like "FR"), the old code would at each step read up to seven uppercase
characters from the input string and give this to
av_get_channel_layout() to parse. The returned layout is then checked
for being a layout with a single channel set by computing its logarithm.
Besides being overtly complicated this also has the drawback of relying
on the assumption that every channel name consists of at most seven
uppercase letters only; but said assumption is wrong: The abbreviation
of the second low frequency channel is LFE2. Furthermore it treats
garbage like "FRfoo" as valid channel.
This commit changes this by using av_get_channel_layout() directly;
furthermore, av_get_channel_layout_nb_channels() (which uses popcount)
is used to find out the number of channels instead of the custom code
to calculate the logarithm.
(As a consequence, certain other formats to specify the channel layouts
are now accepted (like the hex versions of av_get_channel_layout()); but
this is actually not bad at all.)
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The headphone filter has an option for the user to specify an assignment
of inputs to channels (or from pairs of channels of the second input to
channels). Up until now, these channels were stored in an int containing
the logarithm of the channel layout. Yet it is not the logarithm that is
used lateron and so a retransformation was necessary. Therefore this
commit simply stores the uint64_t as is, avoiding the retransformation.
This also has the advantage that unset channels (whose corresponding
entry is zero) can't be mistaken for valid channels any more; the old
code had to initialize the channels to -1 to solve this problem and had
to check for whether a channel is set before the retransformation
(because 1 << -1 is UB).
The only downside of this approach is that the size of the context
increases (by 256 bytes); but this is not exceedingly much.
Finally, the array has been moved to the end of the context; it is only
used a few times during the initialization process and moving it
decreased the offsets of lots of other entries, reducing codesize.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The headphone filter does most of its initialization after its init
function, because it can perform certain tasks only after all but its
first input streams have reached eof. When this happens, it allocates
certain buffers and errors out if an allocation fails.
Yet the filter didn't check whether some of these buffers already exist
(which may happen if an earlier attempt has been interrupted in the
middle (due to an allocation error)) in which case the old buffers leak.
This commit makes sure that initializing the buffers is only attempted
once; if not successfull at the first attempt, future calls to the
filter will error out. Trying to support resuming initialization doesn't
seem worthwhile.
Notice that some allocations were freed before a new allocation was
performed; yet this effort was incomplete. Said code has been removed.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The headphone filter stores the channel position of the ith HRIR stream
in the ith element of an array of 64 elements; but because there is no
check for duplicate channels, it is easy to write beyond the end of the
array by simply repeating channels.
This commit adds a check for duplicate channels to rule this out.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When the headphone filter does its processing in the time domain,
the lengths of the buffers involved are determined by three parameters,
only two of which are relevant here: ir_len and air_len. The former is
the length (in samples) of the longest HRIR input stream and the latter
is the smallest power-of-two bigger than ir_len.
Using optimized functions to calculate the convolution places
restrictions on the alignment of the length of the vectors whose scalar
product is calculated. Therefore said length, namely ir_len, is aligned
on 32; but the number of elements of the buffers used is given by air_len
and for ir_len < 16 a buffer overflow happens.
This commit fixes this by ensuring that air_len is always >= 32 if
processing happens in the time domain.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Not providing any samples makes no sense at all. And if no samples
were provided for one of the HRIR streams, one would either run into
an av_assert1 in ff_inlink_consume_samples() or into a segfault in
take_samples() in avfilter.c.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This buffer was supposed to be initialized by sscanf(input, "%7[A-Z]%n",
buf, &len), yet if the first input character is not in the A-Z range,
buf is not touched (in particular it needn't be zero-terminated if the
failure happened when parsing the first channel and it still contains
the last channel name if the failure happened when one channel name
could be successfully parsed). This is treated as error in which case
buf is used directly in the log message. This commit fixes this by
actually using the string that could not be matched in the log message
instead.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Use pthread to multithread dnn_execute_layer_conv2d.
Can be tested with command "./ffmpeg_g -i input.png -vf \
format=yuvj420p,dnn_processing=dnn_backend=native:model= \
espcn.model:input=x:output=y:options=conv2d_threads=23 \
-y sr_native.jpg -benchmark"
before patch: utime=11.238s stime=0.005s rtime=11.248s
after patch: utime=20.817s stime=0.047s rtime=1.051s
on my 3900X 12c24t @4.2GHz
About the increase of utime, it's because that CPU HyperThreading
technology makes logical cores twice of physical cores while cpu's
counting performance improves less than double. And utime sums
all cpu's logical cores' runtime. As a result, using threads num
near cpu's logical core's number will double utime, while reduce
rtime less than half for HyperThreading CPUs.
Signed-off-by: Xu Jun <xujunzz@sjtu.edu.cn>
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
This reverts commit abc884bcc0.
This patch was pushed without actual review.
An actual review would have revealed that the switch to activate
was not done correctly because the logic between request_frame()
and frame_wanted is not as direct with filters with multiple
outputs than with a single output.
Allow to set the EOF timestamp.
Also: doc/filters/testsrc*: specify the rounding of the duration option.
The changes in the ref files are right.
For filter-fps-down, the graph is testsrc2=r=7:d=3.5,fps=3.
3.5=24.5/7, so the EOF of testsrc2 will have PTS 25/7.
25/7=(10+5/7)/3, so the EOF PTS for fps should be 11/7,
and the output should contain a frame at PTS 10.
For filter-fps-up, the graph is testsrc2=r=3:d=2,fps=7,
for filter-fps-up-round-down and filter-fps-up-round-up
it is the same with explicit rounding options.
But there is no rounding: testsrc2 produces exactly 6 frames
and 2 seconds, fps converts it into exactly 14 frames.
The tests should probably be adjusted to restore them to
a useful coverage.
ff_set_common_formats() is currently only called after
graph_check_validity(), guaranteeing that inputs and outputs
are connected.
If we want to support configuring partially-connected graphs,
we will have a lot of redesign to do anyway.
Fix CID 1466262 / 1466263.
Explicitly insert the scale or aresample filter where it would
have been inserted by the negotiation.
Re-enable conversions if it cannot be done easily.
If a conversion is needed in a test, we want to know about it.
If the negotiation changes and makes new conversion necessary,
we want to know about it even more.
The channel_layouts and channel_counts options set what buffersink
is supposed to accept. If channel_counts contains 2, then stereo is
already accepted, there is no point in having it in channel_layouts
too. This was not properly documented until now, so only print a
warning.
Part of the code expects valid lists, in particular no duplicates.
These tests allow to catch bugs in filters (unlikely but possible)
and to give a clear message when the error comes from the user
((a)formats) or the application (buffersink).
If we decide to switch to a more efficient merging algorithm,
possibly sorting the lists, these functions will be the preferred
place for pre-processing, and can be renamed accordingly.
It will allow to refernce it as a whole without clunky macros.
Most of the changes have been automatically made with sed:
sed -i '
s/-> *in_formats/->incfg.formats/g;
s/-> *out_formats/->outcfg.formats/g;
s/-> *in_channel_layouts/->incfg.channel_layouts/g;
s/-> *out_channel_layouts/->outcfg.channel_layouts/g;
s/-> *in_samplerates/->incfg.samplerates/g;
s/-> *out_samplerates/->outcfg.samplerates/g;
' src/libavfilter/*(.)
The latest builds of glslang introduce new libraries that need to be
linked for all symbols to be fully resolved.
This change will break building against older installations of glslang
and it's very hard to tell them apart as the library change upstream
was not accompanied by any version bump and no official release has
been made with this change it - just lots of people packaging up git
snapshots. So, apologies in advance.
Version 1.1 (FX Fighter) files all have a sample rate of 44100
in the header, but only play back correctly at 22050.
Force the sample rate to 22050 when reading, and restrict it
when muxing.
Since bae8844e35, the AVPacket that is
intended to be used to return the demuxed packet is automatically
unreferenced when the demuxer returns an error. This makes an
av_packet_unref() in the lavfi demuxer redundant.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Although the ICC specifications say to check for this, libtiff doesn't
and neither does any other TIFF implementation, and the TIFF specs
say that Photoshop has a different way to encapsulate ICC profiles,
and are asking for advice on how to deal with it.
So basically, photoshop puts a different type than what's specified,
no other implementation checks for this, we do because we tried to
follow the specs although its harmless to not, and ran into this bug
because we didn't know about it.
Fixes: signed integer overflow: 998938090 + 1169275991 cannot be represented in type 'int'
Fixes: 23411/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP9_fuzzer-4644692330545152
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: 7958120835074169528 * 9 cannot be represented in type 'long long'
Fixes: 23382/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6230683226996736
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If encoding fails, the AVPacket that ought to contain the encoded packet
is already unreferenced generically.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Currently the utilized AVBPrint API is internally limited to unsigned
integers, so if we limit the file size as well as the amount to read
to UINT_MAX - 1, we do not require additional limiting to be performed
on the values.
This change is based on the fact that initially the 8*1024 value added
in 96d70694ae was only for the case where
the file size was not known. It was not a maximum file size limit.
In 2912118898 this was reworked to be
a maximum manifest file size limit, while its commit message appears
to only note that it added support for larger manifest file sizes.
This should enable various unfortunately large MPEG-DASH manifests,
such as Youtube's multi-megabyte live stream archives to load up
as well as bring back the original intent of the logic.
The array in question can not be too large (only 26 elements), so it can
simply be put on the context.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The init function first allocates an AVFrame and then some buffers; if
one of the buffers couldn't be allocated, the AVFrame leaks. Solve this
by setting the FF_CODEC_CAP_INIT_CLEANUP flag.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
YUV4MPEG writes a string as header for both the file itself as well as
for every frame; these strings contain magic strings and these were up
until now included in the string to write via %s. Yet they are compile
time constants, so one can use the compile-time string concatentation
instead of inserting these strings at runtime.
Furthermore, the global header has been written via snprintf() to
a local buffer first before writing it. This can be simplified by using
avio_printf().
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This also changes a check for mfra_size from < 0 to == 0, since
it was always wrong, as avio_rb32 returns an unsigned integer.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
On files with more than one sidx box, like live fragmented MP4
files, it was previously re-reading and seeking on every singl
sidx box, leading to extremely poor performance on larger files,
especially over the network.
Only do it on the first one, and stash its result.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
It should be a 64-bit integer, otherwise it overflows and fails
on files greater than 2GB on some systems like x86_64 Linux.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Expressions for option fontsize of video filter drawtext have been
supported since commit 6442e4ab3c.
Signed-off-by: Andrei Rybak <rybak.a.v@gmail.com>
Revised-by: Gyan Doshi <ffmpeg@gyani.pro>
They are not explicitly in the bitstream in this case, but it is helpful
to be able to use these values without always needing to check the flag
beforehand.
Since c6a63e1109, the parameter sets
modified as content of PPS units were references shared with the
CodedBitstreamH264Context, so modifying them alters the parsing process
of future access units which meant that frames often got discarded
because invalid values were parsed. This patch makes h264_redundant_pps
compatible with the reality of reference-counted parameter sets.
Fixes#7807.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
Use the unit type table to determine what we need to do to clone the
internals of the unit content when making copies for refcounting or
writeability. (This will still fail for units with complex content
if they do not have a defined clone function.)
Setup and naming from a patch by Andreas Rheinhardt
<andreas.rheinhardt@gmail.com>, but with the implementation changed
to use the unit type information if possible rather than requiring a
codec-specific function.
Unit types are split into three categories, depending on how their
content is managed:
* POD structure - these require no special treatment.
* Structure containing references to refcounted buffers - these can use
a common free function when the offsets of all the internal references
are known.
* More complex structures - these still require ad-hoc treatment.
For each codec we can then maintain a table of descriptors for each set of
equivalent unit types, defining the mechanism needed to allocate/free that
unit content. This is not required to be used immediately - a new alloc
function supports this, but does not replace the old one which works without
referring to these tables.
Fixes memleaks with some encoders that don't unref the packet before
returning.
This is consistent with the behavior of AVCodec.encode()
implementations in encode_simple_internal().
Found-by: mkver
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: James Almer <jamrial@gmail.com>
The lengths of the VLC codes are implicitly contained in the VLC tables
itself; apart from that they are not used lateron. So it is unnecessary
to store them and the very same array can be reused to parse the Huffman
table for the next plane.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The code already checks that exactly the expected amount of entries are
read and set. Ergo it is unnecessary to zero them at the beginning.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, there were three comparison functions depending upon
bitness. But they all are actually the same, namely a lexical ordering:
entry a > entry b iff a.len > b.len or a.len == b.len and a.sym < b.sym.
So they can be easily unified.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When parsing Huffman tables, an array of HuffEntries (a struct
containing a code's bitlength, its bits and its symbol) is used as
intermediate tables in order to sort the entries (the order depends on
both the length of the entries as well as on their symbols). After sorting
them, the symbol and len components are copied into other arrays (the
HuffEntries' code has never been set or used, despite using quite a lot
of stack space) and the codes are generated. Afterwards, the VLC is
created.
Yet ff_init_vlc_sparse() can handle non-continuous arrays as input;
there is no need to copy the entries at all. This commit implements
this.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When the MagicYUV decoder builds Huffman tables from an array of code
lengths, it proceeds as follows: First it copies the entries of the
array of lengths into an array of HuffEntries (a struct which contains
a length and a symbol field); it also sets the symbol field in
descending order from nb_elem - 1 to 0, where nb_elem is the common number
of elements of the length and HuffEntry arrays. Then the HuffEntry array
is sorted lexicographically: a > b iff a.len > b.len or a.len == b.len and
a.sym > b.sym. Afterwards the symbols of the so sorted array are
inverted again (i.e. each symbol sym is replaced by nb_elem - sym).
Yet inverting can easily be avoided altogether: Just modify the order so
that smaller symbols correspond to bigger HuffEntries. This leads to the
same permutation as the current code does and given that the two
inversions just cancel each other out, the result is the same.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
av_new_packet() already sets the size. And if the packet is not
allocated by av_new_packet() (which seems to be impossible atm), both
pkt->size as well as size are 0, so setting it again is unnecessary in
this scenario, too.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The comment referred to the INIT_VLC_USE_STATIC flag which has been
removed in 2009 in 595324e143b57a52e2329eb47b84395c70f93087; the
function it referred to was removed even earlier in commit
83422c1940 in 2008.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
In ticket #8754 there is discourse surrounding the error
message which is printed upon a mismatched aspect ratio in
derived encodings. This should make it clearer to the user
as to the issues which they are experiencing.
Reviewed-by: "Jeyapal, Karthick" <kjeyapal@akamai.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The V4L2 driver does not actually have an associated DRM device at all, so
users work around the requirement by giving libva an unrelated display-only
device instead (which is fine, because it doesn't actually do anything with
that device). This was broken by bc9b6358fb
forcing a render node, because the display-only device did not have an
associated render node to use. Fix that by just passing through the
original non-render DRM fd if we can't find a render node.
Reported-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Tested-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
This avoids keeping potentially dangling pointers in the context,
beautifies the code (by replacing "&ri->gb" by gb for every access to
the GetByteContext) and also highlights the GetByteContext's short-lived
nature better.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The implementation of the tag tree did not
set the correct reset value for the encoder.
This lead to inefficent tag tree being encoded.
This patch fixes the implementation of the
ff_tag_tree_zero() function.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This patch allows setting a compression ratio and to
set multiple layers. The user has to input a compression
ratio for each layer.
The per layer compression ration can be set as follows:
-layer_rates "r1,r2,...rn"
for to create 'n' layers.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The implementation of tag tree encoding was incorrect.
However, this error was not visible as the current j2k
encoder encodes only 1 layer.
This patch fixes tag tree coding for JPEG2000 such tag
tree coding would work for multi layer encoding.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This patch makes the tag_tree_zero() and tag_tree_size()
functions non static and callable from other files.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes issue reported by: Xu Guangxin <guangxin.xu@intel.com>
Original report:
Steps to reproduce:
1. ./configure --enable-debug=3 --disable-libx264 && make install
2. ffmpeg -i input.mp4 -profile:v baseline output.mp4 -y
you will see a crash like this:
[mpeg4 @ 0x5555575854c0] [Eval @ 0x7fffffffbf80] Undefined constant or missing '(' in 'baseline'
[mpeg4 @ 0x5555575854c0] Unable to parse option value "baseline"
[mpeg4 @ 0x5555575854c0] Error setting option profile to value baseline.
Thread 1 "ffmpeg" received signal SIGSEGV, Segmentation fault.
root cause:
If the codec has FF_CODEC_CAP_INIT_CLEANUP flag, and avcodec_open2 got an error before avctx->codec->init,
the ff_mpv_encode_end will face a null s->avctx.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The Winnov WNV1 format is designed for a little-endian bitstream reader;
yet our decoder reversed every byte bitwise (in a buffer only
allocated for this purpose) to use a big-endian bitstream reader. This
commit stops this.
Two things needed to be done to achieve this: The codes in the table used
to initialize a VLC reader needed to be reversed bitwise (when
initializing a VLC in LE mode, it is expected that the first bit to be
read is in the least significant bit; with BE codes the first bit to be
read is the most significant bit of the code) and the following
expression needed to be adapted:
ff_reverse[get_bits(&w->gb, 8 - w->shift)]
But this is easy: When only the bits read are reversed, they coincide
with what a little-endian bitstream reader reads that reads the
original, not-reversed data. But ff_reverse always reverses the full
eight bits and this also performs a shift by (8 - (8 - w->shift)) on top
of reversing the bits read. So the above line needs to be changed to
get_bits(&w->gb, 8 - w->shift) << w->shift
and this also shows why the variable shift is named the way it is.
Finally, this also fixes a hypothetical memleak: For gigantic packets,
initializing a GetBitContext can fail and in this case, the buffer
containing the reversed data would leak.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
TrueMotion 2.0 uses Huffmann trees. To parse them, the decoder allocates
arrays for the codes, their lengths and their value; afterwards a VLC
table is initialized using these values. If everything up to this point
succeeds, a new buffer of the same size as the already allocated arrays
for the values is allocated and upon success the values are copied into
the new array; all the old arrays are then freed. Yet if allocating the
new array fails, the old arrays get freed, but the VLC table doesn't.
This leak is fixed by not allocating a new array at all; instead the old
array is simply reused, ensuring that nothing can fail after the
creation of the VLC table.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
MXF CDCI color range was being set to (1<<sc->component_depth) - 1
for full range but it should be (1<<sc->component_depth) as 0 is
a valid value.
Signed-off-by: Harry Mallon <harry.mallon@codex.online>
if taken from stack, they may have garbage in the upper bits otherwise.
Also, there are only 8 arguments, so don't attempt to load 11.
Fixes SIGSEV crashes in some targets.
Reviewed-by: durandal_1707
Signed-off-by: James Almer <jamrial@gmail.com>
A few popular sites have started generating MP4 files which have a
sidx plus an mfra. The sidx accounts for all size except the mfra,
so the old code did not mark the fragment index as complete.
Instead we can just check if there's an mfra and if its size makes
up the difference we can mark the index as complete.
Bug: https://crbug.com/1107130
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
In case the multichannel HRIR mode was enabled, an error could happen
between allocating a channel layouts list and attaching it to its target
destination. If an error happened, the list would leak. This is fixed by
attaching the list to its target directly after its allocation.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The headphone filter uses a variable number of inpads and allocates them
in its init function; if all goes well, the number of inpads coincides
with a number stored in the filter's private context. Yet if allocating a
subsequent inpad fails, the uninit function nevertheless uses the number
stored in the private context to determine the number of inpads to free
and not the AVFilterContext's nb_inputs. This will lead to an access
beyond the end of the allocated AVFilterContext.input_pads array and
an invalid free.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The signature filter uses qsort, but its compare function doesn't have
the signature required of such a function; therefore it casts the
function pointer to void. Yet this is wrong:
C90 only guarantees that one can convert a pointer to any incomplete
type or object type to void* and back with the result comparing equal
to the original which makes pointers to void generic pointers to
incomplete or object type. Yet C90 lacks a generic function pointer
type.
C99 additionally guarantees that a pointer to a function of one type may
be converted to a pointer to a function of another type with the result
and the original comparing equal when converting back.
This makes any function pointer type a generic function pointer type.
Yet even this does not make pointers to void generic function pointers.
Both GCC and Clang emit warnings for this when in pedantic mode.
This commit fixes this by modifying the compare function to comply with
the expected signature.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If an error happens between allocating a string intended to be used as
an inpad's name and attaching it to its input pad, the string leaks.
Fix this by inserting the inpad directly after allocating its string.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If the names are always the same, they need not be duplicated; doing so
saves allocations, checks for the allocations as well as frees.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The aiir filter adds output pads in its init function. Each of these
output pads had a name which was allocated and to be freed in the uninit
function. Given that the aiir filter has between one and two outputs,
one output pad's name was freed unconditionally and a second was freed
conditionally.
Yet if adding output pads fails, there are no output pads at all and
trying to free a nonexistent pad's name will lead to a segfault.
Furthermore, if the name could be successfully allocated, yet adding the
new pad fails, the name would leak.
This commit fixes this by not allocating the pads' names at all any
more: They are constant anyway. This allows to remove the code to free
them and hence fixes the aforementioned bugs.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
These names are always the same, so not using duplicates saves
allocations, checks for the allocations as well as frees.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
These names are always the same, so not using duplicates saves
allocations, checks for the allocations as well as frees.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
These names are mostly the same, so not using duplicates saves
allocations, checks for the allocations as well as frees.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
These names are always the same, so not using duplicates saves
allocations, checks for the allocations as well as frees.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
These names are always the same, so not using duplicates saves
allocations, checks for the allocations as well as frees.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
These names leak because freeing them in the uninit function has been
forgotten. Instead of adding the freeing code, this commit stops
allocating these names. They are constants anyway.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
These names are always the same, so not using duplicates saves
allocations, checks for the allocations as well as frees.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It has been forgotten to free the name of the second outpad if attaching
the first one to the AVFilterContext fails. Fixing this is easy: Only
prepare the second outpad after (and if) the first outpad has been
successfully attached to the AVFilterContext.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
"The entries in an IFD must be sorted in ascending order by Tag. Note that this is
not the order in which the fields are described in this document."
This way various dimensions, sample and bit sizes cannot be changed at
arbitrary times which reduces the potential for bugs.
The tag reading code also on various places assumes that numerically previous
tags have already been parsed, so this needs to be enforced one way or another.
If this commit causes problems with real world files which are not easy to fix
then some other form of checks are needed to ensure the various dependencies
in the tag reading are not violated.
Fixes: out of array access
Fixes: 24825/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-6326925027704832
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Some DVB and ATSC captures are using the official MPEG2 registration
descriptor in addition to using the correct stream type and the
AC-3_audio_stream_descriptor/AC3_descriptor. So let's add it even if it is not
strictly needed for DVB/ATSC.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
The amerge filter uses a variable number of inpads and allocates them
in its init function; if all goes well, the number of inpads coincides
with a number stored in the filter's private context. Yet if allocating a
subsequent inpad fails, the uninit function nevertheless uses the number
stored in the private context to determine the number of inpads to free
and not the AVFilterContext's nb_inputs. This will lead to an access
beyond the end of the allocated AVFilterContext.input_pads array and
an invalid free.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Section 5.9.7 of the spec states
UpscaledWidth = RefUpscaledWidth[ ref_frame_idx[ i ] ]
FrameWidth = UpscaledWidth
FrameHeight = RefFrameHeight[ ref_frame_idx[ i ] ]
RenderWidth = RefRenderWidth[ ref_frame_idx[ i ] ]
RenderHeight = RefRenderHeight[ ref_frame_idx[ i ] ]
Meaning FrameWidth must not be set to RefFrameWidth[ ref_frame_idx[ i ] ]
like we're currently doing.
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Implement Section 7.21 "Reference frame loading process" and Section 7.20
"Reference frame update process" for show_existing_frame frames, as required by
the definition in Section 7.4 "Decode frame wrapup process".
Signed-off-by: James Almer <jamrial@gmail.com>
Unify all error return as DNN_ERROR, in order to cease model executing
when return error in ff_dnn_execute_model_native layer_func.pf_exec
Signed-off-by: Ting Fu <ting.fu@intel.com>
currently, output is set both at DNNModel.set_input_output and
DNNModule.execute_model, it makes sense that the output name is
provided at model inference time so all the output info is set
at a single place.
and so DNNModel.set_input_output is renamed to DNNModel.set_input
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Validates the set channel layout as well as verifies that the received
layout to the function matches the reference layout, so that it matches
the implemented re-ordering logic.
Fixes#8845
It help initialize chroma format and other info properly
Chroma format wasn't correct if I use below code:
avformat_find_stream_info(fmtc, NULL);
iVideoStream = av_find_best_stream(fmtc, AVMEDIA_TYPE_VIDEO, -1, -1, NULL, 0);
eChromaFormat = (AVPixelFormat)fmtc->streams[iVideoStream]->codecpar->format;
Signed-off-by: James Almer <jamrial@gmail.com>
This makes them available for all frames within a Temporal Unit.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes memleaks in case init fails (e.g. because of invalid parameters
like 'aformat=sample_fmts=s16:cl=wtf') or also if query_formats is never
called.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ff_add_format() and ff_add_channel_layout() already unref the list upon
error.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If adding the list of input formats to its AVFilterLink fails, the list
of output formats (which has not been attached to permanent storage yet)
leaks. This has been fixed by not creating the lists of in- and output
formats simultaneously. Instead creating said lists is relegated to
ff_formats_pixdesc_filter() (this also avoids the reallocations implicit
in using ff_add_format()) and the second list is only created after (and
if) the first list has been permanently attached to its AVFilterLink.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The formats API deals with lists of channel layouts, sample rates,
pixel formats and sample formats. These lists are refcounted in a way in
which the list structure itself contains pointers to all of its owners.
Furthermore, it is possible for a list to be not owned by anyone yet;
this status is temporary until the list has been attached to an owner.
Adding an owner to a list involves reallocating the list's list of
owners and can therefore fail.
In order to reduce the amount of checks and cleanup code for the users
of this API, the API is supposed to be lenient when faced with input
lists that are NULL and it is supposed to clean up if adding an owner
to a list fails, so that a simple use case like
list = ff_make_format_list(foo_fmts);
if ((ret = ff_formats_ref(list, &ctx->inputs[0]->out_formats)) < 0)
return ret;
needn't check whether list could be successfully allocated
(ff_formats_ref() return AVERROR(ENOMEM) if it couldn't) and it also
needn't free list if ff_formats_ref() couldn't add an owner for it.
But the cleaning up after itself was broken. The root cause was that
the refcount was decremented during unreferencing whether or not the
element to be unreferenced was actually an owner of the list or not.
This means that if the above sample code is continued by
if ((ret = ff_formats_ref(list, &ctx->inputs[1]->out_formats)) < 0)
return ret;
and that if an error happens at the second ff_formats_ref() call, the
automatic cleaning of list will decrement the refcount from 1 (the sole
owner of list at this moment is ctx->input[0]->out_formats) to 0 and so
the list will be freed; yet ctx->input[0]->out_formats still points to
the list and this will lead to a double free/use-after-free when
ctx->input[0] is freed later.
Presumably in order to work around such an issue, commit
93afb338a4 restricted unreferencing to
lists with owners. This does not solve the root cause (the above example
is not fixed by this) at all, but it solves some crashs.
This commit fixes the API: The list's refcount is only decremented if
an owner is removed from the list of owners and not if the
unref-function is called with a pointer that is not among the owners of
the list. Furtermore, the requirement for the list to have owners is
dropped.
This implies that if the first call to ff_formats_ref() in the above
example fails, the refcount which is initially zero during unreferencing
is not modified, so that the list will be freed automatically in said
call to ff_formats_ref() as every list whose refcount reaches zero is.
If on the other hand, the second call to ff_formats_ref() is the first
to fail, the refcount would stay at one during the automatic
unreferencing in ff_formats_ref(). The list would later be freed when
its last (and in this case sole) owner (namely
ctx->inputs[0]->out_formats) gets unreferenced.
The issues described here for ff_formats_ref() also affected the other
functions of this API. E.g. ff_add_format() failed to clean up after
itself if adding an entry to an already existing list failed (the case
of a freshly allocated list was handled specially and this commit also
removes said code). E.g. ff_all_formats() inherited the flaw.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The query_formats function of the channelmap filter tries to allocate
a list of channel layouts which on success are attached to more permanent
objects (an AVFilterLink) for storage afterwards. If attaching succeeds,
the link becomes one of the common owners (in this case, the only owner)
of the list. Yet if the list has been successfully attached to the link
and an error happens lateron, the list was manually freed, which is wrong,
because it is owned by its link so that the link's pointer to the list will
become dangling and there will be a double-free/use-after-free when the link
is later cleaned up automatically.
This commit fixes this by removing the custom freeing code; this will
temporarily add a leaking codepath (if attaching the list fails, the list
will leak), but this will be fixed soon by making sure that an
AVFilterChannelLayouts without owner will be automatically freed when
attaching it to an AVFilterLink fails.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The query_formats function of the alphamerge filter tries to allocate
two lists of formats which on success are attached to more permanent
objects (AVFilterLinks) for storage afterwards. If attaching a list
to an AVFilterLink succeeds, the link becomes one of the owners of
the list. Yet if attaching a list to one of its links succeeds and
an error happens lateron, both lists were manually freed, which is wrong
if the list is already owned by one or more links; these links' pointers
to their lists will become dangling and there will be a double-free/use-
after-free when these links are cleaned up automatically.
This commit fixes this by removing the custom freeing code; this will
temporarily add a leaking codepath (if attaching a list not already
owned by a link to a link fails, the list will leak), but this will
be fixed soon by making sure that an AVFilterFormats without owner will
be automatically freed when attaching it to an AVFilterLink fails.
At most one list leaks because as of this commit a new list is only
allocated after the old list has been successfully attached to a link.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The query_formats function of the overlay filter tries to allocate
two lists (only one in a special case) of formats which on success
are attached to more permanent objects (AVFilterLinks) for storage
afterwards. If attaching a list to an AVFilterLink succeeds, it is
in turn owned by the AVFilterLink (or more exactly, the AVFilterLink
becomes one of the common owners of the list). Yet if attaching a list
to one of its links succeeds and an error happens lateron, both lists
were manually freed, whic is wrong if the list is already owned by one
or more links; these links' pointers to their lists will become dangling
and there will be a double-free/use-after-free when these links are
cleaned up automatically.
This commit fixes this by removing the custom freeing code; this will
temporarily add a leaking codepath (if attaching a list not already
owned by a link to a link fails, the list will leak), but this will
be fixed soon by making sure that an AVFilterFormats without owner will
be automatically freed when attaching it to an AVFilterLink fails.
Notice that at most one list leaks because a new list is only allocated
after the old list has been successfully attached to a link.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The query_formats function of the remap filter tries to allocate
two lists of formats which on success are attached to more permanent objects
(AVFilterLinks) for storage afterwards. If attaching a list to an
AVFilterLink succeeds, it is in turn owned by the AVFilterLink (or more
exactly, the AVFilterLink becomes one of the common owners of the list).
Yet if attaching a list to one of its links succeeds and an error happens
lateron, both lists were manually freed, which means that is wrong if the
list is already owned by one or more links; these links' pointers to
their lists will become dangling and there will be a double-free/use-after-
free when these links are cleaned up automatically.
This commit fixes this by removing the custom free code; this will
temporarily add a leaking codepath (if attaching a list not already
owned by a link to a link fails, the list will leak), but this will
be fixed soon by making sure that an AVFilterFormats without owner will
be automatically freed when attaching it to an AVFilterLink fails.
Notice at most one list leaks because a new list is only allocated
after the old list has been successfully attached to a link.
Reviewed-by: Nicolas George <george@nsup.org>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The query_formats function of the showpalette filter tries to allocate
two lists of formats which on success are attached to more permanent objects
(AVFilterLinks) for storage afterwards. If attaching a list to an
AVFilterLink succeeds, the link becomes one (in this case the only one)
of the owners of the list. Yet if attaching the first list to its link
succeeds and attaching the second list fails, both lists were manually
freed, which means that the first link's pointer to the first list
becomes dangling and there will be a double-free when the first link is
cleaned up automatically.
This commit fixes this by removing the custom free code; this will
temporarily add a leaking codepath (if attaching a list to a link fails,
the list will leak), but this will be fixed shortly by making sure that
an AVFilterFormats without owner will be automatically freed when
attaching it to an AVFilterLink fails. Notice at most one list leaks
because as of this commit a new list is only allocated after the old list
has been successfully attached to a link.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The query_formats function of the amix filter tries to allocate a list
of channel layouts which are attached to more permanent objects
(an AVFilter's links) for storage afterwards on success. If attaching
a list to a link succeeds, the link becomes one of the common owners
of the list. Yet if a list has been successfully attached to links (or if
there were no links to attach it to in which case
ff_set_common_channel_layouts() already frees the list) and an error
happens lateron, the list was manually freed, which is wrong, because
the list has either already been freed or it is owned by its links in
which case these links' pointers to their list will become dangling and
there will be double-frees/uses-after-free when these links are cleaned
up automatically.
This commit fixes this by removing the custom freeing code; this is made
possible by using the list in ff_set_common_channel_layouts() directly
after its allocation (without anything that can fail in between).
Notice that ff_set_common_channel_layouts() is buggy itself which can
lead to double-frees on error. This is not fixed in this commit.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Replace using ff_add_format() repeatedly by a single call to
ff_make_format_list(). (Right now this also fixes a memleak: If the
first ff_add_format() succeeds and a subsequent call fails, the list
leaks.)
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The vpp_qsv's query_formats function allocated two AVFilterFormats,
before storing them permanently. If storing the first of them fails,
the function simply returns and the second leaks. This has been fixed by
only allocating the second AVFilterFormats structure after the first one
has been successfully stored.
Fixes Coverity issue #1422231.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The paletteuse's query_formats function allocated three AVFilterFormats
before storing them permanently. If allocating one of them failed, the
three AVFilterFormats structures would be freed with av_freep() which
does not free separately allocated subelements (namely the formats
array) which leak.
Furthermore, if storing one of the first two fails, the function simply
returns and the ones not yet stored leak.
These leaks have been fixed by only creating a new AVFilterFormats after
the last one has already been permanently stored. Furthermore, it is
enough to check whether the elements have been properly stored as
ff_formats_ref() by design returns AVERROR(ENOMEM) if it is provided a
NULL AVFilterFormats *.
Fixes Coverity issues #1270818 and #1270819.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Parsing labeled outputs involves a check for an already known match
(a labeled input with the same name) to pair them together. If yes,
it is attempted to create a link between the two filters; in this case
the AVFilterInOuts have fulfilled their purpose and are freed. Yet if
creating the link fails, these AVFilterInOuts have up until now not been
freed, although they had already been removed from their respective lists
(which means that they are not freed automatically). In other words:
They leak. This commit fixes this.
This fixes ticket #7084. Said ticket contains an example program to
reproduce a leak. It can also be reproduced with ffmpeg alone, e.g. with
the complex filters "[0]null[1],[2]anull[0]" or with "[0]abitscope[0]".
All of these three examples involve media type mismatches which make it
impossible to create the links. The bug could also be triggered by other
means, e.g. failure to allocate the necessary AVFilterLink.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The AVFilterInOuts normally get freed in init_output_filter() when
the corresponding streams get created; yet if an error happens before
one reaches said point, they leak. Therefore this commit makes
ffmpeg_cleanup free them, too.
Fixes ticket #8267.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
parse_filter() did not check the return value of av_get_token() for
success; in case name (the name of a filter) was NULL, one got a
segfault in av_strlcpy() (called from create_filter()).
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This happened in parse_link_name() if there was a '[' without matching
']'. While this is not undefined behaviour (pointer arithmetic one
beyond the end of an array works fine as long as there are no accesses),
it is potentially dangerous. It currently isn't (all callers of
parse_link_name() treat this as an error and don't access the string any
more), but making sure that this will never cause trouble in the future
seems nevertheless worthwhile.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
parse_inputs() uses a temporary linked list to parse the labeled inputs
of a filter; said linked list owns its elements (and their names). On
success, the list of unlabeled inputs is appened to the end of the list
of labeled inputs and the new list is returned; yet on failures, nothing
frees the already existing elements of the temporary linked list, leading
to a leak.
This can be triggered by e.g. using '-vf [v][' in the FFmpeg
command-line tool.
This leak seems to exist since 4e781c25b7.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Currently if the frame buffers are full, the frame is unrefed and
dropped. Instead buffer the frame so that it is enqueued in the
next v4l2_receive_packet() call. The behavior was observed on
DragonBoard 410c.
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Check the return value of sscanf as it can return -1(EOF), for example
when the first char in the line is 0x00
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ffmpeg documentation says the NUT container supports SubStation Alpha
This brings actual functionality in line with documentation.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The dvbsubtest_filter.ts sample is a filtered version of the Videolan
sample database (samples/sub/dvbsub/dvbsubtest.ts) using Project X. It
originates from ticket #8844.
The write_colr flag has been marked as experimental for over 5 years.
It should be safe to enable its behavior by default as follows:
- Write the colr atom by default for mp4/mov if any of the following:
- The primaries/trc/matrix are all specified, OR
- There is an ICC profile, OR
- The user specified +write_colr
- Keep the write_colr flag for situations where the user wants to
write the colr atom even if the color info is unspecified (e.g.,
http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259334.html)
This fixes https://trac.ffmpeg.org/ticket/7961
Signed-off-by: Michael Bradshaw <mjbshaw@google.com>
This commit removes ff_parse_sample_format(), ff_parse_time_base() and
ff_query_formats_all_layouts() from libavfilter/formats.c. All of these
functions were completely unused. ff_parse_time_base() has not been used
at all since it had been added in 3448404a707b6e236a2ffa7b0453b3300de41b7b;
the last caller of ff_parse_sample_format has been removed in commit
d1c49bcae9. And the one and only caller of
ff_query_formats_all_layouts() (the asyncts filter) has been removed in
commit a8fe8d6b4a.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ff_planar_sample_fmts_array is unused (and was unused since it was added
in 4d4098da00) and therefore this commit
removes it; ff_packed_sample_fmts_array meanwhile is used only once (in
the amerge filter) and therefore it has been moved to this place.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
dnn_execute_layer_avg_pool() contains the following line:
assert(avgpool_params->padding_method = VALID);
This statement contains an assignment where obviously a comparison was
intended. Furthermore, *avgpool_params is const, so that the attempted
assignment leads to a compilation failure if asserts are enabled
(i.e. if DEBUG is defined which leads libavutil/internal.h to not define
NDEBUG). Moreover, the enumeration constant VALID actually has the value 0,
so that the assert would be triggered if a compiler compiles this with
asserts enabled. Finally, the statement uses assert() directly instead
of av_assert*().
All these errors have been fixed.
Thanks to ubitux for providing a FATE-box [1] where DEBUG is defined.
[1]: http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-ddebug
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Guo, Yejun <yejun.guo@intel.com>
In a function body, a redundant ; is just a null statement that does
nothing. Yet outside a function body, a superfluous ';' like one that
exists if one adds a ';' immediately after a function body's closing
brace is actually invalid C that compilers happen to accept. Yet when
compiled in -pedantic mode, both GCC as well as Clang emit warnings for
this like "ISO C does not allow extra ‘;’ outside of a function
[-Wpedantic]".
The scenario described above existed in vf_overlay.c as a result of
macro expansion. This commit fixes it.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The functions were forgotten in 03c8fe49ea3f2a2444607e541dff15a1ccd7f0c2;
removing them also means that the avassert.h and samplefmt.h headers are
no longer used any more, so they have been removed, too.
Moreover, video.h is unused since b077d8d908
and channel_layout.h is since fdd9663781.
Both headers have therefore been removed, too.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The callers of the ff_merge_*() functions fall into two categories with
quite different needs:
One caller is can_merge_formats() which only wants to test for mergeability
without it merging anything. In order to do so, it duplicates the lists
it intends to test and resets their owners so that they are not modified
by ff_merge_*(). It also means that it needs to receive the merged list
(and not only an int containing whether the lists are mergeable) to
properly free it.
The other callers want the lists to be actually merged. But given the
fact that ff_merge_*() automatically updates the owners of the lists,
they only want the information whether the merge succeeded or not; they
don't want a link to the new list.
Therefore this commit splits these functions in two: ff_merge_*() for
the latter callers and ff_can_merge_*() for the former.
ff_merge_*() doesn't need to return a pointer to the combined list at all
and hence these functions have been modified to return an int, which
allows to distinguish between incompability and memory allocation failures.
ff_can_merge_*() meanwhile doesn't modify its arguments at all obviating
the need for copies. This in turn implies that there is no reason to
return a pointer to the new list, as nothing needs to be freed. These
functions therefore return an int as well. This allowed to completely
remove can_merge_formats() in avfiltergraph.c.
Notice that no ff_can_merge_channel_layouts() has been created, because
there is currently no caller for this. It could be added if needed.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Right now, ff_merge_samplerates() contains three instances of the
MERGE_REF() macro, a macro which reallocates an array, updates some
pointers in a loop and frees several buffers. This commit makes it
possible to contain only one instance of said macro in the function,
thereby reducing codesize.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
In listener mode the first fd is not closed when libsrt_close() is called
because it is overwritten by the new accept fd. Added the listen_fd to the
context to properly close it when libsrt_close() is called.
Fixes trac ticket #8372.
Signed-off-by: Nicolas Sugino <nsugino@3way.com.ar>
Signed-off-by: Marton Balint <cus@passwd.hu>
While reading the filename tag, it may return a EOF and we are still
copying the file with uninitialized value.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is the analogue of cfc6552032 for
formats and samplerates; in contrast to said commit, one can avoid
allocating a new array for formats as well (the complications of the
generic channel layouts made this impossible for channel layouts).
This commit also starts to move the line continuation '\' chars to the
left to keep them in line with MERGE_REF() as well as with the 80 lines
limit.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
and remove the redundant check.
This check for whether the allocated buffer is sufficient has been added
in commit 1cbf7fb434 (merging commit
5775a1832c). It is not sufficient to
detect invalid input lists (namely lists with duplicates); its only use
is to avoid buffer overflows. And this can be achieved by simpler means:
Make sure that one allocates space for so many elements as the outer loop
ranges over and break out of the inner loop if a match has been found.
For valid input without duplicates, no further match will be found anyway.
This change will temporarily make the allocated formats array larger
than before and larger than necessary; this will be fixed in a later
commit that avoids the allocation altogether.
If a check for duplicates in the lists is deemed necessary, it should be
done properly somewhere else.
Finally, the error message that is removed in this commit used
__FUNCTION__, which is a GCC extension (C99 added __func__ for this).
So this commit removes a warning when compiling in -pedantic mode.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If an error happens between the allocation of an AVFilterChannelLayout
and its usage (which involves attaching said object to a more permanent
object), the channel layout array leaks. This can simply be fixed by
making sure that nothing is between the allocation and the
aforementioned usage.
Fixes Coverity issue #1250334.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is as far as 22.2 follows the same channel order as
WaveFormatExtensible's channel mask (and the AV_CH_* defines).
After LFE2 the side channels would follow, but that offset of
one stops us from utilizing them without further tweaks.
This change was verified by using swresample to downmix to 5.1,
and then feeding that to WASAPI.
While having the possibility of non-NOPTS values that can suddenly
jump in time due to adjustments to match PCR is not nice for DVB
subtitles, apparently the parser for this format bases its behavior on
whether the packets' timestamps are NOPTS or not. Thus while we can
adjust timestamps, we should exclude DVB subtitles from the timestamp
unsetting logic.
Fixes#8844
Otherwise it might happen that invalid dimensions are used when reading
a video packet; this might lead to undefined overflow.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The mlv demuxer supports input split into multiple files; if invalid
data is encountered when parsing one of the subsequent files, that file
is closed. But at this point some index entries belonging to this file
might already have been added. In this case, the read_packet function
might try to use the AVIOContext (which is NULL) to read data which will
of course crash. This commit fixes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
and remove reset_packet(). The packet's data pointer is already zeroed,
so the only thing that reset_packet() does that av_init_pkt() doesn't is
redundant.
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Return proper error when frame buffers are full. This path is triggered
on the DragonBoard 410c since the encoding API change in commit
827d6fe73d.
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Fixes#7312, segmentation fault on close of X11 server
xcb_query_pointer_reply() and xcb_get_geometry_reply() can return NULL
if e.g. the X server closes or the connection is lost. This needs to
be checked in order to cleanly exit, because the returned pointers are
dereferenced later.
Signed-off-by: Moritz Barsnick <barsnick@gmx.net>
Reviewed-by: Andriy Gelman <andriy.gelman@gmail.com>
If avio_read() returns a value of bytes read that's lower than the
expected, return an error instead. And when there are zero bytes in
the prefetch buffer, return 0 in order for the frame merge bsf to
drain all potentially buffered packets.
Missed by mistake when amending and committing 9a7bdb6d71.
Signed-off-by: James Almer <jamrial@gmail.com>
When one merges two AVFilterChannelLayouts structs, there is no need to
allocate a new one. Instead one can reuse one of the two given ones.
If one does this, one also doesn't need to update the references of the
AVFilterChannelLayouts that is reused. Therefore this commit reuses the
structure with the higher refcount.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The channel layouts accepted by ff_merge_channel_layouts() are of two
types: Ordinary channel layouts and generic channel layouts. These are
layouts that match all layouts with a certain number of channels.
Therefore parsing these channel layouts is not done in one go; instead
first the intersection of the ordinary layouts of the first input
list of channel layouts with the ordinary layouts of the second list is
determined, then the intersection of the ordinary layouts of the first
one and the generic layouts of the second one etc. In order to mark the
ordinary channel layouts that have already been matched as used they are
zeroed. The inner loop that does this is as follows:
for (j = 0; j < b->nb_channel_layouts; j++) {
if (a->channel_layouts[i] == b->channel_layouts[j]) {
ret->channel_layouts[ret_nb++] = a->channel_layouts[i];
a->channel_layouts[i] = b->channel_layouts[j] = 0;
}
}
(Here ret->channel_layouts is the array containing the intersection of
the two input arrays.)
Yet the problem with this code is that after a match has been found, the
loop continues the search with the new value a->channel_layouts[i].
The intention of zeroing these elements was to make sure that elements
already paired at this stage are ignored later. And while they are indeed
ignored when pairing ordinary and generic channel layouts later, it has
the exact opposite effect when pairing ordinary channel layouts.
To see this consider the channel layouts A B C D E and E D C B A. In the
first round, A and A will be paired and added to ret->channel_layouts.
In the second round, the input arrays are 0 B C D E and E D C B 0.
At first B and B will be matched and zeroed, but after doing so matching
continues, but this time it will search for 0, which will match with the
last entry of the second array. ret->channel_layouts now contains A B 0.
In the third round, C 0 0 will be added to ret->channel_layouts etc.
This gives a quadratic amount of elements, yet the amount of elements
allocated for said array is only the sum of the sizes of a and b.
This issue can e.g. be reproduced by
ffmpeg -f lavfi -i anullsrc=cl=7.1 \
-af 'aformat=cl=mono|stereo|2.1|3.0|4.0,aformat=cl=4.0|3.0|2.1|stereo|mono' \
-f null -
The fix is easy: break out of the inner loop after having found a match.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This reverts commit f156f4ab23.
The checks added by said commit are nonsense because they did not help
in case ff_merge_samplerates() or ff_merge_formats() returned NULL
while freeing one of its arguments: Said freeing does not change
the local variables of can_merge_formats().
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Now that the output's refs-array is only allocated once, it is NULL in
any error case and therefore needn't be freed at all; Instead an
av_assert1() has been added to guarantee it to be NULL.
Furthermore, it is unnecessary to av_freep(&ptr) when ptr == NULL.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ff_merge_formats(), ff_merge_samplerates() and ff_merge_channel_layouts()
share common semantics: If merging succeeds, a non-NULL pointer is
returned and both input lists (of type AVFilterFormats resp.
AVFilterChannelLayouts) are to be treated as if they had been freed;
the owners of the input parameters (if any) become owners of the
returned list. If merging does not succeed, NULL is returned and both
input lists are supposed to be unchanged.
The problem is that the functions did not abide by these semantics:
In case of reallocation failure, it is possible for these functions
to return NULL after having already freed one of the two input list.
This happens because sometimes the refs-array of the destined output
gets reallocated twice to its final size and if the second of these
reallocations fails, the first of the two inputs has already been freed
and its refs updated to point to the destined output which in this case
will be freed immediately so that all of the already updated pointers
are now dangling. This leads to use-after-frees and memory corruptions
lateron (when these owners get cleaned up, the lists they own get
unreferenced). Should the input lists don't have owners at all, the
caller (namely can_merge_formats() in avfiltergraph.c) thinks that both
the input lists are unchanged and need to be freed, leading to a double
free.
The solution to this is simple: Don't reallocate twice; do it just once.
This also saves a reallocation.
This commit fixes the issue behind Coverity issue #1452636. It might
also make Coverity realize that the issue has been fixed.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Despite its name, this function is not part of the public API, as
formats.h, the header containing its declaration, is a private header.
The formats API was once public API, but that changed long ago
(b74a1da49d, the commit scheduling it to
become private, is from 2012). That avfilter_make_format64_list() was
forgotten is probably a result of the confusion resulting from the
libav-ffmpeg split.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It is unused since 8cbb055760 and it
actually coincides with avfilter_make_format64_list().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Snow uses the ratecontrol module, but does not expose a way to set
the rc_eq expression. The default expression, set in the ratecontrol
module, will always be used.
Make it possible to set rc_eq by adding an AVOption to snowenc.
The option definition is mostly a copy from the mpegvideo common
options definition of rc_eq (libavcodec/mpegvideo.h), with some
minor style adjustments to be closer to the other snowenc option
initializer expressions.
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
The new code is analog to how it's done in our mpegaudio parser.
Acked-by: Jun Zhao <barryjzhao@tencent.com>
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
Also add and update some tests.
Change the semantic a little, because for filesytem paths
symlinks complicate things.
See the comments in the code for detail.
Fix trac tickets #8813 and 8814.
different backend might need different options for a better performance,
so, add the parameter into dnn interface, as a preparation.
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Up until now, the TiVo demuxer parse an array of SEQ entries, yet it has
never ever made any use of them. In fact, parse_master, the function
parsing said table, only influenced the outside world in three ways: Via
an excessive amount of error message in case a certain parameter is not
what it expected; via an allocation (the aforementioned write-only
array); and by setting a certain parameter (ty->cur_chunk_pos), but that
parameter is always overwritten before it is used (it is overwritten
in get_chunk() on success and if get_chunk() fails, the error is
returned to the caller anyway). So remove the array and the function
used to parse it.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Speedup from 275sec to 142sec
Testcase: 24426/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5639724379930624
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It has no bearing on structure. Determined by looking at the ASF
files from several Argonaut games:
- FX Fighter,
- Croc,
- Croc 2,
- The Emperor's New Groove, and
- Disney's Aladdin in Nasira's Revenge
The only versions that appear are 1.1, 1.2, and 2.1, and their
structure is identical.
Reviewed-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Up until now, opening a section filter works as follows: A filter is
opened and (on success) attached to the MpegTSContext. Then a buffer for
said filter is allocated and upon success attached to the section
filter; on error, the filter is simply freed without removing it from
the MpegTSContext, leaving the latter in an inconsistent state. This
leads to use-after-frees lateron.
This commit fixes this by allocating the buffer first; the filter is
only opened if the buffer could be successfully allocated.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: out of array read
Fixes: 24487/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5165847820369920
Fixes: 24636/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5700973918683136
Fixes: 24683/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-6202883897556992
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
fix ticket: 8783
Because in single file by encryption mode, it cannot get the last one
block of the file, it need ff_format_io_close for get full file size,
then hlsenc can get the total size of the encryption content,
so write the content into temp file first, and get the temp file content
append the temp file content into append to single file, then hlsenc can
get the correct file/content size and offset.
Signed-off-by: Steven Liu <liuqi05@kuaishou.com>
X2RGB10 tested on both Intel Gen9 and AMD Polaris 11. NV12 tested on
Intel Gen9 only - since it has multiple planes, this requires GetFB2.
Also add some comments to split the list up a bit.
The most useful feature here is the ability to automatically extract the
framebuffer format and modifiers. It also makes support for multi-plane
framebuffers possible, though none are added to the format table in this
patch.
This requires libdrm 2.4.101 (from April 2020) to build, so it includes a
configure check to allow compatibility with existing distributions. Even
with libdrm support, it still won't do anything at runtime if you are
running Linux < 5.7 (before June 2020).
This patch allows for selecting the progression order
in the j2k encoder. However, all components and resolution
levels will use the same progression order and will not
feature the use of progression order change markers.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Before c63c303a1f (the commit which
introduced a typedef for the type of the buffer of a PutBitContext)
skip_put_bits() was as follows:
static inline void skip_put_bits(PutBitContext *s, int n)
{
s->bit_left -= n;
s->buf_ptr -= 4 * (s->bit_left >> 5);
s->bit_left &= 31;
}
If s->bit_left was negative after the first subtraction, then the next
line will divide this by 32 with rounding towards -inf and multiply by
four; the result will be negative, of course.
The aforementioned commit changed this to:
static inline void skip_put_bits(PutBitContext *s, int n)
{
s->bit_left -= n;
s->buf_ptr -= sizeof(BitBuf) * ((unsigned)s->bit_left / BUF_BITS);
s->bit_left &= (BUF_BITS - 1);
}
Casting s->bit_left to unsigned meant that the rounding is still towards
-inf; yet the right side is now always positive (it transformed the
arithmetic shift into a logical shift), so that s->buf_ptr will always
be decremented (by about UINT_MAX / 8 unless n is huge) which leads to
segfaults on further usage and is already undefined pointer arithmetic
before that. This can be reproduced with the mpeg4 encoder with the
AV_CODEC_FLAG2_NO_OUTPUT flag set.
Furthermore, the earlier version as well as the new version share
another bug: s->bit_left will be in the range of 0..(BUF_BITS - 1)
afterwards, although the assumption throughout the other PutBitContext
functions is that it is in the range of 1..BUF_BITS. This might lead to
a shift by BUF_BITS in little-endian mode. This has been fixed, too.
The new version is furthermore able to skip zero bits, too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: -2147483648 * -1 cannot be represented in type 'int'
Fixes: 24011/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-5486376610168832
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The default for the chromaoffset field in AVCodecContext
is zero, which until now always ended up overriding the
AVOption-set value, thus leading to the AVOption not working.
Additionally, the previous usage prevented the usage of
negative values, while both the variable as well as x264's
API would successfully handle such.
Thus, the default value of the AVOption is changed to match
the default of x264 (and what is currently the default for
the AVCodecContext chromaoffset field), and the checks are
changed to check for nonzero values.
This way:
1. the library default is still utilized if the value is zero.
2. both negative and positive values are correctly passed to
x264.
For historical context, this was initially similarly
implemented in 5764d38173, and
then b340bd8a58 broke the
value.
Partially reverts commit b340bd8a58.
Signed-off-by: Takio Yamaoka <y.takio@gmail.com>
This patch allows the encoder to use SOP and EPH
markers. This would be useful as these markers
provide better error detection mechanisms.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This commit avoids allocating a DVDemuxContext when demuxing raw DV by
making it part of the demuxer's context. This also allows to remove
dv_read_close().
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Respecting the framerate in the libopenh264enc codec context.
Both the libx264 and libx265 encoders already contain similar logic
to first check the framerate before falling back to the timebase.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
This differs from the MPEG specification as the actual real world
files do compute their CRC over variable areas and not the fixed
ones listed in the specification. This is also the reason for
the complexity of this code and the need to perform the CRC
check for layer2 in the middle of layer2 decoding.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Only this sub-set of channels actually follows the bit mask order
in the official 22.2 channel mapping. Additionally, the 5.1 channels
are there for backwards compatibility with the previous system.
This enables the utilization of 22.2 content until a proper down/up
matrix is added into swresample.
These bits are utilized by channel layouts such as 22.2. If those
are dropped, the returned channel layout is no longer a match
against the AV_CH_LAYOUT define when returned from this function.
Requires some extraneous top side and bottom front channels to be
defined.
According to STD-B59v2, the defined channel layout is:
- FL
- FR
- FC
- LFE1
- BL
- BR
- FLc
- FRc
- BC
- LFE2
- SiL
- SiR
- TpFL
- TpFR
- TpFC
- TpC
- TpBL
- TpBR
- TpSiL
- TpSiR
- TpBC
- BtFC
- BtFL
- BtFR
Previously, the hls-fmp4 and hls-fmp4_ac3 tests used the same file
names for init and segment files, which occasionally could cause
corruption and failed tests, if the input files for both tests are
generated in parallel, as they could overwrite each other.
This happened to work some of the time, as the fmp4_ac3 test actually
only checked the init segment file (which the fmp4 test case never
wrote, due to using the incorrect hls_segment_type option) and the
fmp4 test case always regenerated the input files due to mismatched
target and file names.
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously, with the file name not matching the target, the files
were regenerated every time fate is rerun - contrary to the other
test targets in the same file. (While regenerating it every time
might be desireable, as that's what the test is about, the file
at least has a dependency on the ffmpeg executable, making them
regenerated every time the executable is updated - and this change
at least makes it consistent with the rest.)
Signed-off-by: Martin Storsjö <martin@martin.st>
Layers 1 and 2 use lengths in bits which are not a multiple of 8,
and our CRC works on a per-byte basis.
Based on b48397e7b8
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: James Almer <jamrial@gmail.com>
This reverts commit b48397e7b8.
The change did not disable crc checks for layer 1 & 2, it removed reading
the CRC field.
Fixes decoding some mp2 samples and FATE test failures.
Signed-off-by: James Almer <jamrial@gmail.com>
Will prevet FATE from breaking once LIBAVCODEC_VERSION_MINOR is bumped to 100.
Reported-by: zane
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The process space is guaranteed to be aligned to the page size, hence we're
never going to map outside of our address space.
There are more optimizations to do with respect to chroma plane alignment and
buffer offsets, but that can be done later.
If a bit is reserved, it matters very much what value it has, because
otherwise a decoder conforming to a future version of the standard might
interpret the output file in an unintended manner. This implies that
one must not use skip_put_bits() for it (which does not give any
guarantees wrt what ends up in the output (in case of a little-endian
bitstream writer (as here) it writes a 0 bit)); given that the reference
encoder as well as the earlier code write a zero bit at this place, the
new code does, too.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
flush_put_bits() already fills the bitstream with zeroes, so it is
unnecessary to align the bitstream before.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Dimensions are normally specified as width x height, and this will match
the same option to libaom-av1.
Remove the indirection through the private context at the same time.
The tile_rows/cols options currently do a confusingly different thing to
the options of the same name on other encoders like libvpx and libaom.
There is no backward-compatibility reason to implement the log2 behaviour
as there was for libaom, so just get rid of them entirely.
This change makes it possible for child encoders to define custom level
option names which can be used for setting the AVCodecContext->level.
Based on 337fe4bcc2
Reviewed-by: jkqxz
Signed-off-by: James Almer <jamrial@gmail.com>
This patch makes the pgx decoder select the correct
byte order instead of selecting big endian format for
16 bit images.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
'li.s' is a synthesized instruction, it does not work properly
when compiled with clang on mips, and A segfault occurred.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Failed fate case: fate-h264-conformance-caba2_sony_e
Clang is more strict in the use of register constraint.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
GCC support these two synthesized instruction, but clang does not yet.
Use machine instruction instead to adapt clang compiler.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Clang report following error in aacsbr_mips.c,ac3dsp_mips.c and aacdec_mips.c:
"couldn't allocate output register for constraint 'r'"
Use 'f' constraint for float variable.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Also query time only once, not for every variant stream, otherwise variant
streams might get a slightly different initial program date time. And we can
set this unconditionally because HLS_PROGRAM_DATE_TIME flag is checked
elsewhere.
Signed-off-by: Marton Balint <cus@passwd.hu>
Threaded input can increase smoothness of e.g. x11grab significantly. Before
this patch, in order to activate threaded input the user had to specify a
"dummy" additional input, with this change it is no longer required.
Signed-off-by: Marton Balint <cus@passwd.hu>
This option is directly copy-pasted from the SVT1-HEVC wrapper and has
no place in the options for an AV1 encoder.
AV1 has no H.264/5 IDR frames nor anything like them.
All this option does is change all real keyframes to an intra-only
AV1 frame, which is not seekable. Hence, any streams encoded with
this option enabled will not be seekable.
instead of get_ue_golomb(). The difference between the two is that the
latter also has to take into account the case in which the read code is
more than 9 bits (four preceding zeroes + at most five value bits) long,
leading to more code.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
get_ue_golomb_31() reads nine bits and an array with 512 entries to
parse golomb codes. The longest golomb codes that fit into 9 bits use
four leading zeroes and five value bits and can encode numbers in the
0..30 range. 31 meanwhile is encoded on 11 bits and if the nine bits
read coincide with the first nine bits of the encoding of 31,
get_ue_golomb_31() returns 31 (and skips 11 bits).
But looking at the first nine bits only makes it impossible to distinguish
31 from 32..34. Therefore the documentation of get_ue_golomb_31() simply
states that the return value is undefined if the value of the encountered
exp golomb code was outside the 0..31 range.
But actually get_ue_golomb_31() does not behave that bad: If the returned
value is in the range of 0..30, then this is the actually encountered value,
so that this function can be used without any problems to parse and validate
parameters whose legal values are a subset of the 0..30 range.
This commit documents this fact.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This happened in get_ue_golomb() if the cached bitstream reader was in
use, because there was no check to handle the case of the read value
not being in the supported range.
For consistency with the uncached bitstream reader and for compliance
with the documentation, every value not in the 0-8190 range is treated as
error although the cached bitstream reader could actually read values in
the range 0..65534 without problems.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This patch adds support for PPM marker for JPEG2000
decoder. It allows the samples p1_03.j2k and p1_05.j2k
to be decoded.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Said error message is not very informative and lacked a proper logging
context; furthermore, many callers already provided more descriptive
error messages of their own. So just drop this one.
Suggested-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
For non-PCM audio, a Smacker frame contains the size of the decoded
audio in the first four bytes of the audio packet data; for PCM data,
said information would be redundant and according to [1] this field does
not exist. Therefore this commit sets the duration and timestamps
properly for PCM audio.
[1]: https://wiki.multimedia.cx/index.php/Smacker#Audio_Track_Chunk
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Add .read_seek function to the smacker demuxer for the special case of
seeking to ts=0. This is useful because smacker – like bink, with a
similar implementation – was mostly used to encode clips in video
games, where random seeks are rare but looping media are common.
Signed-off-by: Timotej Lazar <timotej.lazar@araneo.si>
libsrt changed the:
SRTO_SMOOTHER -> SRTO_CONGESTION
SRTO_STRICTENC -> SRTO_ENFORCEDENCRYPTION
and removed the front of deprecated options (SRTO_SMOOTHER/SRTO_STRICTENC)
in the header, it's lead to build fail
fix#8760
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
This reverts commit 489c5db079.
Treating EQUAL_MULTI_ROWS in the same way as the arbitrary-size cases is
just wrong. Consider 9 rows, 4 slices - we pick 4 slices with sizes
{ 3, 2, 2, 2 }, which EQUAL_MULTI_ROWS does not allow. It isn't possible
to split the frame into 4 slices at all with the EQUAL_MULTI_ROWS
structure - the closest options are 3 slices with sizes { 3, 3, 3 } or 5
slices with sizes { 2, 2, 2, 2, 1 }.
hwcontext_vaapi maps different VA fourcc to the same pix_fmt for U/V
plane swap cases, however duplicate formats are not expected in sw_format
list when merging formats.
For example:
ffmpeg -loglevel debug -init_hw_device vaapi -filter_hw_device vaapi0 \
-f lavfi -i smptebars -vf \
"hwupload=derive_device=vaapi,scale_vaapi,hwdownload,format=yuv420p" \
-vframes 1 -f null -
Without this fix, an auto scaler is required for the above command
Duplicate formats in ff_merge_formats detected
[auto_scaler_0 @ 0x560df58f4550] Setting 'flags' to value 'bicubic'
[auto_scaler_0 @ 0x560df58f4550] w:iw h:ih flags:'bicubic' interl:0
[Parsed_hwupload_0 @ 0x560df58f0ec0] auto-inserting filter
'auto_scaler_0' between the filter 'graph 0 input from stream 0:0' and
the filter 'Parsed_hwupload_0'
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
The size for a previous plane doesn't signal the presence of another after it.
If the plane is present, av_image_fill_plane_sizes() will have returned a size
for it.
Fixes a regression since 3a8e927176.
Reported-by: Imad R. Faiad <irfaiad@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Up until now, the Sega FILM muxer would first write all the packet data,
then shift the data (in the muxer's write_trailer function) by the amount
necessary to write the header at the front (which entails a seek to the
front), then seek back to the beginning and actually write the header.
This commit changes this: The dynamic buffer that is used to write the
sample table (containing information about each sample in the file) is
now used to write the complete header. This is possible because the size
of everything in the header except the sample table is known in advance.
Said buffer can then be used as one of the two temporary buffers used
for shifting which also reduces the amount one has to allocate for this.
Thereby the header will be written when shifting, so that the second
seek to the beginning is unnecessary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the Sega FILM muxer would store some information about
each packet in a linked list. When writing the trailer, the information
in said linked list would be used to write a table in the file header.
Each entry in said table is 16 bytes long, but each entry of the linked
list is 32 bytes long (assuming 64 bit pointer and no padding).
Therefore it makes sense to remove the linked list and write the array
entries directly into a dynamic buffer while writing the packet (this is
possible because the table entries don't depend on any information not
available when writing the packet (the offset is not relative to the
beginning of the file, but to the end of the table). This also
simplifies writing the array at the end (there is no need to traverse a
linked list).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Mostly using intermediate pointers for accesses (i.e. storing s->pb in a
variable pb and then using pb for writing instead of s->pb) to improve
readability. Furthermore, the opening brace '{' of a function has been
moved into a line of its own in instances where it wasn't before.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Also return proper error codes when it is absent: AVERROR(EINVAL)
instead of AVERROR_INVALIDDATA.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When using the WebM DASH Manifest muxer, every stream of each adaptation
set has to contain a metadata entry containing the filename of the
source file. In case of live stream manifests, said filename has to
conform to a pattern of
<file_description>_<representation_id>.<extension>. These pieces are
used to create the other strings that are actually output. Up until now,
these other strings would be allocated, used once and then freed
directly after usage. This commit changes this: The function that
allocated and assembled these strings now returns pointers to the '_'
and '.' delimiters and so that the caller can easily pick substrings
from it without needing to copy the string.
Avoiding allocations also fixes a memleak: One of the allocated strings
would leak upon a subsequent allocation failure.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
In 1ec2b3de5a, the extradata size was affected when the raster was
signaled as flipped due to user-set option rather than via extradata.
This resulted in a wrong header size being written. Fixed.
The codeblock decoder checks whether the mqc decoder
has decoded the right number of bytes. However, this
check does not account for the fact that the mqc encoder's
flush routine adds 2 bytes of data which does not have to be
read by the decoder. The check is modified to account for
this. This patch solves issue #4827
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Later the decorrelate_stereo call is guarded by channels == 2
and non-zero decorr_left_weight. Make sure decorr_shift is in
the expected shift range for that case.
Fixes: shift exponent 128 is too large for 32-bit type 'int'
Fixes: 23860/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALAC_fuzzer-5751138914402304
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The Matroska demuxer currently always opens a GetByteContext to read the
content of the projection's private data buffer; it does this even if
there is no private data buffer in which case opening the GetByteContext
will lead to a NULL + 0 which is undefined behaviour.
Furthermore, in this case the code relied both on the implicit checks
of the bytestream2 API as well as on the fact that it returns zero
if there is not enough data available.
Both of these issues have been addressed by not using the bytestream API
any more; instead the data is simply read directly by using AV_RB. This
is possible because the offsets are constants.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When parsing MXF encountering some tags leads to allocations. And when
these tags were encountered repeatedly, this could lead to memleaks,
because the pointer to the old data got simply overwritten with a
pointer to the new data (or to NULL on allocation failure). This has
been fixed.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The MXF demuxer uses an array of pointers to different structures of
metadata (all containing a common initial sequence containing a type
field to distinguish them) and some of these structures contain pointers
to separately allocated subelements. If an error happens while reading
and creating the tags, the semi-finished new tag is freed using the
function to free these tags. But this function doesn't free the already
allocated subelements, because the type has not been set yet. This commit
changes this.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Said array contains pointers to other structs and both the designated
new element as well as other stuff contained in it (e.g. strings) leak
if the new element can't be added to the array.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
GCC complains:
warning: listing the stack pointer register ‘$29’ in a clobber
list is deprecated [-Wdeprecated]
Actually stack pointer was restored at the end of the inline assembly
so there is no reason to add it to the clobber list.
Also use $sp insted of $29 to make our intention much more clear.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Shiyou Yin <yinshiyou-hf@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Apply optimized functions according to cpuflags.
MSA is usually put after MMI as it's generally faster than MMI.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Shiyou Yin <yinshiyou-hf@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Add MMI & MSA runtime detection for MIPS.
Basically there are two code pathes. For systems that
natively support CPUCFG instruction or kernel emulated
that instruction, we'll sense this feature from HWCAP and
report the flags according to values grab from CPUCFG. For
systems that have no CPUCFG (or not export it in HWCAP),
we'll parse /proc/cpuinfo instead.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Shiyou Yin <yinshiyou-hf@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
That helper grab from kernel code can allow us to inline
newer instructions (not implemented by the assembler) in
a elegant manner.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Shiyou Yin <yinshiyou-hf@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
To enable runtime detection for MIPS, we need to refine ffbuild
part to support buildding these feature together.
Firstly, we fixed configure, let it probe native ability of toolchain
to decide wether a feature can to be enabled, also clearly marked
the conflictions between loongson2 & loongson3 and Release 6 & rest.
Secondly, we compile MMI and MSA C sources with their own flags to ensure
their flags won't pollute the whole program and generate illegal code.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Shiyou Yin <yinshiyou-hf@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This uses av_image_fill_plane_sizes instead of av_image_fill_pointers
when we are getting plane sizes to avoid UB from adding offsets to NULL.
Signed-off-by: Brian Kim <bkkim@google.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This uses av_image_fill_plane_sizes instead of av_image_fill_pointers
when we are getting plane sizes to avoid UB from adding offsets to NULL.
Signed-off-by: Brian Kim <bkkim@google.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This utility helps avoid undefined behavior when doing things like
checking how much memory we need to allocate for an image before we have
allocated a buffer.
Signed-off-by: Brian Kim <bkkim@google.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: signed integer overflow: 33986707200000000 + 9195561788997000192 cannot be represented in type 'long'
Fixes: 23790/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6554232198266880
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
lzwenc stores a function pointer to either put_bits or put_bits_le;
however, after the recent change, the function pointer's prototype
would depend on BitBuf. BitBuf is defined in put_bits.h, whose
definition depends on whether BITSTREAM_WRITER_LE is #defined or not.
For safety, we set a boolean flag for little/big endian instead,
which also allows the definition to be inlined.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Add functions to initialize tile slice structure and make tile slice:
- vaapi_encode_init_tile_slice_structure
- vaapi_encode_make_tile_slice
Tile slice is not allowed to cross the boundary of a tile due to
the constraints of media-driver. Currently adding support for one
slice per tile.
N x N tile encoding is supposed to be supported with the the
capability of ARBITRARY_MACROBLOCKS slice structures.
N X 1 tile encoding should also work in ARBITRARY_ROWS slice
structure.
Signed-off-by: Linjie Fu <linjie.justin.fu@gmail.com>
Wrap current whole-row slice codes into following functions:
- vaapi_encode_make_row_slice()
- vaapi_encode_init_row_slice_structure()
Signed-off-by: Linjie Fu <linjie.justin.fu@gmail.com>
Because the newpos variable is set value before use it.
The newpos variable declared at the head partition of crypto_seek.
Make the code clean.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Change BitBuf into uint64_t on 64-bit x86. This means we need to flush the
buffer less often, which is a significant speed win. All other platforms,
including all 32-bit ones, are unchanged. Output bitstream is the same.
All API constraints are kept in place, e.g., you still cannot put_bits()
more than 31 bits at a time. This is so that codecs cannot accidentally
become 64-bit-only or similar.
Benchmarking on transcoding to various formats shows consistently
positive results:
dnxhd 25.60 fps -> 26.26 fps ( +2.6%)
dvvideo 24.88 fps -> 25.17 fps ( +1.2%)
ffv1 14.32 fps -> 14.58 fps ( +1.8%)
huffyuv 58.75 fps -> 63.27 fps ( +7.7%)
jpegls 6.22 fps -> 6.34 fps ( +1.8%)
magicyuv 57.10 fps -> 63.29 fps (+10.8%)
mjpeg 48.65 fps -> 49.01 fps ( +0.7%)
mpeg1video 76.41 fps -> 77.01 fps ( +0.8%)
mpeg2video 75.99 fps -> 77.43 fps ( +1.9%)
mpeg4 80.66 fps -> 81.37 fps ( +0.9%)
prores 12.35 fps -> 12.88 fps ( +4.3%)
prores_ks 16.20 fps -> 16.80 fps ( +3.7%)
rv20 62.80 fps -> 62.99 fps ( +0.3%)
utvideo 68.41 fps -> 76.32 fps (+11.6%)
Note that this includes video decoding and all other encoding work,
such as DCTs. If you isolate the actual bit-writing routines, it is
likely to be much more.
Benchmark details: Transcoding the first 30 seconds of Big Buck Bunny
in 1080p, Haswell 2.1 GHz, GCC 8.3, generally quantizer locked to
5.0. (Exceptions: DNxHD needs fixed bitrate, and JPEG-LS is so slow
that I only took the first 10 seconds, not 30.) All runs were done
ten times and single-threaded, top and bottom two results discarded to
get rid of outliers, arithmetic mean between the remaining six.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Preparatory patch for making the bit buffer different size on different
platforms; make a typedef and make all the hardcoded sizes into expressions
deriving from this size.
No functional change; generated assembler is near-identical.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The JPEG2000 standard reserves marker values 0xFF30
to 0xFF3F to be used as parameterless markers. This
patch adds support to decode codestream with such
markers. This allows decoding of p0_02.j2k.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
VA_ENC_SLICE_STRUCTURE_EQUAL_MULTI_ROWS is added to in the latest
libva (1.8.0) which matches the hardware behaviour:
/** \brief Driver supports any number of rows per slice but they must
* be the same for all slices except for the last one, which must be
* equal or smaller to the previous slices.
*/
And VA_ENC_SLICE_STRUCTURE_EQUAL_ROWS is kind of deprecated for iHD
since it's somehow introduced in [1] which is misleading from what we
actually handles.
[1]<0e6d5441f1>
Signed-off-by: Linjie Fu <linjie.justin.fu@gmail.com>
remove the timeout option docs part for HTTP protocol and add
auth_type option part.
Reviewed-by: Gyan Doshi <ffmpeg@gyani.pro>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
When there are potentially annotation (i.e. metadata) fields to write,
au_get_annotations() is called to produce a string with them. To do so,
it uses an AVBPrint which is finalized to create the string. This is
wasteful, because it always leads to an allocation even if the string
actually fits into the internal buffer of the AVBPrint. This commit
changes this by making au_get_annotations() modify an AVBPrint that
resides on the stack of the caller (i.e. of au_write_header()).
Furthermore, the AVBPrint is now checked for truncation; limiting
the allocations implicit in the AVBPrint allowed to offload the overflow
checks. Notice that these were not correct before: The size parameter of
avio_write() is an int, yet the string in the AVBPrint was allowed to
grow bigger than INT_MAX. And if the length of the string was so near
UINT_MAX that the length + 32 overflowed, the old code would write the
first eight bytes of the string and nothing more, leading to an invalid
file.
Finally, the special case in which the metadata dictionary of the
AVFormatContext is empty (in which case one still has to write eight
binary zeroes) is now no longer treated specially, because this case
no longer incurs any allocation.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This av_freep(&key) in conjunction with the fact that the loop condition
checks for key != NULL was equivalent to a av_freep(&key) + a break
immediately thereafter. But given that there is an av_freep(&key)
directly after the loop, the av_freep(&key) is unnecessary and the break
can also be added explicitly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
RGB pixel formats are one occasion where by pixel format we mean
pixel format, primaries, transfer characteristic, and matrix coeffs,
so we have to manually set them as they're set to unspecified by
default, despite there only being a single possible combination.
The RPCL progression order check was incomplete. This
patch completes the check. Tested on p1_07.j2k.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
v4l2_receive_frame() uses two packets s->buf_pkt and avpkt. If avpkt
cannot be enqueued, the packet is buffered in s->buf_pkt and enqueued in
the next call. Currently the ownership transfer between the two packets
is not properly handled. A double free occurs if
ff_v4l2_context_enqueue_packet() returns EAGAIN and v4l2_try_start
returns EINVAL.
In fact, having two AVPackets is not needed and everything can be
handled by s->buf_pkt.
This commit removes the local avpkt from v4l2_receive_frame(), meaning
that the ownership transfer doesn't need to be handled and the double
free is fixed.
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
The PCRL progression checks were incomplete. This patch
modifes completes the check. Tested on p1_05.j2k.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Some legacy applications such as AVI2MVE expect raw RGB bitmaps
to be stored bottom-up, whereas our RIFF BITMAPINFOHEADER assumes
they are always stored top-down and thus write a negative value
for height. This can prevent reading of these files.
Option flipped_raw_rgb added to AVI and Matroska muxers
which will write positive value for height when enabled.
Note that the user has to flip the bitmaps beforehand using other
means such as the vflip filter.
Currently, the COC marker overrides the SOP marker bit.
However, only the COD marker may set this value. This
patch fixes this bug.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The number of declared vdpau formats can vary depending on which
version of libvdpau we build against, so the number of pix fmts
can vary too. Let's make sure we keep those numbers in sync.
Some new warnings regarding use of empty macro parameters has
been added, so adjust some x86inc code to silence those.
Fixes part of ticket #8771
Signed-off-by: James Almer <jamrial@gmail.com>
15d160cc0b increased the UDP socket receiving buffer size
(64K ->384K), but missed to update this comments.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
fix the command ffmpeg -h filter=setpts/asetpts both dump the expr
option with "FVA" flags.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
No audio stream is created unconditionally and if none has been created,
no packet with stream_index 1 may be returned. This fixes an assert in
ff_read_packet() in libavformat/utils reported in ticket #8782.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: 86987846-429c8d80-c197-11ea-916b-bb4738e09687.jpg
Fixes: Regression since ec3d8a0e69
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Added VDPAU to list of supported formats for HEVC10 and 12 bit formats
also added 42010 bit to surface_parameters and new VDP chroma formats to
VDPAUPixFmtMaps
Add HEVC 420 10/12 Bit and 444 10/12 Bit support for VDPAU
YUV444P10 is defined as the 444 surface with 10bit valid data in LSBs
but H/w returns Data in MSBs Hence if we map output as YUV444p16 it
is filtering out the LSB to convert to p10 format.
Signed-off-by: Philip Langdale <philipl@overt.org>
Add vdpau_parse_rext_profile and use profile constraint flags to
determine the exact vdp_profile for HEVC_REXT.
If profile mismatch is allowed, select Main profile by default.
Add build object in Makefile for h265_profile_level dependency.
Signed-off-by: Philip Langdale <philipl@overt.org>
Please test with below command:
./ffplay -vf drawtext="fontfile=/Library/Fonts/Arial.ttf:text=\\'%{metadata\\:timecode}\\'" \
../fate-suite/h264/crew_cif_timecode-2.h264
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
We return 0 for this particular architecture but should instead be
returning the number of lines.
Fixes users who check the return value matches what they expect.
When one of output[i] & expected_output is NAN, the unit test will always pass.
Signed-off-by: Ting Fu <ting.fu@intel.com>
Reviewed-by: Guo, Yejun <yejun.guo@intel.com>
broken since:
aa5c6f382b avcodec/libaomenc: Add command-line options to control the use of partition tools
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: James Zern <jzern@google.com>
Or it'll cause null pointer dereference if size < sizeof(uint32_t), also
in case tc[0] > 3, the code will report error directly.
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Fixes: signed integer overflow: 155 + 2147483647 cannot be represented in type 'int'
Fixes: 23421/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LOCO_fuzzer-5652849097965568
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Currently the next thread's context is updated from the previous one's
if the codec descriptor is not marked as intra-only. That is not
entirely correct, since that property does not necessarily imply
anything about how a specific decoder implementation behaves.
Instead, use the presence of the update_thread_context() callback to
decide whether an update should be performed. Fixes races in CFHD,
should cause no behaviour change in any other decoders.
add probeaudiostream for get audio stream's codec_name,codec_time_base,
sample_fmt,channels and channel_layout.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Important part of this algorithm is the double threshold step: pixels
above "high" threshold being kept, pixels below "low" threshold dropped,
pixels in between (weak edges) are kept if they are neighboring "high"
pixels.
The weak edge check uses a neighboring context and should not be applied
on the plane's border. The condition was incorrect and has been fixed in
the commit.
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Reviewed-by: Andriy Gelman <andriy.gelman@gmail.com>
Currently, both bsfs used the same CodedBitstreamContext for reading and
writing; as a consequence, the state of the writer's context at the
beginning of writing a fragment is exactly the state of the reader after
having read the fragment; in particular, the writer might not have
encountered one of its active parameter sets yet.
This is not nice and may lead to invalid output even when the input
is completely spec-compliant: Think of an access unit containing
a primary coded picture referencing a PPS with id id (that is known from
an earlier access unit/from extradata), then a new version of the PPS
with id id and then a redundant coded picture that is also referencing
the PPS with id id. This is spec-compliant, as the standard allows to
overwrite a PPS with a different PPS in between coded pictures and not
only at the beginning of an access unit. In this scenario, the reader
would read the primary coded picture with the old PPS and the redundant
coded picture with the new PPS (as it should); yet the writer would
write both with the new PPS as extradata which might lead to errors or
to invalid data being output without any error (e.g. if the two PPS
differed in redundant_pic_cnt_present_flag).
The above scenario does not directly translate to HEVC as long as one
restricts oneself to input with nuh_layer_id == 0 only (as cbs_h265
does: it currently strips away any NAL unit with nuh_layer_id > 0 when
decomposing); if one doesn't the same issue as above can happen.
If one also allowed input packets to contain more than one access unit,
issues like the above can happen even without redundant coded
pictures/multiple layers.
Therefore this commit uses separate contexts for reader and writer.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Several cbs-functions had an unused CodedBitstreamContext parameter.
This commit removes these.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Commit 601c238854 added support for AV_PKT_DATA_NEW_EXTRADATA, but
only for avcC extradata.
This commit adds support for sps/pps extradata as well. This makes
support consistent for passing new extradata consistent with the
types of extradata that can be passed when initializing the decoder.
Signed-off-by: Oliver Woodman <ollywoodman@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Add qmax/qmin support for HEVC software bitrate control(SWBRC).
Limitations:
- RateControlMethod != MFX_RATECONTROL_CQP
- with EXTBRC ON
Signed-off-by: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Zhong Li <zhongli_dev@126.com>
Instead use ffio_read_size to read data into a buffer. Also check that
the desired size was actually successfully read and combine the check
with the check for reading the extradata.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Allocating two arrays with the same number of elements together
simplifies freeing them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
A Smacker file can contain up to seven audio tracks. Up until now,
the pts for the i. audio packet contained in a Smacker frame was
simply the end timestamp of the last i. audio packet contained in
an earlier Smacker frame.
The problem with this is that a Smacker stream need not contain data in
every Smacker frame and so the current i. audio packet present may come
from a different underlying stream than the last i. audio packet
contained in an earlier frame.
The sample hypnotix.smk* exhibits this. It has three audio tracks and
the first of the three has a longer first packet, so that the audio for
the first track is contained in only 235 packets contained in the first
235 Smacker frames; the end timestamp of this track is 166696 (about 7.56s
at a timebase of 1/22050); the other two audio tracks both have 253 packets
contained in the first 253 Smacker frames. Up until now, the 236th
packet of the second track being the first audio packet in the 236th
Smacker frame would get the end timestamp of the last first audio packet
from the last Smacker frame containing a first audio packet and said
last audio packet is the first audio packet from the 235th Smacker frame
from the first audio track, so that the timestamp is 166696. In contrast,
the 236th packet from the third track (whose packets contain the same number
of samples as the packets from the second track) has a timestamp of
156116 (because its timestamp is derived from the end timestamp of the
235th packet of the second audio track). In the end, the second track
ended up being 177360/22050 s = 8.044s long; in contrast, the third
track was 166780/22050 s = 7.56s long which also coincided with the
video.
This commit fixes this by not using timestamps from other tracks for
a packet's pts.
*: https://samples.ffmpeg.org/game-formats/smacker/wetlands/hypnotix.smk
Reviewed-by: Timotej Lazar <timotej.lazar@araneo.si>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The layout of a Smacker frame is as follows: For some frames, the
beginning of the frame contained a palette for the video stream; then
there are potentially several audio frames, followed by the data for the
video stream.
The Smacker demuxer used to read the palette, then cache every audio frame
into a buffer (that gets reallocated to the desired size every time a
frame is read into this buffer), then read and return the video frame
(together with the palette). The cached audio frames are then returned
by copying the data into freshly allocated buffers; if there are none
left, the next frame is read.
This commit changes this: At the beginning of a frame, the palette is
read and cached as now. But audio frames are no longer cached at all;
they are returned immediately. This gets rid of copying and also allows
to remove the code for the buffer-to-AVStream correspondence.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The first four bytes of smacker audio are supposed to contain the number
of samples, so treat audio frames smaller than that as invalid.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When reading a new frame, the Smacker demuxer seeks to the next frame
position where it excepts the next frame; then it (potentially) reads
the palette, the audio packets associated with the frame and finally the
actual video frame. It is only at the end that the frame counter as well
as the position where the next frame is expected get updated.
This has a downside: If e.g. invalid data is encountered when reading
the palette, the demuxer returns immediately (with an error) and if the
caller calls av_read_frame again, the demuxer seeks to the position where
it already was, reads the very same palette data again and therefore will
return an error again. If the caller calls av_read_frame repeatedly
(say, until a packet is received or until EOF), this meight become an
infinite loop.
This could also happen if e.g. the size of one of the audio frames was
invalid or if the frame size was gigantic.
This commit changes this by skipping a frame if it turns out to be
invalid or an error happens otherwise. This ensures that EOF will be
returned eventually in the above scenario.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The Smacker demuxer buffers audio packets before it outputs them, but it
increments the counter of buffered packets prematurely: If allocating
the audio buffer fails, an error (most likely AVERROR(ENOMEM)) is returned.
If the caller decides to call av_read_frame() again, the next call will
take the codepath for returning already buffered audio packets and it
will fail (because the buffer that ought to be allocated isn't) without
decrementing the number of supposedly buffered audio packets (it doesn't
matter whether there would be enough memory available in subsequent calls).
Depending on the caller's behaviour this is potentially an infinite loop.
This commit fixes this by only incrementing the number of buffered audio
packets after having successfully read them and unconditionally reducing
said number when outputting one of them. It also changes the semantics
of the curstream variable: It is now the number of currently buffered
audio packets whereas it used to be the index of the last audio stream
to be read. (Index refers to the index in the array of buffers, not to
the stream index.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This useful, because by ffprobe's very nature, you use it to probe
a file and find out what it is. Requiring every format private option
to be known to the demuxer forces one to run ffprobe twice, if one
wants to use ffprobe in a generic way.
For example, say one wants to probe all user-uploaded files, while
also ignoring edit lists for any MP4s that are uploaded. Currently,
you'd have to run ffprobe twice: once to identify the format, and
once again to actually probe the metadata you want. After this
patch, you could set -ignore_editlist 1 on every call and only
probe once.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Real files do skip coding 0 bits at the end, thus this kind of check
does not work reliable.
Fixes: Ticket 8770
Fixes: dst-256fs44-6ch-refdstencoder.dff
The samplerate is specified in ISO/IEC 14496-3:2005(E) as one of 3 fixed
values, this also can be used to limit the duration and avoid the timeout
This reverts commit f6df99dba1.
Don't need to do double check by the description of the API.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
floating point precision will cause rgb*max generate different value on
x86_32 and x86_64. have pass fate test on x86_32 and x86_64 by using
lrintf to get the nearest integral value for rgb * max before av_clip.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
This is the only use of 'FontName' with that capitalization, as both
source-code and tests use 'Fontname'. Having consistent capitalization
makes it easier to find the relevant source from the docs.
See these examples for other uses:
libavcodec/ass_split.c:68
tests/ref/fate/sub-cc:9
We can try with the srcnn model from sr filter.
1) get srcnn.pb model file, see filter sr
2) convert srcnn.pb into openvino model with command:
python mo_tf.py --input_model srcnn.pb --data_type=FP32 --input_shape [1,960,1440,1] --keep_shape_ops
See the script at https://github.com/openvinotoolkit/openvino/tree/master/model-optimizer
We'll see srcnn.xml and srcnn.bin at current path, copy them to the
directory where ffmpeg is.
I have also uploaded the model files at https://github.com/guoyejun/dnn_processing/tree/master/models
3) run with openvino backend:
ffmpeg -i input.jpg -vf format=yuv420p,scale=w=iw*2:h=ih*2,dnn_processing=dnn_backend=openvino:model=srcnn.xml:input=x:output=srcnn/Maximum -y srcnn.ov.jpg
(The input.jpg resolution is 720*480)
Also copy the logs on my skylake machine (4 cpus) locally with openvino backend
and tensorflow backend. just for your information.
$ time ./ffmpeg -i 480p.mp4 -vf format=yuv420p,scale=w=iw*2:h=ih*2,dnn_processing=dnn_backend=tensorflow:model=srcnn.pb:input=x:output=y -y srcnn.tf.mp4
…
frame= 343 fps=2.1 q=31.0 Lsize= 2172kB time=00:00:11.76 bitrate=1511.9kbits/s speed=0.0706x
video:1973kB audio:187kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.517637%
[aac @ 0x2f5db80] Qavg: 454.353
real 2m46.781s
user 9m48.590s
sys 0m55.290s
$ time ./ffmpeg -i 480p.mp4 -vf format=yuv420p,scale=w=iw*2:h=ih*2,dnn_processing=dnn_backend=openvino:model=srcnn.xml:input=x:output=srcnn/Maximum -y srcnn.ov.mp4
…
frame= 343 fps=4.0 q=31.0 Lsize= 2172kB time=00:00:11.76 bitrate=1511.9kbits/s speed=0.137x
video:1973kB audio:187kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.517640%
[aac @ 0x31a9040] Qavg: 454.353
real 1m25.882s
user 5m27.004s
sys 0m0.640s
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Pedro Arthur <bygrandao@gmail.com>
OpenVINO is a Deep Learning Deployment Toolkit at
https://github.com/openvinotoolkit/openvino, it supports CPU, GPU
and heterogeneous plugins to accelerate deep learning inferencing.
Please refer to https://github.com/openvinotoolkit/openvino/blob/master/build-instruction.md
to build openvino (c library is built at the same time). Please add
option -DENABLE_MKL_DNN=ON for cmake to enable CPU path. The header
files and libraries are installed to /usr/local/deployment_tools/inference_engine/
with default options on my system.
To build FFmpeg with openvion, take my system as an example, run with:
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/deployment_tools/inference_engine/lib/intel64/:/usr/local/deployment_tools/inference_engine/external/tbb/lib/
$ ../ffmpeg/configure --enable-libopenvino --extra-cflags=-I/usr/local/deployment_tools/inference_engine/include/ --extra-ldflags=-L/usr/local/deployment_tools/inference_engine/lib/intel64
$ make
Here are the features provided by OpenVINO inference engine:
- support more DNN model formats
It supports TensorFlow, Caffe, ONNX, MXNet and Kaldi by converting them
into OpenVINO format with a python script. And torth model
can be first converted into ONNX and then to OpenVINO format.
see the script at https://github.com/openvinotoolkit/openvino/tree/master/model-optimizer/mo.py
which also does some optimization at model level.
- optimize at inference stage
It optimizes for X86 CPUs with SSE, AVX etc.
It also optimizes based on OpenCL for Intel GPUs.
(only Intel GPU supported becuase Intel OpenCL extension is used for optimization)
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Pedro Arthur <bygrandao@gmail.com>
Saves initialization of an HEVCDecoderConfigurationRecord when
the data is already in ISOBMFF-format or if it is plainly invalid.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This patch adds the control for enabling rectangular partitions, 1:4/4:1
partitions and AB shape partitions.
Signed-off-by: Wang Cao <wangcao@google.com>
Signed-off-by: James Zern <jzern@google.com>
Fix two cases of memleaks:
1. The leak of dv_demux
2. The leak of dv_fctx upon dv_demux allocate failure
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The code for demuxing DV audio predates the introduction of refcounted
packets and when the latter was added, changes to the former were
forgotten. This meant that when avpriv_dv_produce_packet initialized the
packet containing the AVBufferRef, the AVBufferRef as well as the
underlying AVBuffer leaked; the actual packet data didn't leak: They
were directly freed, but not via their AVBuffer's free function.
https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4671/dir1.tar.bz2
contains samples for this (enable_drefs needs to be enabled for them).
Moreover, errors in avpriv_dv_produce_packet were ignored; this has been
changed, too.
Furthermore, in the hypothetical scenario that the track has a palette,
this would leak, too, so reorder the code so that the palette code
appears after the DV audio code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The segments / url can be modified by the io read when reloading
This may be an alternative or additional fix for Ticket8673
as a further alternative the reload stuff could be disabled during
probing
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The encoder has no delayed packets at the end of the encoding
process, so signaling this capability is unnecessary.
This also fixes an assertion failure introduced in 827d6fe73d, as
return values higher than 0 are not expected.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: left shift of 1913647649 by 1 places cannot be represented in type 'int'
Fixes: 23572/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-5082619795734528
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: 2048 + 2147483646 cannot be represented in type 'int'
Fixes: 23538/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-5227567073460224
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This patch removes a check which throws an error if
the log2 precinct width/height is 0. The standard allows
the first component to have 0 as the log2 width/height.
However, to ensure proper intialization of coding style,
an extra check has been added.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Also switch to using a pointer to access stream side data instead of
copying the stream's AVPacketSideData.
Reviewed-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The issue is introduced in a705bcd763, please tested with below command line:
make V=1 fate-sub-cc-scte20 TARGET_EXEC="valgrind --error-exitcode=1"
Reported-by: Martin Storsjö <martin@martin.st>
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
When doing streamed output, with e.g. +dash, if the mfra box ended
up being larger than the AVIOContext write buffer, the (unchecked)
seeking back to update the box size would silently fail and produce
an invalid mfra box.
This is similar to how other boxes are written in fragmented mode.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Note for info level, one extra \n will be print after the log.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Nothing written in avformat_write_trailer() for the submuxers will be
output anyway because the AVIOContexts used for actual output have been
closed before the call. Writing the trailer of the subcontext has probably
only been done in order to free the memory allocated by the submuxer.
And this job has been taken over by the deinit functions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
libopenjpeg2000 uses ceiling division while dividing tile
co-ordinates with the sample separation. Also, corrections
were made to the WRITE_FRAME macro.
Improves: p1_01.j2k and p1_07.j2k
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Reduce image size of the image if all components have
a non zero sample separation. This is to replicate the
output of opj_decompress.
Improves: p1_01.j2k
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Up until now, ff_avc_decode_sps would parse a SPS and return some
properties from it in a freshly allocated structure. Yet said structure
is very small and completely internal to libavformat, so there is no
reason to use the heap for it. This commit therefore changes the
function to return an int and to modify a caller-provided structure.
This will also allow ff_avc_decode_sps to return better error codes in
the future.
It also fixes a memleak in mxfenc: If a packet contained multiple SPS,
only the SPS structure belonging to the last SPS would be freed, the
other ones would leak when the pointer is overwritten to point to the
new SPS structure. Of course, without allocations there are no leaks.
This is Coverity issue #1445194.
Furthermore, the SPS structure has been renamed from
H264SequenceParameterSet to H264SPS in order to avoid overlong lines.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
After parsing the end timestamp of a WebVTT cue block, the current code
skips everything after the start of the timestamp that is not a \t, ' '
or \n and treats what is next as the start of a WebVTT cue settings list.
Yet if there is no such list, but a single \r, this will skip a part of
the cue payload (namely everything until the first occurence of \t, ' '
or \n) and treat what has not been skipped as the beginning of the
WebVTT cue settings list that extends until the next \r or \n (or the
end).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Given that AV1 only has exactly one sequence header, it is unnecessary
to copy the content of said sequence header into an intermediate dynamic
buffer; instead the sequence header can be copied from where it is in
the input buffer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Now we just use one ADTS raw frame to calculate the bit rate, it's
lead to a larger error when get the duration from bit rate, the
improvement cumulate Nth ADTS frames to get the average bit rate.
e,g used the command get the duration like:
ffprobe -show_entries format=duration -i fate-suite/aac/foo.aac
before this improvement dump the duration=2.173935
after this improvement dump the duration=1.979267
in fact, the real duration can be get by command like:
ffmpeg -i fate-suite/aac/foo.aac -f null /dev/null with time=00:00:01.97
Also update the fate-adtstoasc_ticket3715.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Currently, the zoompan filter exposes a 'time' variable (missing from docs) for use in
the 'zoom', 'x', and 'y' expressions. This variable is perhaps better named
'out_time' as it represents the timestamp in seconds of each output frame
produced by zoompan. This patch adds aliases 'out_time' and 'ot' for 'time'.
This patch also adds an 'in_time' (alias 'it') variable that provides access
to the timestamp in seconds of each input frame to the zoompan filter.
This helps to design zoompan filters that depend on the input video timestamps.
For example, it makes it easy to zoom in instantly for only some portion of a video.
Both the 'out_time' and 'in_time' variables have been added in the documentation
for zoompan.
Example usage of 'in_time' in the zoompan filter to zoom in 2x for the
first second of the input video and 1x for the rest:
zoompan=z='if(between(in_time,0,1),2,1):d=1'
V2: Fix zoompan filter documentation stating that the time variable
would be NAN if the input timestamp is unknown.
V3: Add 'it' alias for 'in_time. Add 'out_time' and 'ot' aliases for 'time'.
Minor corrections to zoompan docs.
Signed-off-by: exwm <thighsman@protonmail.com>
There is no reason to special-case writing a value of zero as uvlc
element as the generic code is perfectly capable of doing so.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It can't fail, yet it returns an int and other code checks whether it
failed; yet if it did fail, an AVFrame would leak. One could of course
add an av_frame_free for this (that compilers could optimize away), yet
it is easier to simply stop pretending that disp_palette could fail.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Given that av_get_packet returns a blank packet on error, the only
difference to the current approach (that uses intermediate AVPackets on
the stack) is that st->attached_pic will be properly initialized on error
(i.e. the timestamps are AV_NOPTS_VALUE) whereas right now st->attached_pic
is only zeroed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Document that it also sets the size in case the desired side data is
absent (if the pointer has been supplied).
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Document that it also sets the size in case the desired side data is
absent (if the pointer has been supplied).
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Commits 957a593cd9 and
11828b8885 made the flv demuxer export
a certain flag as side data to be used by the nellymoser decoder for
mid-stream sample rate changes. It used a custom side data type 'F' that
was never officially documented.
Yet since 2215c39e94 (merged in commit
52c522c720) this information is exported
via the properly documented AV_PKT_DATA_PARAM_CHANGE side data.
The merge commit therefore stopped exporting the 'F' sidedata; yet the
changes in the Nellymoser decoder (which are now dead code (and would
become dangerous if lots of new side data types were added)) have not
been removed. This commit does this.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If stream's bitrate is not specified:
- for static manifest: an average bitrate will be calculated and used,
- for dynamic manifest: first segment's bitrate will be calculated and used, as before,
for bandwidth setting in adaptation sets.
Fixes an issue with one output channel being slightly louder than
the other. The output now matches other public HCA decoders.
Signed-off-by: t <summertriangle.dev@gmail.com>
I suspect this was originally broken by b7e5c8f , but even
then, it only worked because it read out of bounds from
intensity_ratio_table.
Signed-off-by: t <summertriangle.dev@gmail.com>
Initialize avctx->pix_fmt in av1_parser.c
AV1 Chroma format is invalid when quering using below code if no AV1 decoder
is available:
iVideoStream = av_find_best_stream(fmtc, AVMEDIA_TYPE_VIDEO, -1, -1, NULL, 0);
eChromaFormat = (AVPixelFormat)fmtc->streams[iVideoStream]->codecpar->format;
Signed-off-by: James Almer <jamrial@gmail.com>
Following the same logic as 061a0c14bb, this commit turns the old encode API
into a wrapper for the new one.
Signed-off-by: James Almer <jamrial@gmail.com>
This commit follows the same logic as 061a0c14bb, but for the encode API: The
new public encoding API will no longer be a wrapper around the old deprecated
one, and the internal API used by the encoders now consists of a single
receive_packet() callback that pulls frames as required.
amf encoders adapted by James Almer
librav1e encoder adapted by James Almer
nvidia encoders adapted by James Almer
MediaFoundation encoders adapted by James Almer
vaapi encoders adapted by Linjie Fu
v4l2_m2m encoders adapted by Andriy Gelman
Signed-off-by: James Almer <jamrial@gmail.com>
dash demuxer get the stream info from sub-stream, but missed side
data/disposition part, e,g, missed the DOVI side data when the
stream is Dolby Vision streams
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
hls demuxer get the stream info from sub-stream, but missed side
data/disposition part, e,g, missed the DOVI side data when the
stream is Dolby Vision streams.
Reviewed-by <liuqi05@kuaishou.com>
Signed-off-by: vacingfang <vacingfang@tencent.com>
Currently, ffmpeg inserts scale filter by default in the filter graph
to force the whole decoded stream to scale into the same size with the
first frame. It's not quite make sense in resolution changing cases if
user wants the rawvideo without any scale.
Using autoscale/noautoscale as an output option to indicate whether auto
inserting the scale filter in the filter graph:
-noautoscale or -autoscale 0:
disable the default auto scale filter inserting.
ffmpeg -y -i input.mp4 out1.yuv -noautoscale out2.yuv -autoscale 0 out3.yuv
Update docs.
Suggested-by: Mark Thompson <sw@jkqxz.net>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
This is a requirement of the AV1-ISOBMFF spec. Section 2.1.
General Requirements & Brands states:
* It SHALL have the av01 brand among the compatible brands array of the FileTypeBox
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Only read str_size bytes from offset 30 of extradata if the extradata is
indeed at least 30 + str_size bytes long.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
mov_read_custom tries to read three strings belonging to three different
tags. When an already encountered tag is encountered again, a new buffer
for the string to be read is allocated and stored in the pointer
destined for this particular tag. But in this scenario, said pointer
already holds the address of the string read earlier, leading to a leak.
This commit therefore aborts the reading process upon encountering
an already encountered tag.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The argument pertaining to a printf %s conversion specifier must not
be NULL, even if the precision (i.e. the number of characters to write)
is zero. If it is NULL, it is undefined behaviour.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if allocating the AVStream for the subtitles fails.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle
or when creating extradata.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon creating an AVStream.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle
or when allocating extradata.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle
or if creating the extradata failed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
By default, a demuxer's read_close function is not called automatically
if an error happens when reading the header; instead it is up to the
demuxer to clean up after itself in this case. The mov demuxer did this
by calling its read_close function when it encountered some errors when
reading the header. Yet for other errors (mostly adding side-data to
streams) this has been forgotten, so that all the internal structures
of the demuxer leak.
This commit fixes this by making sure mov_read_close is called when
necessary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes possible leaks of id3v2 metadata as well as an AVDES struct in
case the content is encrypted and an error happens lateron.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
In certain error scenarios, the underlying Matroska demuxer was not
properly closed, causing leaks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When demuxing a Matroska/WebM file, streams are added for tracks and for
attachments, so that the array containing the former can be NULL even
when the corresponding AVFormatContext has streams. So check for there
to be tracks in the MatroskaDemuxContext instead of just streams in the
AVFormatContext before dereferencing the pointer to the tracks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
matroska_parse_block currently asserts that the duration is not equal to
AV_NOPTS_VALUE, but there is nothing that actually guarantees this. It
is easy to create (spec-compliant) files which run into this assert;
so replace it and instead cap the duration to INT64_MAX, as the duration
field of an AVPacket is an int64_t.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
EBML binary elements are already made reference-counted when read;
so when populating the AVStream.attached_pic, one does not need to
allocate a new buffer for the data; instead the current code just
creates a new reference to the underlying AVBuffer. But this can be
improved even further: Just move the already existing reference.
This also fixes a memleak that happens upon error because
matroska_read_close has not been called in this scenario.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
c801ab43c3 caused a regression: The stream
number is now parsed with strtoll without a fixed basis; as a
consequence, the "010" in a variant stream mapping like "a:010" is now
treated as an octal number (i.e. as eight, not ten). This was not
intended and may break some scripts, so this commit restores the old
behaviour.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Commit 17e88bf0df created a memleak by
removing a call to ff_iir_filter_free_coeffsp on error; this has been
found by Coverity (ID 1464159). This commit fixes the memleak by
readding the call to ff_iir_filter_free_coeffsp.
Notice that this is not a simple revert, because several macros that
were used before 17e88bf0df were replaced
in commit 44863b2c2d and completely removed
in 2658680df4.
Reviewed-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The hevc_mp4toannexb bsf does not explicitly check whether a NAL unit
is so big that it extends beyond the end of the input packet; it does so
only implicitly by using the checked version of the bytestream2 API.
But this has downsides compared to real checks: It can lead to huge
allocations (up to 2GiB) even when the input packet is just a few bytes.
And furthermore it leads to uninitialized data being output.
So add a check to error out early if it happens.
Also check directly whether there is enough data for the length field.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If this happens, it's a sign of parsing issues earlier in the process, or
misuse by the calling module.
Prevents writing invalid bitstreams.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
If this happens, it's a sign of parsing issues earlier in the process, or
misuse by the calling module.
Prevents writing invalid bitstreams.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Max region ID is 87. Also the region affects not only the G0 charset but G2 and
the national subset as well.
Signed-off-by: Marton Balint <cus@passwd.hu>
Alternatively these conditions could be treated as errors
Fixes: 23147/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFWAVESYNTH_fuzzer-5639254549200896
Fixes: signed integer overflow: 9223372036854775807 + 1 cannot be represented in type 'int64_t' (aka 'long')
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: -144876608 * 16 cannot be represented in type 'int'
Fixes: 22782/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-6039584977977344
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: 2142077091 + 6881070 cannot be represented in type 'int'
Fixes: 22737/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-5958388889681920
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: -234 * -14797801 cannot be represented in type 'int'
Fixes: 20492/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SONIC_fuzzer-5695924975435776
Fixes: 22275/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SONIC_fuzzer-5695924975435776
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: 2129689466 + 2129689466 cannot be represented in type 'int'
Fixes: 20715/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SONIC_fuzzer-5155263109922816
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: 22082/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5688619118624768
Fixes: crash from V-codecs/Theora/theora_testsuite_broken/multi2.ogg
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Suggested-by: Lynne on IRC
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
256 bits is just wide enough to fit all the operands needed to vectorize
the software implementation, but AVX2 is needed to for a couple of
instructions like cross-lane permutation.
Output is bit-for-bit identical to C.
Signed-off-by: Nelson Gomez <nelson.gomez@microsoft.com>
Extracting information from SwsContext in assembly is difficult, and
rearranging SwsContext just for asm access didn't look good. These
functions only need a couple of fields from it anyway, so just make
them parameters in their own right.
Signed-off-by: Nelson Gomez <nelson.gomez@microsoft.com>
Previously, prompeg_write() would only report to caller that bytes we
written when a FEC packet was actually created. Not all RTP packets are
expected to generate a FEC packet however, so this behavior was causing
avio to retry writing the RTP packet, eventually forcing the FEC state
machine to send a FEC packet erroneously (and so breaking out of the
retry loop).
This was resulting in incorrect FEC data being generated, and far too
many FEC packets to be sent (~100% FEC overhead).
fix#7863
Signed-off-by: David Holroyd <david.holroyd@m2amedia.tv>
make checkheaders will get warning as follow:
In file included from libavcodec/qsv_internal.h.c:1:
./libavcodec/qsv_internal.h:24:5: warning: "CONFIG_VAAPI" is not defined, evaluates to 0 [-Wundef]
24 | #if CONFIG_VAAPI
| ^~~~~~~~~~~~
include "config.h" to fix the warning
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
These functions have a terrible design, let us fix them before extending
them.
First design mistake: no error code. A helper function for testing
memory allocation failure where AVERROR(ENOMEM) does not appear is
absurd.
Second design mistake: printing a message. Return the error code, let
the caller print the error message.
Third design mistake: hard-coded use of goto.
http://ffmpeg.org/pipermail/ffmpeg-devel/2020-May/262544.html
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Fixes: signed integer overflow: 9223372036854775807 - -1 cannot be represented in type 'long'
Fixes: 23167/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6425051741290496
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This should make it easier for the fuzzer to fuzz formats being detected only by
file extension and thus increase coverage
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Two kinds of errors can happen when working with dynamic buffers:
(Re)allocation errors or truncation errors (one has to truncate the
buffer to a size of INT_MAX because avio_close_dyn_buf() and
avio_get_dyn_buf() both return an int). Right now, avio_get_dyn_buf()
returns an empty buffer in either case. But given that
avio_get_dyn_buf() does not destroy the dynamic buffer, one can return
the buffer in case of truncation and let the user check the error flags
and decide for himself instead of hardcoding a single way to proceed
in case of truncation.
(This actually restores the behaviour from before commit
163bb9ac0af495a5cb95441bdb5c02170440d28c.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This has originally been done in 568e18b15e
as a precaution against integer overflows, but it is actually easy to
support the full range of int without overflows.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If adding two ints overflows, it doesn't matter whether the result will
be stored in an unsigned or not; and checking afterwards does not make it
retroactively defined.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Use opaque iteration state instead of the previous child class. This
mirrors similar changes done in lavf/lavc.
Deprecate the av_opt_child_class_next() API.
current_picture was not writable here because a reference existed in
at least avctx->coded_frame, and potentially elsewhere if the caller
created new ones from it.
Signed-off-by: James Almer <jamrial@gmail.com>
The "-deinterlace" was deprecated since d7edd35, over eight years
ago.
Refer to deinterlacing filters instead.
Signed-off-by: Moritz Barsnick <barsnick@gmx.net>
It is a constant known at codec init, so set it in
ff_frame_thread_init(). Also, only set it for video, since the meaning
of this field is not well-defined for audio with frame threading.
Fixes availability of delay in callbacks invoked from the per-thread
contexts after 1f4cf92cfb.
Requires the presence of the SVT-AV1 headers and library during configuration.
You need to explicitly configure the build with @code{--enable-libsvtav1}.
@subsection Options
@table @option
@item profile
Set the encoding profile.
@item level
Set the operating point level.
@item tier
Set the operating point tier.
@item rc
Set the rate control mode to use.
Possible modes:
@table @option
@item cqp
Constant quantizer: use fixed values of qindex (dependent on the frame type)
throughout the stream. This mode is the default.
@item vbr
Variable bitrate: use a target bitrate for the whole stream.
@item cvbr
Constrained variable bitrate: use a target bitrate for each GOP.
@end table
@item qmax
Set the maximum quantizer to use when using a bitrate mode.
@item qmin
Set the minimum quantizer to use when using a bitrate mode.
@item qp
Set the quantizer used in cqp rate control mode (0-63).
@item sc_detection
Enable scene change detection.
@item la_depth
Set number of frames to look ahead (0-120).
@item preset
Set the quality-speed tradeoff, in the range 0 to 8. Higher values are
faster but lower quality. Defaults to 8 (highest speed).
@item tile_rows
Set log2 of the number of rows of tiles to use (0-6).
@item tile_columns
Set log2 of the number of columns of tiles to use (0-4).
@end table
@section libkvazaar
@@ -1981,6 +2177,38 @@ midpoint is passed in rather than calculated for a specific clip or chunk.
The valid range is [0, 10000]. 0 (default) uses standard VBR.
@item enable-tpl @var{boolean}
Enable temporal dependency model.
@item ref-frame-config
Using per-frame metadata, set members of the structure @code{vpx_svc_ref_frame_config_t} in @code{vpx/vp8cx.h} to fine-control referencing schemes and frame buffer management.
The output filename can be empty (or @code{-}) to refer to the default system output device or a number that refers to the device index as shown using: @code{-list_devices true}.
Alternatively, the audio input device can be chosen by index using the
@option{
-audio_device_index <INDEX>
}
, overriding any device name or index given in the input filename.
All available devices can be enumerated by using @option{-list_devices true}, listing
all device names, UIDs and corresponding indices.
@subsection Options
AudioToolbox supports the following options:
@table @option
@item -audio_device_index <INDEX>
Specify the audio device by its index. Overrides anything given in the output filename.
@end table
@subsection Examples
@itemize
@item
Print the list of supported devices and output a sine wave to the default device:
{"dsurex_mode","Dolby Surround EX Mode",OFFSET(dolby_surround_ex_mode),AV_OPT_TYPE_INT,{.i64=AC3ENC_OPT_NONE},AC3ENC_OPT_NONE,AC3ENC_OPT_DSUREX_DPLIIZ,AC3ENC_PARAM,"dsurex_mode"},
{"dsurex_mode","Dolby Surround EX Mode",OFFSET(dolby_surround_ex_mode),AV_OPT_TYPE_INT,{.i64=AC3ENC_OPT_NONE},AC3ENC_OPT_NONE,AC3ENC_OPT_DSUREX_DPLIIZ,AC3ENC_PARAM,"dsurex_mode"},
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.
