[FFmpeg-devel] higher-level libs?

[Rich Felker]

On Sun, Oct 28, 2007 at 08:41:25AM +1300, David McNab wrote:
> It was stated

...by someone who had no clue about their problem domain...

> on #ffmpeg that if libc was like lavf/lavc, then a simple
> open()/read() would take hundreds of lines of code. I tend to agree. In
> fact, back in the 80s when I was working for Wang Labs, they had an
> experimental OS where it did actually take dozens of lines of code just
> to get a disk file open, and dozens more to read or write to it. I got a
> lot of flak from some colleagues for wanting to implement open(),
> close(), read(), write(), fopen(), fclose(), fread(), fwrite(),
> fprintf(), fscanf() etc over the top.

This is argument by false analogy. A file is a stream of bytes. There
is nothing complex to the abstract model; any complexity comes from
bad API design. On the other hand a multimedia stream is fairly
complex on the abstract level. The best abstraction you can get is
that it's a sequence of 'frames' of audio and video (and perhaps text)
ordered in 'time', with a particular time associated with each. But
the stream also has many many parameters because you're not storing
and retrieving exact data but approximations and anyone sane wants
some control over the degree of approximation. On top of that, the
fact that most containers are completely broken makes it hard to reach
the ideal abstraction in a compatible manner.

I'm all for an api where one can seek to exact locations in the
stream, pull frames (decoded or raw or even a mix) in sequence, easily
convert and manipulate them, etc. However after having worked in the
field for a long time and after many unsuccessful attempts at
designing clean APIs, I'm convinced that it is NOT an easy problem
like you make it out to be. It might be possible to make a clean API,
but coming up with it is nontrivial. Kudos to you if you can do it!

> I respect too that video is an inherently complex problem space, due to
> the vast number of video standards out there, and the different
> considerations needing to be applied when dealing with each standard.

Yes, this is only the beginning of the difficulty though..

Rich