[XviD-devel] todo/action list

[Edouard Gomez]

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.

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

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

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.


> 
> * byte order for non-intel cpus.
>  nandub/xvid .stats are stored in little-endian format.
>  ensure to bswap() all fields on big-endian machines.
> 
> hey maybe (and this is a big maybe), we could modifiy xvid such
> that the xvid stats structure _is_ the nandub stats structure ?
> this would make writing 1-pass stats rather easy.
>  xvid_encore(..., pStats)
>  fwrite(pStats, ... )


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). XML would be great to store data but ASCII is just enough, but
i really don't like the nandub format. the 1st pass stat file has only
1pass  data   and  2nd  pass   estimation  file  has  1pass   +  2pass
estimation...  that's really weird,  inneficient and makes the vbr lib
harder to understand  (why should we read 2  nandub's struct, and just
ignore first ? that's a question  i wondered when porting the lib, and
wow 1 day later i had this stupid answer : the 2pass file had both 1st
pass and 2pass est :-).  Nandub  external vbr mode for win32 nandub is
easily implemented  creating a VBR_MODE_EXTERNAL that would  just be a
dummy mode  where externql quant  and external keyframe  decisions are
directly  pasded to  the xvid  frame structure.   XviD Core  should be
platform/program independant.

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.

-- 
Edouard Gomez