[vlc-devel] [PATCH 2/3] vout: pause and resume the decoder pool
thomas at gllm.fr
Fri Nov 27 17:28:56 CET 2015
On Fri, Nov 27, 2015, at 16:47, Rémi Denis-Courmont wrote:
> Le 2015-11-27 17:36, Thomas Guillem a écrit :
> > On Fri, Nov 27, 2015, at 16:03, Rémi Denis-Courmont wrote:
> >> Le 2015-11-26 21:03, Thomas Guillem a écrit :
> >> > This fixes a deadlock when a decoder waits for a new picture while
> >> > it's pausing
> >> How is that a deadlock? Does it not unblock just fine when resuming?
> > No, it deadlocks on flush/close since the decoder thread wait for an
> > other thread that wait for a new picture, picture that will never
> > come
> > since we are paused.
> 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 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).
I added logs in the decoder pool to print the number of frames
- At the beginning, I got 32 frames available (4 threads by avcodec).
- When playing, number of frame available quickly decrease to 1 or 0.
So, picture_pool_Wait is always waiting for a picture, but not for long
since a frame will be displayed. So, the decoder is faster than the
video output and is waiting for it. This is an expected behavior, right
- If you pause, picture_pool_Wait will be stuck if there is no frame
I tried to tweak i_extra_picture_buffers from avcodec. If the value is
5*thread_count, that is 44 frame in total, avcodec won't starve all
pictures (I got between 2 and 3 frames available when playing).
But we don't want to allocate more frames than necessary...
I don't see an other solution than the vout_Flush hack before flush and
> >> > or flushing in a paused state.
> >> It sounds like we have too few pictures in the pool if this happens.
> >> Maybe flushing the video output *also* before the decoder fixes it??
> > I tried to flush before instead of after, but it wasn't working. I
> > didn't think about your solution. It seems to work fine and it's way
> > simper than my solution. I'll propose a patch, thanks!
> Rémi Denis-Courmont
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel