Reviewed-by: Alexander Strasser <eclipse7@gmx.net>
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Reviewed-by: Alexander Strasser <eclipse7@gmx.net>
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
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).
It leads to an assert in ff_read_packet().
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
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: division by zero
Fixes: 24253/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-6250318007107584
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: -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>
Reads color_primaries, color_trc and color_space from mxf
headers. ULs are from https://registry.smpte-ra.org/ site.
Signed-off-by: Harry Mallon <harry.mallon@codex.online>
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>
