Support PSSH in MOOF

[ghost]

Hi,

we're trying to implement the application based on ExoPlayer playing our own implementation of MPEG-DASH encrypted with Widevine, and we're receiving the error, which we are unable to understand, exception_android.txt.

The stream to be played is available at: http://80.188.56.83/dwv-59109745109306328-max720p.mpd (contentId = 59109745109306328, provider = nangu) which is passing validation on http://dashif.org/conformance.html

After analysis of the one google-reference stream (https://storage.googleapis.com/wvmedia/cenc/h264/tears/tears.mpd), we tried to put the PSSH header into the manifest: http://itonis-portal.nangu.tv/dash/pssh.mpd ; But no success even with this change.

Both the samples play just fine in http://shaka-player-demo.appspot.com/, which leads to the idea that there are some differences between the players, which we do not understand well. Testing is done on Nexus 5 with Android 6.0.1, using ExoPlayer (1.5.3) demo app.

Can anyone with the deeper knowledge of the implementation hint on which part of the implementation can be faulty? From what I can understand, the native function playing the stream refuses to play it? Is there any way to debug it further? I'll be grateful for any indication or idea.

Thanks,
Jan

[ojw28]

A few questions:

• Where is the PSSH header in the original stream that you provided? There doesn't seem to be a PSSH box in the moov atom of the streams and it's not in the manifest either, so I'm not sure exactly where you're expecting to find it in order to make the license request?
• Once you add the PSSH header into the manifest the error changes to an error obtaining the license from the license server. This is presumably because the demo app is hitting Widevine's test server rather than your own. What's the license server URL that needs to be hit to play this content?

[ghost]

Thanks for such a quick response:

• PSSH header is in every segment in the stream (e.g. at the offset 0x4AA in the http://80.188.56.83/ab/fb3dafc96644b288ab425b694c91c917/1452702715751/dwv-59109745109306328-max720p/1101/1502/000000.m4s) with the exception of the initialization segment - ExoPlayer requires it to be in the mpd by default?
• thanks for this, I probably mistakenly expected that the default proxy can handle keys in the same fashion as default proxy in Shaka (which is http://widevine-proxy.appspot.com/proxy)

After changing the proxy to http://widevine-proxy.appspot.com/proxy, I can see receiving the keys in the wireshark, but player is erroring out with "Error decrypting data: requested key has not been loaded" requested_key.txt

[ojw28]

ExoPlayer currently expects:

1. The pssh box either in the moov atom in the init segment, or alternatively in the mpd.
2. A sinf box under moov->trak->mdia->minf->stbl->stsd->sample_entry, where sample_entry is enca or encvin your audio and video streams respectively. Within the sinf we expect to find schi->tenc, which contains the keyID.

So your problems are:

• You have the pssh box in the media segments rather than the init segment. As you've observed, this can be resolved by putting it in the mpd instead.
• We're not finding the keyID in the place specified above, so the player is ending up trying to use a key consisting of all zeros. I'm guessing the keyID is also in your media segments rather than in the init segment? Where abouts; it's quite possible that we should be handling that.

[zajicekp]

Hello, and thanks for the clarification, however I'm not certain what you mean by:

Within the sinf we expect to find schi->tenc, which contains the keyID.

According to the common encryption standard the tenc box contains only the default_KID which can (and in our case is) overridden using SampleToGroupBox and SampleGroupDescriptionBox method in the MovieFragmentBox using the sample group description format in the common encryption standard. Am I right in assuming that ExoPlayer reads the default key ID and uses it exclusively in conjunction with the pssh box provided in the MPD?

If so, then we can work around this and everything should work for static content. I expect however, that we will still have problem with dynamic content where key rotation is used. In this case it is impossible to provide the pssh box either in the initialization segment or the MPD since it will change fragment to fragment, and is not know in advance of a possibly infinite live stream. Same goes for the key ID. Does ExoPlayer have support for these kinds of use-cases?

[ojw28]

Yes, you're correct. We don't look at SampleToGroupBox. We should start looking at it, and I'd rather fix that than have people work around the problem ;). Do you know the specification that says exactly where that lives and how it works? I could only find vague descriptions. I also scanned through the boxes in your media and I couldn't seem to find it.

I'm unsure as to whether that's sufficient to enable key rotation. It's unclear to me exactly how the rotating keys should be loaded into the MediaDrm session. But I guess that's something that should be looked at later.

[zajicekp]

I'm far from being an expert on common encryption, even less on the client side, so take this with a grain of salt but the standard says for SampleToGroupBox:

Container: Sample Table Box (‘stbl’) or Track Fragment Box (‘traf’)

also

For fragmented files, it may be necessary to store both the SampleToGroupBox and SampleGroupDescriptionBox in each track fragment to make them accessible for decryption of the samples they describe

Therefore both boxes we put into the traf box ( as can be seen at the offset 0x1EC in the http://80.188.56.83/ab/fb3dafc96644b288ab425b694c91c917/1452702715751/dwv-59109745109306328-max720p/1101/1502/000000.m4sas). This is the same I saw in shaka player examples.

As to how this enables key rotation is for WideVine. With key ID, key ID association to samples and pssh the CDM should be able to generate a licence request. Strictly speaking the pssh should be enough since it does contain all neaded data (key_id, provide, content_id, track_type, policy, crypto_period_index), where the crypto_period_index is what enables key rotation.

[ojw28]

Which standard exactly (if it's an ISO standard then it should have a number), and what revision of it? Thanks.

[zajicekp]

Hi,
I'm using ISO/IEC 14496-12 3nd edition for the SampleToGroupBox and co. For common encryption (the second quote) ISO/IEC 23001-7 3nd edition.

[zajicekp]

Sorry, for ISO/IEC 14496-12 it is the 4th edition. It explicitly states for SampleGroupDescriptionBox:

Container: Sample Table Box (‘stbl’) or Track Fragment Box (‘traf’)

[ghost]

I suppose the same issue is mentioned in #1298

[ojw28]

This is fixed in the dev-v2 branch by cf363f9.

Regarding the comment above, the issues are a little different. The sample in this issue puts the PSSH data in the MOOF but does (as far as I could tell) the keys do not rotate. For #1298 we'd need to support key rotation. Most of the plumbing for key rotation is in V2, but our default DrmSessionManager implementation does not provide full key rotation support yet.