* Description: Tap "PLAY" button cannot get any response after the seekbar returns to 00:00 Attach the demo video and log - WP_20140506_001.mp4 - RTSP_20140505.log * Reproduction steps: 1. Launch the following page via browser - http://goo.gl/FyHFNs 2. Tap the "AMX test file" 3. Waiting for ending RTSP streaming 4. After the seekbar returns to 00:00, please press "PLAY" button * Expected result: You can replay RTSP streaming * Actual result: No response * Reproduction build: V2.0 (Buri) - Gaia e8a08a3f7a608993f0b302371e016e73faceea70 - Gecko https://hg.mozilla.org/mozilla-central/rev/2897fb554990 - BuildID 20140505160203 - Version 32.0a1

RTSP media resource will be destructed after the end of streaming. The 2nd round play should trigger the initialization of RTSP media resource again, but somehow it didn't. I will look into this issue.

Block 2.0 release.

Start debugging for this.

When the first play ended, we receive tear down from server then trigger the "OnDisconnected" event. RtspMediaResource::OnDisconnected -> mDecoder->ResetConnectionState -> MediaDecoder::Shutdown We shutdown the mediaResource, decoder, etc... Then the play command through HTMLMediaElement tries to reload the resource, decoder but failed. Because the HTMLMediaElement doesn't have the attribute "src" since it is load from a channel. Load fail: http://dxr.mozilla.org/mozilla-central/source/content/html/content/src/HTMLMediaElement.cpp?from=htmlmediaelement.cpp#783 src attribute: http://dxr.mozilla.org/mozilla-central/source/content/html/content/public/HTMLMediaElement.h?from=htmlmediaelement.h#89 So, a feasible solution is that in MediaDecoder::ResetConnectionState we do not call shutdown(). But it will involve some leak issues we had resolved before. We need to check it carefully.

In order to fix this, not only the shutdown codes need to be fixed, but also need to ensure the states in MediaDecoder, HTMLMediaElement, MediaDecoderStateMachine are in the right state. It will be a complex fix.... Bug 951278 block this because the "end of stream" effect these states.

It would be a problem for user's usage. We need to fix it in 2.0.

Hi sworkman, I am going to land bug 951278, because it eases the difficulty to fix this bug. We still need to do some minor modifications to make replay work. First, the conditional check for mState in RTSPSource::performSeek should include mState == CONNECTED. RtspController receives seek(0) command if user press the play at the end of stream circumstance. Second, we should not close RTP/RTCP sockets immediately. Leave them open until RtspController is released.

Comment on attachment 8425298 [details] [diff] [review] Patch v1.0 Review of attachment 8425298 [details] [diff] [review]: ----------------------------------------------------------------- OK, looks good to me. r=me.

Rebase the patch.

Using audio RTSP streaming to verify it. Cannot reproduce it on latest V2.0 build. But, while I play video RTSP streaming of Youtube, built-in media player always shows a network error message ( Bug 1021006 ). * Build information: - Gaia 8d865839d932bfbd5e157f376f74d8cb12bfdd51 - Gecko https://hg.mozilla.org/releases/mozilla-aurora/rev/1d4046a8cb6c - BuildID 20140610000223 - Version 32.0a2