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

[Rémi Denis-Courmont]

On Tue, 19 Nov 2013 16:59:25 +0100, Felix Abecassis
<felix.abecassis at gmail.com> wrote:
> On Nexus 5, the issue is that the decoder need to have 5 pictures
> simultaneously in flight during the initial buffering and this seems
> impossible on this device.
> The maximum size of the fifo is defined by the following macro:
> #define DECODER_MAX_BUFFERING_COUNT (4)

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

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.

And lastly, how do you know what the hardware will require anyway? I doubt
that this would be a robust solution to your problem.

> Why 4? Is there a reason?

I think it is just a magic value to ensure that the buffer does not grow
excessively large. Raw pictures are the largest consumers of memory in a
VLC already.

> If the number of pictures becomes greater than this value we use a
> condition variable to signal this change and buffering is disabled for
the
> rest of the video.

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. I would rather
eliminate the decoder decoded buffers completely and let *only* the audio
and video outputs do the buffering of decoded data.

-- 
Rémi Denis-Courmont
Sent from my collocated server