600706 - HTML5 WebM seeking causes video playback stalls

Status: RESOLVED FIXED

Description

[Atul]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)
Build Identifier: Firefox 4.0 beta

If I open a page with an html5 webm video, start playback, and then seek to some different time using the player progress bar, then the video seems to stall for a long time. Additionally, if I play this from youtube and switch to 720p content, this causes a stall as well.



Reproducible: Always

Steps to Reproduce:
1. Install the latest firefox 4 beta (I installed the latest nightly from nightly.mozilla.org)
2. I'm using an NVIDIA GPU and a driver that supports 3DVision, but I'm not certain that this hardware config is specifically needed.
3. Go to www.youtube.com/html5 and join the html5 beta
4. Go to http://www.youtube.com/watch?v=lyUhAUjw-pU
5. It should say html5 and webm in the part below the player progress bar
6. Once the video starts playing, seek to some location on the progress bar, and notice that the video pauses for a long time
7. Alternatively, click on the 720p button and notice that the video refuses to resume playing
8. If I take a webm video on my local disk, embed this in an html page using <video>, and open this page in the browser, then I can reproduce the same problem as in (6) with seeking. Additionally, if I right click and go to fullscreen, I see a similar pause for several seconds before playback resumes.

Actual Results:  
Explained in the repro steps.

Expected Results:  
There should be no stalls during seeking, fullscreen toggle or during a switch from 360p to 720p (youtube)

Comment 1

[Matthew Gregan [:kinetik]]

I don't think I can reproduce this locally.

Switching to and from "fullscreen" (full window mode) is instant, as I'd expect because they're resizing the existing video element.  Using Firefox's built-in fullscreen (if you've found a way to get to that) will have a short delay as it creates a new video element and seeks to the current time before starting playback.

Seeking to an unbuffered part of the video takes around 3 seconds for me.  Switching from 360p to 720p aftering testing the seeking takes around 6 seconds for me (~3s to load the new video, ~3s to seek to the same time as the 360p version was at).  Both of these times seem reasonable to me.  What kind of delays are you seeing?  Is it taking a long time to seek, or is it seeking and then pausing to buffer afterwards?

Comment 2

[Atul]

