[FFmpeg-devel] [PATCH] vsrc_buffer.h: remove API dependency?on?libavcodec/AVFrame

[Stefano Sabatini]

On date Sunday 2011-04-03 22:36:53 +0000, Francesco Pretto encoded:
> Michael Niedermayer <michaelni <at> gmx.at> writes:
> 
> >
> > With AVFrame fields can be added, with a function like this they
> > cannot.
> > And i think we will want to access quite a few other fields from
> > AVFrame. For example in filters to vissualize motion vectors, mb types
> > and many other things
> > 
> >
> 
> This a comment from an api user perspective: I really prefer the first Stefano's
> approach (requiring buffer pointers, buffer size, width, height, pixel
> format..). 
> The reasons are these:
> - If I'm asked to provide an AVFrame, and I don't really have one, the first
> questions in the mind of the api user is: how do I allocate/init an AVFrame
> *properly*? Which fields of AVFrame I should fill? Which not (because maybe is
> dangerous or it would lead to unexpected results)?
> - The same objections stand for having a function that asks for
> AVFilterBufferRef.
> 
> In short, the api would be more opaque, and libav api is already badly opaque
> here and there (and it's the main reason because I'm finding it hard to use). So
> in these cases, I really prefer to be asked to what the function really need to
> work . If you need an "overloaded" function that accept and AVFrame or
> AVFilterBufferRef, I think nothing is stopping you to define it somewhere else.

The problem here is designing an API which won't change every time we
need to add some property to the A/V buffers, so a compromise has to
be found.

The two solutions I see are: using AVFrame (which requires the library
to map between AVFrame <-> AVFilterBufferRef, and depends on
libavcodec), and passing an AVFilterBufferRef already filled by the
application, which hasn't the disadvantages of the prevoius approach.
As you noted both solutions have the problem that they require some
level of opacity.
-- 
FFmpeg = Faithless and Fanciful Mastodontic Powered Explosive Generator