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

RESOLVED WONTFIX

Status

Firefox OS
RTSP
RESOLVED WONTFIX
4 years ago
5 months ago

People

(Reporter: jhao, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
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

4 years ago
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. :)
(Reporter)

Updated

4 years ago
Summary: [RTSP] Clear the queue of access units in RTSPSource::performPlaybackEnded() → [RTSP] Re-play after EOS doesn't work sometime
(Reporter)

Comment 2

4 years ago
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)
(Reporter)

Comment 3

4 years ago
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.
(Reporter)

Comment 4

4 years ago
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

4 years ago
*** 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?

Comment 7

4 years ago
(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

4 years ago
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

5 months ago
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 5 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.