DRM protected content Playback failed

[spakanati123]

Hi,
I implemented video playback app for both Samsung VR and Google daydream headset using Exo Player. The clear content working fine on both headsets but when i play DRM content ExoPlayer throws "MediaCodecRenderer$DecoderInitializationException: Decoder init failed: OMX.Exynos.avc.dec.secure".

DayDream is already supporting the DRM content playback on the secure surface so if i built app using gearVrf the playback should success.
In forums i read that Samsung VR headset not yet supporting Secure content playback.

Please update me correct status for both Daydream and Samsung gear headset when app built using the gearvrf.

Thanks.

[spakanati123]

@liaxim @rahul27 @NolaDonato @bohuang3d

[bohuang3d]

Do you mean the DRM content fails on both GearVR and Daydream?
Or do you mean it only fails on GearVR?

Looks like it's not just you. Here are related issue
google/ExoPlayer#603
google/ExoPlayer#1166

[spakanati123]

@bohuang3d : Playback fails on both GearVR and DayDream .
GearVr framework passing the SurfaceTexture as a surface to Player(here it's Exo) which does not support the protected content playback. So the playback getting failed on both headsets.

It seems, the feature already requested long back.
#1189

[bohuang3d]

Workaround seem to revolve around security as well. Lowering the security settings may invite frame stutters.

This work around found below hacks the Exoplayer. I don't know if that fits your requirement

if(!secureDecodersExplicit) 
{
    codecs.put(key.secure?new MediaCodecUtil.CodecKey(mimeType, false):key,   Pair.create(codecName, capabilities));
     if(secure)
     {
           codecs.put(key.secure?key:new MediaCodecUtil.CodecKey(mimeType, true),    Pair.create(codecName, capabilities));
     }
}
else
{
    codecs.put(key.secure == secure?key:new MediaCodecUtil.CodecKey(mimeType, secure),      Pair.create(**codecName**, capabilities)); //instead if Pair.create(**codecName + ".secure"**,  capabilities)
}

google/ExoPlayer#1341

[spakanati123]

@bohuang3d Thanks for the update. It seems your proposed workaround introduces non-secure codec, which in turn uses non-secure buffers while rendering.
Lowering security to L3 also uses the non-secure buffers if i am not wrong.