[vlc-devel] [PATCH 2/2] RFC: core/vout: don't reset the display pool
thomas at gllm.fr
Wed Jan 4 18:57:36 CET 2017
On Wed, Jan 4, 2017, at 15:14, Rémi Denis-Courmont wrote:
> 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
So, should we kill vout_Reset() ?
Should the decoder call vout_Flush(INT64_MAX) instead ?
> I agree that we should remove it (but don't count on me to fix any
> decoder that
> would still depend on it).
Is libmpeg2 the only decoder that still depends on vout_Reset() ?
> > Or there's no way to know ?
> How do you distinguish between a decoder, a filter, a splitter or a
> 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
> is not compatible with asynchronous decoders, asynchronous displays, mid-
> stream output format change.
Maybe we should replace the whole reset thing by an assert and warning
in picture_Release() when there is a leaking decoder/vout/filter.
> Rémi Denis-Courmont
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel