586572 - ogv video freezes and prevents additional seeking

Status: RESOLVED WORKSFORME

(Core :: Audio/Video, defect)

Description

[sdb]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9pre) Gecko/20100808 Ubuntu/10.04 (lucid) Namoroka/3.6.9pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9pre) Gecko/20100808 Ubuntu/10.04 (lucid) Namoroka/3.6.9pre

I was testing an .ogv video in a video element in Firefox and discovered that it would freeze at what seemed like random times (once at the 76.57 second mark according to the currentTime property and once at the 23.28 second mark).  Once frozen I'm unable to seek to a new position.  I've tested the same video url in both FF3.6.9 and FF4.0b4pre and the same problem occurs in both versions.  I've also tested the url in VLC 1.0.6 and haven't encountered any problems so I don't think that the error is in the video itself.  I've posted another url of the same video below that works fine.  Unfortunately I'm not sure what is different between the 2 encodings since the problematic video was auto-generated by archive.org.  The original file was a webm video that was uploaded to archive.org and to this point I haven't encountered any problems with the webm file in FF, only the ogv file freezes.

Original file (works fine):
http://www.archive.org/download/Horror_Express_WebM/horror_express.webm

Converted by archive.org to ogv. It freezes in FF3.6 - 4.0b4.
http://www.archive.org/download/Horror_Express_WebM/horror_express.ogv

A working copy of the video:
http://www.archive.org/download/horror_express_ipod/horror_express.ogv

Reproducible: Always

Steps to Reproduce:

Load the url below into a video element in Firefox. Eventually it will freeze and you will be unable to seek to a new position.  You should be able to simply paste the url into the address bar and press enter to load it.

http://www.archive.org/download/Horror_Express_WebM/horror_express.ogv

Comment 1

[Matthew Gregan [:kinetik]]

I can't reproduce this with nightly trunk builds on Linux (x86_64) or OS X (x86) using video at http://www.archive.org/download/Horror_Express_WebM/horror_express.ogv.  On both platforms I played the video through to the end without an interruption.

How easy is this for you to reproduce?  Does it happen at some point every time you play a video?  How long does it usually take to occur?

Comment 2

[sdb]

I can reproduce this bug every single time that I attempt to load the video.  The webm file and the alternative ogv file seem to work fine and I can even play the problematic ogv file in VLC, but every time I access it remotely through Firefox it freezes.  It usually occurs around the 23 second mark but a few times I've made it to the 46 and 76 second marks before it froze.

Kubuntu 10.04 amd64
KDE 4.4.5
FF 3.6.9 or FF 4.0b4pre

1. Paste the url below into your browser's address bar

http://www.archive.org/download/Horror_Express_WebM/horror_express.ogv

2. You should be redirected to the url below

http://ia360700.us.archive.org/19/items/Horror_Express_WebM/horror_express.ogv

3.  The video should automatically start playing. If it freezes check the currentTime property. It always seems to occur around the 23.28 second mark.

javascript:var vid = document.getElementsByTagName('video')[0]; alert(vid.currentTime);

4. Once frozen I'm unable to restart playback. I can click the pause button and then click play again but nothing happens. I can drag the slider bar to a new position and it will display the loading image but it never begins playing. I've also checked my firewall and it verifies that data is still being received from ip address 207.241.229.59 but I'm still unable to play the video.

Comment 3

[sdb]

Well this is truly strange. I just tested the url again in the latest trunk and the freezing while playing problem seems to be gone but a new problem occurs.  Anytime I try to seek to a new position by dragging the slider bar or by clicking a new position it freezes and never starts playing again.  This seems to happen with all ogv videos.  Not sure what has changed but it's almost the opposite problem of what I encountered before.  Before, the freezing disabled the seeking feature.  Now the seeking seems to cause it to freeze. :?:

v3.6.9pre
https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa

Video from url in previous post still freezes.  Once frozen I'm unable to resume play or to seek to a new position.  Other urls work fine without freezing and I'm able to seek to a new position without problems.

latest trunk
ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/firefox-4.0b4pre.en-US.linux-x86_64.tar.bz2

Video from url above now appears to be working as long as I don't try to jump to a new position. If I do seek to a new position then the video freezes and doesn't start playing again.  The freeze on seeking bug seems to occur with all ogv videos (tested both ogv urls in original post).  Webm videos seem to work fine. No freezing and the seeking works as expected.

Comment 4

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

sdb: does this problem still occur in Firefox 4 nightly builds?

Comment 5

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

I take that as a no.

Comment 6

[sdb]

Sorry for the delay.  I just tested the issue in FF4.0b12pre on Ubuntu 10.10 amd64 and the issue still exists.  The initial report involved the video freezing randomly in FF3.6 but that issue appears to have been resolved in FF4.  The problem now is that I'm unable to seek to a new position.

Steps to reproduce bug:

1. Download and open ff4.0b12pre x86_64

ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/firefox-4.0b12pre.en-US.linux-x86_64.tar.bz2

2. Visit the link below

http://www.archive.org/download/Horror_Express_WebM/horror_express.ogv

3. After it begins playing click on a new position on the slider bar.

4. Video freezes.

I've checked my firewall and can confirm that content continues to be downloaded even though the video has been frozen.  I decided to wait a little longer after the video froze the last time I tested this bug and after about 5 minutes the video finally resumed playing.

This suggests that instead of aborting the downloading of video at the original location and skipping ahead to the new location it continues to download the entire video stream.  It's only when the downloaded video reaches the new time location that it resumes playing.

