Bug 33121
| Summary: | <audio> treats php source as live broadcast, can't replay | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Peter Parente <parente> |
| Component: | Media | Assignee: | Eric Carlson <eric.carlson> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | Normal | CC: | eric.carlson |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | PC | ||
| OS: | OS X 10.6 | ||
Peter Parente
I'm attempting to embed an HTML5 audio element pointing to MP3 or OGG data served by a PHP file . When I view the page in Webkit (nightly or Safari 4), the controls appear, but the UI says "Live Broadcast." When I click play, the audio starts as expected. Once it ends, however, I can't start it playing again by clicking play. Even using the JS API on the audio element and setting currentTime to 0 fails with an index error exception.
I suspected the headers from the PHP script were the problem, particularly missing a content length. But that's not the case. The response headers include a proper Content-Length to indicate the audio has finite size. Furthermore, everything works as expected in Firefox 3.5+. I can click play on the audio element multiple times to hear the sound replay.
If I remove the PHP script from the equation and serve up a static copy of the MP3 file, everything works fine in WebKit / Safari.
Does this mean Safari is treating audio src URLs with query parameters differently than URLs that don't have them? If so, it seems like a bug for webkit to assume that anything coming from a URL with query parameters is a live stream.
My simple test page is:
<!DOCTYPE html>
<html>
<head></head>
<body>
<audio controls autobuffer>
<source src="say.php?text=this%20is%20a%20test&format=.ogg" type="audio/ogg" />
<source src="say.php?text=this%20is%20a%20test&format=.mp3" type="audio/mpeg" />
</audio>
</body>
</html>
HTTP Headers from the PHP script:
HTTP/1.x 200 OK
Date: Sun, 03 Jan 2010 15:39:34 GMT
Server: Apache
X-Powered-By: PHP/5.2.10
Content-Length: 8993
Keep-Alive: timeout=2, max=98
Connection: Keep-Alive
Content-Type: audio/mpeg
HTTP Headers when directly accessing the MP3 file:
HTTP/1.x 200 OK
Date: Sun, 03 Jan 2010 20:06:59 GMT
Server: Apache
Last-Modified: Sun, 03 Jan 2010 03:20:02 GMT
Etag: "a404b-c3f-47c3a14937c80"
Accept-Ranges: bytes
Content-Length: 8993
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: audio/mpeg
I tried hard-coding the Accept-Ranges header into the script header too, but no luck.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Eric Carlson
Does your server actually support byte range request like it advertises?
Peter Parente
The problem did boil down to ranges not being supported properly. However, the sequence of requests tried by Safari at least seemed less than ideal perhaps.
http://stackoverflow.com/questions/1995589/html5-audio-safari-live-broadcast-vs-not
Eric Carlson
Closing as "won't fix" as there is nothing to do in WebKit. Following up with the QuickTime team about the unusual pattern of requests.