FFmpeg Contribution and Code Review Process

This article provides a comprehensive overview of how the FFmpeg project manages its open-source contributions and code review process. It explains the mechanics of submitting patches, the community-driven review system, the reliance on mailing lists instead of traditional pull requests, and how approved code eventually merges into the main codebase.

The Mailing List Centric Workflow

Unlike many modern open-source projects that utilize platforms like GitHub or GitLab for pull requests, FFmpeg relies on a traditional, email-based workflow. The central hub for all development activity is the ffmpeg-devel mailing list. Every code contribution, discussion, and review occurs publicly within this mailing list, ensuring a transparent and archived history of the project’s evolution.

Submitting Patches

To contribute to FFmpeg, developers write and test their changes locally using Git. Once the code is ready, the submission process follows a specific set of steps:

1. Code Formatting: Developers must adhere to FFmpeg’s strict coding standards, which emphasize clean C99 code, proper naming conventions, and portability.
2. Creating Patches: Contributors use the git format-patch command to generate email-friendly patch files from their local commits.
3. Sending Patches: The patches are sent directly to the ffmpeg-devel mailing list using git send-email. This places the proposed changes directly in front of the community and relevant maintainers.

The Code Review Process

Once a patch arrives on the mailing list, the peer review process begins. Because FFmpeg is highly complex and runs on numerous platforms, thorough code review is critical to prevent regressions and security vulnerabilities.

• Peer Feedback: Anyone in the community can review a patch. Reviewers reply directly to the email thread, inline-commenting on specific lines of code to suggest improvements, point out bugs, or ask for clarification.
• Iterative Revisions: Based on feedback, the author modifies their code and submits a new version of the patch (labeled as v2, v3, etc.) to the same mailing list thread. This process repeats until all objections are resolved.
• Testing: Automated continuous integration (CI) systems and individual developers test the patches across different operating systems, CPU architectures, and compilers to ensure cross-platform compatibility.

Approval and Merging

FFmpeg has a decentralized hierarchy of subsystem maintainers who hold commit access to the main repository.

• Maintainer Sign-off: Once a patch receives consensus—often indicated by a “looks good to me” (LGTM) from experienced community members or the specific subsystem maintainer—it is deemed ready.
• Pushing to Master: The maintainer responsible for that area of the codebase applies the patch to their local tree and pushes it to the official FFmpeg master repository.
• Direct Commit Access: Over time, contributors who consistently submit high-quality patches and actively participate in reviews may be granted direct write access to the Git repository, allowing them to push their own approved changes.