[FFmpeg-devel] [PATCHv3] On2 VP7 decoder

Ronald S. Bultje rsbultje at gmail.com
Tue Feb 25 16:53:17 CET 2014


Hi,

On Tue, Feb 25, 2014 at 4:37 AM, Peter Ross <pross at xvid.org> wrote:

> On Tue, Feb 18, 2014 at 09:52:30PM +1100, Peter Ross wrote:
> > Signed-off-by: Peter Ross <pross at xvid.org>
> > ---
> > Here is my first attempt at addressing the VP8 performance regressions
> > introduced by the VP7 decoder.
> >
> > This uses 'always inline & static template' approach to generate vp7_ and
> > vp8_ variants of performance critical functions. Every function
> containing
> > an 'if vp7' branch below vp8_decode_mb_row_sliced is duplicated.
> >
> > As a sanity check --disable-decoder=vp7 makes the resulting vp8.o binary
> is
> > virtually identical to the current vp8.o file. The only difference being
> the
> > use of function pointers for decode_mb_row_no_filter and filter_mb_row.
> >
> > user times from VP8 'A_4K_Video_Reel_by_Bright_Side_Network_Inc..webm' on
> > Core2 Q9400. In seconds.
> > VP8 only: 82.013 82.049 82.059 82.089 82.095  : AVERAGE 82.061
> > VP7+VP8:  82.206 82.234 82.249 82.253 82.261  : AVERAGE 82.241
> > VP8 only: 82.056 82.065 82.114 82.211 82.224  : AVERAGE 82.134
> > VP7+VP8:  82.257 82.339 82.356 82.391 82.482  : AVERAGE 82.365
> >
> > There is a fairly consistent ~0.25% performance drop for this input. It
> would
> > be nice to get performance data on other platforms where VP8 is popular.
> ARM
> > especially.
>
> Ping. (Take it a step further and split vp7 & vp8 decoders into separate
> files?)


Sorry, lots of other stuff went around, I forgot.

Do you have specific ideas on what could cause the 0.25%? I am inclined to
say that 0.25% is OK, given that it gives us a new decoder. I'm not happy
to give up 0.25% all over the place but we sometimes do it (e.g. to add
threading, or to support partition-threading in vp8, etc.) so it's not
completely outrageous...

Ronald


More information about the ffmpeg-devel mailing list