[XviD-devel] todo/action list

[peter ross]

>peter ross (suxen_drol@hotmail.com) wrote:
> > * where do we place 2pass? within the actual encoder() routines,
> >  or seperaly like, xvid_2pass() XVID_2PASS_CREATE, XVID_2PASS_DESTROY
> >
> >  within encoder makes it simpler to use, however keeping it seperate
> >  makes the code easily available/portable to other projects.
> >  (e.g. ive been thinking about writing a 'nandubvfw' with 2pass)
> >
> > * data passing. the original win32 2pass used struct passing, whilst
> >  ed's vbr lib used individual parameter passing.
> >
>
>yes, i  did that  because transcode  could use the  vbr lib  for other
>mpeg4 codecs. Anyway,  nobody uses it, so i can  simply make it struct
>passing by address.
>
> >  for xvid, i think using structs is better, because it simplifies
> >  the process for xvid frontends, and the struct can be extended to
> >  support new statistics in the future.
>
>Yes, agree.
>
> >
> >  xvid_encore(hEnc, XVID_ENC_ENCODE, &frame, &stats)
> >  xvid_2pass(hPass, XVID_2PASS_UPDATE, &stats)
> >
>
>No, the  lib handles all cases  1pass cbr, 2pass  1/2, constant quant,
>(constant quality is not implemented due to lazyness). So it should be
>used internally. Moreover, the lib  has already a good design we could
>use to wrap the current bitrate allocator. The current behaviour using
>quant=x (0<x<32) could be implemneted in a VBR_MODE_EXTERNAL.

excellent.

>
> >  however, the current stats structure does specify the frame
> >  length. as part of the 2-pass-bframes & api update, i want the
> >  frame statistics to remain indepedant from the bitstream statistics.
>
>Yes,  i  agree, bitrate  allocation  needs a  per  frame  stat, not  a
>bitstream stat. I would like to  have the motion bits in the stats. It
>could  help me  implement  an  hueristic functions  to  give a  better
>approximation of  estimated frame size  (motion bits do not  change so
>much when reasonable quants are used ?).

yep.
>
> >  (sometimes there's more than one frame be bitstream).
> >  we cant do any of this until we tag the cvs.
> >  does anyone, besides me, want CVS_HEAD=dev ?
>
>CVS_HEAD should be  bugfix... i know it's not so  logical but it would
>definitively exclude  too much  feedback on "alpha  code". We  will be
>able to add things without wrapping it in lot of #ifdefs etc etc.

the problem here, is we have to do a big merge every time we want to
go make the dev->stable. then we have to tag and branch again to
continue future alpha-ish development.

ive been looking at cvs guidelines for other opensource projects.
heres my basic xvid cvs rules:

* HEAD=development. changes to HEAD should generally not cause
  instability, incompatibily, etc. for api v3.0 this wis unavoidable.
  but once the api is commited, it should not cause any more trouble.

* when HEAD is deemed stable enough, tag it as release_yyyymmdd
  the latest release should also be tagged STABLE, such that people
  do have to examine cvs to determine the latest stable release.

* if somebody wants to experiment on the code, they can branch off,
  test their idea(s) and merge back if they prove usefull.
  ^^ this is what i shouldve done originally for bframes.

>I propose  to simply add a  pointer to the cvs  guidelines on tldp.org
>saying that we inversed CVS_HEAD and branches roles. It should also be
>appended to the Coding Style file.

there's heaps of these documents about. eg. specifically for cvs,
http://lindir.ics.muni.cz/dg_public/cvs.html

>It's a "big maybe" i do not agree with. We should not rely on external
>programs specifications.  I would  prefer any ascii format (brut, xml)
>and create a small utility to translate it to nandub format.  Ascii is
>better than binary,  it's more easy to read  on every platform, easily
>extendible (just change  column names to inform developers,  and add a
>field).

fair enough. ascii it is then. (xml is overkill).

>Moreover,  as you  can already  read in  the vfw  code, the  struct is
>handled  diffrently depending  on  compiler options/version  (aligment
>problems etc etc). It's a very bad idea to use nandub stats.

i originally implemented "gknot 2pass" for many reasons:
* at the time xvid has no 2-pass; so this was a quick/simple solution.
* gknot & nandub were very popular
* divx4's method, using textfiles seemed crap
* it worked pretty good.

but since we're going multi-platform, we'd might as well go with
platform independant storage.

# bytes header_bits motion_bits frame_type quant kblks mblks ublks

-- pete


_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com