The current design, where
- proper init is called for the first per-thread context
- first thread's private data is copied into private data for all the
other threads
- a "fixup" function is called for all the other threads to e.g.
allocate dynamically allocated data
is very fragile and hard to follow, so it is abandoned. Instead, the
same init function is used to init each per-thread context. Where
necessary, AVCodecInternal.is_copy can be used to differentiate between
the first thread and the other ones (e.g. for decoding the extradata
just once).
Affected the FATE-tests exr-rgb-scanline-pxr24-half-uint32-13x9 and
exr-rgb-scanline-pxr24-uint32.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Out of memory
Fixes: 11582/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-5730204559867904
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: 6154/clusterfuzz-testcase-minimized-5762231061970944
Fixes: runtime error: shift exponent 63 is too large for 32-bit 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>
Fixes: Out of heap array read
Fixes: 4683/clusterfuzz-testcase-minimized-6152313673613312
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
Fixes: 3787/clusterfuzz-testcase-minimized-5728764920070144
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>
reorder_pixels is call by rle_uncompress and zip_uncompress
with size == uncompress_size
uncompress_size is a multiple of 2 (because exr store data
in half, float, or uint32)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
looks like there is a bug in commit
1a08758e7c relating to the handling of
ptr in decode_frame after decode_block is called, before this commit
ptr would have been incremented for each line in the data window, now
after the commit it is left at the start of the first included line
rather than the line after the data window then the code sets the
remaining lines to 0 and thus the whole image is over written.
Fix by adjusting ptr to the correct line after decode_block returns
Signed-off-by: Kevin Wheatley <kevin.j.wheatley@gmail.com>
uint32 need 4 bytes not 1.
Fix decoding when there is half/float and uint32 channel.
This fixes crashes due to pointer corruption caused by invalid writes.
The problem was introduced in commit
03152e74df.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
channel_index can be -1.
This problem was introduced in commit
2dd7b46132.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This also disabled the case of mixed x/ymin with tiles, the code
handles these cases inconsistent for the 2 coordinate axis and is
unlikely working correctly.
Fixes crash
Fixes: poc1.exr, poc2.exr
Found-by: Yaoguang Chen of Aliapy unLimit Security Team
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
a gray channel in exr, is named Y
we admit that the file need to be interpreted as gray
only if no other channel match (except alpha)
to manage RGB and Y in the color conversion part of decode_block,
the color processing is now made with a for loop.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
fix ticket #5674
the size of data to process in piz_uncompress, is now calc
using the pixel type of each channel.
the data reorganization, alos take care about the size of
each channel
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
