Closed Bug 965062 Opened 10 years ago Closed 10 years ago

[B2G][RTSP]Dragging slider bar ahead causes video to jump ahead and pause, but the pause symbol does not change into a play symbol to indicate that the video is paused.

Categories

(Firefox OS Graveyard :: RTSP, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(tracking-b2g:backlog)

RESOLVED WORKSFORME
2.0 S2 (23may)
tracking-b2g backlog

People

(Reporter: rkuhlman, Assigned: bechen)

References

Details

(Whiteboard: dogfood1.3)

Attachments

(2 files)

Attached file SkipAheadPauseLog.txt
The device is playing a rtsp video on the browser. If the user manually adjusts the slider bar, the video will jump ahead to the user defined timeslice. The video will be paused at this point, but a pause symbol is visible instead of the play symbol. The user must tap the pause symbol to resume the video.'

Repro Steps:
1) Updated Buri to BuildID: 20140122004001
2) Launch browser and navigate to http://bit.ly/1bsSLUz.
3) Type something into the search bar to populate the website with videos. (I typed 'fail')
4) Start watching a video.
5) Drag the seek bar slider forward.

Actual:
Video jumps ahead to user defined point, and pauses. However the 'pause' symbol does not change into a 'play' symbol to indicate that the video is paused.

Expected:
The video jumps ahead to the user defined point and continues playing.
-OR-
The video jumps ahead and pauses. The 'pause' symbol changes to a 'play' symbol to indicate to the user that the video is now paused.

Environmental Variables:
Device: Buri v1.3 Moz RIL
BuildID: 20140127004002
Gaia: 25a45a836a4a21a30f63fa7b544b42e8b781180a
Gecko: c40099a42c1f
Version: 28.0a2
Firmware Version: v1.2-device.cfg

Notes:

Repro frequency: 100%
See attached: logcat
That's actually not right - when you jump ahead, the video enters a buffering state waiting to get more frames. When it gets more frames, it will resume playing.

After step #5 - does the video eventually start playing if you wait long enough?
Flags: needinfo?(rkuhlman)
This only occurs if you move the slider within the buffered zone. If you drag the scrubber beyond the buffered zone, then the device will perform as you describe. But if you drag the scrubber into an area that is already buffered, the video will enter a paused state. The easiest way I have found to reproduce the issue is to watch a video for about a minute, and then drag the scrubber backwards ~10-15 seconds. The video will be paused and will not resume playing unless prompted by the user. Eventually the screen will lock.

In the scenario you described, the video will resume playing once it has buffered.
Flags: needinfo?(rkuhlman)
Okay - that sounds bad then. We shouldn't be locking up when we seek to an already buffered location.
Blocks: b2g-RTSP-2.0
blocking-b2g: --- → 1.4?
It blocks 1.4 feature.
blocking-b2g: 1.4? → 1.4+
Whiteboard: dogfood1.3 → dogfood1.3 [FT:RIL]
No longer going to block - RTSP video needs to be preffed off in 1.4 per a drivers decision to cut scope to only DSDS & QC required features.
blocking-b2g: 1.4+ → 1.4?
blocking-b2g: 1.4? → backlog
ni Ben, can you help to take this?
Flags: needinfo?(bechen)
Flags: needinfo?(bechen)
QA Contact: bechen
Assignee: nobody → bechen
QA Contact: bechen
Component: Video/Audio → RTSP
Product: Core → Firefox OS
Target Milestone: --- → 2.0 S2 (23may)
ni William to verify
Flags: needinfo?(whsu)
Whiteboard: dogfood1.3 [FT:RIL] → dogfood1.3
(In reply to rkuhlman from comment #2)
> This only occurs if you move the slider within the buffered zone. If you
> drag the scrubber beyond the buffered zone, then the device will perform as
> you describe. But if you drag the scrubber into an area that is already
> buffered, the video will enter a paused state. The easiest way I have found
> to reproduce the issue is to watch a video for about a minute, and then drag
> the scrubber backwards ~10-15 seconds. The video will be paused and will not
> resume playing unless prompted by the user. Eventually the screen will lock.
> 
> In the scenario you described, the video will resume playing once it has
> buffered.

I cannot reproduce this bug on latest V2.0 build. (Attach the video - WP_20140521_008.mp4)
* Build Information:
 - Gaia      c462d9183d294a2d8ecc472f593ea8cfa15bc9de
 - Gecko     https://hg.mozilla.org/mozilla-central/rev/9d8d16695f6a
 - BuildID   20140520160203
 - Version   32.0a1

By the way, I feel confused regarding the buffered zone you mentioned.
As I known, built-in media player doesn't have buffered zone on UI while you play RTSP streaming.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(whsu)
Resolution: --- → WORKSFORME
Attached video WP_20140521_008.mp4
(In reply to William Hsu [:whsu] from comment #8)
> I cannot reproduce this bug on latest V2.0 build. (Attach the video -
> WP_20140521_008.mp4)
> By the way, I feel confused regarding the buffered zone you mentioned.
> As I known, built-in media player doesn't have buffered zone on UI while you
> play RTSP streaming.

I cannot reproduce it on v2.0 either.
Maybe this issue was fixed somewhere else after v1.3?

Besides, the buffered zone mentioned in comment 2 depends on the implementation of media buffer/cache.
AFAIK, our RTSP media implementation doesn't provide this information, which means a buffered zone (represents the progressive downloading) should not appear on the seek bar for RTSP media.

rkuhlman,
If you can still reproduce this bug, or can see a buffered zone in RTSP, could you please attach a screenshot or video?
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: