[REQUIRED] Searched documentation and issues

ExoPlayer Javadoc and code, exoplayer.dev, issue tracker, stack overflow.

[REQUIRED] Question

When implementing DRM support in ExoPlayer I feel it is not so straight forward as the documentation states. The implementation itself is fine and works as expected on "good" devices, but when you start shipping this to the masses with x number of different "not-so-good" devices(and lower api levels) we start seeing problems. I want to address some of these here to try to clear up what to expect, what workarounds can be made etc.

It all boils down to the native call MediaDrm.provideKeyResponse(...) which on these slow devices I have seen take up to 2500 ms, compared to below 100 ms on faster devices. From my understanding this is called on a single threaded trusted execution environment(TEE).
provideKeyResponse of course needs to run in this TEE, and since the media being played is using DRM, decrypting also have to happen on this same thread within the TEE!? This means that for these devices it will either slow down startup time with 2500 ms or it will stall the playback for up to 2500 ms(depending on buffer size) if you are using clear lead. Both of these will also mean that gapless playback in a ConcatenatingMediaSource will not work.

In some issues you mention that there has been done improvements on Android 10 and concurrency(#6344 (comment) and #6751 (comment)). What exactly are those improvements? Is that something that is added in Android 10 that ExoPlayer can utilize or did ExoPlayer only add it for Android 10? Do you have a commit/PR I can look into to see what this change is, so that I can better understand what is happening and/or try to make other improvements myself? Is it somehow possible to apply these improvements(or other similar workarounds) for earlier versions? Are all Android 10 guaranteed to not cause stalls or longer startup time due to this improvement? Does it exist a multi threaded trusted execution environment?

Since many Android 9 versions actually are fast enough I still want the to be able to use drm, are there any way we can figure out which devices this is working on?

You also mentioned in one of the issues(#6751 (comment)), that you wondered if this happens on Android 8.1 or above? What was the reason for that? Is there anything that should've changed for that version? Are there any differences of this on 8.1 and below? In that case, what are the differences between 8.1 and Android 10?

There is also mentioning about "other DRM improvements"(#4133 (comment)), can you elaborate on what they are and when they are expected to be released?

What about the bufferSize in DefaultAudioSink? Are there any guides on how big this can be? If we succeed to make it a certain size, will it ever cause problems as long as the AudioTrack gets initialized? As you wrote (#6751 (comment)), we could try again with a smaller value if it fails to initialize(but then we're at square one either way).

Has any of this anything to do with audio offloading(mentioned in the bottom here: https://exoplayer.dev/battery-consumption.html) or improved playback rendering(https://medium.com/google-exoplayer/improved-rendering-performance-operating-mediacodec-in-asynchronous-mode-and-asynchronous-buffer-3026207850b2)?

Sorry for all the various questions, but they all relate to each other, I'm just trying to find out how I can best implement DRM with ExoPlayer without degrading performance compared to non-DRM.

I completely understand that you cannot do anything about the slow call and the single threaded TEE, but since you support DRM, it would be nice to know where we can use it and how it affects performance on devices that are not super fast. It would be OK for us to only use this on Android 10, but then we need to be confident that it will actually work on ALL android 10 devices.

Hope you can answer some of these questions as I think they are crucial to actually applying DRM on a release build without the user noticing any bad performance.

Thanks!

A full bug report captured from the device

N/A

Link to test content

N/A