]> git.sesse.net Git - casparcg/blobdiff - ffmpeg 0.8/doc/developer.html
2.0. new dlls.
[casparcg] / ffmpeg 0.8 / doc / developer.html
index 2e1f9f1a5ba988c44847a57e173f969343f42100..9f73c8dc5e9b6b4ea01e3aa9aa7707386fcd59ff 100644 (file)
@@ -1,6 +1,6 @@
 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html401/loose.dtd">
 <html>
-<!-- Created on July 23, 2011 by texi2html 1.82
+<!-- Created on September 2, 2011 by texi2html 1.82
 texi2html was written by: 
             Lionel Cons <Lionel.Cons@cern.ch> (original author)
             Karl Berry  <karl@freefriends.org>
@@ -53,13 +53,14 @@ ul.toc {list-style: none}
   <ul class="toc">
     <li><a name="toc-API" href="#API">1.1 API</a></li>
     <li><a name="toc-Integrating-libavcodec-or-libavformat-in-your-program" href="#Integrating-libavcodec-or-libavformat-in-your-program">1.2 Integrating libavcodec or libavformat in your program</a></li>
-    <li><a name="toc-Coding-Rules-1" href="#Coding-Rules-1">1.3 Coding Rules</a></li>
-    <li><a name="toc-Development-Policy" href="#Development-Policy">1.4 Development Policy</a></li>
-    <li><a name="toc-Submitting-patches" href="#Submitting-patches">1.5 Submitting patches</a></li>
-    <li><a name="toc-New-codecs-or-formats-checklist" href="#New-codecs-or-formats-checklist">1.6 New codecs or formats checklist</a></li>
-    <li><a name="toc-patch-submission-checklist" href="#patch-submission-checklist">1.7 patch submission checklist</a></li>
-    <li><a name="toc-Patch-review-process" href="#Patch-review-process">1.8 Patch review process</a></li>
-    <li><a name="toc-Regression-tests" href="#Regression-tests">1.9 Regression tests</a></li>
+    <li><a name="toc-Contributing" href="#Contributing">1.3 Contributing</a></li>
+    <li><a name="toc-Coding-Rules-1" href="#Coding-Rules-1">1.4 Coding Rules</a></li>
+    <li><a name="toc-Development-Policy" href="#Development-Policy">1.5 Development Policy</a></li>
+    <li><a name="toc-Submitting-patches-1" href="#Submitting-patches-1">1.6 Submitting patches</a></li>
+    <li><a name="toc-New-codecs-or-formats-checklist" href="#New-codecs-or-formats-checklist">1.7 New codecs or formats checklist</a></li>
+    <li><a name="toc-patch-submission-checklist" href="#patch-submission-checklist">1.8 patch submission checklist</a></li>
+    <li><a name="toc-Patch-review-process" href="#Patch-review-process">1.9 Patch review process</a></li>
+    <li><a name="toc-Regression-tests" href="#Regression-tests">1.10 Regression tests</a></li>
   </ul>
 </li>
 </ul>
@@ -94,10 +95,26 @@ generated by ./configure to understand what is needed.
 <em>any patch you make must be published</em>. The best way to proceed is
 to send your patches to the FFmpeg mailing list.
 </p>
+<a name="Contributing"></a>
+<h2 class="section"><a href="developer.html#toc-Contributing">1.3 Contributing</a></h2>
 
+<p>There are 3 ways by which code gets into ffmpeg.
+</p><ul>
+<li> Submiting Patches to the main developer mailing list
+      see <a href="#Submitting-patches">Submitting patches</a> for details.
+</li><li> Directly commiting changes to the main tree.
+</li><li> Commiting changes to a git clone, for example on github.com or
+      gitorious.org. And asking us to merge these changes.
+</li></ul>
+
+<p>Whichever way, changes should be reviewed by the maintainer of the code
+before they are commited. And they should follow the <a href="#Coding-Rules">Coding Rules</a>.
+The developer making the commit and the author are responsible for their changes
+and should try to fix issues their commit causes.
+</p>
 <p><a name="Coding-Rules"></a>
 </p><a name="Coding-Rules-1"></a>
-<h2 class="section"><a href="developer.html#toc-Coding-Rules-1">1.3 Coding Rules</a></h2>
+<h2 class="section"><a href="developer.html#toc-Coding-Rules-1">1.4 Coding Rules</a></h2>
 
 <p>FFmpeg is programmed in the ISO C90 language with a few additional
 features from ISO C99, namely:
@@ -180,7 +197,7 @@ please use av_log() instead.
 should also be avoided if they don&rsquo;t make the code easier to understand.
 </p>
 <a name="Development-Policy"></a>
-<h2 class="section"><a href="developer.html#toc-Development-Policy">1.4 Development Policy</a></h2>
+<h2 class="section"><a href="developer.html#toc-Development-Policy">1.5 Development Policy</a></h2>
 
 <ol>
 <li>
@@ -302,8 +319,9 @@ should also be avoided if they don&rsquo;t make the code easier to understand.
 </p>
 <p>Note, these rules are mostly borrowed from the MPlayer project.
 </p>
