[XviD-devel] Doc Contributions are welcome

Michael Militzer michael at xvid.org
Tue Dec 30 14:24:53 CET 2003


I have a question regarding the 1.0 API. I know it should be frozen by now,
however I believe that minor changes towards a final API should still be
ok in the Beta stage. At least I think that the API is not yet 'finished',
so for example it lacks a DERING decoder flag. Sure, there is no dering
code in xvidcore yet, however it might make its way into core with version
1.0.1 or so and so I think it would be good to have flags in the API for
features that are likely to be added very soon to xvidcore. This would
allow to keep the API stable and unchanged for all 1.0.x versions and the
docs would also be up-to-date for the whole 1.0.x series.

Apart from that, we have used up almost all free slots for motion flags,
while however some of the defined flags are completely useless or
abandoned. So I think it would be good to also kick out useless flags and
free some space for new ones as long as we still can change the API (and I
think we can as long as 1.0 final is not released).

BTW: Adding new flags to the API should be no problem at all because it
doesn't touch interoperability with existing apps in any way. It's just
good to have as much flags as possible described in the docs. Removed un-
used flags could be done in a safe way also: Just define a new DO_NOTHING
flag and map all unused flags to this flag. That frees up some slots with-
out sacrificing compatibility.


Quoting Edouard Gomez <ed.gomez at free.fr>:

> Hello,
> as i've written in the beta3 release notes, i would like to focus now on
> library documentation. So  i started writing some docbook  xml text this
> afternoon.
> See http://ed.gomez.free.fr/vrac/xvid-docs/html/xvid.html
> It will be  a hard (read boring) task  if i complete it all  alone, so i
> call for contributions from you (yeah you !) ;-)
> You can contribute:
>  - The  best start  i  can have  to  write the  docs,  and organize  the
>  contributions is  to have a complete  table of contents.  So list there
>  your ideas.
>  - General information about  XviD. i tried to describe  xvid the best i
>  could,  but  i'm  really a  poor  marketing  guy,  so try  to  describe
>  xvidcore with bells and whistles and send me the resulting text.
>  - A  complete  docbook CSS  stylesheet.  I've  found  on the  net  some
>  docbook stylesheets (freebsd, a french guy css file...) but they sucked
>  as soon as i used more than section and para tags.  I've given a try at
>  it but the result isn't that fancy, so if you have some CSS skills, and
>  know what XHTML 1.1 is... c'mon share your skills.
> PS: the  toolchain  i  use  is  "xmlto",  this  simplifies  a  lot  the
> docbok-xml parsing+transformation.  I prefer having a  single xhtml file
> for now,  but once the doc will  get bigger, i'll switch  to chunked doc
> output and PDF.
> PPS: yes i  know that for now, the  GPL text is the biggest  part of the
> doc ;-)
> -- 
> Edouard Gomez
> _______________________________________________
> XviD-devel mailing list
> XviD-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel

More information about the XviD-devel mailing list