[vlc-devel] [PATCH 2/2] RFC: core/vout: don't reset the display pool
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.
More information about the vlc-devel