DEFECT DESCRIPTION: playing video in www.monternet.com,the cellphone reboot. Steps to reproduce: ---------------------------------------------------- The detail testing steps are in attachment. Please check it. Additional info: -------------------------------------- Reproduce rate: 5/5

From the log in the attachment 8535510 [details] and the link in the my browser, 12-12 17:00:44.869 F/        ( 2685): ../../../../gecko/netwerk/protocol/rtsp/rtsp/RTSPConnectionHandler.h:1300 CHECK_LT( trackIndex,mTracks.size()) failed: 2 vs. 2 It seems a RTSP bug. Hi Ethan, Could you help check it? Thanks!

Hi Blake, I tried to reproduce it on Flame v2.2, but the browser simply shows an error message "Video playback aborted due to a network error". Probably it is a kind of format error handling that triggers this error. I will try to reproduce it again on v2.1.

Dear Ethan, In v1.4,video's "mannifest.webapp" file are defined as follows: >"activities": { > "view" : { > "filters": { > "type": ["video/webm", "video/mp4", "video/3gpp", "video/ogg", "video/rtsp"] > }, > "href": "view.html", > "disposition": "inline", > "returnValue": true > }, > } so video can support "rtsp" in v1.4, according to the testing steps, it will pop-up a alert boxes say： “Video cannot be played: either because the server or network failed or because the format is not supported.“ So this Behavior works fine. but in v2.1, the "manifest.webapp" file are defined as this: >"activities": { > "view" : { > "filters": { > "type": ["video/webm", "video/mp4", "video/3gpp", "video/3gpp2", "video/ogg"] > }, > "href": "view.html", > "disposition": "inline", > "returnValue": true > }, > } It seems that video app do not support "rtsp" in v2.1, so triggers the cellphone reboot. Please refer to version 1.4，and help to fix this issue. Thanks a lot.

