<div dir="ltr">2013/11/20 Rémi Denis-Courmont <span dir="ltr"><<a href="mailto:remi@remlab.net" target="_blank">remi@remlab.net</a>></span><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div class="im">
<br>
</div>As far as I know, that is not what this macro does. This is the maximum<br>
number of pictures decoded but not yet pushed to the video output.</blockquote><div>Indeed, that's what I meant.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

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

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In any case, it should be possible to have more than 5 pictures in flight<br>
regardless, since it is not the sole buffer of decoded pictures.<br></blockquote><div>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.<br>

</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
And lastly, how do you know what the hardware will require anyway? I doubt<br>
that this would be a robust solution to your problem.<br>
</blockquote><div>For MediaCodec direct rendering I would set this value to 0 or perhaps 1, no more.<br></div><div>We should make no assumptions about the hardware and thus we should consider the case where the device has only 1 output buffer.<br>

Thus we should disable *all* buffers of decoded pictures in the pipeline.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
As far as I understand, the only real use of this buffer is to estimate<br>
how much latency is required for smooth playback. If I am not mistaken, the<br>
condition variable is used to wake up the input/ES clock.<br clear="all"></div></blockquote><div>Indeed, In EsOutDecodersStopBuffering() the ES thread calls input_DecoderWaitBuffering() on all es.<br>This function will not exit until the buffer becomes full or b_buffering is set to false.<br>

After exiting this function we have the message "Decoder buffering done in XXX ms".<br>Afterwards input_DecoderStopBuffering() is called and b_buffering is set to "false".<br></div><div>On Nexus 5 with MediaCodec direct rendering (with the enclosed patches), decoder buffering never completes, the ES thread is blocked in input_DecoderWaitBuffering().<br>

</div><div><br></div></div>-- <br>Félix Abecassis<div><a href="http://felix.abecassis.me" target="_blank">http://felix.abecassis.me</a></div>
</div></div>