[MPlayer-dev-eng] mp-g2 pre14

[D Richard Felker III]

On Mon, Apr 21, 2003 at 06:01:27PM +0200, Arpi wrote:
> Hi,
> 
> > hi.
> > On Mon, 21 Apr 2003 17:28:09 +0200
> > Arpi <arpi at thot.banki.hu> wrote:
> > 
> > A> but it also make it impossible to auto-insert or remove filters :(
> > why?
> > (i really dont see, why it "make it impossible")
> 
> RTFS...
> 
> you enter the last filter's process_frame, it calls the previous filter's
> one up to the codec. then codec's decode() is called, which, after parsing
> the frame headers, will call vo_config() which does the colorspace/format
> negotiation and inserts converter filters... then it decodes the image, and
> 'return mpi;' but to the original caller (first filter, _before_ autoinserting
> new filters), so new filters won't get that data...
> 
> one option would be not allowing vo_config() from decoder(), but it didn't
> work (or means big mess and hacks in decoders, but actually for libavocdec
> it doesn't work at all). libmpcodecs solved this problem, it was a big plus
> that times... so we shouldn't go back to the past and re-introduce this.
> 
> another option is maybe keeping put_image(), and pushing, but start
> processing from the bottom (last filter) instead of decoders.
> so you signal the last filter that you want a frame, if it have some
> internally generated frames, it will put_image() them, otherwise signals
> the previous filter up to the codec...

IMO this is ok... I still call it "pulling" as long as the initial
request for a frame comes from the vo's end of the chain rather than
the codec just spitting frames out. Unfortunately this architecture
complicates filter design a bit, since a filter has to set up its
internal state to handle the put_image() from the previous filter
before calling the previous filter to ask for a frame...

On the other hand, is full automatic filter insertion really needed?
Perhaps "vf_vd" could just wrap the codecs, and call swscaler itself
rather than inserting a filter if it's needed...

Or yet another idea... Just have a dummy format conversion filter
that's always inserted at the beginning and end of the chain, but have
it just pass the mpi through unmodified when no conversion is needed.

Which do you like better? The dummy filter sounds sort of silly, but I
don't really like the extra complication (at least conceptually) that
your solution adds to filter implementation. A filter should ideally
be able to call the previous filter and get an image returned, without
having to setup state and then wait for another function call to a
different entry point to actually get the image back...


Rich