[FFmpeg-devel] FOMS 2009 FFmpeg outbrief

[Robert Swain]

2009/1/26 Michael Niedermayer <michaelni at gmx.at>:
> On Mon, Jan 26, 2009 at 04:22:02PM +0000, Robert Swain wrote:
> [...]
>> 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
>
> what was wrong with libswscale/swscale-example.c ?

Note that I was working on it back in July of 2007, so I was looking at:
http://svn.ffmpeg.org/mplayer/trunk/libswscale/swscale-example.c?revision=23722&view=markup
*Looks at the file.*

As a code example, it lacks detailed comments of what each line does.
In my opinion, code examples should be like tutorials in that they
explain what the goal of the code is, what each bit does, the
functions used, maybe which headers they're from, the arguments of the
functions etc etc. It should be very explicit and informative about
how all the code works so that a reader can very easily understand the
meaning of all the significant bits of the API and how they can be
applied to achieve something useful.

A coder will come in with a problem they want to solve. They want to
convert an image buffer from one colour space to another, or they want
to scale it, or both. They've found out that libswscale does this. How
do they use the API to do it? What format do their buffers have to be?
What initialisation needs to be done? What actually conducts the
scaling/conversion? What needs clearing up afterwards? What
performance/quality related flags can be passed through the API that
may be of interest? What other concerns might I have when using the
API?

For someone coming from the API user side with no knowledge of FFmpeg
or MPlayer but just having found libswscale, swscale-example.c did not
at that time really answer too many of those questions. One has to
(know to!) dig around in the header files for more API information and
then play around to figure out what is needed for a simple application
like those proposed above or what to change from pre-existing code to
make it work for their application.

*Looks at the file that currently exists to see if any of his
complaints have been addressed.*
Doesn't look like it. This isn't meant to be a dig at anyone for not
doing it. I'm just pointing out what I perceive to be a good quality,
easy to use code example and for what we should aim.

Michael: what do you think of what I've said?

Best regards,
Rob