[B2G 2.0]Unable to open video in video application when youtube video is buffering in browser running in background

VERIFIED FIXED

Status

()

defect
VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: srinivasvemula.mtech, Assigned: bwu)

Tracking

unspecified
ARM
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(blocking-b2g:2.2+, b2g-v2.2 verified, b2g-master verified)

Details

(Whiteboard: [LibGLA,TD127878,QE4, B])

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36

Steps to reproduce:

1) Open Browser 
2) Enter www.youtube.com
3) Select video with duration > 1hr
4) While video is buffering press home button
5) open video application
6) select video from the video app


Actual results:

video is not getting opened


Expected results:

Able to open and play the video
(Reporter)

Updated

5 years ago
Flags: needinfo?(roc)
(Reporter)

Updated

5 years ago
OS: All → Gonk (Firefox OS)
Hardware: All → ARM
(Reporter)

Comment 1

5 years ago
Issue is not reproducible, when youtube video is playing and manually paused conditions.

Comment 2

5 years ago
Press home button when youtube video is playing, the decoder instance is released.
But when youtube video is loading, the decoder instance is not released.
So new video could not start correctly

Updated

5 years ago
Whiteboard: [LibGLA,TD127878,QE4, B]
Blake, can you take this?
Flags: needinfo?(roc) → needinfo?(bwu)
(Assignee)

Comment 4

5 years ago
yeah. I can check it. 
This problem can be reproed on 2.0 and master branch at my hand. 
It looks like MediaStateMachine didn't enter dormant state successully during buffering.
Flags: needinfo?(bwu)

Comment 5

5 years ago
Our Observation :
While checking the issue we found the the MediaStateMachine entered the dormant state,The state changed to DECODER_STATE_DORMANT.
   - StopPlayback() is not called since IsPlaying() is FALSE
   - The call to ReleaseMediaResources is never reached 

It might have been stuck in mDecodeTaskQueue->AwaitIdle() call, 
since the decoding not started, the thread may not be able to return control to MediaStateMachine.

    
     case DECODER_STATE_DORMANT:
     ..........
    ReentrantMonitorAutoExit exitMon(mDecoder->GetReentrantMonitor());
    // Wait for the thread decoding, if any, to exit.
    mDecodeTaskQueue->AwaitIdle();
    mReader->ReleaseMediaResources();
(Reporter)

Updated

5 years ago
Flags: needinfo?(bwu)
(Assignee)

Comment 6

5 years ago
From what I found is this is a timing issue. When MediaDecoderStateMachine is requesting codec resource via CallDecodeMetadata(), if user pushes home key, media element will ask MediaDecoder to SetDormantIfNecessary if mDecoderStateMachine->IsDormantNeeded() is not false. But since codec is not acquired yet, IsDormantNeeded() will return false and SetDormantIfNecessary will be aborted. And after a short time codec is required which makes the following video APP unable to get codec resource to play.

Hi Srinivas,
From the comment 5, it looks like your observation is not the same to mine. Could you double check it? If not, there may be more than one root cause.
Flags: needinfo?(bwu) → needinfo?(srinivasvemula.mtech)
(Assignee)

Updated

5 years ago
Assignee: nobody → bwu
(Reporter)

Comment 7

5 years ago
In two scenarios Issue is reproducing 

Scenario 1: Select video in youtube while loading the video press home button.
scenario 2: play video for some time then press seek bar, while loading press home button.

Scenario 1: When press the home button play state is PLAY_STATE_PLAYING and mDecoderStateMachine->IsDormantNeeded() is returning false. In this case DecoderStateMachine is Not going to DECODER_STATE_DORMANT state because of below condition in MediaDecoder::SetDormantIfNecessary method.
if (!mDecoderStateMachine || !mDecoderStateMachine->IsDormantNeeded() || (mPlayState == PLAY_STATE_SHUTDOWN))
{ return ;}

Scenario 2: When  home button  is pressed play state is PLAY_STATE_SEEKING and mDecoderStateMachine->IsDormantNeeded() is returning true. MediaDecoderStateMachine enters DECODER_STATE_DORMANT sate but still problem is existed. comment 5 describes the second scenario.
Flags: needinfo?(bwu)
(Reporter)

Updated

5 years ago
Flags: needinfo?(srinivasvemula.mtech)
(Assignee)

Comment 8

5 years ago
For Scenario 1, 
I plan to dispatch the task of ReleaseMediaSources() to the mDecodeTaskQueue to solve this timing problem. 
For Scenario 2, 
I am still tring to repro it.
Flags: needinfo?(bwu)
(Assignee)

Comment 9

