[MPlayer-G2-dev] buffer age & slices: nasty problems

[D Richard Felker III]

On Sun, Jan 11, 2004 at 02:36:29PM +0100, Attila Kinali wrote:
> On Wed, 7 Jan 2004 19:34:55 -0500
> D Richard Felker III <dalias at aerifal.cx> wrote:
> 
> > Buffer age refers to the number of elapsed frames since a buffer was
> > written. Keeping track of buffer age is very useful for codecs (and
> > perhaps some filters) because they can skip writing areas that haven't
> > changed. But it's also a very difficult thing to keep track of with
> > general get_buffer type management instead of the dumb old IMGTYPE_IPB
> > approach.
> > 
> > I see two possible ways to handle it:
> > 
> > 1. Keeping track of buffer age in the vp layer itself.
> > 
> > Basically, when requesting an image buffer you'd specify an AGE flag,
> > meaning (a) you want vp to keep track of the buffer's age, and (b) you
> > want the vp layer (or the filter/vo you're direct rendering into) the
> > youngest buffer it can.
> 
> IMHO this is the best way to go. 

Yeah, I tend to like it too...

> > This is very easy for AUTO type buffers, and of course not necessary
> > for EXPORT. But for DIRECT and INDIRECT buffers that are going through
> > several intermediate filters, it could be very difficult to implement
> > correctly. Think of a chain like:
> > 
> > decoder -> tfields -> expand -> vo
> > 
> > Since tfields makes one INDIRECT buffer out of every _pair_ of
> > INDIRECT buffers it gets from the vo, it would have to convert 2 ages
> > into 1...
> 
> From my uneducated point of view that's a problem tfields should handle.

Yes.

> > 2. Force codecs that want to take advantage of buffer age/unchanged
> >    blocks to keep a lock on the old buffers and use some sort of
> >    reget_buffer function.
> > 
> > The basic idea here is that once a buffer is released, its contents
> > should be considered 100% invalid and its age infinity. Thus if you
> > want to take advantage of what's already in the buffer, you should
> > hang onto it.
> 
> This sound a bit strange to me. Do you mean that the codec
> should hold a lock trough all the filter chain ?

Yes, I agree it's sort of strange/ugly.

> > Even worse, some filters might accept skipped blocks (simple
> > colorspace conversion) while others (scale) might have real trouble
> > with them without lots of clever hacks!
> 
> how about a flag here ?

Maybe, but there are lots of other approaches too... This goes back to
the discussion between me and Ivan over how slices should work. Both
of our ideas have lots of ugly problems.

> > Ultimately what this points out is that slices are the barons of hell
> > (or maybe the cyberdemon) and there seems to be no good way to handle
> > them while maintaining both _generality_ and sufficient _restraints_
> > so that filters can actually handle the slices.
> 
> Do they give so much speed that it's worth this mess ?
> For me it looks like that there is a lot of overhead that
> is needed for proper slice handling that it eats a lot
> of the cpu time we got out of slices.

For just plain drawing, yes, it's huge. Having either slices or DR2
(or both) is absolutely required for a player that doesn't suck. On
the other hand, I have no idea if slices significantly improve
performance when real filtering is involved, since the extra code
coming into the cache to do the image processing might slow us down as
much as having the pixels in the cache speeds us up. I wish we had a
good way of knowing without spending tons of effort writing this ugly
mess...

Rich