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

Felix Abecassis felix.abecassis at gmail.com
Mon Dec 30 16:26:23 CET 2013


2013/12/30 Rémi Denis-Courmont <remi at remlab.net>:
> Le lundi 30 décembre 2013, 15:35:45 Felix Abecassis a écrit :
>> Good point, thanks.
>>
>> MediaCodec opaque direct rendering does not make sense with
>> transcoding since we need an Android surface for rendering.
>
> That's not a good thing at all IMHO. VDPAU has fallback support for copying
> back to main memory to preserve transcoding - even if it might slow it down.
Let me clarify the situation: with this patch the MediaCodec module
has now two modes:
1) Normal HW accelerated decoding: rendering into a picture_t, any
vout can be used.
2) Opaque direct rendering: MediaCodec buffer handles are passed
between the decoder and the opaque vout using the p_sys member.

By default, mode 2) is used:
add_bool(CFG_PREFIX "directrendering", true,
         DIRECTRENDERING_TEXT, DIRECTRENDERING_LONGTEXT, true)
The fallback to 1) is possible if we modify this variable or if
jni_LockAndGetAndroidJavaSurface returned NULL (which is not possible
anymore but could happen if we had a timeout mechanism).

>
>> With this assumption, would it now make sense to call
>> input_DecoderIsExitRequested?
>
> Even if we allow hardware decoding to break transcode, empirically, this will
> sooner or later get copied into a different code path where it will
> nonobviously be wrong.
The call to input_DecoderIsExitRequested would be enclosed by "if
(p_sys->b_direct_rendering) {}", so transcode would not be broken
provided fallback to 1) was made.

>
>> But this raises another question I haven't thought of: is there a way
>> to know if the decoder was instantiated by a transcoder?
>
> The encapsulation principle forbids it. If it were really required, you would
> have to add a new decoder callback.
How did you implement VDPAU fallback to main memory then?

>
> But I am not convinced that it really fixes all race conditions. The lock scope
> does not cover the surface allocation so the TOCTOU issue should remain.
I'm not sure I understand where the race condition is in this case.
Why do you mention surface allocation?

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



More information about the vlc-devel mailing list