[XviD-devel] better size prediction in 2pass2

Michael Militzer michael at xvid.org
Sat Dec 13 17:02:10 CET 2003


Hi,

you're reading my mind ;-) I just sent a similar proposal to the list
just a moment ago ;-)

bye,
Michael

Quoting Radek Czyz <syskin at ihug.com.au>:

> Hi everyone,
> 
> I just made a simple change and I print total bytes taken by textures in 
> 1st-pass statsfile. What I get seems very very useful, because I my 
> observations show that some scenes don't compress at all - which results 
> in horrible overflow soon.
> 
> I made 1st pass of such scene and look at this stats output:
> i 2 1032 0 0 2901 0
> p 2 1032 0 0 3529 14
> p 2 1032 0 0 3496 1
> p 2 1032 0 0 3544 3
> p 2 1032 0 0 3500 0
> p 2 1032 0 0 3506 0
> p 2 1032 0 0 3503 2
> p 2 1032 0 0 3508 6
> p 2 1032 0 0 3499 3
> 
> The last value is bytes taken by textures, the one before is total 
> length. Note that this is *exactly* the frames that boosted overflow by 
> 2kb each time, because the frames were 3200 at quant 8.
> 
> Compare with "normal" scene:
> i 2 1032 0 0 16021 12798
> b 4 0 1032 0 609 144
> b 4 0 1032 0 739 189
> p 2 1 998 33 11059 9573
> b 4 0 1032 0 730 231
> b 4 0 1032 0 872 266
> p 2 1 1019 12 10788 9306
> 
> ... almost all bytes are taken by texture.
> 
> I know we wanted to keep the old 2-pass code, but imho working on it is 
> worth it - our 2-pass makes big scaling errors too often.
> 
> What do you think?
> 
> Radek
> _______________________________________________
> XviD-devel mailing list
> XviD-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel
> 





More information about the XviD-devel mailing list