[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