Main Inclusion Report for ffmpeg

Requirements

1. Availability: http://archive.ubuntu.com/ubuntu/pool/universe/f/ffmpeg, available for all supported architectures

2. Rationale:

   • Build dependency of xine-lib
   • very useful command-line utilities, some front-ends use it
   • nearly all multimedia players rely either on ffmpeg or gstreamer for decoding video formats

3. Security:

   • The following CVE Entries have been filed in the past:

     • http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4800

     • http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4799

     • http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4048

   • 15 Entries in the Secunia history. (please consider that there are some duplicates there).

Please note that the purpose of ffmpeg is to read foreign (multimedia) data. Compared to its spreading in the free software world, I'd not consider ffmpeg as insecure.

• No binaries running as root or suid/sgid.
• Does not open any port.

1. Quality assurance:

   • Package works out of the box without configuration.
   • Package does not ask any debconf questions higher than priority 'medium'.

   • Good maintenance in Debian.

   • No showstopper Debian bugs. Sam is very careful with uploading a new ffmpeg copy, because of ffmpeg's quite instable API/ABI.

   • Very Active and responsive upstream. Big overlap with mplayer developers

   • No upstream bug tracker, bugs are handled via developers list.

   • Does not deal with exotic hardware which we cannot support.

2. Standards compliance:

   • Meets the FHS, Debian Policy

   • Meets Debian library packaging guide standards.

   • Standard debhelper packaging, quilt patch system.

3. Dependencies:

   • libdts (universe)
   • liba52 (universe) (can use internal copy)

both could be disabled at compiletime, but I'd suggest to move them to main as well.

Patent Discussion

Consider the following part of debian/README.Debian:

Summary of the patent issues with ffmpeg
========================================

   The only patents related to ffmpeg which seem to be enforced against open
source software cover the following codec technologies and file formats:

   * MP3 encoding
   * AAC decoding and encoding
   * the ASF file format

   I did not activate MP3 encoding (through LAME) in libavcodec, nor AAC
support (through FAAC/FAAD). However, since I have found no real enforcement
of the mysterious ASF file format patents, I did not deactivate ASF support in
libavformat. See more details in the patents.txt file.

Please now consider the file debian/patents.txt:

The MP3 audio coding format
===========================

   Much has already been said about MP3 and the huge patent portfolio of
the MPEG members, especially the Fraunhofer institute. Eric Scheirer's
MPEG, Patents, and Audio Coding FAQ [1.1] is an attempt to "inject
some sanity in what is becoming an increasingly heated discussion
about patent rights surrounding MPEG technology, especially for audio
compression". It also has a few words about other patented products
covered in this document.

[1.1] http://web.media.mit.edu/~eds/mpeg-patents-faq


The AAC audio coding format
===========================

   Dolby's AAC (Advanced Audio Coding) is covered by patents owned by
Dolby Laboratories, AT&T Laboratories, Fraunhofer Institute and Sony
Corp.

   The FAAC project was threatened by the AAC license consortium. Press
report about how "an opensource project was closed down due to pressures
from the AAC license consortium which requires a lumpsum payment of
10,000 USD plus a per-copy payment of 1.35 USD, thus effectively banning
free software implementations. The policies surrounding AAC also harm
interoperability [2.2]." This was related by Heise [2.3] and FFII has
a page about the Dolby threat [2.1] as well as additional information
about MPEG-related patents [2.4].

   The author stopped distributing the FAAC binaries, but still provides
full source code and CVS access. To my knowledge he has not been
threatened again. I also read on a web forum [2.5] that Cisco's lawyers
claim that their LGPL distribution of AAC software in MPEG4IP is
completely legal and that Dolby cannot forbid such distribution.

[2.1] http://swpat.ffii.org/patents/effects/dolby/index.en.html
[2.2] http://www.xiph.org/archives/vorbis-dev/200011/0286.html
[2.3] http://www.heise.de/newsticker/data/vza-20.11.00-000/
[2.4] http://swpat.ffii.org/patents/effects/mpeg/index.en.html
[2.5] http://www.hydrogenaudio.org/index.php?showtopic=310&


