ffmpeg-doc.texi

The presentation is the one specified by 'indent -i4 -kr'.

Main priority in ffmpeg is simplicity and small code size (=less
bugs).

Comments: use the JavaDoc/Doxygen 
format (see examples below) so that a documentation
can be generated automatically. All non trivial functions should have a comment
above it explaining what the function does, even if its just one sentance.
All Structures and their member variables should be documented too.
@example
/**
 * @file mpeg.c
 * mpeg codec.
 * @author ...
 */

/**
 * Summary sentance.
 * more text ...
 * ...
 */
typedef struct Foobar{
    int var1; /**< var1 description */
    int var2; ///< var2 description
    /** var3 description */
    int var3;
} Foobar;

/**
 * Summary sentance.
 * more text ...
 * ...
 * @param my_parameter description of my_parameter
 * @return return value description
 */
int myfunc(int my_parameter)
...
@end example

fprintf and printf are forbidden in libavformat and libavcodec, 
please use av_log() instead.

@section Submitting patches

First, (@pxref{Coding Rules}) above if you didn't yet.

When you submit your patch, try to send a unified diff (diff '-up'
option). I cannot read other diffs :-)

Run the regression tests before submitting a patch so that you can
verify that there are no big problems.

Patches should be posted as base64 encoded attachments (or any other
encoding which ensures that the patch wont be trashed during 
transmission) to the ffmpeg-devel mailinglist, see 
@url{http://lists.sourceforge.net/lists/listinfo/ffmpeg-devel}

It also helps quite a bit if you tell us what the patch does (for example
'replaces lrint by lrintf') , and why (for example '*bsd isnt c99 compliant
and has no lrint()')

We reply to all patches submitted and either apply or reject with some
explanation why, but sometimes we are quite busy so it can take a week or 2

@section Regression tests

Before submitting a patch (or committing with CVS), you should at least
test that you did not break anything.

The regression test build a synthetic video stream and a synthetic
audio stream. Then these are encoded then decoded with all codecs or
formats. The CRC (or MD5) of each generated file is recorded in a
result file. Then a 'diff' is launched with the reference results and
the result file.

The regression test then goes on to test the ffserver code with a 
limited set of streams. It is important that this step runs correctly
as well.

Run 'make test' to test all the codecs and formats.

Run 'make fulltest' to test all the codecs, formats and ffserver.

[Of course, some patches may change the regression tests results. In
this case, the regression tests reference results shall be modified
accordingly].

@bye