developer.texi: fix spelling errors

credits to: KayC (from Google Code-in)
Signed-off-by: burek <burek021@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

doc/developer.texi

@@ -38,15 +38,15 @@ to send your patches to the FFmpeg mailing list.
 
 There are 3 ways by which code gets into ffmpeg.
 @itemize @bullet
-@item Submiting Patches to the main developer mailing list
+@item Submitting Patches to the main developer mailing list
       see @ref{Submitting patches} for details.
-@item Directly commiting changes to the main tree.
-@item Commiting changes to a git clone, for example on github.com or
+@item Directly committing changes to the main tree.
+@item Committing changes to a git clone, for example on github.com or
       gitorious.org. And asking us to merge these changes.
 @end itemize
 
 Whichever way, changes should be reviewed by the maintainer of the code
-before they are commited. And they should follow the @ref{Coding Rules}.
+before they are committed. And they should follow the @ref{Coding Rules}.
 The developer making the commit and the author are responsible for their changes
 and should try to fix issues their commit causes.
 
@@ -194,7 +194,7 @@ should also be avoided if they don't make the code easier to understand.
    Always fill out the commit log message. Describe in a few lines what you
    changed and why. You can refer to mailing list postings if you fix a
    particular bug. Comments such as "fixed!" or "Changed it." are unacceptable.
-   Recommanded format:
+   Recommended format:
    area changed: Short 1 line description
 
    details describing what and why and giving references.
@@ -316,7 +316,7 @@ send a reminder by email. Your patch should eventually be dealt with.
 @item
     Did you add the CodecID to @file{avcodec.h}?
 @item
-    If it has a fourcc, did you add it to @file{libavformat/riff.c},
+    If it has a fourCC, did you add it to @file{libavformat/riff.c},
     even if it is only a decoder?
 @item
     Did you add a rule to compile the appropriate files in the Makefile?
@@ -435,7 +435,7 @@ where its best maintained.
 
 When resubmitting patches, please do not make any significant changes
 not related to the comments received during review. Such patches will
-be rejected. Instead, submit  significant changes or new features as
+be rejected. Instead, submit significant changes or new features as
 separate patches.
 
 @section Regression tests