locked
Unable to scrub video when using progressive download

    Question

  • Hi all,

    We've developed a VoD application that plays video coming from a remote host using progressive download. So, we simply pass the HTTP url of the video file to the video element and start playing the video (which is an MPEG-4 file). So far, so good. Unfortunately, the user cannot scrub to any parts of the video that are not yet buffered. What will happen is that the player will attempt to jump to the requested section and simply wait until the player has buffered enough video to resume playback.

    As you can imagine, this can take quite a while if the video you are attempting to play is roughly 30mins in duration and you jump to say 25 mins. In comparison, the built-in player in, for example, iOS is smart enough to see that if it's a part of the video that is not yet buffered, to trigger a new HTTP range request starting at the designated entry point (in fact, this is how the iOS video player handles all video coming from progressive download, it sends small HTTP range requests which results in small segments of video coming back with HTTP status "206 Partial Content").

    Is there any way to instruct the video element (or the PlayerFramework, which in itself uses the video element) to simulate this behaviour? Currently I have patched the PlayerFramework to restrict scrubbing to the parts that have already been buffered so they don't get into a state where the player will just look like it's stalled, but this can be quite an annoyance to end users (especially in the case of long videos). We will move to Smooth Streaming in the future, but for now I'd like to present users with a fix.

    Wednesday, December 19, 2012 9:04 AM

Answers

  • Upon further investigation it seems the client will only engage in HTTP partial requests if the server announces *in the very first response* that it supports range requests by setting the header:

    Accept-Ranges: bytes

    See also:

    http://blogs.msdn.com/b/windowsazurestorage/archive/2011/09/15/windows-azure-blobs-improved-http-headers-for-resume-on-download-and-a-change-in-if-match-conditions.aspx

    In our case the problem was that the server wasn't announcing it and the client was therefore not requesting it (sort of a chicken/egg situation) even though it was supported.


    • Edited by tieleman Friday, February 15, 2013 8:33 AM
    • Marked as answer by tieleman Friday, February 15, 2013 8:33 AM
    Friday, February 15, 2013 8:33 AM