[FFmpeg-devel] FOMS 2009 FFmpeg outbrief

[Benjamin Larsson]

Peter Ross wrote:
> Hi,
>
> 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
>    gstreamer.
>
>    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
>    supports.
>
>    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.

>
> Cheers,
>
> -- Peter
>   

MvH
Benjamin Larsson