[MPlayer-dev-eng] mp-g2 pre14

[D Richard Felker III]

On Mon, Apr 21, 2003 at 01:03:11PM +0200, Arpi wrote:
> 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

Hmm, this sounds about the same as what I meant by a pull
architecture... And it should make it very simple for filters to add
and drop frames, right?

> > insurmountible problems, but we should at least think through how to
> > handle stuff. I'm sure it can't be much worse than the negotiation
> > system already is, though...
> 
> as most (all?) filters will start by calling the previous filter's
> process_image() first, it shouldn't be difference for them.

Not all. vf_tfields would only call the previous filter's
process_image once for every 2 output frames. And vf_telecine would
only call it for 4 out of 5 output frames.



Rich