Re: buffer age & slices: nasty problems

On Wed, 7 Jan 2004 19:34:55 -0500
D Richard Felker III <[email protected]> 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. 

 
> 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.
If i understand it correctly tfields will always need two buffers to
write into, so those buffers should be either grouped in pairs or
if this is not possible (eg only 3 buffers) then buffer age should be
always infinity.


 
> 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 ?
 
> NOW, MORE BAD NEWS...
> 
> All of this is further complicated by the fact that, when you're doing
> DR2 or slices, you actually have _2_ output buffers. One is the
> READABLE EXPORT or AUTO type buffer that you're decoding in, and the
> other is the non-READABLE DIRECT or INDIRECT type buffer you're
> slice-rendering to. In principle, their ages could be different.
> 
> Right now, I have code in the vp layer to simplify slice rendering, so
> that when you want to slice-render, you just call start_slices on the
> AUTO or EXPORT image you already have, and it then internally manages
> the associated DIRECT or INDIRECT type image obtained from the next
> filter/vo. But this creates a problem if age isn't managed by the vp
> layer, since the codec has no way to tell the age of the (hidden)
> buffer slices are going to, and thus doesn't know if it can skip
> blocks.

Thus i think it should be hanlde by the vp layer. The filters
should not have to care about buffer age unless they want to use
it for optimization.


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


				Attila Kinali



-- 
egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger
			-- reeler in +kaosu