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

[Michael Niedermayer]

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" <victorpaesa at googlemail.com> 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.

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

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20070707/4e2f0f29/attachment.pgp>