[FFmpeg-devel] [PATCH 1/2] VP4 video decoder

Peter Ross pross at xvid.org
Tue May 14 15:37:03 EEST 2019


On Sun, May 12, 2019 at 01:24:56PM +0200, Reimar Döffinger wrote:
> On 12.05.2019, at 08:12, Peter Ross <pross at xvid.org> wrote:
> > +static int read_mb_value(GetBitContext *gb)
> > +{
> > +    int v = 1;
> > +    int size;
> > +
> > +    do {
> > +        size = 0;
> > +        if (!get_bits1(gb))
> > +            break;
> > +        v++;
> > +        do {
> > +            if (!get_bits1(gb))
> > +                break;
> > +            v += 1 << size++;
> > +        } while (size < 8);
> > +    } while (size == 8);
> > +
> > +    if (size)
> > +        v += get_bits(gb, size);
> > +
> > +    return v;
> > +}
> 
> Maybe not worth it performance wise, but did you check if this could be simplified?
> For example the get_bits1 cases that end up with size 0 could return directly.
> Or it could peek ahead 9 bits in the bitstream and count the leading 1s to get v and size without looping (i.e. loop only for the 9 bits of 1s specifically).
> Alternatively add a comment to clarify the encoding scheme it implements (like 9 consecutive 1s is a prefix encoding an offset of 257 etc).

thanks for these suggestions.

replacing get_bits() with OPEN_READER/UPDATE_CACHE/SHOW_UBITS/etc results in a
consistent 0.50 % speedup.

checking the initial bit, and returning from the function early, appears to make
no difference to decoder speed.

moving 'v += 1 << size++' to go outside the inner loop makes it more clear
what the algorithm is doing. i was hoping for a speed improvement, but see no change.

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20190514/e3a7ddc5/attachment.sig>


More information about the ffmpeg-devel mailing list