@tab Multimedia format used in games like Mad Dog McCree
@item AVS @tab @tab X
@tab Multimedia format used by the Creature Shock game.
+@item Smacker @tab @tab X
+@tab Multimedia format used by many games.
+@item GXF @tab @tab X
@end multitable
@code{X} means that encoding (resp. decoding) is supported.
@item Theora @tab @tab X @tab still experimental
@item Intel Indeo 3 @tab @tab X
@item FLV @tab X @tab X @tab Sorenson H.263 used in Flash
+@item Flash Screen Video @tab @tab X @tab fourcc: FSV1
@item ATI VCR1 @tab @tab X @tab fourcc: VCR1
@item ATI VCR2 @tab @tab X @tab fourcc: VCR2
@item Cirrus Logic AccuPak @tab @tab X @tab fourcc: CLJR
@item American Laser Games Video @tab @tab X @tab Used in games like Mad Dog McCree
@item ZMBV @tab @tab X @tab
@item AVS Video @tab @tab X @tab Video encoding used by the Creature Shock game.
+@item Smacker Video @tab @tab X @tab Video encoding used in Smacker.
+@item RTjpeg @tab @tab X @tab Video encoding used in NuppelVideo files.
+@item KMVC @tab @tab X @tab Codec used in Worms games.
@end multitable
@code{X} means that encoding (resp. decoding) is supported.
@tab All versions except 5.1 are supported
@item DSP Group TrueSpeech @tab @tab X
@item True Audio (TTA) @tab @tab X
+@item Smacker Audio @tab @tab X
@end multitable
@code{X} means that encoding (resp. decoding) is supported.
@chapter Developers Guide
@section API
-@itemize
+@itemize @bullet
@item libavcodec is the library containing the codecs (both encoding and
decoding). Look at @file{libavcodec/apiexample.c} to see how to use it.
The presentation is the one specified by 'indent -i4 -kr -nut'.
The TAB character is forbidden outside of Makefiles as is any
form of trailing whitespace. Commits containing either will be
-rejected by the CVS repository.
+rejected by the Subversion repository.
Main priority in FFmpeg is simplicity and small code size (=less
bugs).
fprintf and printf are forbidden in libavformat and libavcodec,
please use av_log() instead.
-@node CVS Policy
-@section CVS Policy
+@section Development Policy
@enumerate
@item
particular bug. Comments such as "fixed!" or "Changed it." are unacceptable.
@item
If you apply a patch by someone else, include the name and email address in
- the CVS log message. Since the ffmpeg-cvslog mailing list is publicly
+ the log message. Since the ffmpeg-cvslog mailing list is publicly
archived you should add some SPAM protection to the email address. Send an
answer to ffmpeg-devel (or wherever you got the patch from) saying that
you applied the patch.
@item
- Do NOT commit to code actively maintained by others without permission. Send
- a patch to ffmpeg-devel instead.
+ Do NOT commit to code actively maintained by others without permission.
+ Send a patch to ffmpeg-devel instead. If noone answers within a reasonable
+ timeframe (12h for build failures and security fixes, 3 days small changes,
+ 1 week for big patches) then commit your patch if you think it's OK.
+ Also note, the maintainer can simply ask for more time to review!
@item
- Subscribe to the ffmpeg-cvslog mailing list. The diffs of all CVS commits
+ Subscribe to the ffmpeg-cvslog mailing list. The diffs of all commits
are sent there and reviewed by all the other developers. Bugs and possible
improvements or general questions regarding commits are discussed there. We
expect you to react if problems with your code are uncovered.
Update the documentation if you change behavior or add features. If you are
unsure how best to do this, send a patch to ffmpeg-devel, the documentation
maintainer(s) will review and commit your stuff.
-@item
- Revert a commit ONLY in case of a big blunder like committing something not
- intended to be committed or committing a wrong file, the wrong version of a
- patch, CVS policy violation or broken code and you are going to recommit the
- right thing immediately.
-
- Never revert changes made a long time ago or buggy code. Fix it in the
- normal way instead.
@item
Never write to unallocated memory, never write over the end of arrays,
always check values read from some untrusted source before using them
Note, these rules are mostly borrowed from the MPlayer project.
-@subsection Renaming/moving files or content of files
- You CANNOT do that. Post a request for such a change to the mailing list
- Do NOT remove & readd a file - it will kill the changelog!!!!
-
@section Submitting patches
First, (@pxref{Coding Rules}) above if you didn't yet.
Patches should be posted as base64 encoded attachments (or any other
encoding which ensures that the patch won't be trashed during
transmission) to the ffmpeg-devel mailing list, see
-@url{http://www1.mplayerhq.hu/mailman/listinfo/ffmpeg-devel}
+@url{http://lists.mplayerhq.hu/mailman/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 isn't C99 compliant
@section Regression tests
-Before submitting a patch (or committing to CVS), you should at least
+Before submitting a patch (or committing to the repository), you should at least
test that you did not break anything.
The regression tests build a synthetic video stream and a synthetic
projects / ffmpeg / blobdiff