@xyz reported a regression on his Sony Xperia Z3 Tablet Compact where
playback would intermittently fail to start, essentially deadlocking in
the decoder. Bisecting narrowed down the issue to this commit, which was
meant as an optimization but is not necessary.
This reverts commit a75bb5496a.
Signed-off-by: Aman Gupta <aman@tmm1.net>
The output_buffer_count==0 special case is no longer required, and
can cause spurious EAGAIN to surface to the user when input buffers
are filled up. Since the caller now knows if the decoder is accepting
new input (via current_input_buffer>=0), let the wait parameter
control whether we block or not.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Matthieu Bouron <matthieu.bouron@gmail.com>
The new logic follows a recommendation by @rcombs to use
dequeueInputBuffer with a timeout of 0 as a way to detect
whether the codec wants more data. The dequeued buffer index is
kept in MediaCodecDecContext until it can be used next.
A similar technique is also used by the Google's official media
player Exoplayer: see MediaCodecRenderer.feedInputBuffer().
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Matthieu Bouron <matthieu.bouron@gmail.com>
Allows consumers who are converting hardware buffers
to OpenGL textures to render the frames at the intended
display resolution.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Some Android devices are very finicky about how quicky output buffers
are returned back to the decoder, especially when they are associated
with a Surface.
This commit adds a new counter that keeps track of exactly how many hw
output buffers are being retained by the user, along with DEBUG level
logging that makes it easy to track the lifecycle of these buffers.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Matthieu Bouron <matthieu.bouron@gmail.com>
The default behavior of the mediacodec decoder before this commit
was to delay flushes until all pending hardware frames were
returned to the decoder. This was useful for certain types of
applications, but was unexpected behavior for others.
The new default behavior with this commit is now to execute
flushes immediately to invalidate all pending frames. The old
behavior can be enabled by setting delay_flush=1.
With the new behavior, video players implementing seek can simply
call flush on the decoder without having to worry about whether
they have one or more mediacodec frames still buffered in their
rendering pipeline. Previously, all these frames had to be
explictly freed (or rendered) before the seek/flush would execute.
The new behavior matches the behavior of all other lavc decoders,
reducing the amount of special casing required when using the
mediacodec decoder.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Matthieu Bouron <matthieu.bouron@gmail.com>
This refactor splits up the main mediacodec decode loop into two
send/receive helpers, which are then used to rewrite the receive_frame
callback and take full advantage of the new decoding api. Since we
can now request packets on demand with ff_decode_get_packet(), the
fifo buffer is no longer necessary and has been removed.
This change was motivated by behavior observed on certain Android TV
devices, featuring hardware mpeg2/h264 decoders which also deinterlace
content (to produce multiple frames per field). Previously, this code
caused buffering issues because queueInputBuffer() was always invoked
before each dequeueOutputBuffer(), even though twice as many output
buffers were being generated.
With this patch, the decoder will always attempt to drain new frames
first before sending more data into the underlying codec.
Signed-off-by: Matthieu Bouron <matthieu.bouron@gmail.com>
Aman Gupta
Matthieu Bouron
James Almer
Matthieu Bouron