[FFmpeg-soc] [soc]: r329 - libavfilter/TODO

[Víctor Paesa]

Hi,

On 7/7/07, Michael Niedermayer wrote:
> Hi
>
> On Sat, Jul 07, 2007 at 10:31:29AM -0400, Bobby Bingham wrote:
> > On Sat, 7 Jul 2007 09:36:10 +0200 "Víctor Paesa" wrote:
> >
> > > Hi,
> > >
> > > On 7/6/07, koorogi  wrote:
> > > > Log:
> > > > update TODO list a bit
> > >
> > > > --- libavfilter/TODO    (original)
> > > > +++ libavfilter/TODO    Fri Jul  6 19:55:52 2007
> > > > @@ -1,10 +1,9 @@
> > > >  FRAMEWORK:
> > > > -- colorspace negotiation
> > > > +- can colorspace negotiation be improved?
> > > >  - auto-inserting needed filters (colorspace conversion, buffer,
> > > > etc) -- parameter passing
> > > > +- parameter passing (can this be done better with AVOption?)
> > > >  - pass pts, and whatever info is needed to reorder decode ordered
> > > > frames
> > > >  - other useful image flags?  interlace?  top/bottom field first?
> > > > -- rework init sequence
> > > >  - ease reuse of same memory for multiple slices
> > > >
> > > >  - proper vout filter support, with a display() callback?
> > >
> > > I was wondering if would be possible to pass a bit more of context to
> > > the filters.
> > > I am thinking on an AVStream * to the original stream passed on to the
> > > filter chain.
> > >
> > > The scenario is a filter to fade out the last few seconds of a movie.
> > > If you pass the AVStream *, the filter might get the estimated movie
> > > duration by itself.
> >
> > I've thought about this a little.  I do think there needs to be a way
> > to pass data of such to the filters, but I'm not sure about passing an
> > AVStream * itself.  For example, right now I'm using a filter which
> > generates a sequence of frames for testing - I can foresee other cases
> > where there may not actually be an AVStream associated with the filter
> > chain.
> >
> > Also, if such a fadeout filter is at the end of the filter chain, and
> > another filter adjusts timestamps (2x speedup for example), the length
> > of the stream won't match what the fadeout filter itself will see.
> >
> > I think instead it may be better to have an entry point in the filters
> > to get such metadata, process it, and pass it along to the next
> > filter.  So, the program could pass the length of the stream to the
> > first filter, which would pass it up the chain to the next filter, and
> > so on.  If there was a 2x speed filter, for example, it could pass the
> > adjusted running to the next filter.

That sounds perfect.

> in addition to this, the filter API must not depend on libavformat
> that would be quite inconvenient if libavformat isnt needed otherwise

In case metadata gets too difficult to choose/implement, I would be
happy even with
the original source file name plus the stream number (a quite API
agnostic thing).

Regards,
Víctor