On Tue, Mar 07, 2017 at 08:35:33AM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Mar 6, 2017 at 8:41 PM, Michael Niedermayer <mich...@niedermayer.cc>
> wrote:
>
> > -void ff_vp56_init_range_decoder(VP56RangeCoder *c, const uint8_t *buf,
> > int buf_size)
> > +int ff_vp56_init_range_decoder(VP56RangeCoder *c, const uint8_t *buf,
> > int buf_size)
> > {
> > c->high = 255;
> > c->bits = -16;
> > c->buffer = buf;
> > c->end = buf + buf_size;
> > + if (buf_size < 1)
> > + return AVERROR_INVALIDDATA;
> > c->code_word = bytestream_get_be24(&c->buffer);
> > + return 0;
> > }
>
>
> Isn't this AV_INPUT_BUFFER_PADDING_SIZE?There was no out of array access, the issue was that the code spend alot of time doing nothing as a result of 0 bytes input being turned into 16bits of available data repeatly. I intended to suggest to adjust the 16 to 8 on a 1 byte buf_size subsequently > > And this is inconsistent with the silent failure in renorm(). testing each use of renorm likely would cause a speed loss, such a failure should be caught by the explicit end of bitstream checks on the other loops [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
