[vlc-devel] [PATCH 3/3] mediacodec: implementation of MediaCodec direct rendering based on the work by Martin Storsjö.

[Felix Abecassis]

2013/12/30 Rémi Denis-Courmont <remi at remlab.net>:
>
> Point is, VLC should work out of the box. Of course, it is best to disable
> hardware decoding when transcoding (unless there is also hardware encoding).
> But transcoding should still *work* somewhat if hardware decoding is enabled,
> especially if hardware decoding is enabled by default.
This isn't an issue, we can set the default value to "false" and have
a command line switch to explicitly enable MediaCodec opaque DR.
Transcoding will thus work out of the box using mode 1).

> Point is, someone will see the code in your decoder and will copy it in good
> faith into another decoder. If that other decoder happens to support
> transcode, we have a new bug.
I could add a big warning around the code but developers will still be
able to mindlessly copy-paste the snippet and head into big troubles.
Do you have another idea to solve this problem?

> Err, like all other hardware decoders?
I'm not sure, is it the YCbCr submodule?

> Because that's what you claim deadlocked your decoder in the first place.
What's happening is the following: the video is paused and we hit the
"back" button to exit the video, function input_DecoderDelete is
called. This function calls vlc_cancel and vlc_join on the decoder
thread. Since the vout is not releasing the MediaCodec buffers sent by
the decoder, the decoder is not able to exit the DecodeVideo loop: we
are stuck in the loop until we can get an input buffer (to consume the
block) or an output buffer (to return a picture_t).
Thus the call to vlc_join never returns. Without opaque DR (i.e. mode
1), the output buffers are released immediately so we don't get stuck
in DecodeVideo.

-- 
Félix Abecassis
http://felix.abecassis.me