[XviD-devel] pete cvs commits digest :-(

[suxen_drol]

On Tue, 13 May 2003 02:26:56 +0200 Edouard Gomez <ed.gomez at free.fr> wrote:
> Hello,
> 
> Ok  i noticed  Pete comited  the "zones"  code. Good  but it  breaks all
> usefull stuff  (ie xvid_encraw) :-(.   I splited the patch  into logical
> changesets  in order  to  push  the changes  to  my local  tree/revision
> control system.

please accept my deepest sympathys ed. i had modified xvid_encraw in my
local tree, however it appears CVS aborted with a "cvs [server aborted]:
received broken pipe signal" error half-way through the commit. in
addition to the examples dir, none of my vfw changes were commited
either.

> I think it would have been good  to detail a bit more the commit message
> ("zones, profiles, vfw changes"),  as the changes are somewhat important
> and  left the  tree in  a pity  state (did  not compile,  xvid_encraw is
> broken, so  is vfw?).  My  last commit makes  the tree compiles,  but it
> does not fix it (this change is part of my patch-35 changeset).

yep that was my bad. theres quite a few changes:

* addition of num_zones and zones fields in the xvid_enc_create_t struct.
a zone specifies a frame number, mode, and increment/base value. the
mode can either be XVID_ZONE_WEIGHT or XVID_ZONE_QUANT.
- "weight" instructs the rate control process to apply more bitrate. ie.
you might assign the majority of a video weighht=1.0, high action scenes
weight=1.5 and the credits weight=0.3. the rate control process uses the
weights to distribute bits appropriately, such to ensure the 
target bitrate is acheived (for single pass and two pass).
- "quant" instructs the rate control process to use a fixed quantizer.

* addition of profile field to xvid_enc_create_t. if the value is zero,
the encoder does not write the VOSH header. if the value is non-zero,
the encoder writes a VOSH header and given profile.
xvid.h doesnt define the various profile at level values. they can be found
in the mpeg-4 iso document, OR, are listed within the profiles[] table
within vfw/src/config.c.

RFC: should we incoporate this static table with xvid.h, OR, should we
develop some kind of profile listing functionality (e.g.
XVID_GBL_PROFILES
to return the structure of profiles), OR, leave profiles up to the
encoding application.

* plugins/plugin_cbr.c replaced by plugins/plugin_single.c;
plugins/plugin_fixed.c removed from build filex.
as mentioned in a previous email, i wanted to have two primary bitrate
plugins (a single pass plugin and a 2pass plugin), and use the zone
concept to specifiy weights or a quantizers.

ed's plugin_fixed.c performs precise fixed quant encoding (e.g.
quant=2.45). however this precision requires a precomputed table, which
would have to be generated for each bitrate zone. ed's code has not
incorporated in plugin_{single,2pass1,2pass2} yet.

* vfw changes:
- the profiles at level page now has seperates pages for profile and levels.
i intend to add a verficiation tool, which ensures the encoded material
dimensions and frame rate are within the level.
- at present, bitrate is specified by KBPS only (and not total
filesize). mf want to be able to specifiy either. there is also a blank
page ready for a bitrate calculator.
- added listview to display bitrate zones, and button to add/remove/edit
them.
- the advanced pages now specifiy motion options, quantizer limits and
debug options only.
- added initial/experimental support for my vfw-api-extensions. this
permits the encoding application (vdub/mod) to inform xvid about the
frame dimensions, framerate, total number of frames, and active frame 
(ie. the frame presently displayed by virtualdub). this info will be
used to "enhance" the usability of the gui.

important: i havent updated 2pass2 yet. therefore, it should behave a
good (or poorly) as it did last week. i intend to commit an updated
2pass plugin soon, with support for zones.

there's possibly bugs with the gui. i know that turning on/off the greyscale
mode doesnt force a keyframe.. which can lead to some funky color
effects.

> Pete, what  about fixing the  encoding loop ?  It has probably  a higher
> priority  if  we want  to  get good  quality  and  compare devapi4  with
> cvs_head. 

i will work on a fix asap

cheers,
-- pete