Bug 46242
| Summary: | Video element does not use Http Range Header | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Shiv Kumar <shivk> |
| Component: | Media | Assignee: | Nobody <webkit-unassigned> |
| Status: | UNCONFIRMED | ||
| Severity: | Normal | CC: | ahmad.saleem792, destra, eric.carlson, jer.noble |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| URL: | http://exposureroom.com | ||
Shiv Kumar
When the video element in Safari makes a request for a video it does not make a Http Range Request. As a result it takes a very long time for the video to start playing (5-10 seconds sometimes).
Further, there is no ability to skip ahead. That is being able to skip to a portion of the video that has not yet been downloaded. This is such a strong feature of the Html 5 video element but sadly does not work at all.
This feature also cripples another feature we provide in our html 5 video player and that is the ability to switch between different versions of the same video. For example, if a viewer is watching a medium quality version of a video and decides to switch to the HD version in mid play the player needs to make a range request so the viewer can continue to watch the video without having to re-start the video from the begining (which is what happens currently).
Both of these are compelling features of the Html 5 video element but sadly they do not work in Safari.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Eric Carlson
(In reply to comment #0)
Safari does use range requests on OS X when the movie is opened with the QuickTime X backend, but "classic" QuickTime on Windows and OS X does not use range requests.
> When the video element in Safari makes a request for a video it does not make a Http Range Request.
> As a result it takes a very long time for the video to start playing (5-10 seconds sometimes).
>
Why does it take longer for the video to start playing when range requests aren't sent? The only reason I can think of is that the files are not flattened (are not saved with the 'moov' atom at the beginning of the file). Is this the case?
Ahmad Saleem
@Eric & @Jer & @Dana - is this applicable? We don't have 'AppleWin' port and only have 'win-cairo', which might be using different range header and might have separate bug (if it has an issue separately).
Can we mark this as 'RESOLVED CONFIGURATION CHANGED' or 'RESOLVED WONTFIX'?