You can use libavcodec or libavformat in your commercial program, but
@emph{any patch you make must be published}. The best way to proceed is
-to send your patches to the FFmpeg mailing list.
+to send your patches to the Libav mailing list.
@anchor{Coding Rules}
@section Coding Rules
-FFmpeg is programmed in the ISO C90 language with a few additional
+Libav is programmed in the ISO C90 language with a few additional
features from ISO C99, namely:
@itemize @bullet
@item
accept patches to remove their use unless they absolutely do not impair
clarity and performance.
-All code must compile with GCC 2.95 and GCC 3.3. Currently, FFmpeg also
+All code must compile with GCC 2.95 and GCC 3.3. Currently, Libav also
compiles with several other compilers, such as the Compaq ccc compiler
or Sun Studio 9, and we would like to keep it that way unless it would
be exceedingly involved. To ensure compatibility, please do not use any
The presentation is one inspired 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 Subversion repository.
+rejected by the git repository.
-The main priority in FFmpeg is simplicity and small code size in order to
+The main priority in Libav is simplicity and small code size in order to
minimize the bug count.
Comments: Use the JavaDoc/Doxygen
an "or any later version" clause is also acceptable, but LGPL is
preferred.
@item
- You must not commit code which breaks FFmpeg! (Meaning unfinished but
+ You must not commit code which breaks Libav! (Meaning unfinished but
enabled code which breaks compilation or compiles but does not work or
breaks the regression tests)
You can commit unfinished stuff (for testing etc), but it must be disabled
with functional changes, such commits will be rejected and removed. Every
developer has his own indentation style, you should not change it. Of course
if you (re)write something, you can use your own style, even though we would
- prefer if the indentation throughout FFmpeg was consistent (Many projects
+ prefer if the indentation throughout Libav was consistent (Many projects
force a given indentation style - we do not.). If you really need to make
indentation changes (try to avoid this), separate them strictly from real
changes.
if it spans multiple files. This makes reviewing your patches much easier
for us and greatly increases your chances of getting your patch applied.
-Use the patcheck tool of FFmpeg to check your patch.
+Use the patcheck tool of Libav to check your patch.
The tool is located in the tools directory.
Run the regression tests before submitting a patch so that you can
to make some changes and are expected to send in an improved version that
incorporates the requests from the review. This process may go through
several iterations. Once your patch is deemed good enough, some developer
-will pick it up and commit it to the official FFmpeg tree.
+will pick it up and commit it to the official Libav tree.
Give us a few days to react. But if some time passes without reaction,
send a reminder by email. Your patch should eventually be dealt with.
@item
Is the patch a unified diff?
@item
- Is the patch against latest FFmpeg git master branch?
+ Is the patch against latest Libav git master branch?
@item
Are you subscribed to ffmpeg-dev?
(the list is subscribers only due to spam)
patch easily?
@item
If you added a new file, did you insert a license header? It should be
- taken from FFmpeg, not randomly copied and pasted from somewhere else.
+ taken from Libav, not randomly copied and pasted from somewhere else.
@item
You should maintain alphabetical order in alphabetically ordered lists as
long as doing so does not break API/ABI compatibility.
projects / ffmpeg / blobdiff