[vlc-devel] [PATCH 2/3] vout: pause and resume the decoder pool
thomas at gllm.fr
Fri Nov 27 19:08:20 CET 2015
On Fri, Nov 27, 2015, at 18:46, Rémi Denis-Courmont wrote:
> On Friday 27 November 2015 17:28:56 Thomas Guillem wrote:
> > > I am not sure this problem is even specific to pause, and not just pure
> > > timing chance.
> > >
> > > In any case, that looks like a problem with flushing, not with pausing.
> > > There was previously a kludge (I think by "the other" Felix) to prevent
> > > picture allocation during flush.
> > Yes, I know this problem, I reworked the hack in order to don't depend
> > on Decoder_IsFlushing (that is dead now). But now, the problem occurs
> > only with avcodec (on any platforms).
> I think checking the flushing flag is unworkable at this point: the
> the decoder flushing flag and flushing the decoder would have to be done
> On the one hand, currently, the flushing flag is cleared after the
> decoder is
> flushed. A threaded decoder could attempt to allocate a picture buffer in
> interval, e.g. processing extra data, or just in anticipation. So
> the picture buffer cannot fail while flushing: That would lead to
> decoding errors, and potentially loss of key frame.
> On the other hand, if the flushing flag were cleared before flushing the
> decoder, a race condition would exist whereby the decoder attempts to
> a picture buffer before the flush callback - leading back to the original
> problem of waiting on the pool.
> So I can only think of two remaning avenues:
> - flush the video output before *and* after the decoder,
Nothing prevents that the decoder starve all pictures again between the
first vout_Flush and the DecoderFlush. But it's a corner case that is
almost impossible to reproduce.
> - make the decoder plug-in responsible for aborting picture allocation on
> flush (seems impractical though).
We could add a decoder_abortPicture (called from Flush/Close in decoder
module), that call a vout_abortPicture, that call
picture_pool_abortWait(decoder_pool), and that unblocks the
But this is a lot of functions...
> > > I don't think anybody ever figured out what the real problem was
> > > though. As far as I can tell, there are no reasons why we should run out
> > > of picture buffers specifically during flush. I do not even know how to
> > > reproduce the lock-up.
> > To reproduce it: any h264 video decoded with avcodec with mt. Play,
> > Pause, Stop -> deadlock (Play, Pause, Seek with my avcodec flush patch).
> That works just fine here.
This deadlock may depends on numbers of cpu, cpu speed, version of
I can reproduce it on desktop, Android and Tizen ports.
Android, Tizen and I are using a recent git of libav. But I reproduce
the deadlock on last ffmpeg git.
Maybe your libav/ffmpeg version is too old ?
> Rémi Denis-Courmont
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel