[FFmpeg-soc] [soc]: r329 - libavfilter/TODO
victorpaesa at googlemail.com
Sun Jul 8 13:33:47 CEST 2007
On 7/7/07, Michael Niedermayer wrote:
> 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
More information about the FFmpeg-soc