DefaultDrmSession Aquire/Release - Reference Count

[RichardDapice]

First off thank you in advance for taking the time to respond to this question.

Searched documentation and issues

I have searched for related answers on Stack Overflow, existing issues, ExoPlayer Javadoc and the ExoPlayer Developer Website. I also tried the "Similar to # existing issues" on GitHub which as well yielded no result.

Question

Why is the referenceCount in DefaultDrmSession incremented and decremented multiple times by acquire() and release() is called and why are the called multiple times?

Does manually altering the referenceCount to forcefully maintain the session and then forcefully release it cause unforeseen issues? If we need to hold onto this session through add breaks what is an alternative?

Problem and Gathered Information

Version: 2.11

When observing the referenceCount in DefaultDrmSession we see this Integer increment when the session is created and then decrement at the end of a session when the asset is finishing or when the player is released. The count is typically 5 and will decrement and release which is the expected behavior. However, there seems to be an issue arising when we transition to commercial breaks, from protected to clear and back to protected content, the player will release the session. This is not Ideal as it requires another Drm License to be retrieved. Initially, our thought was that this was due to the manifest's structure but after extensive testing we have ruled that out. It seems that MediaCodecRender (Audio/Video) is responsible for calling acquire() and release() but why it is called multiple times is unclear to us. If we alter the referenceCount we are able to prevent this issue from happening however, our lack understanding of this field is causing us concern.

[ojw28]

I think the count is typically 6, which consists of the following for audio and video separately:

1. A reference corresponding to the SampleQueue in the media source
2. A reference corresponding to the source side of the MediaCodecRenderer
3. A reference corresponding to the codec of the MediaCodecRenderer

It should be pretty straightforward for you to attach a debugger or add some logging showing the call stacks in DefaultDrmSession.acquire to verify this, using the ExoPlayer demo app if it's easier.

[RichardDapice]

Thank you for the quick response.

That is indeed where I traced these calls in the stack back to. I was just curious if there was a way to prevent the session from releasing without modifying the reference count manually. I am afraid doing so might have unintended consequences.

[ojw28]

Are you using the IMA extension? If so, this question/bug is a duplicate of #7011. If not, what are you using to insert ad breaks?

[RichardDapice]

No, we are not using IMA, we are using VAST DAI letting the player handle the breaks. Our content is using DASH/Widevine and our ads are unprotected/clear. Our manifest from our packager does not insert any Content Protection inside the ad periods.

[ojw28]

Thanks for the info. If you have a working solution that increments the reference count, then I think you should be good. This is something we want to do a better job of supporting directly, but we haven't quite gotten around to it yet.

[RichardDapice]

Ok great, thank you for your quick responses in regard to this question. Our testing so far has not resulted in any issues that are readily apparent. Hopefully, this holds true in production. We just wanted to make sure there wasn't something we were missing.

We will keep our eye on release notes in the future, or if you guys have a clear plan, let us know if we can contribute.