Closed Bug 1111978 Opened 5 years ago Closed 5 years ago

[dolphin][FFOS7715 v2.1][video][Browser] RTSP error in browser app blocks playing video in other apps

Categories

(Firefox OS Graveyard :: RTSP, defect)

All
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:2.1+, firefox35 wontfix, firefox36 wontfix, firefox37 fixed, b2g-v2.1 verified, b2g-v2.2 verified)

VERIFIED FIXED
2.2 S3 (9jan)
blocking-b2g 2.1+
Tracking Status
firefox35 --- wontfix
firefox36 --- wontfix
firefox37 --- fixed
b2g-v2.1 --- verified
b2g-v2.2 --- verified

People

(Reporter: bwu, Assigned: ethan)

References

Details

Attachments

(4 files, 2 obsolete files)

This is a follow-up bug from Bug 1110663. 
attachment 8536967 [details] shows the detailed information.
I cannot repro this problem over 20 times.....
Dear Blake:

I captured a video about this issue. after rtsp fails to play in the browser, video file cannot be played in video APP.

Please go to the following address to download:
    http://pan.baidu.com/s/1hqf6jDq

If any information required please let me know.

Thanks.
Add logs for debug
Hi lin hui -

Could you help to add debug log as Blake provide in Comment#3, then reproduce this issue and capture the log again?

Thanks

Vance
Flags: needinfo?(lin.hui)
Lin, don't use this logging patch because it could the browser app crash.

