buffer age & slices: nasty problems

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.

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

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.

The nice aspect of this approach is that it simplifies the vp layer,
and moves the complexity to the (few) codecs that care about buffer
age.

The bad part is that I'm not sure the basic premise is good. For
example, if we accept that premise, then vf_expand cannot assume the
black bars are still black after it releases its buffers, and would
either have to redraw them every time or keep its buffers locked.
Just checking buffer age (and only clearing the black bars if
age==infinity) seems like a more sane approach.

3. (??) Maybe some other buffer management scheme I haven't though of
   yet...?????

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.

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!

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.

So in response to this email, I'd like two things:

A. Recommendations on which way to handle buffer age.
B. Ideas on how to make slices (at least slightly) less hellish...


Rich