>
> Yes, that is a better fix. Can you send a proper patch for this?
>
> Best regards,
> Andreas
>
> Yes i will send a patch for this.
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> td->xsize = 800
> td->ysize = 16
> s->current_channel_offset = 5
> td->channel_line_size = s->current_channel_offset * td->xsize = 4000
> uncompressed_size = td->channel_line_size * td->ysize = 64000
>
> s->nb_channels = 3
>
> p s->channels[0].pixel_type = EXR_HALF
> expected_len = td->xsize *
On 16.11.2016 22:16, Martin Vignali wrote:
> I think the trouble come from another place
> The current channel offset is not correct for uint32 (because it use 1<<0 = 1
> instead of 4 for uint32)
>
> Some months ago i propose a patch who was not accepted for uint32 support in
> exr.
> But the cu
Hi,
On 16.11.2016 21:29, Martin Vignali wrote:
> in what case expected_len can be > to uncompress_size ?
td->xsize = 800
td->ysize = 16
s->current_channel_offset = 5
td->channel_line_size = s->current_channel_offset * td->xsize = 4000
uncompressed_size = td->channel_line_size * td->ysize = 64000
>
> +expected_len = FFMIN(expected_len, uncompressed_size);
> +
> dest_len = expected_len;
>
>
> Hello,
in what case expected_len can be > to uncompress_size ?
Did you have a test sample ?
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmp
This fixes crashes due to pointer corruption caused by invalid writes.
The problem was introduced in commit
03152e74dfdc7f438cb4a10402c4de744e807e22.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/exr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/exr.c b/libavcodec/exr.c
i
