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

[Rémi Denis-Courmont]

Le lundi 30 décembre 2013, 16:26:23 Felix Abecassis a écrit :
> 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).

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.

That's what we have with VDPAU, except for unknown bugs.

> >> 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.

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.

> >> 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?

Err, like all other hardware decoders?

> > 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?

Because that's what you claim deadlocked your decoder in the first place.

-- 
Rémi Denis-Courmont
http://www.remlab.net/