[MPlayer-G2-dev] buffer management and libvo2...
D Richard Felker III
dalias at aerifal.cx
Mon Dec 15 07:27:21 CET 2003
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
* 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...?
More information about the MPlayer-G2-dev