On Sun, May 12, 2019 at 01:24:56PM +0200, Reimar Döffinger wrote:
> On 12.05.2019, at 08:12, Peter Ross <pr...@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)
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
