[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