[FFmpeg-devel] higher-level libs?

[Timothy Baldridge]

I'd look at fobs. http://www.sourceforge.net/projects/fobs. Grab the
fobs-src CVS and give it a whirl. I've been using it for a project of
mine for some time. It wraps FFMPeg up into C++ classes, and does a
good job at it too. Infact in the next few weeks I hope to do some
coding for the Fobs project myself.

Timothy

On 10/27/07, Rich Felker <dalias at aerifal.cx> wrote:
> 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
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>


-- 
If you put tomfoolery into a computer, nothing comes out but
tomfoolery. But this tomfoolery, having passed through a very
expensive machine, is somehow ennobled and no one dares criticize it.
(Pierre Gallois)