Video sometimes freezes after switching apps

RESOLVED FIXED

Status

()

P1
normal
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: snorp, Assigned: kaku)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox55 verified)

Details

If I start playing a video, then switch to another app, and finally go back to Nightly, sometimes I'm presented with a still frame from the video that never updates.
Flags: needinfo?(jyavenard)
Flags: needinfo?(jolin)
CC Joe who showed me this problem yesterday. 
ni Kaku as well, who is currently in charge of shutdown decoder. 
Kaku, 
John could be quite busy lately. Maybe you could have a look first.
Flags: needinfo?(kaku)
Priority: -- → P1
(Assignee)

Comment 2

2 years ago
I cannot reproduce this issue at all, however, it is quite similar to Bug 1348864 which is confirmed that is related to OOP decoding on fennec. So, let's set this bug to depend on bug 1349883.
Flags: needinfo?(kaku)
(Assignee)

Updated

2 years ago
Depends on: 1349883
See Also: → bug 1348864
Hello,

 I was also able to reproduce this issue when switching to the YouTube app for example.

STR:

 1. Open any YouTube video in nightly
 2. Minimize Nightly and open the YouTube app and start playing a video
 3. Wait 15-20 seconds and switch back to Nightly and try to resume video playback.

After the 3rd step video playback would not resume anymore. The only fix was to refresh the player. 

Notes:
 This issue only occurred when switching between Nightly and the YouTube app. I was not able to reproduce it using other apps.
(Assignee)

Comment 4

2 years ago
Thank you, Bogdan. Through your STR, I found something interesting, actually, a bug.

According to your STR, the video in Nightly is in the DORMANT state and is also suspended. While exiting the DORMANT state, the MDSM switches to SEEKING state which turns off suspend-video-decoder and dispatches a "mozexitvideosuspend" event. The "mozexitvideosuspend" event triggers a throbber on the video controller which will never be canceled because the seeking operation is not a video-only seek and we won't dispatch a "mozvideoonlyseekcompleted" event.

I will open a new bug to handle this issue but leave this bus as it is because it still depends on bug 1349883.
(Assignee)

Updated

2 years ago
Depends on: 1354465
Depends on: 1355407
(Assignee)

Updated

2 years ago
Assignee: nobody → kaku
Status: NEW → ASSIGNED
(Assignee)

Updated

2 years ago
No longer depends on: 1355407
(Assignee)

Comment 5

2 years ago
:bogdan, since both bug 1349883 and bug 1354465 have been resolved, could you help to verify this bug?
Flags: needinfo?(bogdan.surd)
Hello,

 The issue seems to be fixed but there still seems to be a problem when switching between apps multiple times.

STR:
 1. Load YouTube and play any video;
 2. Open the YouTube app and play a video.
 3. Open Nightly again and resume video playback.
 4. Open the YouTube app and resume the video.

Results:
 After the 4th step video playback on Nightly does not pause. Is this to be expected? If yes the issue is fixed then. 

Also please check bug 1355407 I would like to do some further testing but as the issue seems to be constantly reproducible on some devices it's preventing me for properly verifying this.
Flags: needinfo?(bogdan.surd) → needinfo?(kaku)
(Assignee)

Comment 7

2 years ago
(In reply to Bogdan Surd, QA [:bogdan] from comment #6)
> Hello,
> 
>  The issue seems to be fixed but there still seems to be a problem when
> switching between apps multiple times.
> 
> STR:
>  1. Load YouTube and play any video;
>  2. Open the YouTube app and play a video.
>  3. Open Nightly again and resume video playback.
>  4. Open the YouTube app and resume the video.
> 
> Results:
>  After the 4th step video playback on Nightly does not pause. Is this to be
> expected? If yes the issue is fixed then. 

@Alastor, 
I can reproduce the scenario, is this something about audio competition? and is the scenario expected?

> Also please check bug 1355407 I would like to do some further testing but as
> the issue seems to be constantly reproducible on some devices it's
> preventing me for properly verifying this.
Sure, we're now working on it, will update you as long as we get any advance.
Flags: needinfo?(kaku) → needinfo?(alwu)

Comment 8

2 years ago
I've filed bug1357633 for that.
Flags: needinfo?(alwu)
(Assignee)

Comment 9

2 years ago
@Alastor, thanks!

@Bogdan, then I will close this bug since the remaining issue is now handled by a separated bug, bug 1357633.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(jyavenard)
Flags: needinfo?(jolin)
Resolution: --- → FIXED
status-firefox55: affected → verified
You need to log in before you can comment on or make changes to this bug.