replace FFmpeg with Libav in doc/

unless it stands for ffmpeg the program or is historic

1 files changed, 10 insertions, 10 deletions

diff --git a/doc/developer.texi b/doc/developer.texi
index 96ab9f7a4b..379f6b2a40 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -32,12 +32,12 @@ generated by ./configure to understand what is needed.
 
 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
@@ -54,7 +54,7 @@ These features are supported by all compilers we care about, so we will not
 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
@@ -76,7 +76,7 @@ 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.
 
-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
@@ -129,7 +129,7 @@ should also be avoided if they don't make the code easier to understand.
    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
@@ -168,7 +168,7 @@ should also be avoided if they don't make the code easier to understand.
    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.
@@ -253,7 +253,7 @@ keeping it as a logical unit that contains an individual change, even
 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
@@ -275,7 +275,7 @@ Your patch will be reviewed on the mailing list. You will likely be asked
 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.
@@ -325,7 +325,7 @@ 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)
@@ -374,7 +374,7 @@ send a reminder by email. Your patch should eventually be dealt with.
     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.