Hi, 2011/12/15 Måns Rullgård <[email protected]>
> "Ronald S. Bultje" <[email protected]> writes: > > > From: "Ronald S. Bultje" <[email protected]> > > > > Based on work (for GCI) by Aneesh Dogra <[email protected]>, and > > inspired by patch in Chromium by Chris Evans <[email protected]>. > > > > When turned on, H264/CAVLC gets ~15% (CVPCMNL1_SVA_C.264) slower for > > ultra-high-bitrate files, or ~2.5% (CVFI1_SVA_C.264) for lower-bitrate > > files. Other codecs are affected to a lesser extent because they are > > less optimized; e.g., VC-1 slows down by less than 1% (all on x86). > > The patch generated 3 extra instructions (cmp, cmovae and mov) per > > call to get_bits(). > > --- > > configure | 2 ++ > > libavcodec/get_bits.h | 48 > ++++++++++++++++++++++++++++++++++++++++++++++-- > > libavcodec/wmavoice.c | 2 ++ > > 3 files changed, 50 insertions(+), 2 deletions(-) > > [...] > > > // FIXME name? > > +#if UNCHECKED_BITSTREAM_READER > > # define SKIP_COUNTER(name, gb, num) name##_index += (num) > > +#else > > +# define SKIP_COUNTER(name, gb, num) name##_index = \ > > + (gb)->size_in_bits_plus1 - name##_index < (num) ? \ > > + (gb)->size_in_bits_plus1 : name##_index + (num) > > +#endif > > Why +1? Is this for the hypothetical decoders that require overreading? > Which are those, and why don't we fix them? > It's so get_bits_left() returns -1 on overread. I agree we should fix them but there's so many of them that I lost track. > @@ -230,7 +263,12 @@ static inline int get_bits_count(const GetBitContext > *s) { > > static inline void skip_bits_long(GetBitContext *s, int n){ > > OPEN_READER(re, s); > > re_bit_count += n; > > +#if UNCHECKED_BITSTREAM_READER > > re_buffer_ptr += re_bit_count>>5; > > +#else > > + re_buffer_ptr = FFMIN(re_buffer_ptr + (re_bit_count >> 5), > > + (const uint32_t *) s->buffer_end); > > +#endif > > This addition can overflow. > Changed locally to: re_buffer_ptr = (re_bit_count >> 5) < (const uint32_t *) s->buffer_end - re_buffer_ptr ? re_buffer_ptr + (re_bit_count >> 5) : (const uint32_t *) s->buffer_end; Ronald
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
