[vlc-devel] [PATCH 2/3] vout: pause and resume the decoder pool

[Thomas Guillem]

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
available.
- 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
available.

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
close.

> 
> >> > 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
> http://www.remlab.net/
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel