3

So this is an odd issue I'm running into. I've only tested Chrome and Safari, both on Mac, and between those browsers the problem only manifests on Chrome.

I have a very basic HTML5 video element, which loads a video from my server, and the user has a few buttons onscreen to jump to specific times within the video.

When the video file is referenced as a direct link, e.g.:

<video id="thevideo" width="720" height="480">
  <source type="video/webm" src="videos/vid102.webm" />
  <source type="video/mp4" src="videos/vid102.mp4" />
  <p>Your browser does not support this video.</p>
</video>

...it works just fine.

However, I've just set it up so the videos can be instead loaded via a PHP fpassthru, e.g.:

<video id="thevideo" width="720" height="480">
  <source type="video/webm" src="getvideo.php?t=webm&v=166" />
  <source type="video/mp4" src="getvideo.php?t=mp4&v=166" />
  <p>Your browser does not support this video.</p>
</video>

where getvideo.php looks something like this:

<?php
$videoID = $_REQUEST["v"];
$videoType = $_REQUEST["t"];
$vidPath = "videos/video$vidFile.$videoType";

$fp = fopen($vidPath, 'rb');
header("Content-Type: video/$videoType");
header("Content-Length: " . filesize($vidPath));
fpassthru($fp);

?>

The strange behavior is this: On both browsers, the video loads and plays just fine. On Chrome, however, the version using the fpassthru PHP script breaks the ability to set the player's "currentTime" attribute and thus jump to somewhere in the video. If I call document.getElementById('thevideo').currentTime = 50, instead of jumping to the 50 second mark, it just stays where it is.

Any idea why this might be?

UPDATE: I've seen some indications that this has something to do with Chrome specifically requiring the "Accept-Ranges" header to be provided in the response. I've added the header "Accept-Ranges: bytes" to the .php script's output, and I've made sure that the web server is allowing byte range requests, but still, it's not working.

DanM
  • 7,037
  • 11
  • 51
  • 86

1 Answers1

4

You are correct about requiring the "Accept-Ranges" header, as part of HTTP Byte Serving. I suggest reading this answer to a similar question:

Seekbar not working in Chrome

Adding the response header is not sufficient. You have to also respond with the "206 Partial Content" status code and return only the requested range of bytes. It sounds like you're still returning the whole file. fpassthru will read back the file all the way to the end, so it looks like you're going to need to find another way to read the file.

Community
  • 1
  • 1
brianchirls
  • 7,661
  • 1
  • 32
  • 32
  • Aha! That makes a lot of sense. Doesn't matter if I'm telling the client I can return a requested range of bytes, if I'm not in fact returning the requested range of bytes, does it? :) – DanM Jan 22 '14 at 20:49
  • And by the way, thanks to your tip, I found the following, which looks to solve the problem: http://stackoverflow.com/questions/157318/resumable-downloads-when-using-php-to-send-the-file – DanM Jan 22 '14 at 20:50
  • Glad it worked out. I suspect serving a file like that with PHP will be a bit slow. Why not use a CDN or dedicated file serving machine without PHP and dynamically compute the URL in Javascript? – brianchirls Jan 22 '14 at 22:14
  • Mainly, I don't want to expose the actual file, and I want different users to receive different versions of the file using the same URL. – DanM Jan 23 '14 at 12:56
  • There are CDNs that will give you an expiring key, and you could use a 'Location' header to dynamically redirect to the CDNs temporary URL. – brianchirls Jan 23 '14 at 14:04