[FFmpeg-devel] FOMS 2009 FFmpeg outbrief

[Peter Ross]

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.

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
    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.

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.


Cheers,

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090122/80fcfce6/attachment.pgp>