-<a name="Submitting-patches"></a>
-<h2 class="section"><a href="developer.html#toc-Submitting-patches">1.5 Submitting patches</a></h2>
+<p><a name="Submitting-patches"></a>
+</p><a name="Submitting-patches-1"></a>
+<h2 class="section"><a href="developer.html#toc-Submitting-patches-1">1.6 Submitting patches</a></h2>
 
 <p>First, read the <a href="#Coding-Rules">Coding Rules</a> above if you did not yet, in particular
 the rules regarding patch submission.
@@ -347,7 +365,7 @@ send a reminder by email. Your patch should eventually be dealt with.
 </p>
 
 <a name="New-codecs-or-formats-checklist"></a>
-<h2 class="section"><a href="developer.html#toc-New-codecs-or-formats-checklist">1.6 New codecs or formats checklist</a></h2>
+<h2 class="section"><a href="developer.html#toc-New-codecs-or-formats-checklist">1.7 New codecs or formats checklist</a></h2>
 
 <ol>
 <li>
@@ -387,11 +405,11 @@ send a reminder by email. Your patch should eventually be dealt with.
 
 
 <a name="patch-submission-checklist"></a>
-<h2 class="section"><a href="developer.html#toc-patch-submission-checklist">1.7 patch submission checklist</a></h2>
+<h2 class="section"><a href="developer.html#toc-patch-submission-checklist">1.8 patch submission checklist</a></h2>
 
 <ol>
 <li>
-    Does &rsquo;make fate&rsquo; pass with the patch applied?
+    Does <code>make fate</code> pass with the patch applied?
 </li><li>
     Was the patch generated with git format-patch or send-email?
 </li><li>
@@ -403,7 +421,7 @@ send a reminder by email. Your patch should eventually be dealt with.
 </li><li>
     Is the patch against latest FFmpeg git master branch?
 </li><li>
-    Are you subscribed to ffmpeg-dev?
+    Are you subscribed to ffmpeg-devel?
     (the list is subscribers only due to spam)
 </li><li>
     Have you checked that the changes are minimal, so that the same cannot be
@@ -461,7 +479,7 @@ send a reminder by email. Your patch should eventually be dealt with.
 </li></ol>
 
 <a name="Patch-review-process"></a>
-<h2 class="section"><a href="developer.html#toc-Patch-review-process">1.8 Patch review process</a></h2>
+<h2 class="section"><a href="developer.html#toc-Patch-review-process">1.9 Patch review process</a></h2>
 
 <p>All patches posted to ffmpeg-devel will be reviewed, unless they contain a
 clear note that the patch is not for the git master branch.
@@ -477,35 +495,23 @@ After a patch is approved it will be committed to the repository.
 <p>We will review all submitted patches, but sometimes we are quite busy so
 especially for large patches this can take several weeks.
 </p>
+<p>If you feel that the review process is too slow and you are willing to try to
+take over maintainership of the area of code you change then just clone
+git master and maintain the area of code there. We will merge each area from
+where its best maintained.
+</p>
 <p>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
 separate patches.
 </p>
 <a name="Regression-tests"></a>
-<h2 class="section"><a href="developer.html#toc-Regression-tests">1.9 Regression tests</a></h2>
+<h2 class="section"><a href="developer.html#toc-Regression-tests">1.10 Regression tests</a></h2>
 
 <p>Before submitting a patch (or committing to the repository), you should at least
 test that you did not break anything.
 </p>
-<p>The regression tests build a synthetic video stream and a synthetic
-audio stream. These are then encoded and decoded with all codecs or
-formats. The CRC (or MD5) of each generated file is recorded in a
-result file. A &rsquo;diff&rsquo; is launched to compare the reference results and
-the result file. The output is checked immediately after each test
-has run.
-</p>
-<p>The regression tests then go on to test the FFserver code with a
-limited set of streams. It is important that this step runs correctly
-as well.
-</p>
-<p>Run &rsquo;make test&rsquo; to test all the codecs and formats. Commands like
-&rsquo;make regtest-mpeg2&rsquo; can be used to run a single test. By default,
-make will abort if any test fails. To run all tests regardless,
-use make -k. To get a more verbose output, use &rsquo;make V=1 test&rsquo; or
-&rsquo;make V=2 test&rsquo;.
-</p>
-<p>Run &rsquo;make fulltest&rsquo; to test all the codecs, formats and FFserver.
+<p>Running &rsquo;make fate&rsquo; accomplishes this, please see &lsquo;<tt>doc/fate.txt</tt>&rsquo; for details.
 </p>
 <p>[Of course, some patches may change the results of the regression tests. In
 this case, the reference results of the regression tests shall be modified
@@ -514,7 +520,7 @@ accordingly].
 <hr size="1">
 <p>
  <font size="-1">
-  This document was generated by <em>Kyle Schwarz</em> on <em>July 23, 2011</em> using <a href="http://www.nongnu.org/texi2html/"><em>texi2html 1.82</em></a>.
+  This document was generated by <em>Kyle Schwarz</em> on <em>September 2, 2011</em> using <a href="http://www.nongnu.org/texi2html/"><em>texi2html 1.82</em></a>.
  </font>
  <br>