5 years ago
(In reply to Blake Wu [:bwu][:blakewu] from comment #8)
> For Scenario 1, 
> I plan to dispatch the task of ReleaseMediaSources() to the mDecodeTaskQueue
> to solve this timing problem. 
> For Scenario 2, 
> I am still tring to repro it.
I can repro Scenario 2 at my hand. As comment 5, it gets stuck in mDecodeTaskQueue->AwaitIdle(). The reason is a DecodeSeek task in MediaTaskQueue is still running to wait to get the decoded frame but data on internet is not available anymore.
(Assignee)

Updated

4 years ago
Depends on: 1113527
blocking-b2g: --- → 2.2?
will investigate on flame
Flags: needinfo?(npark)
I can see the issue intermittently, but with the slightly different steps in 2.2

- Open youtube, and select a video file that is longer than an hour (the interview movie), go to fullscreen mode, and select play
- While buffering, press homescreen
- Open video app, select video.  (At this point, the playback begins on youtube and audio is heard, but once the video app starts up, it stops)
Actual:
I can play the video no problem.

But with the following scenario, I did see an issue:
- Open video app, select the video file, play, then pause
- Press homescreen, open browser and go to www.youtube.com and select a long video and set to fullscreen
- Start playing.
- Press homescreen, and select the video app again

Actual:
Now, video app shows the video paused page, but it cannot be played.  If I go back to the previous page where it lists the videos, then it shows "Video is used by another app" message.

In my case, buffering for even a long video took very little time, so when I exit the browser, often I could hear the audio from it until I start the video app.
Flags: needinfo?(npark)

Updated

4 years ago
Component: Gaia::Video → Video/Audio
Product: Firefox OS → Core

Comment 12

4 years ago
as comment 9 and comment 11, mark as blocker.
Status: UNCONFIRMED → ASSIGNED
blocking-b2g: 2.2? → 2.2+
Ever confirmed: true
(Assignee)

Comment 13

4 years ago
[Blocking Requested - why for this release]:

Since there are many related patches which should partly or completely fix these 2 problems (comment 7) landed in master branch(v3.0) and considering the dependency between patches it may take some efforts to merge those patches to v2.2, I suggest we check this bug in v3.0 if possible.
blocking-b2g: 2.2+ → 3.0?
Flags: needinfo?(bchien)

Comment 14

4 years ago
Agree to only fix in v3.0 for now. However, please help to attach related bugs here if v2.2 uplift is required in the future.
blocking-b2g: 3.0? → 3.0+
Flags: needinfo?(bchien) → needinfo?(bwu)
(Assignee)

Comment 15

4 years ago
After checking the patch in bug 1113527 and those patches in its dependent bugs, they have been uplifted to b2g37(v2.2). 
So I think it is ok to fix this bug in 2.2. 
Sorry to change blocking flag again.
Flags: needinfo?(bwu) → needinfo?(bchien)

Updated

4 years ago
blocking-b2g: 3.0+ → 2.2+
Flags: needinfo?(bchien)
Keywords: verifyme
Posted file logcat
Hi Eric,
Per comment 15, this problem should be fixed on Flame 2.2, but I can repro it on latest build of Flame 2.2 with the step of scenario 2 in Comment 7(the problem cannot be repro with the step of Scenario 1 ), could you help with it? thanks!
See attachments: logcat_0524.txt & Verifyfail_video.mp4
Occurrence Time: 05:24
Rate: 2/4

Flame 2.2 build (319 mb):
Build ID               20150227002521
Gaia Revision          eb6a5ac9081d3962198e0f4520b0743d716d7a27
Gaia Date              2015-02-26 17:25:22
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/c8a38dcfbebc
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150227.035943
Firmware Date          Fri Feb 27 03:59:54 EST 2015
Bootloader             L1TC000118D0
Flags: needinfo?(echang)
Posted video video
QA Whiteboard: [MGSEI-Triage+]
Keywords: verifyme
(Assignee)

Comment 18

4 years ago
(In reply to Shine from comment #16)
> Created attachment 8570878 [details]
> logcat
> 
> Hi Eric,
> Per comment 15, this problem should be fixed on Flame 2.2, but I can repro
> it on latest build of Flame 2.2 with the step of scenario 2 in Comment 7(the
> problem cannot be repro with the step of Scenario 1 ), could you help with
> it? thanks!
The patch in bug 1113527 is currently in central branch, not in 2.2 branch yet. 
Please wait it to be in 2.2 and test it again.
Thanks!
Flags: needinfo?(echang)
(Assignee)

Comment 19

4 years ago
After applying the patch in bug 113527 to my v2.2 Flame, the second problem in comment 7 can be still seen. 
"play video for some time then press seek bar, while loading press home button"

The rootcause of it is codec resource cannot be released since OMXCodec is blocked to read data from MediaCache[1] via MediaResource, but at this time the channel is closed due to suspend[2] so no data will be coming. Since codec is occupied by browser, video app has no code resource to play.    

[1]https://dxr.mozilla.org/mozilla-central/source/dom/media/MediaCache.cpp?from=MediaCache.cpp&case=true#2279
[2]https://dxr.mozilla.org/mozilla-central/source/dom/media/MediaResource.cpp?from=MediaResource.cpp#836
(Assignee)

Comment 20

4 years ago
(In reply to Blake Wu [:bwu][:blakewu] from comment #19)
> After applying the patch in bug 113527 to my v2.2 Flame, the second problem
> in comment 7 can be still seen. 
> "play video for some time then press seek bar, while loading press home
> button"
> 
> The rootcause of it is codec resource cannot be released since OMXCodec is
> blocked to read data from MediaCache[1] via MediaResource, but at this time
> the channel is closed due to suspend[2] so no data will be coming. Since
> codec is occupied by browser, video app has no code resource to play.
                                                 ^^^^ typo. codec      
> 
> [1]https://dxr.mozilla.org/mozilla-central/source/dom/media/MediaCache.
> cpp?from=MediaCache.cpp&case=true#2279
> [2]https://dxr.mozilla.org/mozilla-central/source/dom/media/MediaResource.
> cpp?from=MediaResource.cpp#836
This is not a problem for Firefox browsers since they don't have limited codec resource.
(Assignee)

Updated

4 years ago
Depends on: 1139276
(Assignee)

Comment 21

4 years ago
(In reply to Blake Wu [:bwu][:blakewu] from comment #18)
> (In reply to Shine from comment #16)
> > Created attachment 8570878 [details]
> > logcat
> > 
> > Hi Eric,
> > Per comment 15, this problem should be fixed on Flame 2.2, but I can repro
> > it on latest build of Flame 2.2 with the step of scenario 2 in Comment 7(the
> > problem cannot be repro with the step of Scenario 1 ), could you help with
> > it? thanks!
> The patch in bug 1113527 is currently in central branch, not in 2.2 branch
> yet. 
> Please wait it to be in 2.2 and test it again.
> Thanks!
For your information, 
The patch in bug 1113527 has been checked in v2.2 (bug 1113527 comment 107).
Per #c21, changing state to resolved, and adding verifyme
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Keywords: verifyme
Resolution: --- → FIXED
(Assignee)

Comment 23

4 years ago
There is another problem (scenario 2 in comment 7) not fixed yet. But I think we can create another bug to fix it since that is a little special case which not many people will do that.
(Assignee)

Comment 24

4 years ago
See also bug 1142452.
(Assignee)

Updated

4 years ago
No longer depends on: 1139276
Environmental Variables:
Device: Flame 2.5
BuildID: 20151015030226
Gaia: 40ae7c292a36156458c66712b4bd61ecbe69272a
Gecko: e193b4da0a8c1025aa76a403c64663ff1cd41709
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 44.0a1 (2.5) 
Firmware Version: v18D

Environmental Variables:
Device: Aries 2.5
BuildID: 20151015110122
Gaia: 40ae7c292a36156458c66712b4bd61ecbe69272a
Gecko: e193b4da0a8c1025aa76a403c64663ff1cd41709
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 44.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf

Environmental Variables:
Device: Flame 2.2
BuildID: 20151006032504
Gaia: 5dd95cfb9f1d6501ce0e34414596ef3dd9c2f583
Gecko: fc588eb28eab
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D
QA Whiteboard: [MGSEI-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
Keywords: verifyme
Was unable to repro Scenario 1. Able to repro Scenario 2 at a low repro rate of 1/10

Environmental Variables:
Device: Flame 2.5
BuildID: 20151015030226
Gaia: 40ae7c292a36156458c66712b4bd61ecbe69272a
Gecko: e193b4da0a8c1025aa76a403c64663ff1cd41709
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 44.0a1 (2.5) 
Firmware Version: v18D

Environmental Variables:
Device: Aries 2.5
BuildID: 20151015110122
Gaia: 40ae7c292a36156458c66712b4bd61ecbe69272a
Gecko: e193b4da0a8c1025aa76a403c64663ff1cd41709
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 44.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf

Environmental Variables:
Device: Flame 2.2
BuildID: 20151006032504
Gaia: 5dd95cfb9f1d6501ce0e34414596ef3dd9c2f583
Gecko: fc588eb28eab
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado)
You need to log in before you can comment on or make changes to this bug.