[vlc-devel] [PATCH 2/2] RFC: core/vout: don't reset the display pool

Rémi Denis-Courmont remi at remlab.net
Wed Jan 4 15:14:10 CET 2017

Le mercredi 4 janvier 2017, 08:38:09 Steve Lhomme a écrit :
> On Tue, Jan 3, 2017 at 4:45 PM, Thomas Guillem <thomas at gllm.fr> wrote:
> > In case of direct rendering, the decoder_pool (== the display_pool) should
> > not be reseted. Indeed, the vout display module implementation could
> > still hold pictures while the decoder is reseted. This fixes the warning
> > "n picture(s) leaked by decoder" and an assert from
> > picture_pool_ReleasePicture() when the vout is finally releasing the
> > picture.
> That sounds hackish when the vout reset is already described as a hack:
> /* Hack to make sure all the the pictures are freed by the decoder
>  * and that the vout is not paused anymore */

> It seems that a cleaner fix would be to release the pictures when
> there's no reference left ?

In other words, the clean fix consists of never resetting a picture pool at 

I agree that we should remove it (but don't count on me to fix any decoder that 
would still depend on it).

> Or there's no way to know ?

How do you distinguish between a decoder, a filter, a splitter or a display 
leaking a picture reference or holding a reference thereto? Without any 
further assumptions, that is the halting problem.

The reset hack made sense when leak-prone libmpeg2 was the norm. But this hack 
is not compatible with asynchronous decoders, asynchronous displays, mid-
stream output format change.

Rémi Denis-Courmont

More information about the vlc-devel mailing list