497182 - Seeking while video is downloading results in a video player hang

Status: VERIFIED WORKSFORME

(Core :: Audio/Video, defect)

Description

[Aaron Train [:aaronmt]]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b99) Gecko/20090604 Firefox/3.5b99

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090609 Shiretoko/3.5pre

Seeking while video is downloading *in some cases* places the video player in a hanging state (i.e, spinning throbber, play/pause do nothing, seeking does nothing).

For example, I just did a tiny seek here - very little of the video has been downloaded http://i39.tinypic.com/zwgqs9.png

Comment 1

[Aaron Train [:aaronmt]]

Tested on a Windows 7 machine here too

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1pre) Gecko/20090609 Shiretoko/3.5pre (.NET CLR 3.5.30729)

Duplicate results

Comment 2

[Aaron Train [:aaronmt]]

Related? bug 494305

Comment 3

[Simon Bünzli]

(In reply to comment #0)
> Seeking while video is downloading *in some cases* places the video player in
> a hanging state

... until the video has been downloaded up to where you've tried to seek, in which case it reverts to behave normally.

Comment 4

[Aaron Train [:aaronmt]]

(In reply to comment #3)
> (In reply to comment #0)
> > Seeking while video is downloading *in some cases* places the video player in
> > a hanging state
> 
> ... until the video has been downloaded up to where you've tried to seek, in
> which case it reverts to behave normally.

I have the tab still open for the past hour and a half and it's still hanging.

Comment 5

[Chris Pearce [:cpearce (Not reading bugmail)]]

These situations are hard to diagnose. Are you seeking inside time ranges which the progress bar reports as buffered? The progress bar is actually inaccurate, so if you seek close to the end of the time range which the progress bar reports as buffered, it might actually not be, and so we may need to do HTTP requests to do the seek, which can be slow. The progress bar will be able to report the correct buffered time ranges once bug 462957 is fixed (won't be in for FF3.5).

Also, that video is hosted on Amazon S3. I've found that the network performance of videos hosted there is inconsistent, and often very bad, which could also explain why you're getting slow seeks on that video. Especially if S3 drops a connection. I'm not sure how we handle that.

I've been meaning to find myself an easy to modify web server and start testing with sensible non-bursty rate-limiting and dropping connections, this is probably a good excuse to do that.

Comment 6

[Aaron Train [:aaronmt]]

(In reply to comment #5)
> These situations are hard to diagnose. Are you seeking inside time ranges which
> the progress bar reports as buffered? The progress bar is actually inaccurate,
> so if you seek close to the end of the time range which the progress bar
> reports as buffered, it might actually not be, and so we may need to do HTTP
> requests to do the seek, which can be slow. The progress bar will be able to
> report the correct buffered time ranges once bug 462957 is fixed (won't be in
> for FF3.5).
> 
> Also, that video is hosted on Amazon S3. I've found that the network
> performance of videos hosted there is inconsistent, and often very bad, which
> could also explain why you're getting slow seeks on that video. Especially if
> S3 drops a connection. I'm not sure how we handle that.
> 
> I've been meaning to find myself an easy to modify web server and start testing
> with sensible non-bursty rate-limiting and dropping connections, this is
> probably a good excuse to do that.

Yeah unfortunately alot of the HTML5 vid tests are being done solely on this tinyvid website which is not good.

Comment 7

[cajbir (:cajbir)]

Yes, think of the poor soul who has to pay the bandwidth bill for all that testing :-)

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #5)
> I've been meaning to find myself an easy to modify web server and start testing
> with sensible non-bursty rate-limiting and dropping connections, this is
> probably a good excuse to do that.

Why don't you do this with httpd.js? See http://mxr.mozilla.org/mozilla-central/find?text=&kind=text&string=httpd.js

Comment 9

[cmtalbert]

(In reply to comment #5)

> I've been meaning to find myself an easy to modify web server and start testing
> with sensible non-bursty rate-limiting and dropping connections, this is
> probably a good excuse to do that.
Didn't Dolske mock up some kind of buffered video server using httpd.js and some php?  CCing him.

Comment 10

[Justin Dolske [:Dolske]]

Yeah, I wrote a little PHP script to dribble out data at fixed rates and stall at specified points.

See http://dolske.net/mozilla/tests/video/tests.html (live) or http://dolske.net/mozilla/tests/video/slowsend.php.txt (source)

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+2]]

See a similar bug which is a regression on 1.9.2: bug 518125.

Comment 12

[Chris Pearce [:cpearce (Not reading bugmail)]]

WFM.