[XviD-devel] minor changes / todo list

[suxen_drol]

hi,

On Sat, 21 Jun 2003 17:29:02 +0200 Michael Militzer <michael at xvid.org>
wrote:
> yes, I understand the idea. I just wonder whether defining weights for a
> certain 'zone' can be as accurate, flexible and reliable than rescaling/
> redistributin the bits immediately. I also wonder whether the rate control
> results will still be accurate and reliable when we have many, many zones
> defined. Maybe it will work, but I'm just a bit sceptic because of my
> experiences with the credits option (and this was only one zone - so what
> will happen if we have many more?).

sorry to beat the drum further, but i try and explain the weights
concept further.

tradinally the scaling process has taken the "1st pass frame lengths" of
sequence and reduce each frame's length by constant scaling factor, to
achieve a desired "overall 2nd pass length".

weights influence the scaling factor, such that scaling is no longer
constant across all frame. the desired length should always be achived,
(as long as the weights are sensible).

also: traditional constant scaling can be ahcieved by using a constant
weight across all frames (ie. 1.0).

> > (imho external scaling tools are an added nussiance. you must supply
> > them with the target filesize/bitrate and recalcuate the stats for the
> > entire file. with weights xvid does the recalcuations, and in theory you
> > could use vi just almost as easily as a gui editor to adjust weights.)
> 
> yes, in theory. And when the many zones and potentially insane weights
> don't confuse the internal scaler, then everything is fine ;-)

ok. in my tree, i have removed the zones completely and weights are now assigned
using an external editing gui tool. if this tool is not used, the 2pass
experience should be identical to the old vfw.

on a simular matter, i experimented with some "3rd pass" encoding sessions,
where the third pass uses "quant-length" data collected from the 1st and
2nd pass to increase desired frame size accuracy.
in my tests it works quite well (frame overflow decrease by upto 50%),
however there doesnt seem to be much noticble visible improvement.
more testing is neccessary.


cheers,
-- pete