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

[Felix Abecassis]

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)
Why 4? Is there a reason?
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.

To solve this issue, we should be able to change this maximum size when
opening a decoder module. I suggest adding a member to decoder_t and
assigning it a default value of 4 while allowing modules to override this
value.
I've sent the patch for review.


2013/11/15 Felix Abecassis <felix.abecassis at gmail.com>

> 2013/11/15 Rémi Denis-Courmont <remi at remlab.net>
>
>> If the hardware (driver) does not provide enough picture for decoding,
>> then you are screwed, period. Depending on the codec (and profile), you
>> need a certain minimum number of concurrent pictures.
>>
>> If however you are merely waiting for pictures to free up, then it might
>> just mean you are not keeping track of them correctly. Note that the video
>> output prepare and display callbacks bear little to no relevance to the
>> picture references. A single picture may be displayed more than once (for
>> instance when paused), or never (due to frame skip or preroll).
>>
>
> I don't think that's the issue. It looks like no pictures are being
> displayed before the decoder has returned N pictures.
> If N is greater that the number of MediaCodec output buffers then the
> decoder is called repeatedly but it can neither accept an input block nor
> return a frame since all the output buffers are currently associated with
> pictures that are currently in flight.
> The only way for the decoder to make progress is to release output buffers
> by displaying or skipping frames.
> By returning fake pictures, the pictures associated to real buffers will
> start getting displayed (or skipped), freeing some buffers and unblocking
> the decoder.
>
> Another way to solve this issue is to apply the following patch (by
> Martin) in decoder.c:
> ---
> a/src/input/decoder.c
>
> +++
> b/src/input/decoder.c
>
> @@ -1391,12 +1391,13 @@ static void DecoderPlayVideo( decoder_t *p_dec,
> picture_t *p_picture,
>          bool
> b_reject;
>
>
>
>          DecoderWaitUnblock( p_dec, &b_reject
> );
> -
>
> +/*
>
>          if( p_owner->b_buffering && !p_owner->buffer.b_first
> )
>
> {
>
>              vlc_mutex_unlock( &p_owner->lock
> );
>
> return;
>
>
> }
>
> +*/
>
>          bool b_buffering_first =
> p_owner->b_buffering;
>
>
>          /*
> */
>
> @@ -1415,8 +1416,8 @@ static void DecoderPlayVideo( decoder_t *p_dec,
> picture_t *p_picture,
>          /*
> */
>
>          if( b_buffering_first
> )
>
> {
>
> -            assert( p_owner->buffer.b_first
> );
> -            assert( !p_owner->buffer.i_count
> );
> +//            assert( p_owner->buffer.b_first
> );
> +//            assert( !p_owner->buffer.i_count
> );
>              msg_Dbg( p_dec, "Received first picture"
> );
>              p_owner->buffer.b_first =
> false;
>              p_picture->b_force =
> true;
>
>
>
> --
> Félix Abecassis
> http://felix.abecassis.me
>



-- 
Félix Abecassis
http://felix.abecassis.me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20131119/42aa779c/attachment.html>