[FFmpeg-devel] [PATCH] lavfi: add avfilter_copy_frame_props()

[Michael Niedermayer]

On Tue, May 03, 2011 at 12:20:48AM +0200, Stefano Sabatini wrote:
> On date Tuesday 2011-05-03 00:06:11 +0200, Michael Niedermayer encoded:
> > On Mon, May 02, 2011 at 07:26:13PM +0200, Stefano Sabatini wrote:
> > > On date Monday 2011-05-02 12:42:04 +0200, Michael Niedermayer encoded:
> > > > On Sun, May 01, 2011 at 04:29:54PM +0200, Stefano Sabatini wrote:
> > > [...] 
> > > > >  ffmpeg.c                  |    1 
> > > > >  ffplay.c                  |    5 ++--
> > > > >  libavfilter/Makefile      |    2 -
> > > > >  libavfilter/avcodec.h     |   50 ++++++++++++++++++++++++++++++++++++++++++++++
> > > > 
> > > > isnt it possible to just always install libavcodec/avcodec.h even
> > > > if libavcodec is disabled?
> > > 
> > > I would prefer to avoid hacking configure and keep the dependency on
> > > libavcodec strict, AVFrame should be used only if libavcodec is used,
> > > so I'd prefer not to make distinctions between compile-time and
> > > running-time dependencies (and we could need at some point the use of
> > > some function from libavcodec).
> > 
> 
> > is this change needed at all? #include "libavcodec/avcodec.h" in
> > libavfilter should use the non installed header and no installed
> > header from libavfilter shouldneed  libavcodec/avcodec.h for a struct
> > pointer
> > am i missing something ?
> 
> Do you mean something like this:
> 
> struct AVFrame;
> 
> static inline
> void avfilter_copy_frame_props(AVFilterBufferRef *dst, const AVFrame *src);

i was thinking of
void avfilter_copy_frame_props(AVFilterBufferRef *dst, const struct AVFrame *src);

> 
> and then define in libavfilter/avcodec.c the code for the function?
> 
> In general I like the current solution the better (static inline and
> so faster, autodocumented and more transparent for the user), and I
> like the idea of keeping the libavcodec/libavfilter interface
> insulated from the rest of lavfi, putting it in separate files helps
> with this.

seperate files are a good idea, i agree
but static inline has a disadvantage, namely the code is compiled into
applications and cant be changed without recompiling apps.
for example new fields cant be copied

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

There seems to be only one solution to NIH syndrom, ... a shooting squad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110503/198743cb/attachment.asc>