[MPlayer-dev-eng] [PATCH]Implement advanced deinterlacing for vdpau with SW decoders, try 2

[Reimar Döffinger]

On Sun, Mar 15, 2009 at 06:20:11PM +0000, Carl Eugen Hoyos wrote:
> > > -                            field, 0, NULL,
> > > +                            field, 2, deint_surfaces,
> > >                              surface_render[vid_surface_num].surface,
> > > -                            0, NULL, &src_rect_vid,
> > > +                            1, &deint_surfaces[2], &src_rect_vid,
> > 
> > Can you explain the semantics of deint_surfaces (i.e. what is stored in
> > it at what moment) in one short sentence? If not it's probably a bad
> > idea.
> 
> deint_surfaces[0], deint_surfaces[1] are past surfaces, deint_surfaces[2] is the
> future surface for reference.

No, it is the "future" one after the FFSWAP, before it was used to store
the previous frame.

> I wanted to explain, because I still think this was a simple idea (although not
> a working one).

Well, it mostly did not work because you forgot this chunk:
> -        struct vdpau_render_state *rndr = get_surface(0);
> +        struct vdpau_render_state *rndr = get_surface(deint_counter);

Again, the reason I suggested it is because when decoding with VDPAU the
past surfaces will not be in such a simple order, thus your current code
using (vid_surface_num - 2) & 3 is a dead-end, you will have to throw
away almost all of it if you implement deinterlacing+decoding.

> > at least I think
> > that this might allocate some extra data. We can try it anyway and see
> > what happens though.
> 
> It is possible that mobile chipsets have even slower memory connections, but I
> would prefer to wait for bugreports, too.

Mobile chipsets usually use normal RAM, so yes memory is _extremely_
slow for them.