2009-01-22 00:55:12 UTC
Last week the third Foundations of Open Media Software Workshop (FOMS 2009)
was held in Hobart, Australia. I attended to wave the FFmpeg & Xvid flag.
A number of concerns about FFmpeg were spoken of during the workshop, so
about half an hour was spent collating them. A dump of my notes is provided
below with a paraphrasing of the hurt statements.
Each year the FOMS workshop identifies community goals to progress the state
of open media software. It is neither practical nor my place to commit other
developers to do stuff. So, for the concerns that *I* agree with, *I* have
nominated some goals that *I* might work towards over the next 12-18 months.
Comments are most welcome.
1. CONCERN: Quality assurance
"It is difficult to determine which revision of the FFmpeg tree is
suitable for distributing and/or linking against.."
This comment was echoed in unison by the gnash, gstreamer, swfdec devs
whom rely on FFmpeg for decoding/encoding services.
Yes, the head revision isn't always suitable for use due to regressions.
Recent examples include the Aug'08 WMA regression (now fixed), and audio
resampling between different sample formats (my fault, still broken).
Mike Melanson's FATE effort was discussed, and seen as a good step forward
in improving QA.
There are many outstanding bugs in roundup.
Bugs get dealt with when *somebody* fixes them (stating the obvious).
Regression tests to stress the behaviour of the FFmpeg API, not just
bitstream regressions, are lacking.
Formal releases have been discussed at length by the FFmpeg community and
have not been pursued due to lack of time & effort. 'Somebody' needs to
do the hard work.
Other projects employ bug squashing events to improve quality.
GOAL: Improve QA processes
OBJECTIVES: Extend FFmpeg regression test scripts and test cases.
Contribute FATE test cases.
Fix more bugs.
2. CONCERN: API stability
"The FFmpeg API keeps changing..."
API is not backwards compatible between major API version bumps. Stuff
gets deprecated, API behaviour changes.
This makes upgrading the libav* packages on a distribution difficult,
because often the application also needs to be upgraded.
As long as new codecs, containers and concepts are being added to FFmpeg,
the API will continue to change.
Ensuring backwards compatibility is a lot of work. There are perhaps more
important things to be concerned about.
Do we need a mechanism to inform users of FFmpeg about API changes?
3. CONCERN: Authorship
"The practises used to develop FFmpeg are considered as questionable."
This is perception stems from the unwillingness of authors to associate
their names with particular blobs of code.
4. CONERN: --disable-patents.
"It would be nice to build FFmpeg with all patent encumbered
Duh, this is can be achieved today by disabling everything except RAW.
Would require lots of work to tag pieces of the code with the corresponding
patent number(s) and expiry dates.
Such an effort would never be complete, or carry authority. It would
therefore be of academic value only.
Which country? Only U.S patents? Probably.
Somebody who cares about patents would need to do this.
5. CONCERN: Suitability of libavformat API
Libavformat API is considered inadequate for 'tight' integration with
So presently there is a libavformat wrapper within gstreamer, but is not
used by default. Gstreamer provides its own demuxers. This prohibits
demuxing of all the gamer & special-interest formats that libavformat
A similar comment was recorded on the FFmpeg TODO/wiki list years ago
GOAL: Make the libavformat API more appropriate to users
OBJECTIVES: Review the TODO list item, is it still valid?
Survey existing libavformat users; gather API requirements.
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)