[MPlayer-dev-eng] mp-g2 pre14

[Fabian Franz]

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...

cu

Fabian

>
> > 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.
> (so instead of getting mpi as parameter for put_image, it will be called
> process_image, and its first line will get the mpi. and at the end instead
> of put_image(mpi), it will return mpi;
>
>
> A'rpi / Astral & ESP-team
>
> --
> Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
>
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng