DOCS/contribute.md
The main contact for mpv development is IRC, specifically #mpv and #mpv-devel on Libera.chat. GitHub is used for code review and long term discussions.
git format-patch.Copyright in the
repository root directory).Write informative commit messages. Use present tense to describe the situation with the patch applied, and past tense for the situation before the change.
The subject line (the first line in a commit message) must contain a prefix identifying the sub system, followed by a short description what impact this commit has. This subject line and the commit message body must not be longer than 72 characters per line, because it messes up the output of many git tools otherwise.
For example, you fixed a crash in af_volume.c:
fixed the bug (wtf?)af_volume: fix crash due to null pointer accessHaving a prefix gives context, and is especially useful when trying to find
a specific change by looking at the history, or when running git blame.
Sample prefixes: vo_gpu: ..., command: ..., DOCS/input: ...,
TOOLS/osxbundle: ..., osc.lua: ..., etc. You can always check the git
log for commits which modify specific files to see which prefixes are used.
The first word after the : is lower case.
Don't end the subject line with a ..
Put an empty line between the subject line and the commit message. If this is missing, it will break display in common git tools.
The body of the commit message (everything else after the subject line) must be as informative as possible and contain everything that isn't obvious. Don't hesitate to dump as much information as you can - it doesn't cost you anything. Put some effort into it. If someone finds a bug months or years later, and finds that it's caused by your commit (even though your commit was supposed to fix another bug), it would be bad if there wasn't enough information to test the original bug. The old bug might be reintroduced while fixing the new bug.
The commit message must be wrapped on 72 characters per line, because git tools usually do not break text automatically. On the other hand, you do not need to break text that would be unnatural to break (like data for test cases, or long URLs).
Another summary of good conventions: https://chris.beams.io/posts/git-commit/
mpv uses C11 with K&R formatting, with some exceptions.
Use the K&R indent style.
Use 4 spaces of indentation, never use tabs (except in Makefiles).
Add a single space between keywords and binary operators. There are some other cases where spaces must be added. Example:
if ((a * b) > c) {
// code
some_function(a, b, c);
}
Break lines on 80 columns. There is a hard limit of 100 columns. You may ignore this limit if there's a strong case that not breaking the line will increase readability. Going over 100 columns might provoke endless discussions about whether such a limit is needed or not, so avoid it.
If the body of an if/for/while statement has more than 1 physical lines, then always add braces, even if they're technically redundant.
Bad:
if (a)
// do something if b
if (b)
do_something();
Good:
if (a) {
// do something if b
if (b)
do_something();
}
If the if has an else branch, both branches must use braces, even if they're technically redundant.
Example:
if (a) {
one_line();
} else {
one_other_line();
}
If an if condition spans multiple physical lines, then put the opening brace for the if body on the next physical line. (Also, preferably always add a brace, even if technically none is needed.)
Example:
if (very_long_condition_a &&
very_long_condition_b)
{
code();
} else {
...
}
(If the if body is simple enough, this rule can be skipped.)
Remove any trailing whitespace.
Do not make stray whitespaces changes.
The order of #include statements in the source code is not very consistent.
New code must follow the following conventions:
#include <stdlib.h> etc.) on the top,#include <zlib.h> etc.)#include "player/core.h")If you have used an AI/LLM for your contribution, you must disclose this in the PR description. Such contributions are not forbidden, but the submitter takes full responsibility for the code changes. This includes having full understanding of the code (knowing what was changed and why) and the ability to participate in the code review process with human-written responses. This also includes confirming that the code can be submitted under the same license as the relevant files (usually LGPLv2 or GPLv2).
Clearly vibe-coded patches will not be considered.
Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms. The Contributor Code of Conduct can be found here: https://www.contributor-covenant.org/version/2/0/code_of_conduct/
Push access to the main git repository is handed out on an arbitrary basis. If you got access, the following rules must be followed: