[XviD-devel] minor changes / todo list

[Michael Militzer]

Hi,

Quoting suxen_drol <suxen_drol at hotmail.com>:

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

yes, this makes sense.

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

sounds good.

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

ok, that's good. I think it's not that surprising that the visual quality is
not visibly improved: it's very seldom that the rate control buffer is
overflowed (with the effect that the rate controller goes crazy). But maybe
the issue becomes more important when we go for VBV compliance.

bye,
Michael