[vlc-devel] [PATCH 3/3] mediacodec: implementation of MediaCodec direct rendering based on the work by Martin Storsjö.

[Rémi Denis-Courmont]

Le lundi 30 décembre 2013, 18:01:45 Felix Abecassis a écrit :
> > Because that's what you claim deadlocked your decoder in the first place.
> 
> What's happening is the following: the video is paused and we hit the
> "back" button to exit the video, function input_DecoderDelete is
> called. This function calls vlc_cancel and vlc_join on the decoder
> thread. Since the vout is not releasing the MediaCodec buffers sent by
> the decoder, the decoder is not able to exit the DecodeVideo loop:

The way the input is designed currently, the decoder cannot "wait" to get an 
output buffer. This will always risk deadlocking one way or another. If there 
is no buffer, it is supposed to discard the current frame, but mostly, the core 
is supposed to compute a sufficiently large number of output buffers.

This is a bit shaky design - even with CPU decoding. In particular, filters 
cannot influence the number of buffers, and the output can only influence it by 
second guessing the core and allocating more buffers than requested.

That said, waiting should only fix lost frames in live playback. I do not 
really understand how paused state would be special with respect to pictures 
allocation. Afterall the video output and decoder do not even know about being 
paused.

> we
> are stuck in the loop until we can get an input buffer (to consume the
> block) or an output buffer (to return a picture_t).

I don't really understand how vlc_object_alive or ExitRequested helps. The 
decoder thread will be sleeping within your custom picture pool code. The 
input thread will not be able to wake up the decoder thread after it sets the 
exiting flag.

-- 
Rémi Denis-Courmont
http://www.remlab.net/