1105201 - [RTSP] Can't play if tap pause/play continuously

Status: RESOLVED DUPLICATE of bug 1112412

(Firefox OS Graveyard :: RTSP, defect)

Description

[Jonathan Hao (inactive) [:jhao]]

Please refer to https://bugzilla.mozilla.org/show_bug.cgi?id=1074791#c28

Comment 1

[Jonathan Hao (inactive) [:jhao]]

This problem could relate to Bug 1097447, because seek is essentially a pause followed by a play.

Comment 2

[Jonathan Hao (inactive) [:jhao]]

The logs show that the decoder state machine was stuck in DECODER_STATE_BUFFERING, and the HasLowUndecodedData() always returned true. It never gets enough undecoded data, so it waits for a 30 second timeout. See also Bug 1093020.

I think this bug may be blocked by or even a duplicate of a bug Benjamin filed a few days ago, Bug 1104413, in which the GetBuffered function will be implemented.

Comment 3

[Jonathan Hao (inactive) [:jhao]]

Attachment: Return NS_ERROR_NOT_IMPLEMENTED in RtspOmxReader::GetBuffered

Currently, RtspOmxReader::GetBuffered() is not implemented, but returns NS_OK. Therefore, there's always not enough undecoded data. In this patch, the function returns NS_ERROR_NOT_IMPLEMENTED instead, so that the NS_ENSURE_SUCCESS will make HasLowUndecodedData() return false, see 
http://dxr.mozilla.org/mozilla-central/source/dom/media/MediaDecoderStateMachine.cpp?from=mediadecoderstatemachine.cpp#1939

Hi Alissa, please check if this patch solves the bug.

Comment 4

[Alissa（leave from Mozilla）]

Hi Hubert，
According to commen 3, could you help to provide a build for us to verify.

Comment 5

[Benjamin Chen [:bechen]]

Comment on attachment 8531742 [details] [diff] [review]
Return NS_ERROR_NOT_IMPLEMENTED in RtspOmxReader::GetBuffered

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

Please help to modify the RtspMediaCoderReader::GetBuffered as well.

Comment 6

[Jonathan Hao (inactive) [:jhao]]

Attachment: Return NS_ERROR_NOT_IMPLEMENTED in RtspOmxReader/RtspMediaCodecReader::GetBuffered()

Comment 7

[Jonathan Hao (inactive) [:jhao]]

https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=3056c357e018

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/b2g-inbound/rev/d991e83fd0ee

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/d991e83fd0ee

Comment 10

[Alissa（leave from Mozilla）]

This issue has been failed verified on Flame 2.1
Reproducing rate: 0/5
Flame 2.1 build
Gaia-Rev        6af3d029bae3a14f400fec0926f0f8ad7b579b4b
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/39eaa987093b
Build-ID        20141221001202
Version         34.0

Comment 11

[Alissa（leave from Mozilla）]

Attachment: logcat.txt

Comment 12

[Jonathan Hao (inactive) [:jhao]]

Hi Alissa, I'm not sure what info you want me to provide. Could you elaborate on it? Do you want to uplift this patch to 2.1?

Thanks.

Comment 13

[Alissa（leave from Mozilla）]

This issue still exist on flame2.1,so maybe there need some more modify.

Comment 14

[Alissa（leave from Mozilla）]

Hi Jonathan,
Sorry for type on comment 10, this bug is not fixed on latest build, Reproducing rate should be 5/5.

Comment 15

[Jonathan Hao (inactive) [:jhao]]

It seems I didn't solve the problem completely. I used to test on this stream
rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov
and it doesn't have this problem, but when I tried other streams, if I pressed enough pause and play fast, the loading circle will come up, and when loading finished the video stays in paused state. It won't start playing even if I press play.

I can always reproduce it on this stream rtsp://10.247.24.86/t-mobile.mp4

I will look into the cause.

Comment 16

[Jonathan Hao (inactive) [:jhao]]

I can reproduce this bug on this HTTP stream too. 
http://10.247.24.86/t-mobile.mp4

After pressing pause and play fast and continuously for several seconds, the video froze. As I continue to press pause and play, the button's appearance did change accordingly (|| in paused state, and |> in playing state), and logs indicated that the state of decoder also did change accordingly, but the video just won't keep going.

The problem doesn't seem to be in the RTSP component, but more likely a timing issue of the decoder state machine. Hence, I will file another bug blocking this one.