[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