(In reply to lin.hui@spreadtrum.com from comment #3) > It seems that video app do not support "rtsp" in v2.1, so triggers the > cellphone reboot. Hi Lin, In v1.3 and v1.4, we support only RTSP audio and it is rendered in the video app. Since v2.0, we support both RTSP audio and video, and it is rendered in the browser instead of the video app. That's why "video/rtsp" was removed from the manifest.webapp file of the video app. Thus, both v2.1 and v2.2 support playing RTSP video in the system browser. The reason why v2.1 crashes but v2.2 does not crash is because v2.2 contains the patch of this bug: Bug 1045062 - [RTSP] Replace CHECK assertions by NS_ASSERTION or graceful assertions I will try to see if we can uplift this patch to v2.1.

(In reply to Ethan Tseng [:ethan] from comment #4) Dear Ethan： Firstly, thanks for your explain. Now this issue blocking our PTR plan, so please help to fix it as soon as possible. Thanks a lot!

(In reply to lin.hui@spreadtrum.com from comment #5) > Now this issue blocking our PTR plan, so please help to fix it as soon as > possible. Ideally I would like to uplift the patch of bug 1045062 to more fully fix system crash issue like this. But I see some code conflicts by simply applying that patch to v2.1. We need more time to resolve those conflicts (maybe more patches need to be uplifted as well). If this is urgent, I can provide a patch in this bug to just avoid the crash in your scenario. But we can only avoid the crash, the streaming video still cannot be played. If this is what you want, let me know and I'll upload a patch.

(In reply to Ethan Tseng [:ethan] from comment #6) > (In reply to lin.hui@spreadtrum.com from comment #5) > > Now this issue blocking our PTR plan, so please help to fix it as soon as > > possible. > > Ideally I would like to uplift the patch of bug 1045062 to more fully fix > system crash issue like this. > But I see some code conflicts by simply applying that patch to v2.1. > We need more time to resolve those conflicts (maybe more patches need to be > uplifted as well). > Hi Ethan: Please provide the patch in this bug to just avoid the crash firstly. If the user want to supports the RTSP in that website, then we fix it again. Thanks!

(In reply to Ethan Tseng [:ethan] from comment #4) > (In reply to lin.hui@spreadtrum.com from comment #3) > > It seems that video app do not support "rtsp" in v2.1, so triggers the > > cellphone reboot. > > Hi Lin, > > In v1.3 and v1.4, we support only RTSP audio and it is rendered in the video > app. > Since v2.0, we support both RTSP audio and video, and it is rendered in the > browser instead of > the video app. > That's why "video/rtsp" was removed from the manifest.webapp file of the > video app. > > Thus, both v2.1 and v2.2 support playing RTSP video in the system browser. > The reason why v2.1 crashes but v2.2 does not crash is because v2.2 contains > the patch of this bug: > Bug 1045062 - [RTSP] Replace CHECK assertions by NS_ASSERTION or graceful > assertions > > I will try to see if we can uplift this patch to v2.1. Hi Ethan Tseng: Can you tell me How or Where did v1.4 do in gecko that v1.4-gecko can send message to open Video app to play RTSP video ?

(In reply to jinchao.wang from comment #8) > Hi Ethan Tseng: > Can you tell me How or Where did v1.4 do in gecko that v1.4-gecko can > send message to open Video app to play RTSP video ? The code is in mainly in nsExternalHelperAppService.cpp. We dispatch RTSP url scheme to the video app using activity. You can find the patches in these two bugs: Bug 884702 - Make Rtsp non-exposed protocol and support rtsp in HTML <a> tag Bug 947132 - [RTSP] Replace system message by activity when handing off rtsp URL loading The patch of bug 884702 used system message to launch the video app, which was a wrong decision. And it was replaced by activity in bug 947132. Hope this information helps. We used system activity to launch the video app.

Hi Ethan Tseng： > (In reply to lin.hui@spreadtrum.com from comment #5) > > Now this issue blocking our PTR plan, so please help to fix it as soon as > > possible. > > If this is urgent, I can provide a patch in this bug to just avoid the crash > in your scenario. > But we can only avoid the crash, the streaming video still cannot be played. > If this is what you want, let me know and I'll upload a patch. Can you help to provide the patch in this bug to just avoid the crash firstly? we should avoid the crash emergency. Thank a lot.

(In reply to lin.hui@spreadtrum.com from comment #7) > Please provide the patch in this bug to just avoid the crash firstly. > If the user want to supports the RTSP in that website, then we fix it > again. Hi Lin, After some discussion with my teammates, we think it's still better to uplift the patch of bug 1045062 in order to reduce confusion and maintenance trouble in the future. (We try to keep v2.1 and v2.2 as consistent as possible and trace patches in the right bugs.) Anyway, I think there is no much difference to you. Instead of uploading a patch here, I will upload a v2.1 patch in bug 1045062, and request uplift to mozilla-b2g34 in that bug.

Dear Ethan: > After some discussion with my teammates, we think it's still better to uplift the patch of > bug 1045062 in order to reduce confusion and maintenance trouble in the future. I agree with your idea. and after applying the patch "bug-1045062-fix-2.1.patch" to v2.1, it will bring some side effects. > Ideally I would like to uplift the patch of bug 1045062 to more fully fix system crash issue like > this. > But I see some code conflicts by simply applying that patch to v2.1. > We need more time to resolve those conflicts (maybe more patches need to be uplifted as well). Because of we don't know clearly about the code, We waiting for you to resolve the code conflicts as soon as possible, and provide us a correct patch to resolve this issue. Thanks for your help.

(In reply to lin.hui@spreadtrum.com from comment #12) > I agree with your idea. and after applying the patch > "bug-1045062-fix-2.1.patch" to v2.1, it will bring some side effects. > Because of we don't know clearly about the code, We waiting for you to > resolve the code conflicts as soon as possible, and provide us a correct > patch to resolve this issue. I already tested the "bug-1045062-fix-2.1.patch" in v2.1 and requested uplift to v2.1. https://bugzilla.mozilla.org/show_bug.cgi?id=1045062#c30 So, what side effect did you encounter? Can you elaborate it? Would the patch affect other functionality?

Dear Ethan: This attachment is the side affect after using the "bug-1045062-fix-2.1.patch". Please check it. Thanks.

It looks like codec is not released when rtsp error occurs. This is a new problem which is different from the current bug. I think we could create a new bug to fix it.

Bug 1111978 is created to follow up the bug described in comment 14.

(In reply to lin.hui@spreadtrum.com from comment #14) > This attachment is the side affect after using the > "bug-1045062-fix-2.1.patch". As Blake said, it seems the hardware codec is not released properly in this case. This should be another bug. BTW, v2.2 is not unaffected. Only v2.1 has this problem. (In reply to Blake Wu [:bwu][:blakewu] from comment #16) > Bug 1111978 is created to follow up the bug described in comment 14. Thanks, Blake!

(In reply to Ethan Tseng [:ethan] from comment #17) > BTW, v2.2 is not unaffected. Only v2.1 has this problem. Sorry for my typo. It should be: "v2.2 is unaffected".

Dear Ethan： Now all the RTSP video in v2.1, when they are loaded, it's duration is a random value，like “67911：05：05“，67911：05：05 etc.. So, is there anything wrong about RTSP video in v2.1 ?

(In reply to lin.hui@spreadtrum.com from comment #19) > Now all the RTSP video in v2.1, when they are loaded, it's duration is a > random value，like “67911：05：05“，67911：05：05 etc.. > So, is there anything wrong about RTSP video in v2.1 ? I cannot reproduce this issue in v2.1. Can you successfully play out the streaming in this situation?

Dear Ethan: The RTSP video can successfully playing. following the test steps: 1.open the website "114.30.40.60：8800" 2.select "index.html" 3.select "video streaming test", click the RTSP video to play. During the loading time, the video's duration is a random value.

I think there maybe something wrong during RTSP metadata parsing. >RtspMetaData::DeserializeRtspMetaData(const InfallibleTArray<RtspMetadataParam>& metaArray) The metaArray's duration is a random value, so set the wrong duration to gaia cause the problem.

(In reply to lin.hui@spreadtrum.com from comment #22) > I think there maybe something wrong during RTSP metadata parsing. > >RtspMetaData::DeserializeRtspMetaData(const InfallibleTArray<RtspMetadataParam>& metaArray) > The metaArray's duration is a random value, so set the wrong duration to > gaia cause the problem. I don't think it's a bug of parsing metadata. Let me confirm one thing first. In your case, the duration would become correct when the streaming starts to play, right?

Dear Ethan： > I don't think it's a bug of parsing metadata. > Let me confirm one thing first. > In your case, the duration would become correct when the streaming starts to > play, right? Yes，after the RTSP video playing, the duration become correct. but I want to know, why before the video playing the duration is a big time ?

(In reply to lin.hui@spreadtrum.com from comment #24) > Yes，after the RTSP video playing, the duration become correct. but I want to > know, why before the video playing the duration is a big time ? The real duration of RTSP streaming is carried in the server response to RTSP DESCRIBE request. (It is in SDP). Our RTSP client can obtain the correct duration only when it successfully receives such response. So before that happens, the duration is unknown to our player. The problem is we should display zero or something like N/A instead of a messy random value. There must be some uninitialized value somewhere in code base. I suggest we file a new bug to track this issue.

(In reply to Ethan Tseng [:ethan] from comment #25) > The real duration of RTSP streaming is carried in the server response to > RTSP DESCRIBE request. > (It is in SDP). Our RTSP client can obtain the correct duration only when it > successfully receives > such response. So before that happens, the duration is unknown to our player. > > The problem is we should display zero or something like N/A instead of a > messy random value. > There must be some uninitialized value somewhere in code base. > I suggest we file a new bug to track this issue. I think we display zero to the video duration is the best way. By the way, I fire a new bug about this wrong duration issue. Bug 1112030 - [dolphin][FFOS7715 v2.1][RTSP video][Browser] Go browser, playing RTSP video, during video loaded, the duration of video is a very large value.

(In reply to Ethan Tseng [:ethan] from comment #2) > I tried to reproduce it on Flame v2.2, but the browser simply shows an error > message > "Video playback aborted due to a network error". > Probably it is a kind of format error handling that triggers this error. > > I will try to reproduce it again on v2.1. Now, I want to confirm two things: 1.On Flame v2.2, according to testing steps, could you successfully playing video in website "www.monternet.com ? 2.Since both v2.1 and v2.2 support playing RTSP video in the system browser, Why we successfully playing RTSP video in "114.30.40.60:8800", but failed on "www.monternet.com" ?

(In reply to lin.hui@spreadtrum.com from comment #27) > Now, I want to confirm two things: > 1.On Flame v2.2, according to testing steps, could you successfully playing > video in website "www.monternet.com ? No. > 2.Since both v2.1 and v2.2 support playing RTSP video in the system browser, > Why we successfully playing RTSP video in "114.30.40.60:8800", but failed on > "www.monternet.com" ? There are various payload/codec formats and RTSP client/server implementations. Sometimes it is because we don't support the media codec yet; sometimes it's just a bug in either the client or the server side. We need to pay more debugging effort to identify the real cause.

The system crash is resolved fixed by the v2.1 patch of bug 1045062. https://bugzilla.mozilla.org/show_bug.cgi?id=1045062#c33 Lin, please help to verify the fix. :)

I am so sorry to trouble you, 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 videos, 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:40 This is very abnormally about video app. So please help to check this issue.

(In reply to lin.hui@spreadtrum.com from comment #30) > As per steps I did in this videos, when I kill all browser app, the video > still cannot be played in video APP, I think we are tracking this issue in bug 1111978 now.

Dear Ethan： Now when go to "www.monternet.com", when I click the “fluency" or "HD" to play RTSP video, sometimes the shows "video playback aborted due to a network error", but sometimes the will not show this alert, and you can click the video controls, but video can not be played. in this case, user will think it's a bug that can not play videos. When click these two buttons, I think the best way that we always pop-up the alert "video playback aborted due to a network error". Do you think so?

Dear Ethan： > Now when go to "www.monternet.com", when I click the “fluency" or "HD" to > play RTSP video, sometimes the shows "video playback aborted due to a > network error", but sometimes the will not show this alert, and you can > click the video controls, but video can not be played. in this case, user > will think it's a bug that can not play videos. > > When click these two buttons, I think the best way that we always pop-up the > alert "video playback aborted due to a network error".

(In reply to lin.hui@spreadtrum.com from comment #32) > Now when go to "www.monternet.com", when I click the “fluency" or "HD" to > play RTSP video, sometimes the shows "video playback aborted due to a > network error", but sometimes the will not show this alert, and you can > click the video controls, but video can not be played. in this case, user > will think it's a bug that can not play videos. > > When click these two buttons, I think the best way that we always pop-up the > alert "video playback aborted due to a network error". > > Do you think so? When I click the "Fluency" button, it always display error message immediately. And we know the root cause is due to an error while parsing RTSP PLAY response packet. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1111978#c12 As for the "HD" button, it keeps loading without error message. There is no parsing error. I think this is a different scenario that we need to dig more deeply.

(In reply to Ethan Tseng [:ethan] from comment #34) > When I click the "Fluency" button, it always display error message > immediately. Just displayed the first time you click it, if you click back(or refresh this page), then click "fluency" or "HD" again, it keeps loading without error message.