HTML5＆LT;音频＆GT;野生动物园现场直播相较于未 [英] HTML5 <audio> Safari live broadcast vs not
问题描述
我试图嵌入指向一个PHP文件送达MP3或OGG数据的HTML5音频元素。当我在Safari浏览网页，控件出现，但UI写着现场直播。当我点击播放，音频正常启动。一旦结束，不过，我可以不启动它通过点击播放再次播放。即使使用音频元件上的JS API和设置currentTime的0失败，索引错误异常。
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 Safari, 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.
我怀疑从PHP脚本的标题是问题，特别是缺少内容长度。但事实并非如此。响应头包括一个适当的内容 - 长度指示音频存在尺寸有限。此外，一切都按预期在Firefox 3.5+。我可以将音频元素上点击播放多次听到声音重播。
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.
如果我从等式中删除PHP脚本和服务于MP3文件的静态副本，一切都在Safari浏览器工作正常。
If I remove the PHP script from the equation and serve up a static copy of the MP3 file, everything works fine in Safari.
这是否意味着Safari浏览器是治疗与查询参数音频SRC的URL不同于没有他们的网址吗？任何人有任何运气得到这个工作？
Does this mean Safari is treating audio src URLs with query parameters differently than URLs that don't have them? Anyone have any luck getting this to work?
我的简单的例子网页是：
My simple example page is:
<!DOCTYPE html>
<html>
<head></head>
<body>
<audio controls autobuffer>
<source src="say.php?text=this%20is%20a%20test&format=.ogg" />
<source src="say.php?text=this%20is%20a%20test&format=.mp3" />
</audio>
</body>
</html>
HTTP标头的PHP脚本：
HTTP Headers from 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头直接文件访问：
HTTP Headers from direct file access:
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
我试过硬编码的Accept-范围头到脚本过，但没有运气。
I tried hard-coding the Accept-Ranges header into the script too, but no luck.
推荐答案
您可以通过发布使用和不使用PHP脚本服务器发送的头？如果PHP脚本发送我想知道不同的内容类型比正常服务的文件。
Can you post the headers sent by the server both with and without the PHP script? I'm wondering if the PHP script is sending a different Content-Type than serving the files normally.
这也将是指定键入的源属性元素是个好主意，这样浏览器就无需下载这两个片段，以确定它是否可以播放它们。
It would also be a good idea to specify the type attribute on the source elements, so the browser does not have to download both clips to determine if it can play them.
我无法重现你的问题。我试图重新夜间在Safari 4.0.4的问题，而目前的WebKit，与下面的测试页。我只是使用mod_rewrite派遣到基于参数，而不是PHP不同的格式，但我不认为应该有所作为，除非不知何故PHP是修改文件。
I cannot reproduce your problem. I have tried to recreate the problem in Safari 4.0.4, and the current WebKit nightly, with the following test page. I am simply using mod_rewrite to dispatch to different formats based on a parameter instead of PHP, but I don't think that should make a difference, unless somehow PHP is modifying the file.
<!DOCTYPE html>
<title>Auido test</title>
<audio controls autobuffer>
<source src="gnossienne-no-1?foo=bar&format=.mp4">
<source src="gnossienne-no-1?foo=bar&format=.ogg">
</audio>
您可以试试我的例子出来，让我知道它是否适合你？
Can you try my example out and let me know if it works for you?
修改啊。它四处多一点后，它出现的问题是由于一个奇怪的方式，在＆LT;音频＆GT; 在Safari元素表现在试图确定的大小的内容。
edit Ah. After poking around at it a bit more, it appears that the problem is due to an odd way that the <audio> element in Safari behaves in attempting to determine the size of the content.
下面是从Safari浏览器的数据包捕获在遇到一个℃的摘录;音频＆GT; 指向文件元素直接来自Apache服务。正如你所看到的，它首先尝试psumably获取媒体，$ P $的前两个字节，因此它可以得到一个Content-Length的背，和其他可能的标头。然后，它会尝试获取整个事情。然后，莫名其妙地，它会尝试再次读取前两个字节，但通过适当的缓存头得到一个304未修改响应。最后，还莫名其妙地，它一遍获取最后一个字节3440的文件。它所有的这些在不同的TCP连接，这在获取数据了几次的开销增加了相当大的开销，除了
Here's an excerpt from a packet capture of Safari upon encountering an <audio> element pointing to a file served directly from Apache. As you can see, it first tries to fetch the first two bytes of the media, presumably so it can get a Content-Length back, and possibly other headers. It then tries to fetch the whole thing. Then, inexplicably, it tries to fetch the first two bytes again, but passes appropriate caching headers to get a "304 Not Modified" response. And finally, still inexplicably, it fetches the last 3440 bytes of the file all over again. It does all of these in separate TCP connections, which adds considerable overhead, in addition to the overhead of fetching the data a couple of times.
GET /stackoverflow/audio-test/say-noid3?foo=bar&format=.mp3 HTTP/1.1
Host: ephemera.continuation.org
Range: bytes=0-1
Connection: close
User-Agent: Apple Mac OS X v10.6.2 CoreMedia v1.0.0.10C540
Accept: */*
Accept-Encoding: identity
Cookie: [redacted]
HTTP/1.1 206 Partial Content
Date: Tue, 05 Jan 2010 02:12:48 GMT
Server: Apache
Last-Modified: Tue, 05 Jan 2010 02:02:08 GMT
ETag: "b2a80ad-11f6-47c6139aaa800"
Accept-Ranges: bytes
Content-Length: 2
Content-Range: bytes 0-1/4598
Connection: close
Content-Type: audio/mpeg
# 2 bytes of data
GET /stackoverflow/audio-test/say-noid3?foo=bar&format=.mp3 HTTP/1.1
Host: ephemera.continuation.org
Range: bytes=0-4597
Connection: close
User-Agent: Apple Mac OS X v10.6.2 CoreMedia v1.0.0.10C540
Accept: */*
Accept-Encoding: identity
Cookie: [redacted]
HTTP/1.1 206 Partial Content
Date: Tue, 05 Jan 2010 02:12:48 GMT
Server: Apache
Last-Modified: Tue, 05 Jan 2010 02:02:08 GMT
ETag: "b2a80ad-11f6-47c6139aaa800"
Accept-Ranges: bytes
Content-Length: 4598
Content-Range: bytes 0-4597/4598
Connection: close
Content-Type: audio/mpeg
# 4598 bytes of data
GET /stackoverflow/audio-test/say-noid3?foo=bar&format=.mp3 HTTP/1.1
Host: ephemera.continuation.org
Range: bytes=0-1
Connection: close
User-Agent: Apple Mac OS X v10.6.2 CoreMedia v1.0.0.10C540
Accept: */*
Accept-Encoding: identity
Cookie: [redacted]
If-None-Match: "b2a80ad-11f6-47c6139aaa800"
If-Modified-Since: Tue, 05 Jan 2010 02:02:08 GMT
HTTP/1.1 304 Not Modified
Date: Tue, 05 Jan 2010 02:12:49 GMT
Server: Apache
Connection: close
ETag: "b2a80ad-11f6-47c6139aaa800"
# no data
GET /stackoverflow/audio-test/say-noid3?foo=bar&format=.mp3 HTTP/1.1
Host: ephemera.continuation.org
Range: bytes=1158-4597
Connection: close
User-Agent: Apple Mac OS X v10.6.2 CoreMedia v1.0.0.10C540
Accept: */*
Accept-Encoding: identity
Cookie: [redacted]
HTTP/1.1 206 Partial Content
Date: Tue, 05 Jan 2010 02:12:49 GMT
Server: Apache
Last-Modified: Tue, 05 Jan 2010 02:02:08 GMT
ETag: "b2a80ad-11f6-47c6139aaa800"
Accept-Ranges: bytes
Content-Length: 3440
Content-Range: bytes 1158-4597/4598
Connection: close
Content-Type: audio/mpeg
# 3440 bytes of data
总之，到如何与你的PHP脚本的输出交易。在这里，Safari浏览器再次尝试下载前两个字节，但你的脚本忽略范围请求，并返回了整个事情。显然，WebKit的不喜欢，因此它再次尝试，而不范围请求。同样，你的脚本发送的全部内容。 Safari浏览器现在将尝试一次，添加冰爽的元数据头，这表明它认为它的下载流，并希望被发送流媒体元数据。它终于接受的，输出，以及＆LT;音频方式＆gt; 元素能起到
Anyhow, on to how it deals with the output of your PHP script. Here, Safari again tries to download the first two bytes, but your script ignores the Range request and returns the whole thing. Apparently, WebKit doesn't like that, and so it tries again, without the Range request. Again, your script sends the full contents. Safari now tries once more, adding an Icy-Metadata header, which indicates it thinks that it's downloading a stream and wants streaming metadata to be sent. It finally accepts the output of that, and the <audio> element can play.
GET /say.php?text=this%20is%20a%20test&format=.mp3 HTTP/1.1
Host: tts.mindtrove.info
Range: bytes=0-1
Connection: close
User-Agent: Apple Mac OS X v10.6.2 CoreMedia v1.0.0.10C540
Accept: */*
Accept-Encoding: identity
HTTP/1.1 200 OK
Date: Tue, 05 Jan 2010 02:14:28 GMT
Server: Apache
X-Powered-By: PHP/5.2.10
Content-Length: 4598
Connection: close
Content-Type: audio/mpeg
# 4598 bytes of data
GET /say.php?text=this%20is%20a%20test&format=.mp3 HTTP/1.1
Host: tts.mindtrove.info
Connection: close
User-Agent: Apple Mac OS X v10.6.2 CoreMedia v1.0.0.10C540
Accept: */*
HTTP/1.1 200 OK
Date: Tue, 05 Jan 2010 02:14:28 GMT
Server: Apache
X-Powered-By: PHP/5.2.10
Content-Length: 4598
Connection: close
Content-Type: audio/mpeg
# 4598 bytes of data
GET /say.php?text=this%20is%20a%20test&format=.mp3 HTTP/1.1
Host: tts.mindtrove.info
Accept: */*
User-Agent: Apple Mac OS X v10.6.2 CoreMedia v1.0.0.10C540
Icy-Metadata: 1
Connection: close
HTTP/1.1 200 OK
Date: Tue, 05 Jan 2010 02:14:28 GMT
Server: Apache
X-Powered-By: PHP/5.2.10
Content-Length: 4598
Connection: close
Content-Type: audio/mpeg
# 4598 bytes of data
在摘要，看来的Safari（或更准确地，QuickTime的，其中Safari使用来处理所有的媒体和媒体下载）有一个完全braindamaged方法来下载媒体。事情妨碍你把你的数据备份，这可能是事实，你不要响应范围的要求，使得它认为你是发送流媒体，使其下载内容反复（但即使当与不为范围请求做出响应的服务器面对，它仍然没有几个请求比实际需要）。
In summary, it appears that Safari (or more accurately, QuickTime, which Safari uses to handle all media and media downloading) has a completely braindamaged approach to downloading media. Something in the way you send your data back, probably the fact that you don't respond to Range requests, makes it think that you are sending streaming media, causing it to download the content repeatedly (though even when confronted with a server that does respond to a Range request, it still does several more requests than it really needs to).
我的建议是尝试适当地范围请求作出回应;服务了媒体的时候，浏览器可能会用它们来尽量减少带宽，只缓冲，因为他们需要能够通过发挥（尽可能多虽然有自动缓冲属性，该属性表明您希望他们来缓冲整个事情，浏览器可能会忽略这一点）。我会建议使用 X-SENDFILE 让Apache的处理服务的文件，缓存和范围请求，但你似乎是在Dreamhost的，不具有 mod_xsendfile 安装的，所以你将不得不推出自己的范围处理。
My advice would be to try to respond appropriately to Range requests; when serving up media, browsers will likely use them to try to minimize bandwidth, by only buffering as much as they need to be able to play through (although have the autobuffer attribute which indicates that you would like them to buffer the whole thing, browsers may ignore that). I would recommend using X-Sendfile to let Apache deal with serving the file, caching, and range requests, but you appear to be on Dreamhost, which doesn't have mod_xsendfile installed, so you're going to have to roll your own Range handling.
这篇关于HTML5＆LT;音频＆GT;野生动物园现场直播相较于未的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
