FFmpeg

https://git.ffmpeg.org/ffmpeg.git

https://git.ffmpeg.org/ffmpeg.git - it uses Git, and as such keeps track of the revisions. Note that revisions may also be viewed at the FFmpeg cvslog archives: https://lists.ffmpeg.org/pipermail/ffmpeg-cvslog/. Remark: The name cvslog dates to when the project used CVS. Now, the project uses Git.

FFmpeg's repository is public, so in addition to the release branches (e.g https://git.ffmpeg.org/gitweb/ffmpeg.git/shortlog/refs/heads/release/3.0), we have a branch for master (https://git.ffmpeg.org/gitweb/ffmpeg.git/shortlog/refs/heads/master). Developers also sometimes maintain their own private forks for work in progress, e.g https://github.com/gajjanag/FFmpeg).

Git is currently used, as reflected by https://git.ffmpeg.org/ffmpeg.git .

https://ffmpeg.org/developer.html#Release-process-1 - this describes the release process. In particular, major and minor version numbers are maintained for releases.

https://git.ffmpeg.org/gitweb/ffmpeg.git/tags - each release is tagged. As an example, please see https://git.ffmpeg.org/gitweb/ffmpeg.git/tag/ee4ec90241c2e8c2ab69a1155fc3df86ff6f09ad.

https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/Changelog - this file keeps track of the release notes.

https://ffmpeg.org/security.html - FFmpeg associates public vulnerabilities with the release that fixes them here.

https://trac.ffmpeg.org/ - the bug tracker for FFmpeg.

https://trac.ffmpeg.org/ticket/5689 - an illustration of an individual ticket.

As can be seen at https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&col=id&col=summary&col=status&col=type&col=component&col=version&col=time&col=changetime&report=1&desc=1&order=time, the project does respond to most bug reports within a few days.

A significant fraction of them are fixed: https://trac.ffmpeg.org/query?status=closed&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=component&order=priority.

https://trac.ffmpeg.org/query?status=closed&status=new&status=open&desc=1&order=priority - as can be seen here, all incoming reports are classified into categories, and can be associated with the "enhancement" type or the "wish" priority.

Also clear from the above links is that a significant fraction are implemented.

https://trac.ffmpeg.org/report - this allows searching through the report database via a variety of queries.

As seen at: https://ffmpeg.org/security.html, vulnerabilities are reported to ffmpeg-security@ffmpeg.org.

As seen at: https://ffmpeg.org/security.html, vulnerabilities reported to ffmpeg-security@ffmpeg.org are private.

As can be seen at: https://ffmpeg.org/security.html, regular point releases are made to address security vulnerabilities. For further evidence of a regular response time, please see: https://security.googleblog.com/2014/01/ffmpeg-and-thousand-fixes.html.

For more detailed statistics, please check the commit log - any commit addressing a CVE has the CVE number associated with it via the commit message.

FFmpeg can be built on a variety of platforms, including but not limited to Windows, GNU/Linux, OS X, BSD's, Solaris. Generally, it may be accomplished via ./configure, make, make install with a few flags, see https://trac.ffmpeg.org/wiki/CompilationGuide/Generic for details.

FFmpeg builds fine with FLOSS tools, please see e.g fate.ffmpeg.org.

FFmpeg uses the FATE automated test suite: http://fate.ffmpeg.org/. The client side infrastructure is maintained within the FFmpeg repo. Server side is maintained at https://git.ffmpeg.org/fateserver. For details on how this works, please see https://ffmpeg.org/fate.html.

As seen from https://ffmpeg.org/fate.html, invoking the FATE test suite is usually as simple as make fate. To obtain the test samples, make fate-rsync pulls samples from the https://samples.ffmpeg.org/ directory.

The code coverage is generally at a 66%-75% level. It is still being actively worked upon, with http://coverage.ffmpeg.org/ showing the current status.

A number of FATE clients are run, as can be seen from fate.ffmpeg.org. Clients get added and removed, but at any given moment there are a reasonable variety of CPU architectures, operating systems, and toolchains represented at fate.ffmpeg.org.