The video should stop being downloaded as soon as you click on a new location and immediately start downloading at the location on which you clicked.

Comment 7

[sdb]

I forgot to mention that I've also tried disabling all extensions and plugins and it doesn't seem to make any difference.  The bug still occurs with all extensions and plugins disabled.

Comment 8

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

So the following things could be happening:
* We seek in ogg files by doing a bisection search over HTTP, provided the webserver supports HTTP1.1 Byte Range requests. It looks to me like that webserver is advertising that is supports byte range requests, but perhaps your ISP has a cache or proxy in the way messing it up?
* It could be that your connection is very slow, and the bisections are taking a very long time to run.

Could you try opening the Web Console (CTRL + SHIFT + K) and reloading that video, and observing the network connections which are activated when you seek? When you seek, you should see a several requests targeting different byte ranges in the media in an attempt to determine where it should start decoding.

If you see byte range requests are still being made, but slowly, then we know it's just a slow connection. If you only see 1 connection, you know there's a cache or proxy in between you and the server which is preventing byte range requests.

Comment 9

[Matthew Gregan [:kinetik]]

(In reply to comment #8)
> * We seek in ogg files by doing a bisection search over HTTP, provided the
> webserver supports HTTP1.1 Byte Range requests. It looks to me like that
> webserver is advertising that is supports byte range requests, but perhaps your
> ISP has a cache or proxy in the way messing it up?

Could be some variant of bug 546700.  sdb, there are instructions in that bug on how to enable detailed HTTP logging.

Comment 10

[sdb]

I checked the Web Console and can confirm that this bug only exists with the specified ogv file above.  Other ogv files and webm files seem to work fine.  I'm using a high speed internet connection so it's not the connection that is the problem.

There were only two http 206 requests made for the problematic ogv file.  I tried selecting different positions in the video but no additional requests were made.  I tested other ogv files of the same movie and they all seem to seek fine.

A working ogv file:
[19:00:29.465] GET http://www.archive.org/download/horror_express_ipod/horror_express.ogv [HTTP/1.1 302 Moved Temporarily 435ms]
[19:00:29.910] GET http://ia700304.us.archive.org/31/items/horror_express_ipod/horror_express.ogv [HTTP/1.1 200 OK 338ms]
[19:00:30.262] GET http://ia700304.us.archive.org/31/items/horror_express_ipod/horror_express.ogv [HTTP/1.1 206 Partial Content 445ms]
[19:00:30.709] GET http://ia700304.us.archive.org/31/items/horror_express_ipod/horror_express.ogv [HTTP/1.1 206 Partial Content 14990ms]
[19:00:45.698] GET http://ia700304.us.archive.org/31/items/horror_express_ipod/horror_express.ogv [HTTP/1.1 206 Partial Content 854ms]
[19:00:46.554] GET http://ia700304.us.archive.org/31/items/horror_express_ipod/horror_express.ogv [HTTP/1.1 206 Partial Content 539ms]
[19:00:47.095] GET http://ia700304.us.archive.org/31/items/horror_express_ipod/horror_express.ogv [HTTP/1.1 206 Partial Content]

A working webm file:
[18:57:37.647] GET http://www.archive.org/download/Horror_Express_WebM/horror_express.webm [HTTP/1.1 302 Moved Temporarily 240ms]
[18:57:37.873] GET http://ia700101.us.archive.org/19/items/Horror_Express_WebM/horror_express.webm [HTTP/1.1 200 OK 35107ms]
[18:58:12.981] GET http://ia700101.us.archive.org/19/items/Horror_Express_WebM/horror_express.webm [HTTP/1.1 206 Partial Content 17009ms]

The problematic ogv file:
[19:02:19.880] GET http://www.archive.org/download/Horror_Express_WebM/horror_express.ogv [HTTP/1.1 302 Moved Temporarily 434ms]
[19:02:20.309] GET http://ia700101.us.archive.org/19/items/Horror_Express_WebM/horror_express.ogv [HTTP/1.1 200 OK 294ms]
[19:02:20.604] GET http://ia700101.us.archive.org/19/items/Horror_Express_WebM/horror_express.ogv [HTTP/1.1 206 Partial Content 458ms]
[19:02:21.069] GET http://ia700101.us.archive.org/19/items/Horror_Express_WebM/horror_express.ogv [HTTP/1.1 206 Partial Content]

After I click on a new position in the video it doesn't submit any additional http requests.  Other ogv files do seek successfully and all webm files seem to work fine.  Could this be related to the way the video was encoded?  It was automatically transcoded from a webm file by archive.org so I have no idea what default settings they use.

Comment 11

[Matthew Gregan [:kinetik]]

Reproducing the steps for Horror_Express_WebM/horror_express.ogv, I end up at the same redirect (which resolves to 207.241.229.60), but the video seeks fine for me.  It seems to take a good 5-10s between clicking on the seek bar and the next HTTP 206 being made/responded to, but my connection is very slow right now.

I don't think it has anything to do with the file itself, otherwise I'd expect it to be easier for others to reproduce the problem.

Are you able to produce a more detailed HTTP log of the failing case per the instructions at https://developer.mozilla.org/en/HTTP_Logging?  That might give us a clue, but I'm not sure if it's HTTP related yet either.

Comment 12

[Ada [:adalucinet]]

1Mozilla/5.0 (X11; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0

WFM with latest Nightly (Build ID: 20130820030206).

Reporter, do you still see this issue?

Comment 13

[sdb]

Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0

I can't reproduce the bug in the version of FF I'm using.