DEFECT DESCRIPTION: The DUT reset after 5 seconds when you reproduce an specific video in AT4 server REPRODUCING PROCEDURES: 1-Conect the DUT on a Network 2-Open URL: http://186.148.57.28/altmp/ 3-select the first video and the you will see the reset EXPECTED BEHAVIOUR: Device should'nt reset in any circumstances ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: High REPRODUCING RATE: 5/5 For FT PR, Please list reference mobile's behavior:

Created an attachment (id=1244182) media resource service died adb log for this issue. We found media resource service died, but don't know why.

Created an attachment (id=1244182) media resource service died adb log for this issue. We found media resource service died, but don't know why.

Created an attachment (id=1244182) media resource service died adb log for this issue. We found media resource service died, but don't know why.

D/AudioMTKPolicyManager( 997): getDeviceForStrategy() strategy 0, device 2 D/IPCThreadState( 997): [DN #5] BR_DEAD_BINDER cookie 0x419d3f08 I/ServiceManager( 133): service 'media.resource_manager' died I/ServiceManager( 133): service 'SurfaceFlinger' died I/ServiceManager( 133): service 'permission' died I/ServiceManager( 133): service 'android.security.keystore' died D/IPCThreadState( 1177): [DN #5] BR_DEAD_BINDER cookie 0x43d0fc80 Some media service died, and I dont think if we can support 720p rtsp video on Fire 2 3.5.

Hi Norry, qawanted for Woodduck 2.0M and Flame 2.0/2.1/2.2. Thanks!

Hi Ethan, Could you shed some light about "Whether Woodduck support 720p rtsp video playback"? Thanks!

I see the following messages in the attached log, which indicate some clue. I/Gecko ( 165): [Parent 165] ###!!! ABORT: file /data/workspace/fire2-3.5-hz/gecko/netwerk/protocol/rtsp/rtsp/RTSPSource.cpp, line 700 I/GraphicBuffer( 165): allocate buffer (w:32 h:16 f:1) handle(0x47ad41c0) err(0) E/Gecko ( 165): mozalloc_abort: [Parent 165] ###!!! ABORT: file /data/workspace/fire2-3.5-hz/gecko/netwerk/protocol/rtsp/rtsp/RTSPSource.cpp, line 700 I'll keep investigating more deeply about the root cause.

The server 186.148.57.28 is not available now. Could the reporter help to make it back online?

I try to repro this bug on latest Woodduck v2.0 and Flame v2.0&2.1 by the following steps. But the server 186.148.57.28 is not available now, so I can't collect log and video. Hi Reporter, Could you help to check the following steps and actual behavior and confirm whether the behavior is same as "Device Reset" that you mentioned. ----------------------------------------------------------- Repro STR: 1.Conect a Wifi. 2.Open URL: "http://186.148.57.28/altmp/". 3.Select the first video and play it. 4.Tap on the video playing control area, and pay attention to the palying time of the progress bar. **When playing time is 5 seconds,the whole highlighted progress bar shows that the video is played completely. Please see video:verify.mp4.

(In reply to Josh Cheng [:josh] from comment #6) > Hi Ethan, > Could you shed some light about "Whether Woodduck support 720p rtsp video > playback"? > Thanks! Woodduck can play 720P file. I just play one with Video App.

(In reply to comment #7) > Comment from Mozilla: I try to repro this bug on latest Woodduck v2.0 and > Flame v2.0&2.1 by the following steps. But the server 186.148.57.28 is not > available now, so I can't collect log and video. > > > Hi Reporter, > > Could you help to check the following steps and actual behavior and confirm > whether the behavior is same as "Device Reset" that you mentioned. > > ----------------------------------------------------------- > Repro STR: > 1.Conect a Wifi. > 2.Open URL: "http://186.148.57.28/altmp/". > 3.Select the first video and play it. > 4.Tap on the video playing control area, and pay attention to the palying time > of the progress bar. > **When playing time is 5 seconds,the whole highlighted progress bar shows that > the video is played completely. > > Please see video:verify.mp4. > hi,The server 186.148.57.28 is available now. the step is right, and the video is about 2 minutes, when playing time is 5 seconds, the device will reset and show an crash report dialog after start.

(In reply to comment #6) > Comment from Mozilla:The server 186.148.57.28 is not available now. > Could the reporter help to make it back online? > The server 186.148.57.28 is available now.

I can't repro the device reset and crash,and only repro this problem as mentioned in Comment 9 on latest Woodduck v2.0 and Flame v2.0&2.1&2.2&3.0. See attachment: verify_v2.2.mp4 and logcat_0554.txt Reproduce rate: 0/5(reset&crash) > 4.Tap on the video playing control area, and pay attention to the palying time > of the progress bar. > **When playing time is 5 seconds,the whole highlighted progress bar shows that > the video is played completely. ---------------------------------------------------------------------------------- Device: Woodduck 2.0 build Build ID 20150421050314 Gaia Revision 37e63db3af0f76fe9c71a4ce23aef9771491124f Gaia Date 2015-04-12 07:28:35 Gecko Revision be29567fc9b1467162a79a39ad7c5db3ac5b0582 Gecko Version 32.0 Device Name jrdhz72_w_ff Firmware(Release) 4.4.2 Firmware(Incremental) 1429563900 Firmware Date Tue Apr 21 05:05:18 CST 2015 Device: Flame 2.0 build Build ID 20150420000202 Gaia Revision 84898cadf28b1a1fcd03b726cff658de470282f0 Gaia Date 2015-04-03 21:42:36 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/c17fa8ed09c7 Gecko Version 32.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150420.033008 Firmware Date Mon Apr 20 03:30:19 EDT 2015 Bootloader L1TC000118D0 Device: Flame 2.1 build Build ID 20150420001205 Gaia Revision bbe983b4e8bebfec26b3726b79568a22d667223c Gaia Date 2015-04-09 13:52:48 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/b85d4f4a6d61 Gecko Version 34.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150420.035930 Firmware Date Mon Apr 20 03:59:40 EDT 2015 Bootloader L1TC000118D0 Device: Flame 2.2 build Build ID 20150420002502 Gaia Revision c15a2b6d3a783813959c2b3bffd2a131f4270b9e Gaia Date 2015-04-17 17:49:32 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/cc02ee38b252 Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150420.041634 Firmware Date Mon Apr 20 04:16:45 EDT 2015 Bootloader L1TC000118D0 Device: Flame 3.0 build Build ID 20150420160201 Gaia Revision a8e4f95dce9db727dda5d408b038f97fb4296557 Gaia Date 2015-04-20 19:30:21 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/e7112314d9d5 Gecko Version 40.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150420.191858 Firmware Date Mon Apr 20 19:19:10 EDT 2015 Bootloader L1TC000118D0

(In reply to Blake Wu [:bwu][:blakewu] from comment #11) > Woodduck can play 720P file. I just play one with Video App. Yes. I verified it too. After investigation, this bug is irrelevant to video resolution. Thus, remove "720" from the title to avoid confusion.

This bug is actually a duplicate of bug 1088538. The patch for 2.0M was landed on 2015/4/6: https://bugzilla.mozilla.org/show_bug.cgi?id=1088538#c23 I guess the build of reporter is earlier than this date and does not include this patch. That's why Shally cannot reproduce this bug (comment 14). From the perspective of crash issue, I'll set this bug as resolved (and duplicate as 1088538). However, as Shally mentioned in comment 9 and comment 14, the playback ends at the time of 5 seconds. This is because there is always a time gap (around 5~6 seconds) of RTP stream packets between 4~5 seconds from the beginning. And our RTSP client uses 2 seconds timeout to detect network error or end-of-stream. In this case, we treat it as end-of-stream and immediately set the playback as ended. The simplest work-around is to change kAccessUnitTimeoutUs (defined in RTSPConnectionHandler.h) from 2 seconds to 10 seconds. static int64_t kAccessUnitTimeoutUs = 2000000ll; // Change this to 10000000ll The side effect of this solution is, we have to wait 10 seconds in the real end-of-stream. Before this timeout, we cannot replay the clip.

(In reply to Ethan Tseng [:ethan] from comment #18) > This is because there is always a time gap (around 5~6 seconds) of RTP > stream packets between 4~5 seconds from the beginning. And our RTSP client > uses 2 seconds timeout to detect network error or end-of-stream. *** Additional Note *** A more robust solution of this problem is developed in bug 1151760 (Playback jumps to the end-of-stream after playing 34 seconds). The patch is expected to land to mozilla central in few weeks. But I am not sure whether it is possible to uplift to 2.0 and 2.0M.

hi The device don't do the reset anymore but can't reproduce the video well. only the audio can be heared but the video is not showed.

(In reply to sync-1 from comment #20) > The device don't do the reset anymore but can't reproduce the video well. > only the audio can be heared but the video is not showed. Got it. I saw you filed bug 1158661 as a follow-up to trace this issue.