[FFmpeg-devel] FOMS 2009 FFmpeg outbrief
Thu Jan 22 04:13:26 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.
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?).
More information about the ffmpeg-devel