[FFmpeg-devel] FOMS 2009 FFmpeg outbrief

Robert Swain robert.swain
Mon Jan 26 17:22:02 CET 2009


2009/1/26 M?ns Rullg?rd <mans at mansr.com>:
> Diego Biurrun <diego at biurrun.de> writes:
>> On Thu, Jan 22, 2009 at 03:06:51PM +0100, Diego Biurrun wrote:
>>> On Thu, Jan 22, 2009 at 11:30:21AM +0100, Benjamin Larsson wrote:
>>> > Peter Ross wrote:
>>> > >
>>> > > 1. CONCERN: Quality assurance
>>> > >    [...]
>>> > >
>>> > >    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.
>>>
>>> It sounds like a great idea in fact.  Let's schedule one right away.
>>>
>>> How about the weekend at the end of January?
>>
>> Any takers for a bug squashing weeken scheduled for this weekend or
>> the next, later?
>
> What exactly does a bug squashing weekend entail?  I'll be at FOSDEM
> in Brussels the 7-8 February, so don't expect any development work
> from then.  Anyone else going there?  You'll probably find me with the
> OpenEmbedded crowd.

Looking at the bug tracker or wherever else known bugs are documented
and working to resolve as many bugs as possible. It's mainly a
motivational community event that encourages developers and
contributors to squash as many bugs as they can while they're all
motivated to do so.

>>> > And regarding releases we should atleast put together a roadmap for one.
>>>
>>> What do you want to see in such a roadmap?
>
> "Roadmaps" are silly.  They belong in the rubbish bin next to the
> "whitepapers".

Disagree. They at least show that we have some idea of the major
things that need to be improved and allow for prioritisation of issues
to be addressed. And things (CLI/API documentation, API examples) most
certainly do need to be improved and have been mostly neglected for as
long as I've had an interest in the project. Writing a roadmap itself
doesn't get these issues addressed, but it should at least increase
awareness of them.

Even if the time frame for the next release remains as "When it's
done.", if we make bite sized road map items that genuinely do improve
the usability and reliability (which are the main concerns for
releases I think...) we at least have a hope of making releases. I
would be happy to do a bit of documentation but my usual feeling is
"Where do I start?" and then nothing gets done because I can't just
look at a list of things to do and think "OK, I'll do that bit because
it'll take about half an hour to do."

FFmpeg need some organisation and improved presentation. The current
state is (and has been for some time) a rabble of interested/funded
parties working on whatever interests them/they are being paid to work
on. This is fine in many respects and the freedom is appreciated but
it isn't leading to a well-rounded, polished, professional product.

FFmpeg is obviously technically strong and is the core of open source
multimedia because of the wide format support and fairly
well-optimised implementations of said formats. It is _not_ the core
of open source multimedia because many of its community are (or are
perceived to be) unwelcoming, unhelpful and unfriendly, because its
documentation is severely lacking (I never look at the documentation
because I know it's weak whereas when using MPlayer I know the man
page is very good), because its API examples are unclear and
monolithic rather than modular (I have had to implement swscale in a
separate program and it took a lot of prodding and guess work to make
it not crash and function properly as I had to use ffplay.c and
ffmpeg.c as reference points at the time) and so on, and it has no
plans to combat these issues which are significant to many quiet
observers and outside users.

I think you underestimate the power of a little organisation.

Regards,
Rob




More information about the ffmpeg-devel mailing list