Closed Bug 1519683 Opened 10 months ago Closed 10 months ago

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

Categories

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

defect

Tracking

()

RESOLVED DUPLICATE of bug 1519617
Tracking Status
firefox-esr60 --- unaffected
firefox64 --- unaffected
firefox65 --- unaffected
firefox66 - fixed

People

(Reporter: cpeterson, Assigned: bryce)

References

Details

(Keywords: regression)

[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

  1. 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)".

  2. Click the "Load" button

  3. 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

Flags: needinfo?(bvandyk)
Flags: needinfo?(bvandyk)

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

Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1519617

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

Assignee: nobody → bvandyk
Status: RESOLVED → REOPENED
Priority: -- → P1
Resolution: DUPLICATE → ---

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.

Status: REOPENED → RESOLVED
Closed: 10 months ago10 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1519617
See Also: → 1519919
You need to log in before you can comment on or make changes to this bug.