[XviD-devel] 2pass results

[Michael Militzer]

Hi,

Quoting Edouard Gomez <ed.gomez at free.fr>:

> Edouard Gomez (ed.gomez at free.fr) wrote:
> > Edouard Gomez (ed.gomez at free.fr) wrote:
> > > some results
> > some more results when using the encoder compensation 
> 
> I think i've  found where the problem lies  when compensating the bframe
> formula in encoder.c applied twice.
> 
> I was  looking at scaled/result  but i was  wrong, i may have  looked at
> desired/result. Here the results are inversed, my code is always missing
> the  desired  size  by  a  quite  large  amount  compared  to  the  "not
> compensated" bquant.
> 
> I also  noticed, the current code  (whatever flavor) is  pretty bad with
> still scenes.  Most  of the time (99.99%) it scales  the first frame too
> much and  then next frames compress  worse than 1st pass  (i mean second
> pass frames  are larger than in first  pass). Big loss of  PSNR. I'm now
> planning to play  a bit with the  blocks[] to find a good  way to detect
> those scenes and  thus try to prevent a too big  quantizer for the first
> frame.
> 
> To be continued... 

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?

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).

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 2pass
code has been tested and proven to be good and stable for a long time. I
admit that there might be further improvements possible but all
improvements and changes to the existing code would also mean that a
long testing phase would be needed again. And 2pass rate control is
hard to test: often rather short scenes don't tell everything, small
changes can have huge effects (as you've already noticed yourself) and
just a small bug could totally ruin the overall impression of a whole
coded clip.

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. The 2pass code is an extremely important part of
XviD 1.0 and we can not afford to have any bugs here. If we introduce new
or modified 2pass code now, we'd have to perform many tests (carried
out by many people) to make sure that the code is really bug-free and
really stable (like the existing 2pass code already is). However this
would mean that the release date of XviD 1.0 would be quite far off...

So we should really aim for exactly imitating the windows 2pass
behaviour. Of course improvements are welcome, but these should just be
alternatives to the trusted code, as long as these improvements have not
been proven to be stable. 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.

bye,
Michael