bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

video element not play mp4 file after playing widevine drm video

RESOLVED FIXED in Firefox 53

Status

()

Core
Audio/Video: Playback
P1
normal
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: sh84, Assigned: kikuo)

Tracking

49 Branch
mozilla53
Points:
---

Firefox Tracking Flags

(firefox53 fixed)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20161025170400

Steps to reproduce:

First play widevine drm with dash.js - everything is fine.
After that try to play any mp4 video - it does not work.

http://jsbin.com/xigebamupa/1/edit?html,output - demo, mp4 runs on 5-th second.

Updated

2 years ago
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core

Comment 1

2 years ago
To save the folks at Mozilla some time, can you try to reproduce with Shaka Player?  http://shaka-player-demo.appspot.com/

If you can't reproduce in Shaka Player, it might be a bug in dash.js rather than in Firefox.

Comment 2

2 years ago
We see the exact same issue in our player (https://bitmovin.com/html5-player/). Playback of progressive content throws a MEDIA_ERR_DECODE if a DRM protected source has been played back earlier using the same video element. Interestingly, playing back DASH content afterwards works perfectly.

Comment 3

2 years ago
So going from EME+MSE to src= fails, but from EME+MSE to just MSE works?

Comment 4

2 years ago
EME+MSE works
EME+MSE > src fails
EME+MSE > MSE > src fails
EME+MSE > MSE > ... > MSE > src fails

Comment 5

2 years ago
I've uploaded a test page where you can reproduce this issue with our Bitmovin Player, Shaka and dash.js.
http://bitmovin.com/public-demos/1316573/
Can you look into this one?
Flags: needinfo?(jyavenard)
Priority: -- → P1
(Assignee)

Comment 7

2 years ago
I have some spare time now and I can look into it.
(Assignee)

Comment 8

2 years ago
It seems that the value of HTMLMediaElement.mPendingEncryptedInitData.mIsEncrypted is still true when switches from WIDEVINE PROTECTED DASH to PROGRASSIVE.   That would result to an error [2].
[1] http://searchfox.org/mozilla-central/rev/8144fcc62054e278fe5db9666815cc13188c96fa/dom/media/MediaInfo.h#401
[2] http://searchfox.org/mozilla-central/rev/8144fcc62054e278fe5db9666815cc13188c96fa/dom/html/HTMLMediaElement.cpp#5081-5086

I'll dig further and provide a fix later, because what I've tried only solves the case for BITMOVIN PLAYER.
Assignee: nobody → kikuo
Flags: needinfo?(jyavenard)
Comment hidden (mozreview-request)
(Assignee)

Comment 10

2 years ago
mozreview-review
Comment on attachment 8825418 [details]
Bug 1316573 - Reset the information in EncryptionInfo to make MediaElement reusable from encrypted content to plain content.

https://reviewboard.mozilla.org/r/103584/#review104198

EncryptionInfo.mEncrypted should be reset when its mInitDatas array is cleared. That should be enough for this bug.
Try run looks good (Mochitest-media only). https://treeherder.mozilla.org/#/jobs?repo=try&revision=331eaf5927de9b160c67b2af13aa946bc21ea7e3&selectedJob=67635485


I found another issue here.
The mp4 file also stops playback when the source is switched from DASH to PROGRESSIVE via DASH.js.
The reason is that somehow HTMLMediaElement.SetPlaybackRate(0.0) is called. (Can be reproduced on Chrome too)
(Assignee)

Updated

2 years ago
Attachment #8825418 - Flags: review?(jyavenard)
(Assignee)

Comment 11

2 years ago
Try run with mochitest-media & all web-platform-tests, 
https://treeherder.mozilla.org/#/jobs?repo=try&revision=f7c3d739d98153b5b172d7102ab42af7b6264e77

Looks good.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 12

2 years ago
mozreview-review
Comment on attachment 8825418 [details]
Bug 1316573 - Reset the information in EncryptionInfo to make MediaElement reusable from encrypted content to plain content.

https://reviewboard.mozilla.org/r/103584/#review104740

I would change the commit message to something more explict, such as allow reusing media element with unencrypted content

::: dom/media/mediasource/TrackBuffersManager.cpp:1096
(Diff revision 1)
>                                     crypto->mInitDatas[i].mType));
>      }
>      info.mCrypto = *crypto;
>      // We clear our crypto init data array, so the MediaFormatReader will
>      // not emit an encrypted event for the same init data again.
> -    info.mCrypto.mInitDatas.Clear();
> +    info.mCrypto.Reset();

this shouldnt be necessary here. as the trackbuffer aren't reused when modifying the src attribute. it will br garbage collected
Attachment #8825418 - Flags: review?(jyavenard) → review+
Comment hidden (mozreview-request)
(Assignee)

Comment 14

2 years ago
mozreview-review
Comment on attachment 8825418 [details]
Bug 1316573 - Reset the information in EncryptionInfo to make MediaElement reusable from encrypted content to plain content.

https://reviewboard.mozilla.org/r/103582/#review104806

Thanks !
I rephrased the commit message, and removed unnecessary Reset().

Comment 15

2 years ago
Pushed by kikuo@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7561c49864f5
Reset the information in EncryptionInfo to make MediaElement reusable from encrypted content to plain content. r=jya

Comment 16

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/7561c49864f5
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox53: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
You need to log in before you can comment on or make changes to this bug.