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?

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.

Okay - that sounds bad then. We shouldn't be locking up when we seek to an already buffered location.

It blocks 1.4 feature.

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.

ni Ben, can you help to take this?

ni William to verify

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

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