[FFmpeg-devel] FOMS 2009 FFmpeg outbrief

[Mike Melanson]

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.

Thanks for taking the initiative on this. Executive summary: "Same s***, 
different conference." :) (Note to the LinuxTag-FFmpeg crew: that might 
actually make a good banner for this year's booth.)

>    Mike Melanson's FATE effort was discussed, and seen as a good step forward
>    in improving QA.

Whooo! I matter! :)

>    There are many outstanding bugs in roundup. 
>    Bugs get dealt with when *somebody* fixes them (stating the obvious).

Thanks for laying out the reality on this one.

>    Regression tests to stress the behaviour of the FFmpeg API, not just
>    bitstream regressions, are lacking.

Indeed. And I was also thinking that FFmpeg should come with a number of 
smaller sample programs, rather than one mega-example demonstrating the 
API. It might make the program less intimidating (assuming that devs 
want that) while also facilitating automated testing.

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

I've been undertaking a clandestine effort to push this through. But I 
want something like 99% test coverage in FATE before it happens, though.

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

Releases should at least partially obviate the problem.

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

I hope you pointed these people to CREDITS.

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

Echoing what other responders have indicated: Stick to raw, uncompressed 
data if you have the slightest paranoia about patents. If you think 
about it hard enough, you will be able to envision a doomsday scenario 
where just about any format is restricted (think about it: it's 
generally accepted that WAV and AVI formats are actually "Microsoft WAV" 
and "Microsoft AVI" formats; should we get MS' permission before writing 
code to manipulate them?).

-- 
     -Mike Melanson