[FFmpeg-devel] higher-level libs?

[Michael Niedermayer]

On Sun, Oct 28, 2007 at 08:41:25AM +1300, David McNab wrote:
> 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.

iam not against simplifying the API
patches which add new public functions to perform common and complex things
needed to use lavc/lavf (that is functions which factorize common code from
applications into lavc/lavf) are welcome

also many small patches are preferred over few large ones!

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071027/6d3ab6f0/attachment.pgp>