[FFmpeg-devel] FOMS 2009 FFmpeg outbrief
Thu Jan 22 11:30:21 CET 2009
Peter Ross wrote:
> 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.
A bug squash week every now and then should be doable. And regarding
releases we should atleast put together a roadmap for one. And then I
think we should adopt the wine method of releasing. But to do that we
need better testing of the code.
> 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.
Err, no (for codec and containers).
> 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?
We have the mechanism, the version numbers.
> 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.
Well the license is what matters in most part of the world.
> 4. CONERN: --disable-patents.
> "It would be nice to build FFmpeg with all patent encumbered
> codecs/containers disabled."
> 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.
We had this before and it is not possible to maintain. With the
exception that of letting it disable everything.
> 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
> concerning MPlayer.
> 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.
VLC also rolls their own demuxers so I guess it has some valid points.
> -- Peter
More information about the ffmpeg-devel