[FFmpeg-devel] higher-level libs?

[David McNab]

On Sat, 2007-10-27 at 20:45 +0200, Michael Niedermayer wrote:
> > My idea of an ideal wrapper lib would be one which gives simple
> > primitives to:
> >  - open an arbitrary video file for input
> >  - read transparently-decoded video frames, as raw YCbCr or RGB planes
> >  - read decoded audio, as buffers of raw samples
> >  - open an arbitrary video file for output
> >  - choose codecs, frame size, fps, audio sample rate etc
> >  - feed in raw video frames, as raw YCbCr or RGB planes
> >  - feed in raw audio samples
> > 
> > I'd be most comfortable with a library which allows the application to
> > achieve these things in dozens, rather than hundreds or thousands of
> > lines.
> 
> system("ffmpeg -i infile -s mysize -vcodec mycodec outfile");

Hehe, nice one. Jumping from one extreme to the other! :P

But that is a little too coarse-grained for what I'm after. It just
transcodes one file to another without giving access to individual video
frames.

I've been working up some code which actually popens:
 'ffmpeg -i infile -f yuv4mpegpipe -vcodec pgmyuv -'
then uses mjpegtools' 'yuv4mpeg' api to read the frames. Works perfectly
well, until one has to deal with the audio side of things.

I can't get away from the feeling that the lavc/lavf APIs, in their
present low-level state, coupled with the lack of higher-level
abstracted libs, might be repelling lots of otherwise keen developers.
Not everyone wants to do piles of low level C nuts'n'bolts 'yak
shaving'.

It was stated 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.

These comments, however, do not detract from my overall admiration of
lavf/lavc - they are a marvellous achievement that have achieved much to
help Linux/BSD to become viable platforms for video applications.

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.

Cheers
David