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

[Edouard Gomez]

suxen_drol (suxen_drol at hotmail.com) wrote:
> 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.

No problem, i  was just surprised to see such a  great number of changes
and the cvs  tree left in an  unusable state.  Note that i  did not rant
you, i just provided my personal changelogs so everyone could undertsand
the changes a bit. 

Btw christoph and I are suffering the same problems with the cvs server.
It has even some problems  at serving the complete tree sometimes. Quite
annoying. Any news from our web/cvs admin ?

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

ok

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

teh table should be incorporated  to xvid but not in a header :) then we
should provide a way to specify the profile we would like to use.

In   a   larger  scope,   XviD   core   needs   a  config   library   to
check/validate/fix/set  flags according  to the  profile  (features) and
xvid  internals (motion flags).  The last  one is  mostly done  with the
CheckMotionFlags function.

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

Yep, i noticed that (subtil) change (mv plugin_cbr.c plugin_single.c)
;-). Just kidding.

Well, my algorithm is not so hard, it tries to distribute quant packets
the more homogenous it can. I'm quite sure i can convert it to something
more flexible that: allocate quant array->fill it->use it. Th problem is
i lack time (lot of) because of school projects.

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

Would be very  nice, THANK U... i was so desperate  about this code that
was so ... unfixable by my all my attempts.

-- 
Edouard Gomez-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030514/811a4d59/attachment.bin