1095329 - [RTSP] Receiving data but not playing if resume from screen lock after end-of-stream

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: RTSP, defect)

Description

[Jonathan Hao (inactive) [:jhao]]

1. Play a video to end-of-stream.
2. Wait for the screen timeout
3. Unlock the screen

Actual situation:
Started receiving packets from server(May have wrongly sent a PLAY request). Cannot replay by pressing the play button.

Expected situation:
Not receiving packets. Should be able to replay if pressing the play button.

Comment 1

[Jonathan Hao (inactive) [:jhao]]

The log shows that the extra PLAY comes from a seek in MediaDecoder::MetadataLoaded().

Comment 2

[Jonathan Hao (inactive) [:jhao]]

Attachment: Work-in-progress patch

This patch can solve the problem that data keep coming in, and makes the decoder go to COMPLETE state. However, the browser will crash after pressing play button to replay. Still looking into the cause.

Comment 3

[Jonathan Hao (inactive) [:jhao]]

Attachment: Work-in-progress patch

After replay, essentially a seek to time 0, there were several attempts to write buffer with data time near the end. The reason was that when the browser resumed from screen lock, and seek to the end, there were some access units left in the queue.

This patch dequeues the remaining access units when end-of-stream occurs, so there won't be access units left from the previous seek. However, this wasn't the root cause of the crash. As shown in the log of ReadBuffer, there're still malformed data with negative time or unreasonably large time.

Comment 5

[Ethan Tseng [:ethan]]

Jonathan,

When I was performing reproduction steps of this bug on Flame 3.0 (base image 184), instead of system crash you mentioned, I encountered more serious problem -- kernel panic (kernel crash) -- several times. After the media player kept spinning for a short period, the screen suddenly became blank and the adb connection was disconnected. The only thing I can do is to re-install the battery to bring it back.

Have you ever encountered kernel panic when reproducing this bug?

Comment 6

[Jonathan Hao (inactive) [:jhao]]

I have encountered this situation even though I'm not sure if it happened when I was reproducing this bug.
It also happened sometimes when I used flame as my daily phone.

Comment 7

[Jonathan Hao (inactive) [:jhao]]

When I say "as my daily phone," it wasn't RTSP video I was watching. It happened when I was watching youtube video.

Comment 8

[Ethan Tseng [:ethan]]

(In reply to Jonathan Hao [:jhao] from comment #6)
> I have encountered this situation even though I'm not sure if it happened
> when I was reproducing this bug.
> It also happened sometimes when I used flame as my daily phone.

Henry told me that kernel panic occasionally happens on Flame and it's still an unsolved issue. Although it could happen not only when playing RTSP, I am worried that certain behavior of RTSP code raises the chance of kernel panic. But since we don't know the root cause of kernel crash for now, we can do nothing with it.

Which version of base image do you use?
I intend to update my base image from 184 to 188 to see if it helps.

Comment 9

[Jonathan Hao (inactive) [:jhao]]

Unassign myself since I'm not actively working on Firefox OS anymore.

Comment 10

[Ethan Tseng [:ethan]]

RTSP in FxOS is rarely used by users.
Unless there is strong user demand, I don't think anyone will fix this bug.