Re: buffer management and libvo2...

On Sun, Dec 14, 2003 at 03:17:10PM -0500, D Richard Felker III wrote:
> What can be done about it?
> 
> Solution 1. Never allow dr to the last buffer.
> Pros: Deadlock impossible. Simple.
> Cons: Sometimes we can't know how many buffers are available. Even if
> we can, refusing to use one buffer may prevent DR entirely!!
> 
> Solution 2. When we run into deadlock, shuffle buffers. I.e. allocate
> new buffer in system memory and move the contents of one dr buffer
> there to free up space.
> Pros: Deadlock impossible. All buffers can be used.
> Cons: Very slow if dr buffers are in video memory! Also requires
> horrible hacks to change a dr-type mpi into an auto-type one.
> 
> Solution 3. Require codecs/filters to report how many buffers they
> will need at config-time.
> Pros: Deadlock impossible. All buffers can be used. No ugly hacks.
> Cons: Very confusing! Requires considerably more logic in filters. For
> example, in case 1 above, tfields has to figure out it will need 4
> buffers based on the info the codec gives it. How to do this?!
> 
> Solution 4. ???

I think I have a solution #4 that might work. This is a little bit
hackish, but I can't think of anything better.

* When requesting a DR or indirect buffer, a codec/filter MUST flag
  whether it will want any more buffers before releasing the one it
  requests.

* If the "will want more buffers" flag is set, the destination
  filter/vo MUST not give up its last buffer. Thus, if only one buffer
  remains, the destination MUST reject direct rendering/slices.

Sound ok? The only remaining question is how to know if a buffer is
the last one. For vo's with a fixed number of buffers this is trivial,
but if buffers are allocated on demand, maybe we have to attempt to
allocate one buffer ahead...?

Rich