Closed Bug 1155544 Opened 9 years ago Closed 9 years ago

[FFOS2.0][Woodduck][HOMO] Device reset when user try to see a RTSP video in H-264

Categories

(Firefox OS Graveyard :: Gaia, defect, P2)

Product:
Firefox OS Graveyard
Component:
Gaia
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1088538

People

(Reporter: sync-1, Unassigned)

References

Details

Attachments

(3 files)

media resource service died
1.54 MB, text/x-log
Details
logcat_0554.txt
92.93 KB, text/plain
Details
verify_v2.2.mp4
4.67 MB, video/mp4
Details 
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!
Blocks: Woodduck, Woodduck_Blocker
Flags: needinfo?(fan.luo)
Keywords: qawanted
Hi Ethan,
Could you shed some light about "Whether Woodduck support 720p rtsp video playback"?
Thanks!
Flags: needinfo?(ettseng)
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?
Flags: needinfo?(ettseng) → needinfo?(sync-1)
    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.
Flags: needinfo?(fan.luo)
(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
Flags: needinfo?(sync-1)
Keywords: qawanted
(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.
Summary: [FFOS2.0][Woodduck][HOMO]Device reset when user try to see a RSTP video in 720 H-264 → [FFOS2.0][Woodduck][HOMO] Device reset when user try to see a RSTP video in H-264
Summary: [FFOS2.0][Woodduck][HOMO] Device reset when user try to see a RSTP video in H-264 → [FFOS2.0][Woodduck][HOMO] Device reset when user try to see a RTSP video in H-264
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.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
(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.
See Also: → 1158661
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: