[vlc-devel] commit: Check some invalid uses of pl_Yield() ( Rémi Denis-Courmont )

[Rémi Denis-Courmont]

Le samedi 28 juin 2008 11:24:25 Rémi Denis-Courmont, vous avez écrit :
> Le samedi 28 juin 2008 00:58:16 Ilkka Ollakka, vous avez écrit :
> > But why is video-output destroyed after playlist?
>
> Video outputs are created/used/held by the playlist/input anyway. Hence
> video outputs cannot be removed safely before both VLM and the playlist are
> gone.

In other words, both playlist cleanup paths and libvlc main cleanup paths 
could try to destroy the same vout(s). That was one frequent cause of exit 
crash until not so long ago.

> If we never reuse the video outputs, we say welcome back to the 
> inter-video flickering.

One of the solution involves removing the video outputs directly from the 
input/ES code, as soon as the corresponding video E/S and codec are 
destroyed. Unfortunately, as noted, this would cause excessive flickering, 
e.g. when switching from one video file to another.

When it comes to pl_Yield() from video output threads... certain things must 
be considered:

First, it might be completely wrong for a video output to mess with the 
playlist. For instance, if the video output is part of a VLM input, it 
definitely must not deal with the (unrelated) playlist. In fact, one could 
argue that video outputs should only ever deal with their parent input, never 
with the playlist directly.

Second, there is no way to ensure that the playlist still exists when calling 
pl_Yield(). So, either pl_Yield() is modified so that it _safely_ returns 
NULL when the playlist is destroyed, and affected pl_Yield() users check that 
pl_Yield() returns non-NULL. Currently, pl_Yield() always succeeds. But *if* 
I understand correctly, Pierre believes video outputs must never access the 
playlist.

> That's how we currently deal with the audio output at the moment.

Fortunately audio outputs don't flicker. However, this means we reinitialize 
the sound card more often than before, which may cause some cracks depending 
on the hardware.

-- 
Rémi Denis-Courmont
http://www.remlab.net/