[XviD-devel] minor changes / todo list

[suxen_drol]

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.

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

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.

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

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

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

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

we've had a gui toolkit debate before. i do have a win32 stats editorprototype
yea, asside from the regular linux folks, is anyone here interested in
such a tool. keeping in mind, the such a tool would be restricted to 3rd
pass refinement (and possible 2nd pass scaling, for those game to guess
high bitrate zones) ?

ive attached a snap of my old stats viewing tool with mods. the line
running though the middle of the window indicates frame weight (value=1.0).

cheers,
-- PeteSAF