[XviD-devel] [CVS commits] decoder speedups and fixed cbr

[Edouard Gomez]

Bryan Mayland (bmayland at leoninedev.com) wrote:
>    Is there a better way to quantifiably test this instead of just 
> playing an AVI and watching the task manager?

On GNU/Linux box i use mplayer to measure decoding time:
mplayer -benchmark -nosound -vo null -vc xvid sequence.avi

I know mplayer has a win32 port, but i dunno if it can be
linked against xvidcore to activate "-vc xvid" option, you may
give a try at compiling mplayer yourself, and force
xvidcore.dll usage, or maybe using xvidvfw.dll is enough
(overhead is ~0, and anyway, it would be constant accross
tests)

> >- test CBR/ABR coding, just to make sure Foxer (and I, his
> >  tester) didn't miss something important.
> > 
> >
>    I've run some tests on 320x240 15fps source content, 900 frames, 
> Constant Q=1 2310 kbps,
> XVID 1.0.1, 2 max consecutive BVOPs
> Target  1-Pass  2-Pass
> 300     247     263
> 700     570     699
> 1000    831     998
> 2000    1408    1651

ABR was really off in 1.0.1

> XVID 1.0.1, Bframes disabled
> Target  1-Pass
> 700     700   
> 1000    998
> 2000    1838

With bvops turned off, however it was really good... this was
known behavior
 
> XVID HEAD, 2 max consecutive BVOPs
> Target  1-Pass  2-Pass
> 300     288     263
> 700     665     701
> 1000    936     997
> 2000    1512    1656

Much better than 1.0.1 results, results are not exactly what
you aimed at, but at least theyget much closer.

> I've also looked at every resultant video and they all look as 
> expected.  Something that I thought was odd was that using constant 
> quantizer=1 that I and P frames used Q=1 but B frames used Q=2.  Not 
> that it makes any difference at that bitrate, but is that intended behavior?

Yes, bvop qp is always the result of ratio*qp+offset.

Thanks for the feedback.

-- 
Edouard Gomez