Closed Bug 1352934 Opened 3 years ago Closed 3 years ago

Background suspended Netflix cannot resume

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla55
Tracking Status
platform-rel --- +
firefox55 --- fixed

People

(Reporter: cpearce, Assigned: kaku)

References

Details

(Whiteboard: [platform-rel-Netflix])

Attachments

(1 file)

If suspending background video decoding is enabled, and I blur a tab playing Netflix, and then the video decoder is suspended, and then I focus the tab, Netflix playback fails.

STR:
1. Ensure suspending background video decoding is enabled (Nightly build).
2. Open Netflix and begin playing a video.
3. Open a new tab (CTRL+T).
4. Wait until the background video decoder suspends.
5. Refocus the Netflix tab.

Expected result:
Netflix should keep playing.

Observed result:
Netflix tab stops playing when tab is focused.
Kaku would be very interested in this bug. :-)
Flags: needinfo?(kaku)
Chris, 
Did you see any error code on Netflix page? I wonder if this is similar to what I hit in bug 1350453.
Yes, I'm seeing F7375. They likely are related.
I'm happy for Kaku to take this bug. Let me know if you need any help Kaku.

I looked briefly, and here's what I discovered:

If I set media.eme.video.blank=true (to bypass the CDM video decoding) and I still see the failure. So that indicates that the failure is not originating inside the CDM, as we don't use the CDM decode path when media.eme.video.blank=true.

My ClearKey demo at https://people-mozilla.org/~cpearce/mse-clearkey/ works as expected, so my *guess* is that there's something in Netflix's player that can observe the shutdown/restart of the decoder and whatever it's observing is causing it to error.

Maybe NSPR logs would show something useful?
platform-rel: --- → +
Whiteboard: [platform-rel-Netflix]
Duplicate of this bug: 1350453
(In reply to Chris Pearce (:cpearce) from comment #4)
> Maybe NSPR logs would show something useful?
Yes, it does. I observed a pattern every time before the Netflix playback fails: 
1. Switch the Netflix tab back to the foreground.
2. HTMLMediaElement dispatches a "mozexitvideosuspend" event.
3. HTMLMediaElement dispatches a "seeking" event.
4. HTMLMediaElement calls MediaDecoder::Pause().
5. Netflix shows error.

While resuming a suspend video element, we fire a video-only seek operation for seeking to the right video position. (http://searchfox.org/mozilla-central/rev/b8cce081200129a1307e2a682f121135b5ca1d19/dom/media/MediaDecoderStateMachine.cpp#2039)

I think it is this unexpected seeking event makes Netflix player panic. So, I modify the seeking operation to be unobservable, and it works, the Netflix player feels comfortable now and it keeps working.

The seeking operation WAS unobservable before Bug 1309494. I changed it because I want the "canplay" event, which will be dispatched after the seeking operation is done, to notify our video controller to cancel the throbber(which will be shown if the decoder resuming cannot be done in 250 ms).

But, no worry, we can change the seeking operatoin back to unobservable thanks to bug 1350852. Now, we rely on a specific "mozvideoonlyseekcompleted" event to cancel the throbber, so we no longer need the "canplay" event.

A patch is following.
Assignee: nobody → kaku
Status: NEW → ASSIGNED
Flags: needinfo?(kaku)
Comment on attachment 8855202 [details]
Bug 1352934 - make the seek operation at StateObject::HandleResumeVideoDecoding() unobservable;

https://reviewboard.mozilla.org/r/127076/#review129834
Attachment #8855202 - Flags: review?(jwwang) → review+
Kaku, Cool! You are really fast to find the root cause. 

Chris, 
Do you know if there is any test case in automation to test Netflix? I am thinking a way to avoid any possible regression on Netflix.
Flags: needinfo?(cpearce)
Try looks good. Thanks for the review!
Pushed by tkuo@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b86a04a468b3
make the seek operation at StateObject::HandleResumeVideoDecoding() unobservable; r=jwwang
https://hg.mozilla.org/mozilla-central/rev/b86a04a468b3
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Thanks Kaku. Are any other branches affected?
Flags: needinfo?(cpearce) → needinfo?(kaku)
(In reply to Blake Wu [:bwu][:blakewu] from comment #10)
> Kaku, Cool! You are really fast to find the root cause. 
> 
> Chris, 
> Do you know if there is any test case in automation to test Netflix? I am
> thinking a way to avoid any possible regression on Netflix.

We have the external-media-tests, but they don't have a background playback case so they won't have discovered this regression. We recently decided to stop investing in those tests however, as they've required a lot of work to keep running and haven't delivered much value.
(In reply to Chris Pearce (:cpearce) from comment #14)
> Thanks Kaku. Are any other branches affected?

No, we only turn on the suspend-vide-decoder flag in Nightly.
Flags: needinfo?(kaku)
(In reply to Chris Pearce (:cpearce) from comment #15)
> (In reply to Blake Wu [:bwu][:blakewu] from comment #10)
> > Kaku, Cool! You are really fast to find the root cause. 
> > 
> > Chris, 
> > Do you know if there is any test case in automation to test Netflix? I am
> > thinking a way to avoid any possible regression on Netflix.
> 
> We have the external-media-tests, but they don't have a background playback
> case so they won't have discovered this regression. We recently decided to
> stop investing in those tests however, as they've required a lot of work to
> keep running and haven't delivered much value.
I thought external-media-tests is useful since they test the real world and should be able to increase our testing coverage. I am going to bother you or Bryce to know more background about it. :-)
Would manual QA be of value here? I'm not sure if all the steps described in Comment 0 can be simulated manually though, so we'd need to clarify that first if the answer is yes.
Flags: qe-verify?
You need to log in before you can comment on or make changes to this bug.