This was previously adjusted by me in 6b3f9c2e92.
Unfortunately, I traded one integer overflow bug for
another.
Currently, NTP timestamps that exceed INT64_MAX
(~Jan 20, 1968) will cause an overflow when passed
to av_rescale.
This patch replaces av_rescale, which operates on
int64_t, with ff_parse_ntp_time, which operates on
uint64_t. This will give the correct values for
timestamps back around the NTP epoch and present day
timestamps.
Fixes ticket #11388.
Signed-off-by: Martin Storsjö <martin@martin.st>
Fixes: 377965565/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1_fuzzer-4504434689769472
Fixes: out of array access
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 5 out of bounds for type 'uint8_t [5]'
Fixes: 377748135/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-5167109774049280
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: -nan is outside the range of representable values of type 'int'
Fixes: 377072730/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-6545416570601472
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 * -4962931467012268000 cannot be represented in type 'long'
Fixes: 376496313/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-4921469185884160
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: 1239596184 + 2119376059 cannot be represented in type 'int'
Fixes: 376136844/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6581164455821312
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: -1082982400 + -1195645138 cannot be represented in type 'int'
Fixes: 376136843/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-4791844321427456
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: crash
Found-by: Elias Myllymäki <elias.myllymaki04p@gmail.com>
Reviewed-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array read
Found-by: Elias Myllymäki <elias.myllymaki04p@gmail.com>
Reviewed-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This sample is rather difficult, containing a lot of subtle edge cases
which revealed errors in the VVC decoder. It covers 88.4% of lines in
libavcodec/vvc and brings the line coverage of the entire VVC fate suite
from 96.3% to 97.2%.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: James Almer <jamrial@gmail.com>
In mpeg_decode_a53_cc() only the A/53 part 4 CC data ("GA94") is saved between
frames. The other formats incorrectly created a larger buffer than they use
since a705bcd763 because they did not append to
the previous data.
The a53_buf_ref is added to the frame in mpeg_field_start() which will only be
called in decode_chunks() if not all of the picture data slices are skipped.
For these formats, utilize the data added to the buffer in case frames are skipped
(concatenating the CC data until a frame can be exported), in a similar fashion to
the A/53 part 4 logic.
Reviewed-by: Marth64 <marth64@proxyid.net>
Signed-off-by: Marth64 <marth64@proxyid.net>
After support was added for DVB 0502 Closed Caption coding,
the cc_format option's range was never updated so user
cannot select this coding as a forced formatting choice.
Fix the range of the option by ending it with the new coding type.
Signed-off-by: Marth64 <marth64@proxyid.net>
Fix the incorrect capitalization of the project name in a comment.
The project is named FFmpeg, not FFMpeg.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
This will ensure any future goto leave that may be added doesn't accidentally forget to
set ret to some proper value.
Reviewed-by: Timo Rothenpieler <timo@rothenpieler.org>
Signed-off-by: James Almer <jamrial@gmail.com>
When muxing to FLV/RTMP a MP3 track with an ID greater than zero,
enhanced RTMP has to be used, and a sequence start should preceed track
data.
This is already implemented (see line 823 of flvenc.c) but the code is
never reached due to a too-strict condition before it. This patch fixes
the issue.
Signed-off-by: Alessandro Ros <aler9.dev@gmail.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
The scale_vulkan filter initializes the shader once, with the crop
region set by the original frame. However, subsequent frames may
specify a different crop region than the first frame. This change
updates the cropping to match the behavior present on the other
hardware frame scale filters.
The scale filter should also allow negative values
that respect aspect ratio, similar to other scale filters.
Signed-off-by: Koushik Dutta <koushd@gmail.com>
These properties are unreliable because they depend on the frames decoded so
far, users should check directly the presence of the decoded AVFrame side data
or AVFrame flags.
Signed-off-by: Marton Balint <cus@passwd.hu>
When the current subpicture has sps_subpic_treated_as_pic_flag equal to
1, motion vectors are cropped such that they cannot point to other
subpictures. This was accounted for in the prediction logic, but not
in pred_get_y, which is used by the scheduling logic to determine which
parts of the reference pictures must have been reconstructed before
inter prediction of a subsequent frame may begin. Consequently, where a
motion vector pointed to a location significantly above the current
subpicture, there was the possibility of a race condition. Patch fixes
this by cropping the motion vector to the current subpicture in
pred_get_y.
Signed-off-by: Frank Plowman <post@frankplowman.com>
When a stream has ALF filtering enabled but not CC-ALF, the CC-ALF set indexes alf->ctb_cc_idc are being read uninitialized during ALF filtering.
This change initializes alf->ctb_cc_idc whenever ALF is enabled.
Ref. https://trac.ffmpeg.org/ticket/11325
Indexes in tile_grid->offsets were fixed in the previous commit, but just in case,
make sure to not overread the streams array.
Signed-off-by: James Almer <jamrial@gmail.com>
The amount of tiles does not necessarely need to match the amount of streams referenced
in the grid, as there could be duplicates.
Don't silently ignore EEXIST return codes from avformat_stream_group_add_stream() and
instead store the index of the duplicate stream.
Signed-off-by: James Almer <jamrial@gmail.com>
References https://trac.ffmpeg.org/ticket/11387
Defining anchors is needed, even when a filename with the labels is set.
The issue was identified when using yolov4-tiny model using openvino.
More information about how to reproduce the bug can be found on the trac
issue referenced by this commit.
Signed-off-by: Leandro Santiago <leandrosansilva@gmail.com>
A new codec ID has been added to avcodec for animated JPEG XL, so
we should use that in the animated JPEG XL demuxer.
Reviewed-by: Marth64 <marth64@proxyid.net>
Signed-off-by: Leo Izen <leo.izen@gmail.com>
libjxl supports animated encoding, so we add a wrapper to the
library using the receive_packet callback method.
This code was based largely on a patch sent by Zsolt Vadász,
although it was updated to use more recent coding practices
and many of the leaks and issues were fixed.
Reviewed-by: Marth64 <marth64@proxyid.net>
Co-authored-by: Zsolt Vadász <zsolt_vadasz@protonmail.com>
Signed-off-by: Leo Izen <leo.izen@gmail.com>
The arm/aarch64 horizontal filter reads one additional pixel beyond what
the filter uses. This can become an issue if the application does not
allocate larger buffers than what's required for the pixel data. If the
motion vector points to the bottom right edge of the picture this
becomes a read buffer overflow. This triggers segfaults in Firefox for
video resolutions which result in a page aligned picture size like
1280x640.
Prevent this by using emulated edge in this case.
Fixes: https://bugzilla.mozilla.org/show_bug.cgi?id=1881185
Signed-off-by: Janne Grunau <janne-ffmpeg@jannau.net>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This reduces the amount the horizontal filters read beyond the filter
width to a consistent 1 pixel. The data is not used so this is usually
not noticeable. It becomes a problem when the application allocates
frame buffers only for the aligned picture size and the end of it is at
a page boundary. This happens for picture sizes which are a multiple of
the page size like 1280x640. The frame buffer allocation is based on
its most likely done via mmap + MAP_ANONYMOUS so start and end of the
buffer are page aligned and the previous and next page are not
necessarily mapped.
This mirrors the aarch64 change.
Signed-off-by: Janne Grunau <janne-ffmpeg@jannau.net>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This reduces the amount the horizontal filters read beyond the filter
width to a consistent 1 pixel. The data is not used so this is usually
not noticeable. It becomes a problem when the application allocates
frame buffers only for the aligned picture size and the end of it is at
a page boundary. This happens for picture sizes which are a multiple of
the page size like 1280x640. The frame buffer allocation is based on
its most likely done via mmap + MAP_ANONYMOUS so start and end of the
buffer are page aligned and the previous and next page are not
necessarily mapped.
Under these conditions like seen by Firefox a read beyond the end of the
buffer results in a segfault.
After the over-read is reduced to a single pixel it's reasonable to use
VP9's emulated edge motion compensation for this.
Fixes: https://bugzilla.mozilla.org/show_bug.cgi?id=1881185
Signed-off-by: Janne Grunau <janne-ffmpeg@jannau.net>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