(In reply to comment #1)
> I don't think I can reproduce this locally.
> Switching to and from "fullscreen" (full window mode) is instant, as I'd expect
> because they're resizing the existing video element.  Using Firefox's built-in
> fullscreen (if you've found a way to get to that) will have a short delay as it
> creates a new video element and seeks to the current time before starting
> playback.
> Seeking to an unbuffered part of the video takes around 3 seconds for me. 

When I seek while playing youtube html5 webm content (I pasted the link in the bug repro steps), I see a stall of > 30 seconds before playback resumes.

When you tried this, did you see the html5 and webm tags show up in the area below the progress bar?

> Switching from 360p to 720p aftering testing the seeking takes around 6 seconds
> for me (~3s to load the new video, ~3s to seek to the same time as the 360p
> version was at).  Both of these times seem reasonable to me.  What kind of
> delays are you seeing?  Is it taking a long time to seek, or is it seeking and
> then pausing to buffer afterwards?

When I clicked on the 720p link, it took ~20 seconds before resuming.

I'm using an AMD Athlon 2.2G CPU, 1GB RAM, Windows7 (forgot to mention in the bug details)

Comment 3

[Matthew Gregan [:kinetik]]

(In reply to comment #2)
> When I seek while playing youtube html5 webm content (I pasted the link in the
> bug repro steps), I see a stall of > 30 seconds before playback resumes.
> 
> When you tried this, did you see the html5 and webm tags show up in the area
> below the progress bar?

It does, yes.  I'm testing against the URL you provided just in case it's specific to that video.

> When I clicked on the 720p link, it took ~20 seconds before resuming.

How long does it take for the video to load and start playing when you first visit the page?

How fast is your connection and what's the latency to YouTube like?  Try pinging youtube.com and paste the results in the bug--it's not a perfect test, since the video is served by a (hopefully) local content distribution server, but pinging youtube.com will at least give us a baseline.

Another thing to test: open the page, wait for the video to load, then right click on a blank part of the page and select "View Page Info".  Select the media tab, then scroll down in the list until you find the video URL (will contain youtube.com/videoplayback).  Select it in the list, then copy and paste the full URL from the location into a new tab.  Once the video loads there, right click on it and select "Save Video As".  Once it finishes download, open the local copy and test seeking to see if it's still very slow for you.

Comment 4

[Matthew Gregan [:kinetik]]

Once you've found the video URL, you could try pinging that hostname to measure the actual latency to your local CDN server.  For example, for me I'd ping v11.lscache1.c.youtube.com and see the average RTT is around 40ms.

Comment 5

[Atul]

> How long does it take for the video to load and start playing when you first
> visit the page?

Pretty fast. It first loads in about 1 or 2 seconds

> How fast is your connection and what's the latency to YouTube like?  Try
> pinging youtube.com and paste the results in the bug--it's not a perfect test,
> since the video is served by a (hopefully) local content distribution server,
> but pinging youtube.com will at least give us a baseline.

Gives me 54ms whenI ping youtube.com, so connection speed seems pretty good.

> Another thing to test: open the page, wait for the video to load, then right
> click on a blank part of the page and select "View Page Info".  Select the
> media tab, then scroll down in the list until you find the video URL (will
> contain youtube.com/videoplayback).  Select it in the list, then copy and paste
> the full URL from the location into a new tab.  Once the video loads there,
> right click on it and select "Save Video As".  Once it finishes download, open
> the local copy and test seeking to see if it's still very slow for you.

Seemed to be crashing when I tried to open it. I'll try some other clip and let you know what I see.

Comment 6

[Atul]

(In reply to comment #4)
> Once you've found the video URL, you could try pinging that hostname to measure
> the actual latency to your local CDN server.  For example, for me I'd ping
> v11.lscache1.c.youtube.com and see the average RTT is around 40ms.

It was v11.lscache1.c.youtube.com for me as well. RTT was reported as 1ms.

Comment 7

[Atul]

Matthew, in order to remove the dependency on the network, I added the following html to a page and loaded that page in ff4. (testfile is a placeholder name)

<video src="testfile.webm" width="800" height="600" controls="PlayControls" loop autoplay>

When I open ths page to start playback, and then seek, I see the long stall again. I'm wondering if there is some variable here that is unaccounted for. I uninstalled firefox and removed all personalized settings, but doesn't help. Also tried ff4 beta 6, same result.

During a seek, is there some condition that might maybe cause a spin? I'm wondering if I'm possibly hitting something like that?

Thanks.

Comment 8

[Chris Pearce (:cpearce)]

(In reply to comment #7)
> During a seek, is there some condition that might maybe cause a spin? I'm
> wondering if I'm possibly hitting something like that?

Do you see the video frame change when you seek, but you then have to wait for some time before playback starts? That sounds the same as bug 598140 - which we also can't reproduce locally. :(

Comment 9

[Atul]

(In reply to comment #8)
> Do you see the video frame change when you seek, but you then have to wait for
> some time before playback starts? That sounds the same as bug 598140 - which we
> also can't reproduce locally. :(

Yes, that sounds like the same issue. When I seek, the video frame changes but I have to wait for a while before playback resumes. With the 360p to 720p switch from youtube, seems like it never resumes, but that might just be a manifestation of the same problem.

Comment 10

[Chris Pearce (:cpearce)]

(In reply to comment #9)
> (In reply to comment #8)
> > That sounds the same as bug 598140
> 
> Yes, that sounds like the same issue. When I seek, the video frame changes but
> I have to wait for a while before playback resumes. With the 360p to 720p
> switch from youtube, seems like it never resumes, but that might just be a
> manifestation of the same problem.

Ok, if you seek to N seconds into the media, and you have to wait for N seconds for playback to begin after the frame changes, then it's the same.

Comment 11

[Chris Pearce (:cpearce)]

Atul: do you have sound disabled on your system? Or are you testing a video which doesn't have sound? I've discovered that I can only reproduce bug 598140 if I've got sound disabled.

Comment 12

[Atul]

(In reply to comment #11)
> Atul: do you have sound disabled on your system? Or are you testing a video
> which doesn't have sound? I've discovered that I can only reproduce bug 598140
> if I've got sound disabled.

I don't have an audio device connected, so yes, I have sound disabled. I'm pretty sure the videos I was testing had sound, though, since most of them were from youtube. Tried on another machine that has an audio device and it seems to work fine there. So looks like there is a correlation.

Comment 13

[Atul]

Chris, I noticed that there was a fix ready for checkin in bug 598140. I'll give this another try once that fix lands.

Thanks!

Comment 14

[Chris Pearce (:cpearce)]

Atul: I've landed the patch for bug 598140, would you be able to check that the issue you reported here is fixed? If it's not, please change the status of this bug to REOPENED. Thanks very much!

Comment 15

[Atul]

(In reply to comment #14)
> Atul: I've landed the patch for bug 598140, would you be able to check that the
> issue you reported here is fixed? If it's not, please change the status of this
> bug to REOPENED. Thanks very much!

Thanks Chris. I can confirm with local file playback (local test html page) that the seeking issues seem to be resolved. However I cannot get youtube to go into html5 + webm for some reason, so I cannot tell if that works as expected. Do the youtube links I posted earlier link to the html5 webm content for you, or does it default to the flash player?

Thanks.

Comment 16

[Chris Pearce (:cpearce)]

(In reply to comment #15)
> Do the youtube links I posted earlier link to the html5 webm content for you,
> or does it default to the flash player?

Yup, those videos work as expected in last night's nightly, with sound both enabled and disabled.

Comment 17

[Atul]

(In reply to comment #16)
> Yup, those videos work as expected in last night's nightly, with sound both
> enabled and disabled.

Ok, thanks. So I guess the switch to flash must be a recent thing then (as of 10 mins back, I couldn't get YT to link to the html5 webm content).