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

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.

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!

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).

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---

(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.

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.

(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.

(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).

Hi Benjamin, Could you help to review this patch?

(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.

Thanks Benjamin! Redundant code removed.

(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.

Update commit comment.

The same patch for mozilla-central (just different file patch).

The result of Treeherder: v2.1 patch: https://treeherder.mozilla.org/#/jobs?repo=try&revision=29abaabb482d v2.2 patch: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3f448291c163

This bug was found on v2.1. The fix will have to be landed in both v2.1 and v2.2.

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

Hi Bhavana, We have to check in the fix to 2.1, in which this bug was found. Can you approve the uplift request?

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

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?

(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?

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.

(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.