FFmpeg Contribution and Code Review Process Explained

FFmpeg manages its open-source contribution and code review process through a decentralized, mailing-list-driven workflow centered around Git, peer review, and automated regression testing. Rather than relying on modern pull request platforms like GitHub or GitLab for intake, the project uses the ffmpeg-devel mailing list as the primary hub for submitting patches, discussing technical design, conducting peer reviews, and achieving consensus before designated maintainers push code to the master repository.

Patch Submission via the Mailing List

Contributors submit changes by sending unified patches directly to the ffmpeg-devel mailing list. The project relies on standard Git utilities, primarily git format-patch and git send-email.

Submissions must adhere to strict formatting rules:

  • Each patch must represent a single, atomic change to ensure reviewability and bisectability.
  • Commit messages must follow a specific convention, generally starting with the modified subsystem or component (for example, avcodec/h264:), followed by a concise description of the change.
  • Code must conform to C99 standards and follow the project's formatting guidelines, avoiding unnecessary stylistic changes to untouched code.

Public Code Review

Once a patch hits the mailing list, it enters an asynchronous, public review process. Anyone in the community can review, test, and comment on submitted patches. Reviewers examine the code for:

  • Correctness and Security: Verifying buffer bounds, memory management, and prevention of undefined behavior.
  • Performance: Ensuring code paths do not introduce regressions, particularly in critical audio/video processing pipelines where SIMD assembly optimizations are often required.
  • API/ABI Stability: Checking that public interfaces in libraries like libavcodec and libavformat maintain backward compatibility according to FFmpeg's deprecation rules.

If revisions are necessary, the author submits an updated version of the patch set, marked with a version tag (such as [PATCH v2]), along with an explanation of changes since the previous iteration.

Automated Testing with FATE

FFmpeg relies heavily on its regression testing suite, known as FATE (FFmpeg Automated Testing Environment). FATE runs comprehensive decoding, encoding, and filtering tests against a large repository of multimedia samples across diverse hardware architectures, operating systems, and compilers.

Contributors are expected to run the test suite locally using make check or make fate before submitting patches. Additionally, automated build bots run FATE against submitted patches and report regressions back to the development community. A patch that breaks existing FATE tests will not be accepted until the failure is resolved or the test reference is intentionally and validly updated.

Commit Access and Maintainership

FFmpeg uses a maintainer-based model to manage write access to its official Git repository:

  • Subsystem maintainers oversee specific modules (such as specific demuxers, decoders, or platform-specific optimizations).
  • Once a patch receives sufficient review approvals (an explicit "LGTM" or "Looks Good To Me" from relevant maintainers) and no objections are raised during a standard waiting period, a maintainer applies the patch using git am.
  • Long-term, active contributors who consistently demonstrate high-quality code and good judgment can be granted direct commit access following community consensus, allowing them to apply their own reviewed patches and assist with applying patches from newer contributors.

Governance and Conflict Resolution

Technical disputes that cannot be resolved through normal mailing list discussion are governed by the FFmpeg Constitution. The project elects a Technical Committee tasked with resolving deadlocks over code design, API changes, and contentious contributions, ensuring that technical decisions align with the long-term stability and performance goals of the software.