[vlc-devel] [PATCH 0/3] Android MediaCodec direct rendering

Felix Abecassis felix.abecassis at gmail.com
Wed Nov 20 12:09:35 CET 2013

2013/11/20 Rémi Denis-Courmont <remi at remlab.net>

> As far as I know, that is not what this macro does. This is the maximum
> number of pictures decoded but not yet pushed to the video output.

Indeed, that's what I meant.

I don't even know why it would ever need to be more than 0 or maybe 1. (And
> we
> already know that the corresponding buffer is harmful for audio decoders.)
Can someone else provide explanations on this? Should we keep this value of
4? Why this buffering?

> In any case, it should be possible to have more than 5 pictures in flight
> regardless, since it is not the sole buffer of decoded pictures.
But unfortunately it is not possible on Nexus 5 since the decoder will not
be able to decode new pictures if the previous pictures are not displayed.

> And lastly, how do you know what the hardware will require anyway? I doubt
> that this would be a robust solution to your problem.
For MediaCodec direct rendering I would set this value to 0 or perhaps 1,
no more.
We should make no assumptions about the hardware and thus we should
consider the case where the device has only 1 output buffer.
Thus we should disable *all* buffers of decoded pictures in the pipeline.

> As far as I understand, the only real use of this buffer is to estimate
> how much latency is required for smooth playback. If I am not mistaken, the
> condition variable is used to wake up the input/ES clock.
Indeed, In EsOutDecodersStopBuffering() the ES thread calls
input_DecoderWaitBuffering() on all es.
This function will not exit until the buffer becomes full or b_buffering is
set to false.
After exiting this function we have the message "Decoder buffering done in
XXX ms".
Afterwards input_DecoderStopBuffering() is called and b_buffering is set to
On Nexus 5 with MediaCodec direct rendering (with the enclosed patches),
decoder buffering never completes, the ES thread is blocked in

Félix Abecassis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20131120/cdb09270/attachment.html>

More information about the vlc-devel mailing list