[XviD-devel] minor changes / todo list

[Michael Militzer]

Hi,

Quoting suxen_drol <suxen_drol at hotmail.com>:

> On Fri, 13 Jun 2003 15:44:10 +0200 Michael Militzer <michael at xvid.org>
> wrote:
> > well, I wouldn't say that the old credits encoding option worked
> > sufficiently. I checked it myself while assisting doom9 with his latest
> > codec comparison and experienced that credits encoding did lead to heavy
> > undersizing problems. This gives a bad impression of our ratecontrol algo
> > which normally works pretty nicely (without credits encoding).
> 
> which credits mode (quant,bitrate,size?). bitrate and size modes

bitrate

> will decrease the bits allocated to the body of the video sequence, so
> the target file size should have been beet. i cant recall what quant mode
> does, though i assume its some form of approximation.
> 
> if target size is not being met, then there is a bug in the old code.
> this of course depends on what is considered to be unacceptable
> underflow. imho <1% is acceptable (e.g. 3 out of 610meg), though it
> should be exact to the last kilobyte.

Supposedly there is a bug. Because undersize where about 10 out of 600 meg.
But whatever, credits should not influence the rate control accuracy. Our
rate controller can reach a target size very accurately (+/- 0.1%). If we
can fix the credits bug so that we can retain the rate control precision,
the credits option is fine with me.

BTW: speaking about 2pass bugs, I also remember that b-frames in packed
mode broke the 2pass rate control accuracy. I think we should fix this
issue too. I know you don't like the packed mode, but I think many others
(including me ;-)) would prefer it.
 
> > So I'd rather suggest the following: Remove the zones option from vfw and
> > instead create an own small application out of it. Leave the normal 2pass
> > algorithm but add support to write second pass statistics (quantizer/bits
> > distribution) into the stats file as well. Then such a stats file could be
> > opened with our new application after both first and second pass have been
> > finished.
> > 
> > The application opens the stats file and displays the second pass bit 
> > distribution as a simple graph. The user could watch the result of his
> > second pass and search for "bad looking" scenes. Using the apllication, he
> > could then assign more bits to difficult/bad looking scenes and less to
> > very good looking ones. So he could manually refine the bit distribution.
> > Once the user has finished, the application stores the refined bit
> > distribution scheme into the stats file again.
> > 
> > Now the user could perform a third-pass encoding where the XVID encoder
> > would exactly respect the user refined bit distribution. Since we've
> > collected useful information during the second pass already and because
> > the user-refined bit distribution shouldn't be too different from the
> > original 2pass distribution, the encoder should be able to respect the
> > user distribution with pretty high accuracy.
> > 
> > So to sum it up: we could turn our current 2pass system into a 2pass plus
> > optional third-pass encoding process. And this third-pass could really
> > bring an improvement because it does not rely on mathematic error metrics
> > but on real human viewing impressions. So I think this could be a valuable
> > application for a zone-like concept while not being very difficult to
> > implement and not adding too much of a computational overhead.
> 
> okay, well this sounds good.
> 
> pass	stats input		stats output
> ----------------------------------------------
> 1. 	fixed quant=2		1st pass stats
> 2. 	1st pass stat		2nd pass stats
> (edit 2nd pass stats file and set curve weights as neccessary)
> 3.	edited 2nd pass stats	nothing
> 
> 
> the 1st pass stats will contain:
> 	frame-type
> 	quant
> 	length
> 
> the 2nd pass stats will contain:
> 	frame-type
> 	(1stpass) quant, length
> 	(2ndpass) desired-length, quant, length
> 
> the edited 2nd pass stats will contain an additional weight field.

hm, maybe no weight field. I'd rather thought of adding an additional
desired-length field which holds the number of bits for every frame that
the encoder should achieve during the third-pass. This means that the
external application has to do the scaling and the calculation of the
frame bits. I think this would be more precise than weights but has the
disadvantage that the 'zones feature' wouldn't be needed for the third-
pass ;-)

> desired-length indicate the length the rc wanted for each frame, and
> quant/length will indicate what was actually achieved. in the third pass
> we might be able to use difference between desired and actual to
> increase size-quanter relationship accuracy.

yes, we could try. Secon pass results might be more reliable because the
second and third-pass frame sizes should be closely related (and often be
identical).

> all of this isnt terribily difficult, however writing a nice stats
> editor will take some time. it could also be written in a
> platform-independant manner to give non-win32 folk access to bitrate
> tuning. anyway, i will start thinking about a win32 prototype.

yes, platform independent gui programming. I remember we discussed it
already some time ago. I think Ed suggested wxWindows and I think I found
it pretty good but never used it yet...

bye,
Michael