[XviD-devel] minor changes / todo list

[Michael Militzer]

Hi,

Quoting suxen_drol <suxen_drol at hotmail.com>:

> hi,
> 
> On Mon, 16 Jun 2003 01:07:35 +0200 Michael Militzer <michael at xvid.org>
> wrote:
> > 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.
> 
> 10 is a lot, i wll go over the old vfw credits code at somepoint.
> 
> iam still thinking about credits... in an ideal would we would have a
> script that defines what options are used for macroblock regions individual
> frames. for example, if credits/text are present in the video, enable
> chroma optimization for the macroblocks of the text area.
> however we're not living in such a world, and must sacrifice such
> power/flexibility in favour of realitisc, down-to-earth options.
> 
> credits rate can be controlled using 2nd pass using scaling editor. so
> maybe making the editor more generic to support 2/3 passes is neccessary.
> 
> for greyscaling credits, maybe we can just have a cfg text box that
> lets u specifiy frame ranges (much like the print menu in msword):
> for example "-1000-4000, 5000, 105000-", would encoding frames 1000-4000
> in greyscale, frame 5000 in greyscale, and frames after 105000 in
> greyscale.

yes, I guess this recently was a feature request: activating grey-scale and
chroma optimizer independently for start- and endcredits. I suppose it makes
no real difference anyway, but yes, in an ideal world we should have this...
 
> > 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.
> 
> whilst ive not tested it, the core-based 2pass should respect target
> with packed mode bframes. the length of the "fake/placeholder pframe" is
> added to the length of the actual pframe before it is given to the rate
> controller.

ok, good. I'll check.
 
> cbr does not work well with bframes, and i have my sights set on fixing
> this as soon as 2pass issues are sorted. cbr is not aware of bframes and
> the need modification to treate bframes quantizers differently to
> i,pframes.

hm, back when we encoded the VQEG sequences for the c't test, I also noticed
that CBR didn't work at all with b-frames enabled. I committed a fix at that
time and the target bit-rate was then respected with b-frames enabled.
However I don't really remember what I did or whether it was really a good
solution but it did work. So I wonder why we have problems again - maybe I
committed this patch to cvs-head and it had not been ported to dev-api-4?
Was the dev-api-4 branch already at this time? - I'll check...

> > > 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 ;-)
> 
> the 2pass plugin presently supports external scaling, like you described,
> using a desired_length field for each frame. this is intended for
> debugging or the elite-super-users.

yes, true.

> so, by using weights i was hoping to keep bitrate curve scaling purely
> inside xvidcore, rather than having seperate scaling code in the editor.
> either way it doesnt matter much, i will need to think some more about
> this...

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?).
 
> (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 ;-)

bye,
Michael