[FFmpeg-devel] [PATCH] lavfi: add avfilter_copy_frame_props()
stefano.sabatini-lala at poste.it
Thu May 5 01:08:55 CEST 2011
On date Tuesday 2011-05-03 01:49:19 +0200, Michael Niedermayer encoded:
> 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);
Sorry I can't see the point of avoiding #include
"libavcodec/avcodec.h" when the file is supposed to be used only when
avcodec.h is used in the application, in other words you can avoid
including libavcodec/avcodec.h, but the application will *have* to do
it anyway, and even if you don't include it I can't see the advantage.
> > 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
Reimplemented in a separate .c file.
BTW this poses a problem, since we're conditionally compiling a
function of the public interface. Anyway this shouldn't be used if
libavcodec is not compiled/installed, so shouldn't be an issue. Or
FFmpeg = Fostering Fierce Muttering Peaceful Exciting Geisha
More information about the ffmpeg-devel