This returns to code closer to prior 56c334d732
The prior fixes should limit the sum and avoid the need for double argument log2()
Fixes: Assertion n>=0 && n<=32 failed at libavcodec/get_bits.h:406
Fixes: 410109093/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6550900028276736
No testcases except fuzzers
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 a5f861d335)
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: 410109093/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6550900028276736
Note, none of the available osq files uses update_stats(), this change may fix or break
files using coding_mode == 2. The code prior looks wrong though
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 c909ef31be)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The code uses int, unsigned int and uint16_t to store num_entry_point_offsets
This limits it to the smallest of the 3.
Alternatively uint16_t can be changed and then a larger limit used.
A Check will still be needed.
Fixes: 391974932/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5966648879677440
Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
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 791a333a0e)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Dithering relies on a 8 line dithering table and the code always uses it from
the beginning. So in order to make dithering independent from height of the
slices used we must enforce a 8 line alignment.
Fixes issue #20071.
Signed-off-by: Marton Balint <cus@passwd.hu>
(cherry picked from commit b61e510e75)
The issue is that:
float en[2];
...
tns->n_filt[w] = is8 ? 1 : order != TNS_MAX_ORDER ? 2 : 3;
for (g = 0; g < tns->n_filt[w]; g++) {
tns->direction[w][g] = slant != 2 ? slant : en[g] < en[!g];
When using the AAC Main profile, n_filt = 3, and slant is by
default 2 (normal long frames), g can go above 1.
en is the evolution of energy in the frequency domain for every
band at the given window. E.g. whether the energy is concentrated
at the top of each band, or the bottom.
For 2-pole filters, its straightforward.
For 3-pole filters, we need more than 2 measurements.
This commit properly implements support for 3-pole filters, by measuring
the band energy across three areas.
Do note that even xHE-AAC caps n_filt to 2, and only AAC Main allows
n_filt == 3.
Fixes https://trac.ffmpeg.org/ticket/11418
(cherry picked from commit ed09aa28ae3b4509f00a24a9ebdeb084ee00736a)
Regardless of the source being an AVFMT_NOTIMESTAMPS format, if the timestamps
are generated like when using the use_wallclock_as_timestamps demuxer option,
then they are reliable.
Fixes ticket #11268
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit 1787fade20)
We may write up to 43 bits, so 5 bytes is not enough.
Fixes: Assertion n>=0 && n<=32 failed at ./libavcodec/get_bits.h:406
Fixes: 398527871/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-6602025714647040
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: James Almer <jamrial@gmail.com>
The encoder uses max 128 taps, which is quiet a lot already
If work is done to improve sonic, it will be more radical than changing the taps
Fixes: Timeout
Fixes: 402539974/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SONIC_fuzzer-6122944271286272
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 fd0a792766)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is based on discussion with the GA and its simply the people
who have done or tried to do some uploads recently.
Everyone who has a shell account on ffmpeg.org should have powers to
upload samples.
CC: compn <compn@ffmpeg.org>
CC: Thilo Borgmann <thilo.borgmann@mail.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 1a5ed492e5)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When decoding a bitstream with weighted-bipred enabled,
the results on ARM and x86 platforms may differ.
The reason for the inconsistency is that the value of
STRIDE_ALIGN differs between platforms. And STRIDE_ALIGN
is set to the buffer stride of temporary buffers for U
and V components in mc_part_weighted.
If the buffer stride is 32 or 64 (as on x86 platforms),
the U and V pixels can be interleaved row by row without
overlapping, resulting in correct output.
However, on ARM platforms where the stride is 16,
the V component did overwrite part of the U component's pixels,
leading to incorrect predicted pixels.
The bug can be reproduced by the following bitstream.
https://trac.ffmpeg.org/attachment/ticket/11357/inter_weighted_bipred2.264
Fixes: ticket 11357
Commit-msg-mostly-by: Bin Peng <pengbin@visionular.com>
Reviewed-by: Bin Peng <pengbin@visionular.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 74fd2c3ddb)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This differs from libvorbis by
stddev: 2.44 PSNR: 88.58 MAXDIFF: 41 bytes: 834304/ 834304
for the file from the ticket
Fixes: Ticket11427
Regression since: dc89cf804a
This is a similar solution to what james proposed earlier in
[FFmpeg-devel] [PATCH] avcodec/vorbisdec: don't abort on EOD when decoding residuals
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit fd5a3c5fed)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This allows the user to set only the one that is needed to ALL or a
specific "wrong" extension like html
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit f99f223eb1)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes part of Ticket11435
Fixes: Elisa Viihde (Finnish online recording service)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 68644994fd)
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: 390646659/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-5040277374435328
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 c6a889f3e0)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
t_info.keyframe_granule_shift is set to the library default of 6, which is ok
for gop sizes up to 63. Since there's apparently no way to query the updated
value after having forced a gop value with TH_ENCCTL_SET_KEYFRAME_FREQUENCY_FORCE,
calculate it manually instead.
Fixes ticket #11454.
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit 22aa71d4da)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes mixing up contexts, use of uninitialized data and crashes.
More specifically:
==1001752== Conditional jump or move depends on uninitialised value(s)
==1001752== at 0xA9ED82: avpriv_h264_has_num_reorder_frames (h264dec.c:64)
==1001752== by 0x668C7E: has_decode_delay_been_guessed (demux.c:757)
==1001752== by 0x66AB13: compute_pkt_fields (demux.c:1137)
==1001752== by 0x66B2E9: parse_packet (demux.c:1265)
==1001752== by 0x66BD84: read_frame_internal (demux.c:1449)
==1001752== by 0x67085B: avformat_find_stream_info (demux.c:2692)
==1001752== by 0x25157C: ifile_open (ffmpeg_demux.c:1814)
==1001752== by 0x272B15: open_files (ffmpeg_opt.c:1366)
==1001752== by 0x272D85: ffmpeg_parse_options (ffmpeg_opt.c:1415)
==1001752== by 0x2925C9: main (ffmpeg.c:991)
==1001752== Uninitialised value was created by a heap allocation
==1001752== at 0x483E0F0: memalign (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==1001752== by 0x483E212: posix_memalign (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==1001752== by 0x14882CE: av_malloc (mem.c:107)
==1001752== by 0x1463785: av_buffer_alloc (buffer.c:82)
==1001752== by 0x146423F: pool_alloc_buffer (buffer.c:369)
==1001752== by 0x14643C4: av_buffer_pool_get (buffer.c:407)
==1001752== by 0x752C4B: buffer_pool_get (mpegts.c:1142)
==1001752== by 0x7538F2: mpegts_push_data (mpegts.c:1407)
==1001752== by 0x758893: handle_packet (mpegts.c:2909)
==1001752== by 0x758E90: handle_packets (mpegts.c:3048)
==1001752== by 0x759B1D: mpegts_read_packet (mpegts.c:3290)
==1001752== by 0x6687A3: ff_read_packet (demux.c:649)
==1001752== by 0x66B594: read_frame_internal (demux.c:1346)
==1001752== by 0x67085B: avformat_find_stream_info (demux.c:2692)
==1001752== by 0x25157C: ifile_open (ffmpeg_demux.c:1814)
==1001752== by 0x272B15: open_files (ffmpeg_opt.c:1366)
==1001752== by 0x272D85: ffmpeg_parse_options (ffmpeg_opt.c:1415)
==1001752== by 0x2925C9: main (ffmpeg.c:991)
Found-by: Alexander A. Shvedov <shvedov@gmx.com>
CC: Pavel Koshevoy <pkoshevoy@gmail.com>
This reverts commit 0021484d05.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Legal since commit 1cd0a9be4b2d1e7c60184ec68404e00e46e3123e
(Jan 4) in the Cellar Matroska specification git repo.
We still hold out on muxing it due to compatibility with
old demuxers.
Reviewed-by: compn <ff@hawaiiantel.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 8a936b8726)
The structure is padded to an even length with an internal
size field to indicate the real size.
The matroska-matroska-display-metadata test (writing FFV1
in VFW mode) was affected by this.
It should also fix ticket #11613.
Reviewed-by: compn <ff@hawaiiantel.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 92e310eb82)
On msys2, `uname -m` returns the architecture of the base msys2
layer. On Windows on arm64, the base msys2 layer itself is still
x86_64 only, even if running with e.g. the clangarm64 where the
windows native applications are built as aarch64.
If MSYSTEM_CARCH is set, use this instead of `uname -m` for
the default architecture. This gives the correct behaviour
for the clangarm64 environments. It also gives the correct
default for the 32 bit x86 environments such as `mingw32`.
(On `mingw32`, the fact that `uname -m` returned `x86_64`
hasn't been an issue, as both that and `i686` gets normalized
into `x86` internally in ffmpeg's configure.)
Signed-off-by: Coia Prant <coiaprant@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit df967d095a)
The buffer references may not be writable at this point, as the decoder
calls get_buffer2() with the AV_GET_BUFFER_FLAG_REF flag.
Fixes races as reported by tsan, producing correct output regardless of
threading choices.
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit 8eae65dc5c)
I have several .ts captures where video and audio codec changes even
though the PMT version does not change and the PIDs stay the same.
This happens during transition to/from slate (mpeg2 video and audio)
to network broadcast (hevc video and eac3 audio in private PES).
I've updated fate ts-demux expected results.
