GSoC 2008 - FFmpeg integration

From Audacity Wiki
Revision as of 04:34, 22 April 2008 by LRN (talk | contribs) (Created a page about FFmpeg integration GSoC project.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


This page describes the FFmpeg integration GSoC project and will reflect it's progress over time.


FFmpeg is a set of libraries for audio/video encoding/decoding/muxing/demuxing/processing/capturing. In Audacity FFmpeg will be used to import and export audio data. While FFmpeg also has other uses, this is outside the scope of this project.



As a design decision, FFmpeg libraries are being linked dynamically and loaded at run time. This allows FFmpeg to be optional (Audacity will run without FFmpeg) and it could be distributed separately (removes licensing issues).

It's not yet clear which build of FFmpeg will be used - static or shared. Static build results in one big library, that contains all functions from FFmpeg package. Shared build results in a few libraries (and these libraries may depend on other non-FFmpeg libraries), each library exports different functions. Valid system-wide FFmpeg package is usually shared, and resides somewhere in PATH, so any application is able to load functions from any of these libraries. This is also necessary because libraries depend on each other. Static build is usually stored somewhere within application's directory as some kind of plug-in. My guess is that Linux users would prefer shared FFmpeg, since they have superior package managing system, while on Windows it's easier to drop static FFmpeg build into Audacity and forget about packages.

From Audacity's point of view there's only one difference: when using shared FFmpeg, Audacity has to load each function from respective library, and each library has to be mapped into Audacity process memory by separate wxDynamicLibrary object. When using static FFmpeg, Audacity only loads one library and imports everything from it. Because all shared libraries should be in PATH, it's not useful to ask user for libraries' location when shared build is used, while with static build it may be necessary.

Functionality overlap

FFmpeg is able to import and export FLAC, OGG Vorbis, MP3, MP2 and various uncompressed wave files, however Audacity already possesses all necessary capabilities to work with these formats (except MP3 - exporting requires separate plug-in). Using built-in Audacity import/export modules is better because they support various sample formats, while FFmpeg supports only 16-bit integer samples. FFmpeg also cannot (at the time of writing) import meta-data (tags) from raw FLAC files.

In some cases user may wish to use FFmpeg to import files however. This could be achieved in two ways:

  • Add new preference - plug-in loading order. By using this preference user could adjust the order in which plug-ins are being registered in Audacity. When FFmpeg import plug-in is registered before all others, it would handle importing of any file without letting other plug-ins even try. At the moment FFmpeg is always registered last.
  • Make Importer aware of the file filter user choose in FileDialog, and assume that when user chooses "FFmpeg-compatible file" filter, he (user) wants to import files via FFmpeg, and by choosing "MP3 files" user suggests Audacity to use libmp3lame. Implementing this requires a few changes, some of them may involve cumbersome passing of additional argument through several functions from ShowOpenDialog to Importer.

Overlap in export functionality is discussed later.

Export procedure

Currently Audacity only offers limited choice of export file types:

  • WAV, AIFF and other uncompressed files
  • OGG Vorbis
  • MP3
  • MP2
  • FLAC
  • Command-line exporter

First one hides variety of export types (header formats) and codecs (sample encoding formats) in it's "Options..." dialog. This is possible because there's little or no difference between all these formats. For FFmpeg such solution is not acceptable, since FFmpeg can export audio in completely different formats and grouping them all in one choice is unintuitive. Grouping all the options for all these formats in one dialog is not the easiest (to implement and to use) thing in the Universe too.

To overcome this ExportPlugin class was slightly redesigned to present itself as more than one export type, while using the same code to perform actual export procedure. This new feature will be used to present FFmpeg as a few common export types, while still providing access to complete functionality in options dialog. It is not yet decided whatever options dialog should be one for all FFmpeg-exported types or separate dialog for each type/group of types.

User may explicitly choose either built-in FLAC exporter or FFmpeg loss-less exporter (featuring FLAC amongst other codecs/formats).


GetOpenFileName filter length bug

On Windows one file filter in OpenDialog can't exceed the length of 260 bytes. This cannot be fixed. To work around this issue two solutions were presented:

  • remove "All supported files" import filter on Windows (this is the filter that exceeds the limit of 260 bytes), and replace it with a set of common media file types (shorter than 260 bytes). This solution is also easy enough. However, "All supported files" is considered a valuable feature, as it allows user to separate unimportable files from importable ones without actually knowing which files are supported by Audacity. Removing it will create inconsistency in Audacity cross-platform support. This solution cannot be improved later.
  • use wxGenericFileDialog instead of wxFileDialog. This solution is very easy (three lines of code and one, additional #include and a tweak to wxWidgets to enable generic file dialog) and it works. Filter duplication bug in wxGenericFileDialog is not critical and has been easily worked around. As a side effect the resulting dialog does not have native Windows look and may confuse Windows users. This can be fixed by improving wxGenericFileDialog to look more Windows-native, but this may be outside the scope of this project, and takes some time and effort. However, in a long run this can be done, making this solution the best one. It also may benefit wxWidgets project.

Channel order

FFmpeg presents channels in the order they stored on the media. Audacity has to watch the importing type and reorder channels accordingly. Same goes for export. This is worsened by the fact that Audacity lacks proper multi-channel support.

Dynamic changes

For some files or other sources audio parameters may change over time. For example, number of channels or sample rate may vary. At the moment FFmpeg importer can't handle that.

Special cases

FFmpeg offers a lot of information, most of it is used to handle special cases (like - additional time offset, etc) and is completely ignored at the moment.

Error handling

Importers and exporters in Audacity are not known for their meaningful error messages, because there is no error messages coming from them. Error reporting could be improved in all plug-ins, and error handling should be improved in FFmpeg plug-in in particular.


  • FFmpeg exporter.
  • Compatibility detection for FFmpeg exporter.


This will serve as some kind of log, anyone is free to post FFmpeg-related entries here. This could be done in Talks of course, but Talks are supposed to be used for discussions about contents of the page and further edits, not for content itself.

LRN 21:34, 21 April 2008 (PDT): First log entry.