1090838 - [RTSP] Re-play after EOS doesn't work sometime

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: RTSP, defect)

Description

[Jonathan Hao (inactive) [:jhao]]

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

Comment 1

[Ethan Tseng [:ethan]]

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. :)

Comment 2

[Jonathan Hao (inactive) [:jhao]]

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)

Comment 3

[Jonathan Hao (inactive) [:jhao]]

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.

Comment 4

[Jonathan Hao (inactive) [:jhao]]

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().

Comment 5

[Ethan Tseng [:ethan]]

*** 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.

Comment 6

[Benjamin Chen [:bechen]]

(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?

Comment 7

[Ethan Tseng [:ethan]]

(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.

Comment 8

[Ethan Tseng [:ethan]]

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.

Comment 9

[BMO Automation]

Firefox OS is not being worked on