This is currently only an informal requirement, and generally is enforced only in libavcodec, where new encoders and decoders must be accompanied by tests.

However, this is not uniformly enforced. Roughly, libavfilter tends to lack a lot of tests, and many new filters do not have tests associated with them immediately. It is the general expectation (informal) that tests will be added by the developer over time.

There are FATE clients running the ubsan toolchain, valgrind, etc. Generally speaking, -Wall and some other warnings are enabled by default for all compilations.

There are numerous commits in the repository addressing warnings, and patches are regularly submitted and reviewed for the same.

However, it must be noted that as FFmpeg supports a variety of toolchains, some of which omit bogus warnings, and that too sometimes only for specific versions of the toolchain, it is infeasible to reach a 0 warnings policy across all FATE clients. Generally, on "standard" toolchains, such as GNU/Linux OR OS X + gcc OR clang, the warning count does not exceed 100, and most warning cleanup work addresses such toolchains.

Nicholas George and Michael Niedermayer (among possibly others) are developers who understand the above principles and actively use them. Michael Niedermayer is perhaps the only currently active developer who meets all of the above criteria.

FFmpeg uses Coverity (https://scan.coverity.com/), a number of FATE clients use aids like ubsan, Valgrind, Helgrind, etc.

FFmpeg does address the issue of creating more secure defaults, defensive programming practices, etc from time to time.

As seen from files like aes.c, blowfish.c, etc in libavutil/, FFmpeg only uses publicly known cryptographic algorithms by default.

This may be seen by examining the source code.

Although FFmpeg does provide a low level DES API, it is used strictly for format interoperability and is thus not part of any security mechanism.

FFmpeg does implement and export a number of low level cryptographic primitives, some of which are broken such as MD5 and single DES. However, it should be noted that the usage of these primitives within FFmpeg are confined to instances where it is necessary in order to meet some specification.

Same remarks as above. In particular, SHA-1 is used for creating identifiers, and is not used for a security purpose.

FFmpeg does not store passwords for authentication of external users.

As can be seen from https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/libavutil/random_seed.c, FFmpeg makes a best effort at providing a cryptographically secure random number generator.

PGP signatures are provided: https://ffmpeg.org/download.html#releases. The download is over https.

PGP signatures are provided: https://ffmpeg.org/download.html#releases. The download is over https.

FFmpeg fixes public vulnerabilities much more quickly than this. Please see the commit logs for evidence of this.

FFmpeg has a track record of fixing CVE's promptly. Some evidence for this: 1. https://ffmpeg.org/security.html 2. Commit logs - all CVE related commits have the CVE number included in the message 3. https://security.googleblog.com/2014/01/ffmpeg-and-thousand-fixes.html.

FFmpeg uses Coverity (scan.coverity.com) before production releases, which checks for a variety of common C programming mistakes. It should be noted that Coverity is not perfect, and there are false positives which is why FFmpeg does not necessarily "clear" the list before release. Nevertheless, an effort is made to fix Coverity reports before release.

FFmpeg uses Coverity (scan.coverity.com), which checks for a variety of common C programming mistakes.

FFmpeg fixes exploitable vulnerabilities promptly, regardless of whether they are found via static analysis (e.g privately via Coverity) or made public.

Fuzzing is certainly performed quite regularly on FFmpeg: https://security.googleblog.com/2014/01/ffmpeg-and-thousand-fixes.html, http://obe.tv/about-us/obe-blog/item/26-fuzzing-ffmpeg-for-fun-and-profit. Note that this is being done by third parties.

FFmpeg uses assertions at various locations in the code (https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/libavutil/random_seed.c).

FFmpeg does tend to fix vulnerabilities discovered via dynamic code analysis in a timely fashion: https://security.googleblog.com/2014/01/ffmpeg-and-thousand-fixes.html, http://obe.tv/about-us/obe-blog/item/26-fuzzing-ffmpeg-for-fun-and-profit. Note that is being done by third parties.