Closed Bug 1049235 Opened 7 years ago Closed 7 years ago

[MADAI][Multimedia] Some RTSP link does not operate seek function.

Categories

(Firefox OS Graveyard :: RTSP, defect)

defect
Not set
normal

Tracking

(tracking-b2g:backlog, b2g-v2.0 affected, b2g-v2.1 affected)

RESOLVED FIXED
2.1 S2 (15aug)
tracking-b2g backlog
Tracking Status
b2g-v2.0 --- affected
b2g-v2.1 --- affected

People

(Reporter: jaemin1.song, Assigned: ethan)

Details

(Whiteboard: [ LibGLA, dev , B ] [p=3])

Attachments

(1 file, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36

Steps to reproduce:

Execute web browser and play RTSP Streaming link.
1. To play RTSP link, connect "rtsp://125.141.31.147:554/QE/Coverage20130826/R003_3gp_mpeg4(sp@l1@qvga@452kbps@15fps)_aac-lc(96kbps@32khz@2ch).3gp"
2. While playing RTSP link, operate seek function.


Actual results:

(This case is separated from Bug 1043024.)
If you try to reproduce,
seek function will be not worked.
blocking-b2g: --- → 2.0?
Whiteboard: [ LibGLA, dev , B ]
QA Wanted to see if we can reproduce this on Flame.
Keywords: qawanted
Issue is reproducible on Flame 2.0.

Observed behavior: When playing the provided link via Browser, and attempt to use the Seek bar, the player will display a loading icon, but it does not actually load after waiting for a minute. User needs to refresh browser in order to view the video again.

Also If I wait for the video to finish playing, and attempt to rewind using the Seek bar, Firefox OS will crash (device displays the Firefox animation and reboots)

Tested on:
Device: Flame (512MB mem)
BuildID: 20140805164926
Gaia: 5ba22d458fdb63bd72c59de53c701d0efe35c1e2
Gecko: 6fbc60a80c6d
Version: 32.0 (2.0)
Firmware: V122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Contact: pcheng
QA-Wanted for Branch checks
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Issue occurs on Flame 2.1 and Buri 2.0.

Observed behavior: Same as comment 2.

Tested on:
Device: Flame
BuildID: 20140806054320
Gaia: 5e6ef81cb9e917657ce050f598229dfc83c58b8f
Gecko: bdf301b20cab
Version: 34.0a1 (Master)
Firmware V123
User Agent Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Device: Buri
BuildID: 20140806084615
Gaia: 47fa0ba8197e71cc7034943ff037642e7f35cdfe
Gecko: 4feed2803746
Version: 32.0 (2.0)
Firmware v1.2device.cfg
User Agent Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

------------

In Flame 1.4 the Browser displays a blank page when attempting to access the URL. I used TinyURL to access this link, so I thought maybe it's TinyURL's problem. I then handtyped the whole URL to my Browser and accessed it - device then displays a notification saying that 'Download started', but if I go to Downloads in Settings, nothing is being listed there. It looks like this file isn't being recognized in 1.4 at all.

Device: Flame
BuildID: 20140806081546
Gaia: e9dce1f60f729e228810f751417681b5ff937b6b
Gecko: d281a3bdfea6
Version: 30.0 (1.4)
Firmware V122
User Agent Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
not a regression
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
I can reproduce this bug on Flame v2.1 too.
RTSP seek function works for other video clips but not for this one. I will look into this issue.
Assignee: nobody → ettseng
blocking-b2g: 2.0? → 2.0+
The root cause is found. It's about NPT (Normal Play Time) range.
I captured packets to observe client-server behavior of this particular video.

C->S: PLAY rtsp://125.141.31.147/QE/Coverage20130826/R003_3gp_mpeg4(sp@l1@qvga@452kbps@15fps)_aac-lc(96kbps@32khz@2ch).3gp RTSP/1.0\\r\\n
      Session: 2460823137
      Range: npt=0-\r\n
      CSeq: 4\r\n

S->C: Response: RTSP/1.0 200 OK\r\n
      CSeq: 4\r\n
      Session: 2460823137
      Range: npt=0.0000-\r\n

Because the server doesn't specify the end time in the PLAY response, our client treats this session as a live stream and non-seekable. That's why the seek operation doesn't work for this video streaming.
However I also notice that both VLC desktop and Android phone could still execute seek operation on this video clip. Need more investigation to find out how they did that.


=== Reference about NPT ===
NPT is defined in section 3.6 in RFC 2326 (http://tools.ietf.org/html/rfc2326#page-17).
"Normal play time (NPT) indicates the stream absolute position relative to the beginning of the presentation."

RFC also says (section 10.5 PLAY):
"The PLAY request positions the normal play time to the beginning of the range specified and delivers stream data until the end of the range is reached."
...
"For a on-demand stream, the server replies with the actual range that will be played back."
Attached patch Fix parseNTPRange (obsolete) — Splinter Review
Modify the logic in parseNTPRange(), which is called to determine live stream in parsePlayResponse().
If the end time is not specified in the PLAY response, we could treat it as playing until the end of the clip.
Attachment #8469904 - Flags: feedback?(bechen)
Comment on attachment 8469904 [details] [diff] [review]
Fix parseNTPRange

Review of attachment 8469904 [details] [diff] [review]:
-----------------------------------------------------------------

As we discussed offline, the patch might have some affection to live stream. Please have a try.
And during this case, the |mSeekable| is changed to false but the UI still can perform a seek operation, that means the change of mSeekable doesn't propagate to our "media codes" (MediaDecoder::SetDuration), it might be another bug.
Attachment #8469904 - Flags: feedback?(bechen)
Reference: bug 1003037.
We don't support live stream over RTSP right now.
Whiteboard: [ LibGLA, dev , B ] → [ LibGLA, dev , B ] [p=1]
Target Milestone: --- → 2.1 S2 (15aug)
Whiteboard: [ LibGLA, dev , B ] [p=1] → [ LibGLA, dev , B ] [p=3]
(In reply to Benjamin Chen [:bechen] from comment #9)
> Comment on attachment 8469904 [details] [diff] [review]
> As we discussed offline, the patch might have some affection to live stream.
> Please have a try.
> And during this case, the |mSeekable| is changed to false but the UI still
> can perform a seek operation, that means the change of mSeekable doesn't
> propagate to our "media codes" (MediaDecoder::SetDuration), it might be
> another bug.

Thanks for your input.
I will setup a streaming server to generate (emulate) live stream over RTSP and do further research on this issue.
[Blocking Requested - why for this release]:
Based on comment 7, I wonder if this bug is really a blocker.
blocking-b2g: 2.0+ → 2.0?
This is not a regression, so triage decided to not block 2.0 on fixing this.
blocking-b2g: 2.0? → backlog
(In reply to Benjamin Chen [:bechen] from comment #9)
> Comment on attachment 8469904 [details] [diff] [review]
> As we discussed offline, the patch might have some affection to live stream.
> Please have a try.

I verified live stream using DarwinStreamingServer.

C->S: PLAY rtsp://10.247.24.86/TestLiveStream.sdp/ RTSP/1.0\r\n
      CSeq: 6\r\n
      Range: npt=0.000-\r\n

S->C: Response: RTSP/1.0 200 OK\r\n
      CSeq: 6\r\n
      Range: npt=now-\r\n

In live stream, the NPT field value carried in PLAY response is "now-".
So I think my patch wouldn't affect the case of live stream.
Comment on attachment 8469904 [details] [diff] [review]
Fix parseNTPRange

Hi Steve,
This is a minor patch.
Please see comment 7 and comment 8 describing the root cause and solution.
Attachment #8469904 - Attachment description: bug-1049235-wip.patch → Fix parseNTPRange
Attachment #8469904 - Attachment filename: bug-1049235-wip.patch → bug-1049235-fix.patch
Attachment #8469904 - Flags: review?(sworkman)
Comment on attachment 8469904 [details] [diff] [review]
Fix parseNTPRange

Review of attachment 8469904 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good. r=me.
Attachment #8469904 - Flags: review?(sworkman) → review+
(In reply to Steve Workman [:sworkman] from comment #17)
> Comment on attachment 8469904 [details] [diff] [review]
> Fix parseNTPRange 
> Review of attachment 8469904 [details] [diff] [review]:
> -----------------------------------------------------------------
> Looks good. r=me.

Thanks, Steve.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Keywords: checkin-needed
Refresh comment "r=sworkman".
Attachment #8469904 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/1d77c5d889e6
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Dear Ethan,

I want to know whether below symptoms in comment 2 is fixed.
[line 5 in comment 2]
"Also If I wait for the video to finish playing, and attempt to rewind using the Seek bar, Firefox OS will crash (device displays the Firefox animation and reboots)"

I had detect same symptoms while testing RTSP Streaming.
Could you let me know whether reboots symptoms is fixed in your patch?

If reboot symptoms is not fixed, I will open another case.

Thanks.
Flags: needinfo?(ettseng)
(In reply to Jaemin Song from comment #22)
> Dear Ethan,
> I want to know whether below symptoms in comment 2 is fixed.
> [line 5 in comment 2]
> "Also If I wait for the video to finish playing, and attempt to rewind using
> the Seek bar, Firefox OS will crash (device displays the Firefox animation
> and reboots)"
> I had detect same symptoms while testing RTSP Streaming.
> Could you let me know whether reboots symptoms is fixed in your patch?
> If reboot symptoms is not fixed, I will open another case.

Oh, it's my mistake. I didn't notice this reboot symptom.
Yes, it does crash we perform re-play on this clip.
Please file a new bug and I'll deal with it ASAP.

Sorry for my carelessness.
Flags: needinfo?(ettseng)
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.