The ASF file encapsulation format
=================================

   Microsoft obtained a patent on the ASF (Active Stream Format) audio
file format on March 21, 2000:

  | United States Patent 6,041,345 Levi , et al. March 21, 2000
  |
  | Active stream format for holding multiple media streams
  |
  |  Abstract An active stream format is defined and adopted for a
  | logical structure that encapsulates multiple data streams. The data
  | streams may be of different media. The data of the data streams
  | is partitioned into packets that are suitable for transmission
  | over a transport medium. The packets may include error correcting
  | information. The packets may also include clock licenses for
  | dictating the advancement of a clock when the data streams are
  | rendered. The format of ASF facilitates flexibility and choice
  | of packet size and in specifying maximum bit rate at which data
  | may be rendered. Error concealment strategies may be employed in
  | the packetization of data to distribute portions of samples to
  | multiple packets. Property information may be replicated and stored
  | in separate packets to enhance its error tolerance. The format
  | facilitates dynamic definition of media types and the packetization
  | of data in such dynamically defined data types within the format.

   This patent is rumoured to have been enforced at least once, though
only through what I'd call non-hostile intimidation. Avery Lee, the
VirtualDub author, removed ASF support from his software after a phone
call from a Microsoft employee that he relates in his 5/12/2000 news
[3.1].

   However I could not find evidence of an official threat: all I could
find on the web seemed to be interpretations of the VirtualDub author's
article, for instance on Advogato [3.2], CPT [3.3] or FFII [3.4]. Avery
Lee states that the phone call was from a programmer, not from the
legal department. There does not seem to be an official statement from
Microsoft.

[3.1] http://web.archive.org/web/20000817222620/http://www.geocities.com/virtualdub/virtualdub_news.html
[3.2] http://www.advogato.com/article/101.html
[3.3] http://www.cptech.org/ip/business/software/audio.html
[3.4] http://swpat.ffii.org/patents/effects/asf/index.en.html

remarks of the submitter of this request

Given that we shipped exactly this package in main for ubuntu 5.04 (hoary), I ask for reinclusion.

I could imagine that canonical would not want to have mpeg decoders shipped on (live) cds. This is no problem, since I plan to split xine's ffmpeg plugin into a seperate binary package, so that it does not need to be on the cd.

On the other hand, we don't seem to have problems with mpeg decoders in main. We even ship libmad in main.

I don't see what patents ffmpeg actually violates and are actively enforced. debian is shipping this package in main since years without problems. Considering this beeing already discussed at the TB meeting, I ask for inclusion into main of ffmpeg.

Reviewers

I'd like to comment by referencing the Restricted Formats policy of two popular North American linux vendors: http://en.opensuse.org/Restricted_Formats http://fedoraproject.org/wiki/Multimedia

I note that ffmpeg in its current state still decodes mpeg2-mpeg4, mp3, and several other formats that USA Linux vendors would not dare to touch. In fact, they've physically stripped away much of the code for this at the source level, not just disabling it via --configure flags.

As much as I'd personally love to see FFmpeg in main, is this a legally sound choice?

--JohnDong

Answer to jdong: I don't see much legal difference between shipping ffmpeg in multiverse or in main: both are on the same ftp servers and ubuntu mirrors. As said above, no ffmpeg code needs to be on the live cd nor in the ship seed. The main point of this MIR is to reduce code duplication and faciliate xine-lib packaging.

--ReinhardTartler

MartinPitt:

• Packaging looks reasonably sane (modulo upstream's lack of real stable APIs).
• Security: we want to have security updates to these codes anyway due to their widespread usage, and we have to apply them to the xine-lib copy anyway.

• Patents: The reasoning above is convincing, and I agree that shipping it in main or multiverse does not make a legal difference. It *could* make a legal difference to ship it on CDs, so we should not do that. Given that we ship the same code in xine-lib in main already, I am not too concerned about it.

• Therefore: approved