[Solved] Seeking in HTML5 video with Chrome

I’m having issues seeking in video’s using Chrome.

For some reason, no matter what I do, video.seekable.end(0) is always 0.

When I call video.currentTime = 5, followed by console.log(video.currentTime), I see it is always 0, which seems to reset the video.

I’ve tried both MP4 and VP9-based webm formats, but both gave the same results.

What’s more annoying is that Firefox runs everything perfectly. Is there something special about Chrome that I should know about?

Here’s my code (which only works in Firefox):

      <div class="myvideo">
        <video width="500" height="300" id="video1" preload="auto">
          <source src="data/video1.webm" type="video/webm"/>
          Your browser does not support videos.

And here’s the javascript:

var videoDiv = $(".myvideo").children().get(0)
  videoDiv.addEventListener("loadeddata", function(){
    console.log(videoDiv.seekable.end(0)); //Why is this always 0 in Chrome, but not Firefox?
    videoDiv.currentTime = 5;
    console.log(videoDiv.currentTime); //Why is this also always 0 in Chrome, but not Firefox?

Note that simply calling does actually correctly play the video in both browsers.

Also, after the movie file is fully loaded, the videoDiv.buffered.end(0) also gives correct values in both browsers.

Enquirer: Tovi7


Solution #1:

It took me a while to figure it out…

The problem turned out to be server-side. I was using a version of Jetty to serve all my video-files. The simple configuration of Jetty did not support byte serving.

The difference between Firefox and Chrome is that Firefox will download the entire video file so that you can seek through it, even if the server does not support http code 206 (partial content). Chrome on the other hand refuses to download the entire file (unless it is really small, like around 2-3mb).

So to get the currentTime parameter of html5 video to be working in Chrome, you need a server that supports http code 206.

For anyone else having this problem, you can double check your server config with curl:

curl -H Range:bytes=16- -I http://localhost:8080/GOPR0001.mp4

This should return code 206. If it returns code 200, Chrome will not be able to seek the video, but Firefox will, due to a workaround in the browser.

And a final tip: You can use npm http-server to get a simple http-server for a local folder that supports partial content:

npm install http-server -g

And run it to serve a local folder:

http-server -p 8000
Respondent: Tovi7

Solution #2:

If you wait for canplaythrough instead of loadeddata, it works.

See this codepen example.

Respondent: Ian Devlin

Solution #3:

Work around if modifying server code is unfeasible. Make an API call for you video, then load the blob into URL.createObjectURL and feed that into the src attribute of your video html tag. This will load the entire file and then chrome will know the size of the file allowing seeking capabilities to work.

 axios.get(`${url}`, {
      responseType: "blob"
      .then(function(response) {
      .catch(function(error) {
        // handle error
Respondent: Luis Salas

Solution #4:

You have 3 possibilities for the Video tag: MP4, OGG, WebM.

Not all formats work in all browsers.

Here, I’m thinking that WebM works in Firefox but not Chrome, so you should supply both alternative formats for MP4 and WebM files, by including a 2nd Source tag referring to the MP4 file.

E.g. src=”″ type=”video/mp4″

The relevant version will be automatically selected by the browser.

Respondent: Tony Duffill

Solution #5:

I had a similar problem. I was listening for an the end event on a video and setting currentTime to the middle of the video to loop it continuously. It wasn’t working in Safari or Chrome.

I think there may be a bug in Safari/Chrome where playhead position properties aren’t available unless the media is currently playing.

My workaround was to start my loop just before the video end and not letting it actually end.

Try testing yours by starting playback first and then run your fuction to see if it works in Safari Chrome.

Respondent: Mysterfxit

The answers/resolutions are collected from stackoverflow, are licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0 .

Most Popular

To Top
India and Pakistan’s steroid-soaked rhetoric over Kashmir will come back to haunt them both clenbuterol australia bossier man pleads guilty for leadership role in anabolic steriod distribution conspiracy