2010-04-27
HTML 5 Video Seeking and Redirects
Bug 560806 has landed on trunk. Seeking and duration works for videos hosted on some servers where it didn't before.
Firefox's implementation of HTML 5 video allows seeking in unbuffered portions of the video as long as the server that hosts the video supports byte range requests.
Firefox needs to know in advance if it can seek the video so it can correctly display the 'progress' bar. It also needs this information so it can compute the duration (which requires seeking into the video to find the end time).
Most servers that support byte range requests send an Accept-Ranges header. If we see this on the initial request we know the server supports seeking.
Some servers support byte range requests but do not send this header. Amazon S3 is an example of a server that does this. To detect if these servers support seeking we make our inital request for the video include a 'Range' header that askes for the bytes from zero to the end of the file. Servers like S3 that support byte ranges will respond with a '206' response code meaning a partial request is returned. This is sent even though the byte range we asked for is actually for the entire file. Once we see the '206' we mark the resource as seekable.
A very few servers don't send an Accept-Ranges header and recognize our byte range request as actually being for the entire file and return a '200' response code. Unfortunately we don't recognize resources hosted on these servers as seekable. This means Ogg media on these servers don't have a duration since we can't seek to find it.
Another issue we came across, and exists in Firefox 3.5 and Firefox 3.6, is detecting seeking when the initial request for the media resource results in a '3XX' response code. This is a redirect to another URL. Current Firefox versions (and possibly other browsers) do not pass on the value of headers to the redirected URL. This means the 'Range' header is removed and we don't get a '206' response code on the redirected request. In servers like Amazon S3 that don't send 'Accept-Ranges' this means we don't support seeking.
This is why videos hosted on Amazon S3 and similar serving platforms that arrive there via a redirect don't get a duration, show progress or allow seeking. It's a fairly common practice to hide the fact that Amazon S3 is being used by having a redirect from a URL on the web site domain that redirects to the S3 location which results in this problem.
The following are two URL's that show the problem. The first is a direct link to the video. The second redirects to the final URL. In the first you can seek and see a duration of '1:00'. In the second you can't seek and no duration is shown:
This is Bug 560806 and has been fixed and is now on Firefox trunk and in the nightly builds. The fix was to explicitly pass the 'Range' header along to the final URL. This workaround exists in a few other areas in Firefox and Bug 311599 discusses a similar issue for plugins.
If your own videos are not seekable or showing a duration then you may be facing a similar issue and it might be worthwhile trying a nightly build and seeing if that fixes it. Other things to look at are the server configuration to make sure that byte range requests are supported and the Accept-Ranges header is being sent. If you use Amazon S3 you might want to try and get them to support Accept-Ranges. This forum post discusses the issue.
