1519683 - Shaka Player demo page's "Verizon Digital Media Services" streams no longer plays

Status: RESOLVED DUPLICATE of bug 1519617

(Core :: Audio/Video: Playback, defect, P1)

Description

[Chris Peterson [:cpeterson]]

[Tracking Requested - why for this release]:

Bryce, this bug is a regression from mp4 bug 1515471.

STR:

1. Load the Shaka Player demo page:

https://shaka-player-demo.appspot.com/demo/#asset=https://content.uplynk.com/847859273a4b4a81959d8fea181672a4.mpd?pr.version=2&pr.playenabler=B621D91F-EDCC-4035-8D4B-DC71760D43E9&pr.securitylevel=150;lang=en-US;build=uncompiled

2. Select any of the "Verizon Digital Media Services" streams:
   "Multi DRM - 8 Byte IV"
   "Multi DRM - MultiPeriod - 8 Byte IV"
   "Widevine - 16 Byte IV"
   "Widevine - 16 Byte IV - (mix of encrypted and unencrypted periods)".

3. Click the "Load" button

4. Wait for the video to play

RESULT:
The video never plays. The player is stuck showing Shaka's loading spinner.

I bisected this regression to this pushlog for mp4 bug 1515471:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4b0da3a2a9facebc598079ca6e8161cefb3448ea&tochange=8bbbc4ae3211427848d827d96c62dd0220374b6f

Comment 1

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Same issue as bug 1519617. Going to request backout of my patches while I determine a fix.

Comment 2

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

I was incorrect: looking into this, it's similar, but a slightly different failure case.

Comment 3

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

I appear to have mostly been correct initially and this is the same root cause as bug 1519617. The different bugs have different regression ranges due to the encrypted case failing earlier in the parse -- my changes meant we wouldn't try to parse crypto when the parser was reading metadata for all tracks. This is because each MoofParser has a single set of crypto data, and if we read multiple tracks, and pick up multiple crypto data, how should we map that to a single instance? Before my changes (the regressing ones here) we would have used the last set of crypto data we found, which would mostly work because of how fragmented mp4s are structed, but was not a reliably strategy over all.

The root cause is further detailed in this comment on the other bug. The fix I'm working on appears to resolve both issues, remarking as dupe.