When played to the end-of-stream, the state is changed to CONNECTED, and RTSPSource::onTrackDataAvailable() stops calling dequeue, so there may still be something left in the queue. They should be cleaned up to avoid problems with replaying. Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=1088538#c11 https://bugzilla.mozilla.org/show_bug.cgi?id=1021006#c12

Jonathan, thanks for filing this bug. Please note the intent of this bug is to make sure "re-play after EOS" works well and smoothly. As we observed, sometimes the re-play suffers a longer period of time to start playing, sometimes it even fails to play at all. Cleaning up the access unit queue in RTSPSource::performPlaybackEnded() is just one potential solution. Don't be limited if you come up with better ideas while solving the problem. :)

Most of the time, if we try to re-play after end-of-stream, it just keeps loading and never plays. Sometimes, it does play. Rarely, it crashes after end-of-stream. Here is the gdb backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 11546.12325] 0xb4a955f6 in android::AnotherPacketSource::read (this=0xaefcfd40, out=0xb4692024 <android::gLooperRoster+4>) at frameworks/av/media/libstagefright/mpeg2ts/AnotherPacketSource.cpp:125 125 CHECK(buffer->meta()->findInt64("timeUs", &timeUs)); (gdb) bt #0 0xb4a955f6 in android::AnotherPacketSource::read (this=0xaefcfd40, out=0xb4692024 <android::gLooperRoster+4>) at frameworks/av/media/libstagefright/mpeg2ts/AnotherPacketSource.cpp:125 #1 0xaeebdc80 in ?? () #2 0xaeebdc80 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb)

I found that sometimes the handler sends an extra PLAY request after EOS (I didn't press re-play button). I'm not sure if this's related to the re-play problem.

I think I observe the symptom of https://bugzilla.mozilla.org/show_bug.cgi?id=1021006#c12 One call to RTSPSource::play() happened after performPlaybackEnded().

*** Work note *** I added some logs around the class RtspTrackBuffer and found something unusual. While re-playing after EOS: 1. WriteBuffer() is called on track index 1 (audio), but not called on track index 0 (video). 2. ReadBuffer() is never called on both tracks.

(In reply to Ethan Tseng [:ethan] from comment #5) > *** Work note *** > I added some logs around the class RtspTrackBuffer and found something > unusual. > While re-playing after EOS: > 1. WriteBuffer() is called on track index 1 (audio), but not called on track > index 0 (video). > 2. ReadBuffer() is never called on both tracks. Could you confirm the ReadBuffer() function is "never called" or had called once but start waiting at the monitor because some track has no data?

(In reply to Benjamin Chen [:bechen] from comment #6) > (In reply to Ethan Tseng [:ethan] from comment #5) > > *** Work note *** > > I added some logs around the class RtspTrackBuffer and found something > > unusual. > > While re-playing after EOS: > > 1. WriteBuffer() is called on track index 1 (audio), but not called on track > > index 0 (video). > > 2. ReadBuffer() is never called on both tracks. > > Could you confirm the ReadBuffer() function is "never called" or had called > once but start waiting at the monitor because some track has no data? I checked again. When the bug occurs, ReadBuffer() is called once on trackIdx 0 (video) before any WriteBuffer() is called. After that, WriteBuffer() is called only on trackIdx 1 (audio). But ReadBuffer() is not called anymore.

Jonathan and Benjamin, When the bug is occurring, RtspTrackBuffer::WriteBuffer() on trackIdx 0 keeps returning at this line: http://dxr.mozilla.org/mozilla-central/source/dom/media/RtspMediaResource.cpp#322 In the beginning of seek operation, RtspMediaResource::SeekTime() raises the frame type MEDIASTREAM_FRAMETYPE_DISCONTINUITY for each track. When RTSP network stack completes the seek operation, it will send an artificial frame with this special frame type "discontinuity" to notify RtspTrackBuffer that the track is ready to receive data. From logs we can see RTSPSource::onTrackDataAvailable() sends discontinuity frame for trackIdx 1 and 2, but not for trackIdx 0. Please note there are totally four tracks in the specific clip we were testing. It's possible that this bug only happens with more than two tracks.

Firefox OS is not being worked on