[MPlayer-dev-eng] mp-g2 pre14

[D Richard Felker III]

On Mon, Apr 21, 2003 at 08:25:02PM +0200, Fabian Franz wrote:
> Am Montag, 21. April 2003 13:03 schrieb Arpi:
> > Hi,
> >
> > > As for DR and slices, I don't see any particular problems with this
> > > design. Each vf can just pass the slice callback and/or DR buffer back
> > > to the previous filter. The only area where I see a little bit of
> > > confusion is negotiation of config and image format/dimensions, since
> > > that normally starts at the codec end. There shouldn't be
> >
> > I had the same idea a few weeks ago (when i decided to change
> > demuxer->codec relation from push to poll), but dropped for config and dr
> > problems.
> >
> > DR and buffering should not be changed. It is good as-is.
> > But we need to change put_image() to something like process_image()
> > (no, get_image is sth else! may be confusing btw), and it will return mpi
> > instead of calling the next filter's put_image.
> >
> > So processing will look like:
> >
> > core calls ve or vf_vo to process a frame, it calls the _last_ filter's
> > process_image, it calls the previous filter's process_image and so on, up
> > to the codec (probably i have to write a codec wrapper filter, like vf_vo,
> > some vf_vd). The filters will call-back to the next filter's get_image to
> > get teh buffers allocated.
> >
> > So, if you have VD -> VF1 -> VF2 -> VO path, it will looks like:
> > core
> >   VF_VO->process_image()
> >     VF2->process_image()
> >       VF1->process_image()
> >         VD->process_image()
> >           VF1->get_image()
> >           decode
> >           return
> >         VF2->get_image()
> >         filter1
> >         return
> >      VF_VO->get_image()
> >      filter2
> >      return
> >   display
> >   return
> > show (swap buffers) at PTS got from VF_VO
> 
> Hm, this seems from description to me to be some sort of recursive calling ?!
> 
> Why do you want to use recursive-calling, when you can have:
> 
> // process_image-chain
> 
> for (filter=start;filter!=NULL;filter=filter->next)
>   filter->process_image();
> 
> # get_image-chain
> 
> for (;filter!=NULL;filter=filter->prev)
>   filter->get_image(); //vd will first config the colorspace and then set 
> vd->prev to the autoinserted filters.
> 
> Which will be called next, vd can also prepend filters before the first.
> 
> I don't see, why this won't be possible...

Because this does not accomplish the goal at all. It assumes input and
output frames are in one-to-one correspondence, and it probably
wouldn't work at all with dr/slices.

Rich