11

I want to be able to play back video from a specific time using the HTML5 video tag (and currently only need to worry about Chrome). This is possible by setting the currentTime property of a video element. That works fine in Chrome with a video sourced from html5rocks.com, but is ignored when the same file is loaded from my own local webserver.

Using the sample code from http://playground.html5rocks.com/#video_tag, I have arrived at the following HTML:

<!DOCTYPE html>
<html>
<body>
<video id="video1" width="320" height="240" volume=".7" controls preload=true autobuffer>
    <source src="http://playground.html5rocks.com/samples/html5_misc/chrome_japan.webm" type='video/webm; codecs="vp8, vorbis"'/>
    </video>
<input type=button onclick="play()" value="play">
<input type=button onclick="setTime()" value="setTime">
<input type=button onclick="pause()" value="pause">
<script>
    var play=function() {
        document.getElementById("video1").play();
    }
    var setTime=function() {
        document.getElementById("video1").currentTime=2;
    }
    var pause=function() {
        document.getElementById("video1").pause();
    }
</script>
</body>
</html>

Using Chrome, if you

  1. Wait for the video to download for a bit (until the progress bar is about 10% in)
  2. Press setTime - you should notice the time jump to 2 seconds
  3. press play

...the video will start at 2 seconds in.

But if I download the webm file in the source src to my local webserver, and change src to point locally:

<source src="chrome_japan.webm" type='video/webm; codecs="vp8, vorbis"'/>

...then setting currentTime is complete ignored. No errors are showing in the developer tools console.

Now, my webserver is serving this with mime type "video/webm", but it will be served like any old file -- not streamed.

Do I need a webserver that streams in some specific way? What else could be at fault here?

Note: The webserver is a proprietary platform and won't have any of the same exact settings or controls one might expect of Tomcat or some other commonly used webserver, though there may be other ways to achieve the same effect.

jwl
  • 10,418
  • 13
  • 48
  • 86

1 Answers1

15

Make sure your web server is capable of serving the document using byte ranges. Google Chrome requires that this works. Without it, seeking will be disabled and setting currentTime will have no effect.

To test if your web server does this, use the following command:

curl --dump-header - -r0-0 http://theurl

The response status must read 206 Partial Content and you should receive only the first byte of the resource instead of the whole resource.

-Phil

Celada
  • 20,176
  • 3
  • 55
  • 70
  • I won't be able to test this for a while however, I know that the webserver is _not_ capable of serving the document using byte ranges. thanks for the tip... – jwl Mar 25 '11 at 20:11
  • "Google Chrome requires that this works. Without it, seeking will be disabled and setting currentTime will have no effect." THANKS! This really messed me up. – Alex K Feb 28 '13 at 20:21
  • 2
    the corresponding Chromium bug lives unloved at http://code.google.com/p/chromium/issues/detail?id=121765 – user7610 Oct 01 '13 at 19:48
  • I have the same problem. Can anyone direct me to info on how to modify a node server to serve byte ranges? – gloo Jun 25 '14 at 14:28
  • 1
    @gloo I don't know about nodejs, but I ran into this with Python and CherryPy, and I basically had to write Python code to check for the `Range` header, parse it if present, and deliver only the requested bytes, overriding the default 200 response to 206 as needed. Annoying. My guess is that nodejs offers no better support. Still, in my case it's good that I did it this way because it allowed my application logic to be fully aware and in control of the byte ranges being requested, and it is optimized to only actually FETCH from the requested portion of the stream in this case. – Celada Jun 25 '14 at 20:31