[XviD-devel] Doc Contributions are welcome
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>:
> 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
> 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
More information about the XviD-devel