[XviD-devel] 2pass results

Edouard Gomez ed.gomez at free.fr
Thu May 29 03:30:03 CEST 2003


Michael Militzer (michael at xvid.org) wrote:
> Since all  this is no  small bug fix  anymore, I have  some questions:
> From what  I understood,  your initial problem  was that  b-frames got
> quantized too heavily. You tried several possible solutions how to fix
> this and discovered  that there can be a  huge PSNR difference between
> these. I suppose  that your current problem with  still scenes is also
> somewhat re- lated to the changes you recently introduced, right?

No absolutly not related with my changes, but with the way current 2pass
works compared to the old 2pass.

vfw code  and current dev-api-4 are  very close. The  main problems come
from the fact 2pass is now modifying encoding parameters from the inside
of  the  core  lib  and  that  we have  legacy  code  that  is  strongly
interfering with  the plugin system  (the bquant formula depends  on the
frame->quant value, the plugin value is then overwritten).

All i did is lot of  debugging, cleaning, and commenting. It's true that
i added code this last days, but don't be so afraid, i do things cleanly
and i have just to #undef some constants :-)

> Well,  what  I  find strange  is  that  2pass  + bframes  works  under
> windows. I  may be  totally wrong, but  I really believe  that b-frame
> quant settings are respected under windows and that 2pass rate control
> with b-frames works  quite fine (as long as you  don't use the 'packed
> bitstream' option).

Yes, at first it was not working, i explained why, but now with some of
my fixes it (mostly) works.

What i observe, is that controlling quants from core+plugins is creating
divergences between  old code and the  new one because  of the quantizer
being modyfied in encode.c that  looks at the input frame->quant. Moving
the bquant  computation before the call  to plugin(...BEFORE...); should
solve that that problem.

> Also I thought that we wanted to port _exactly_ the windows 2pass code
> into dev-api-4.  I know it might  be difficult to  exactly imitate the
> windows 2pass behaviour but this is what we should aim for. 

The only  part that differs, is  the internal scaling pre  pass, that is
probably borrowed from  the Koepi's scaler tool (sorry  i don't remember
the name).

All other stuff is from vfw.

> So  don't  get  me  wrong  here:  I  appreciate  your  work  on  2pass
> improvements and I'm sure that  there's something to optimize here and
> there,  but  I'd  really like  to  have  a  two-pass code  that  gives
> identical results to the trusted windows code. 

No problem,  telling your  opinion is welcome,  i was feeling  lonely on
this ML (lot of emails, ~0 answers...).
 
> btw speaking  about alternatives: I  think that not many  people still
> use the  altcc option, so to  answer one of your  earlier questions: I
> think it's not really needed to port the altcc code.

The alt cc is gone in my tree.  I have some easy commits ready (like the
frame type  respect, cleanups).  All  my "alternatives" for  bquants are
separated with #defines, so it's easy to remove part of them.

Once i'll do my commits, i  would like is to see some win32 users/coders
starting comparing head and dev-api-4 (that is something i can't do).

-- 
Edouard Gomez-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030529/3ab3c5fa/attachment.bin


More information about the XviD-devel mailing list