Blake and I started to debug and we already had some clues.
We will update our progress tomorrow.
(In reply to Ethan Tseng [:ethan] from comment #5)
> Lin, don't use this logging patch because it could the browser app crash.
Typo. It could cause the browser app crash.
(In reply to Ethan Tseng [:ethan] from comment #6)
> (In reply to Ethan Tseng [:ethan] from comment #5)
> > Lin, don't use this logging patch because it could the browser app crash.
> Typo. It could cause the browser app crash.

Get!

Thanks a lot.
Flags: needinfo?(lin.hui)
Unassign myself. 

According to the checking with Ethan and Benjamin last night, 
It looks like codec not released may result from getting stuck in reading source in RTSPMediaResource.  
Hi Benjamin,
May I have your help to further check? 
Thanks!
Assignee: bwu → nobody
Flags: needinfo?(bechen)
After applying the patch "bug-1045062-fix-2.1.patch" to avoid the crash, I did the selftest. the test diatils is this attachment.

Please go to the following address to download:
    http://pan.baidu.com/s/1kT86s31

As per steps I did in this video, when I kill all browser app, the video still cannot be played in video APP,

Next, when I open broswer app again, and find a video in "www.monternet.net", click HD to playing, this time, the video app playing video in background.

The issue occurred time:
after 2:43

This is very abnormally about video app.

So please help to check this issue too.
> Next, when I open broswer app again, and find a video in "www.monternet.net", click HD to playing, 
Typo. find a video in "www.monternet.com"
(In reply to Blake Wu [:bwu][:blakewu] from comment #8)
> Unassign myself. 
> 
> According to the checking with Ethan and Benjamin last night, 
> It looks like codec not released may result from getting stuck in reading
> source in RTSPMediaResource.  
> Hi Benjamin,
> May I have your help to further check? 
> Thanks!

Now we suspect there is threading problem between RtspMediaResource::OnDisconnected (main thread) and RtspOmxReader::ReadMetadata (decode thread).
Flags: needinfo?(bechen)
Benjamin and I identified the root cause.

In the scenario of this bug, RTSP connection is successfully established, a PLAY request is sent 
to the server, and a 200 OK PLAY response is replied from the server.
Right now the decoder thread is blocked in waiting to read metadata from the first frame.
Then, our RTSP client encounters an error while parsing the PLAY response [1].
This error is reported to RtspMediaResource and it shutdowns MediaDecoder.
(MediaDecoder's mPlayState becomes PLAY_STATE_SHUTDOWN).

However RtspMediaResource does not implement a mechanism to notify the decoder thread that it
should give up to read metadata under this situation.
The decoder thread enters RtspTrackBuffer::ReadBuffer() and is blocked in monitor.wait() again.

In short, the HW codec resource is not released.
I think we can work out a solution in several days.


p.s. [1] We should file another bug to fix the parsePlayResponse() function.
Logs regarding to Blake's suggested logging patch.

// Step 1. Open streaming from www.monternet.com in the browser app
12-19 18:51:57.943 29602 29602 D MediaDecoder: SetDormant: false
12-19 18:51:57.943 29602 29602 D MediaDecoder: return from setDormant
12-19 18:51:58.393 29602 29602 D MediaDecoder: SetDormant: false
12-19 18:51:58.403 29602 29602 D MediaDecoder: mDecoderStateMachine->IsDormantNeeded():false
12-19 18:51:58.403 29602 29602 D MediaDecoder: return from setDormant
12-19 18:51:58.403 29602 29679 D StateMachine: DecodeMetadata+
12-19 18:51:58.403 29602 29679 D RtspOmxReader: RtspOmxReader::ReadMetadata: called
12-19 18:51:58.563 29602 29679 D RtspMediaResource: ReadBuffer: Monitor wait due to no data
12-19 18:51:58.703 29602 29602 D RtspMediaResource: RtspMediaResource::OnDisconnected called
12-19 18:51:58.713 29602 29602 D RtspMediaResource: RtspMediaResource::OnDisconnected 
                                                    mDecoder->NetworkError
12-19 18:51:58.713 29602 29679 D RtspMediaResource: ReadBuffer: No data and disconnected
12-19 18:51:58.713 29602 29679 D RtspOmxReader: RtspOmxReader::ReadMetadata: EnablePlayoutDelay
12-19 18:51:58.713 29602 29679 D RtspMediaResource: ReadBuffer: Monitor wait during playout delay


// Step 2. Press the Home button
12-19 18:52:06.913 29602 29602 D MediaDecoder: SetDormant: true
12-19 18:52:06.913 29602 29602 D MediaDecoder: mDecoderStateMachine->IsDormantNeeded():true
12-19 18:52:06.913 29602 29602 D MediaDecoder: return from setDormant


// Step 3. Open the video app and click one clip
12-19 18:52:15.513 29630 29630 D MediaDecoder: SetDormant: false
12-19 18:52:15.513 29630 29630 D MediaDecoder: mDecoderStateMachine->IsDormantNeeded():false
12-19 18:52:15.513 29630 29630 D MediaDecoder: return from setDormant
12-19 18:52:15.513 29630 29735 D StateMachine: DecodeMetadata+
12-19 18:52:15.613 29630 29735 D StateMachine: DecodeMetadata---
Assignee: nobody → ettseng
(In reply to Ethan Tseng [:ethan] from comment #12)
> Benjamin and I identified the root cause.
> 
> In the scenario of this bug, RTSP connection is successfully established, a
> PLAY request is sent 
> to the server, and a 200 OK PLAY response is replied from the server.
> Right now the decoder thread is blocked in waiting to read metadata from the
> first frame.
> Then, our RTSP client encounters an error while parsing the PLAY response [1].

Since there have something error in RTSP client parsing the PLAY responce, casue the RTSP video cannot be played in "www.monternet.com".

After a little test, in other streaming website, the RTSP videos playback quality are not as good as other videos(like HTTP videos in youtube and youku) in the same network state. when playing RTSP videos, appear the network error very easily(The network in good condition), so user‘s experience is not enough good.

Can we find a way to improve this issue?
(In reply to lin.hui@spreadtrum.com from comment #14)
> After a little test, in other streaming website, the RTSP videos playback
> quality are not as good as other videos(like HTTP videos in youtube and
> youku) in the same network state. when playing RTSP videos, appear the
> network error very easily(The network in good condition), so user‘s
> experience is not enough good.
> Can we find a way to improve this issue?

There are so many factors that could affect the overall playback quality.
Please file bugs to concretely describe each specific scenario/problem you observe.
Dear Ethan:

How about this issue? if I open browser to playing RTSP video, then click homebutton, open video app, click video to play, video app always pop-up "Cannot play video, another app is currently using the video player".

Now, download File Manager app from Marketplace, launch File Manager app, select any video to play,  they also pop up "Another app is currently using the video player" while launching any video in File Manager app.

This is last until I kill the browser app.

User will so perplex about this.
Flags: needinfo?(ettseng)
Hi Lin hui -

As mentioned in several comments, we think it is better a use one Bugzilla ID for one bug, so if you find any new bug, instead of raising the bug in the comment, please find a new bug such that we can track it separately.

Thanks for your understanding.
Flags: needinfo?(ettseng) → needinfo?(lin.hui)
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #17)
> Hi Lin hui -
> 
> As mentioned in several comments, we think it is better a use one Bugzilla
> ID for one bug, so if you find any new bug, instead of raising the bug in
> the comment, please find a new bug such that we can track it separately.
> 
> Thanks for your understanding.

I'm so sorry, I can understanding that.

Because Comment 16 description is the same situation about this bug, it's not be another one, if I find any new bug, I will fire a new bug about that.

Thank you.
Flags: needinfo?(lin.hui)
(In reply to lin.hui@spreadtrum.com from comment #16)
> How about this issue? if I open browser to playing RTSP video, then click
> homebutton, open video app, click video to play, video app always pop-up
> "Cannot play video, another app is currently using the video player".

Lin,

Okay. I realize this is a reinforced description of the original bug.
As my comment 12 stated, the root cause is because RTSP does not release HW decode resource
in this scenario. When the bug happens, any app which tries to play video would fail until
the browser app is terminated.
I will come back to resolve this problem.

In the meanwhile, bug 1116085 was filed to track the problem we cannot play RTSP video on
the website monternet.com (root cause also stated in comment 12).
Status: NEW → ASSIGNED
Attached patch bug-1111978-fix.patch (obsolete) — Splinter Review
Hi Benjamin,

Could you help to review this patch?
Attachment #8542471 - Flags: review?(bechen)
(In reply to Ethan Tseng [:ethan] from comment #20)
> Created attachment 8542471 [details] [diff] [review]
> bug-1111978-fix.patch

> Could you help to review this patch?

Dear Ethan:

I have reviewed this patch just now, it's looks good to me. 

by this time, RTSP video always pop-up "video playback aborted duo to network error" whenever you click "fluency" or "HD" to playing video in "www.monternet.com“.

Thanks.
(In reply to lin.hui@spreadtrum.com from comment #21)
> I have reviewed this patch just now, it's looks good to me. 
> by this time, RTSP video always pop-up "video playback aborted duo to
> network error" whenever you click "fluency" or "HD" to playing video in
> "www.monternet.com“.
Lin,
Do you mean you already applied and tried the patch?
When network error happens and before terminating the browser app, could you play video in the
video app or other apps?
Comment on attachment 8542471 [details] [diff] [review]
bug-1111978-fix.patch

Review of attachment 8542471 [details] [diff] [review]:
-----------------------------------------------------------------

::: content/media/RtspMediaResource.cpp
@@ +224,5 @@
> +    // It could be stopped when RTSP connection is disconnected.
> +    if (!mIsStarted) {
> +      RTSPMLOG("ReadBuffer: mIsStarted is false");
> +      return NS_ERROR_FAILURE;
> +    }

Since we move the mIsStarted check here, please remove the same check below.
Attachment #8542471 - Flags: review?(bechen) → review+
Attached patch bug-1111978-fix.patch (obsolete) — Splinter Review
Thanks Benjamin! Redundant code removed.
Attachment #8542471 - Attachment is obsolete: true
(In reply to Ethan Tseng [:ethan] from comment #22)
> Do you mean you already applied and tried the patch?
I applying this patch only by myself.

> When network error happens and before terminating the browser app, could you
> play video in the video app or other apps?
Yes! when network error happens and before terminating the browser app, I can play video in the video app or other apps.

Thank you to help to fix this issue.
Make the bug summary more succinct.
Summary: [dolphin][FFOS7715 v2.1][video][Browser] After rtsp fails to play in the browser, video file cannot be played in video APP → [dolphin][FFOS7715 v2.1][video][Browser] RTSP error in browser app blocks playing video in other apps
Update commit comment.
Attachment #8542511 - Attachment is obsolete: true
Attachment #8542830 - Flags: review+
The same patch for mozilla-central (just different file patch).
Attachment #8542833 - Flags: review+
This bug was found on v2.1.
The fix will have to be landed in both v2.1 and v2.2.
Component: Video/Audio → RTSP
Product: Core → Firefox OS
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/8768e1f8108e
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.2 S3 (9jan)
Comment on attachment 8542830 [details] [diff] [review]
bug-1111978-fix-v2.1.patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): None
User impact if declined: Sometimes cannot play video by any app
Testing completed: On m-c and 2.1
Risk to taking this patch (and alternatives if risky): None
String or UUID changes made by this patch: None
Attachment #8542830 - Flags: approval-mozilla-b2g34?
Hi Bhavana,

We have to check in the fix to 2.1, in which this bug was found.
Can you approve the uplift request?
Flags: needinfo?(bbajaj)
blocking-b2g: --- → 2.1+
Flags: needinfo?(bbajaj)
Comment on attachment 8542830 [details] [diff] [review]
bug-1111978-fix-v2.1.patch

Approving given tis issue was introduced in 2.1 ..Please verify once this lands on 2.1
Attachment #8542830 - Flags: approval-mozilla-b2g34? → approval-mozilla-b2g34+
Keywords: verifyme
Thanks Bhavana and Ryan for your help!
Hi all,This issue has been successfully verified on Flame 2.1, 2.2
Reproducing rate: 0/5
Flame 2.1 
ia-Rev        64db236bea9a0510567ab7ced2f2b4688737123c
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/273f24a1d1fe
Build-ID        20150111001202
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150111.035122
FW-Date         Sun Jan 11 03:51:33 EST 2015
Bootloader      L1TC000118D0
Flame 2.2:
Gaia-Rev        f5e481d4caf9ffa561720a6fc9cf521a28bd8439
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/bb8d6034f5f2
Build-ID        20150111010223
Version         37.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150111.043244
FW-Date         Sun Jan 11 04:32:55 EST 2015
Bootloader      L1TC000118D0

Besides,The unwanted prompt view pop up before video is played on 2.1(verify1.3gp),there is no this issue on 2.2.if we need new a issue to follow this issue?
Flags: needinfo?(ettseng)
(In reply to Alissa from comment #39)
> Besides,The unwanted prompt view pop up before video is played on
> 2.1(verify1.3gp),there is no this issue on 2.2.if we need new a issue to
> follow this issue?

Hi Alissa,

What prompt do you mean?
The "Video playback aborted due to a network error" message?

This error message should be prompted if we click the streaming button on www.monternet.com
because we don't support the format of this site yet.
What do you mean by there is no this issue on 2.2?
Flags: needinfo?(ettseng)
Status: RESOLVED → VERIFIED
Keywords: verifyme
Hi Alissa, refer to comment 40, this error message maybe due to format not supportted problem.
But if there have any inconsistent behavior between v2.1 and v2.2, please file another bug then comment and see also here.
Flags: needinfo?(huayu.li)
(In reply to Ethan Tseng [:ethan] from comment #40)
> (In reply to Alissa from comment #39)
> > Besides,The unwanted prompt view pop up before video is played on
> > 2.1(verify1.3gp),there is no this issue on 2.2.if we need new a issue to
> > follow this issue?
> 
> Hi Alissa,
> 
> What prompt do you mean?
> The "Video playback aborted due to a network error" message?
> 
> This error message should be prompted if we click the streaming button on
> www.monternet.com
> because we don't support the format of this site yet.
> What do you mean by there is no this issue on 2.2?

Plese refer to issue 1122400.
Flags: needinfo?(huayu.li)
See Also: → 1122400
You need to log in before you can comment on or make changes to this bug.