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: out of array access
Fixes: 24823/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-4855119863349248
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
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>
Here it even leads to the complete removal of the context.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
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>
The frame will only be allocated a few lines below.
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>
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>
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>
"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>
Fixes: out of array access
Fixes: 24604/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-4843529818603520
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
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
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>
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>
Paul B Mahol
Gautam Ramakrishnan
Michael Niedermayer
Xiaohan Wang
Andreas Rheinhardt
James Almer
Derek Buitenhuis
Jan Ekström
Mark Thompson
Andriy Gelman