Licenses for patches must be compatible with FFmpeg.
Contributions should be licensed under the LGPL 2.1, including an "or any later version" clause, or, if you prefer a gift-style license, the ISC or MIT license. GPL 2 including an "or any later version" clause is also acceptable, but LGPL is preferred. If you add a new file, give it a proper license header. Do not copy and paste it from a random place, use an existing file as template.
You must not commit code which breaks FFmpeg!
This means unfinished code which is enabled and breaks compilation, or compiles but does not work/breaks the regression tests. Code which is unfinished but disabled may be permitted under-circumstances, like missing samples or an implementation with a small subset of features. Always check the mailing list for any reviewers with issues and test FATE before you push.
Commit messages
Commit messages are highly important tools for informing other developers on what a given change does and why. Every commit must always have a properly filled out commit message with the following format:
area changed: short 1 line description
details describing what and why and giving references.
If the commit addresses a known bug on our bug tracker or other external issue (e.g. CVE), the commit message should include the relevant bug ID(s) or other external identifiers. Note that this should be done in addition to a proper explanation and not instead of it. Comments such as "fixed!" or "Changed it." are not acceptable.
When applying patches that have been discussed at length on the mailing list, reference the thread in the commit message.
Testing must be adequate but not excessive.
If it works for you, others, and passes FATE then it should be OK to commit it, provided it fits the other committing criteria. You should not worry about over-testing things. If your code has problems (portability, triggers compiler bugs, unusual environment etc) they will be reported and eventually fixed.
Do not commit unrelated changes together.
They should be split them into self-contained pieces. Also do not forget that if part B depends on part A, but A does not depend on B, then A can and should be committed first and separate from B. Keeping changes well split into self-contained parts makes reviewing and understanding them on the commit log mailing list easier. This also helps in case of debugging later on. Also if you have doubts about splitting or not splitting, do not hesitate to ask/discuss it on the developer mailing list.
Cosmetic changes should be kept in separate patches.
We refuse source indentation and other cosmetic changes if they are mixed 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 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.
NOTE: If you had to put if(){ .. } over a large (> 5 lines) chunk of code, then either do NOT change the indentation of the inner part within (do not move it to the right)! or do so in a separate commit
Credit the author of the patch.
Make sure the author of the commit is set correctly. (see git commit –author) If you apply a patch, send an answer to ffmpeg-devel (or wherever you got the patch from) saying that you applied the patch.
Credit any researchers
If a commit/patch fixes an issues found by some researcher, always credit the researcher in the commit message for finding/reporting the issue.
Always wait long enough before pushing changes
Do NOT commit to code actively maintained by others without permission. Send a patch to ffmpeg-devel. If no one answers within a reasonable time-frame (12h for build failures and security fixes, 3 days small changes, 1 week for big patches) then commit your patch if you think it is OK. Also note, the maintainer can simply ask for more time to review!