Hi Ronald,
On 07.06.2015 17:52, Ronald S. Bultje wrote:
> On Sun, Jun 7, 2015 at 10:05 AM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>
>> +#define MARGIN (16 << 2)
>> +#define MAX_MB_SIZE (((INT16_MAX - MARGIN) >> 6) + 1)
>>
>
> So this is roughly 9 bits.
>
>
>> + if (s->avctx->coded_width > MAX_MB_SIZE * 16 ||
>> + s->avctx->coded_height > MAX_MB_SIZE * 16) {
>> + av_log(s->avctx, AV_LOG_ERROR, "too large dimensions %dx%d\n",
>> + s->avctx->coded_width, s->avctx->coded_height);
>> + return AVERROR_INVALIDDATA;
>> + }
>
>
> And this makes it 13, so we have a max w/h of around ~8k.
That is 8176 and thus mb_width/mb_height can maximally be 511.
> That's not very
> big. Does that conform to any code in libvpx? Is it possible mv_max.x/y
> should be 32bit instead?
The type of mv_max is VP56mv, which is used in quite many places, so
I'm not overly confident in changing that.
And it seems libvpx uses short [1], which should be equivalent to int16_t.
> We can't simply claim that 8k is not a valid dimension, that would make us
> a vp8-incompatible decoder if vp8 stream dimensions are allowed to be >8k.
> This could particularly happen in images (webp).
I'd change the error to AVERROR_PATCHWELCOME as Michael suggested, so feel
free to fix this limitation. ;)
Best regards,
Andreas
1: https://sources.debian.net/src/libvpx/1.3.0-3/vp8/common/mv.h/?hl=16#L16
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
