无法在 Safari/Mac (5.0) 上通过 PHP 提供 HTML5 视频
我在 Safari 中遇到一个奇怪的错误，当我通过 PHP 提供 MP4 视频（使用基于令牌的身份验证系统混淆文档根目录下的文件）时，Safari 出于某种原因会触发 onerror 事件，并且视频永远不会加载（我无法从发送到 onerror 的事件对象中获取任何有用的信息 - 一切都是未定义的）。
当我直接访问 PHP 脚本时（即视频未嵌入页面中），视频控件会短暂出现，然后闪烁为 QuickTime 问号。
当我直接访问 MP4 文件时，它按预期工作。
奇怪的是，嵌入的视频在最新版本的 Mac 版 Chrome 中完美运行。
以下是通过 PHP 访问时的标头：
Connection:Keep-Alive
Content-Disposition:inline; filename="test.mp4"
Content-Length:5558749
Content-Type:video/mp4
Date:Tue, 22 Jun 2010 01:24:25 GMT
Keep-Alive:timeout=10, max=29
Server:Apache/2.2.15 (CentOS) mod_ssl/2.2.15 0.9.8l DAV/2 mod_auth_passthrough/2.1 FrontPage/5.0.2.2635
X-Powered-By:PHP/5.2.13
以下是直接访问 test.mp4 时的标头：
Accept-Ranges:bytes
Connection:Keep-Alive
Content-Length:5558749
Content-Type:video/mp4
Date:Tue, 22 Jun 2010 01:26:45 GMT
Etag:"1c04757-54d1dd-489944c5a6400"
Keep-Alive:timeout=10, max=30
Last-Modified:Tue, 22 Jun 2010 01:25:36 GMT
Server:Apache/2.2.15 (CentOS) mod_ssl/2.2.15 0.9.8l DAV/2 mod_auth_passthrough/2.1 FrontPage/5.0.2.2635
唯一不同的标头是：Accept-Ranges（我认为没有必要）、Etag、Last-Modified、Content-处置和 X-Powered-By。
Chrome 不仅可以很好地处理 PHP 提供的视频，而且当我使用相同的脚本通过 Flash 播放器加载 MP4 时，它也可以正常工作。我就是不明白 Safari 到底是被什么卡住了。
编辑：另外，当我将内容配置更改为“附件”时，Safari 将很好地下载 MP4 文件。
I'm encountering a strange bug in Safari where, when I serve MP4 video through PHP (to obfuscate the file beneath the document root with a token-based authentication system), Safari for some reason fires the <video>'s onerror event, and the video never loads (I can't get any useful information out of the event object sent to onerror — everything is undefined).
When I access the PHP script directly (i.e., the video is not embedded in a page), the video controls appear momentarily before flashing to a QuickTime question mark.
When I access the MP4 file directly, it works as expected.
What's bizarre is that the embedded video works perfectly in the latest version of Chrome for Mac.
Here are the headers when accessed through PHP:
Connection:Keep-Alive
Content-Disposition:inline; filename="test.mp4"
Content-Length:5558749
Content-Type:video/mp4
Date:Tue, 22 Jun 2010 01:24:25 GMT
Keep-Alive:timeout=10, max=29
Server:Apache/2.2.15 (CentOS) mod_ssl/2.2.15 0.9.8l DAV/2 mod_auth_passthrough/2.1 FrontPage/5.0.2.2635
X-Powered-By:PHP/5.2.13
And here are the headers when test.mp4 is accessed directly:
Accept-Ranges:bytes
Connection:Keep-Alive
Content-Length:5558749
Content-Type:video/mp4
Date:Tue, 22 Jun 2010 01:26:45 GMT
Etag:"1c04757-54d1dd-489944c5a6400"
Keep-Alive:timeout=10, max=30
Last-Modified:Tue, 22 Jun 2010 01:25:36 GMT
Server:Apache/2.2.15 (CentOS) mod_ssl/2.2.15 0.9.8l DAV/2 mod_auth_passthrough/2.1 FrontPage/5.0.2.2635
The only differing headers are: Accept-Ranges (which I don't think is necessary), Etag, Last-Modified, Content-Disposition, and X-Powered-By.
Not only can Chrome handle the PHP-served video fine, but when I use the same script to load the MP4 through a Flash player, it also works fine. I just can't figure out what Safari is choking on.
EDIT: Also, when I change the content disposition to "attachment", Safari will download the MP4 file just fine.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
为了让遇到这个问题的人感兴趣，这里有一个解释：
我问了一个我认为与另一个 Safari 特定 HTML5 视频问题无关的问题：单个 PHP“退出；”声明阻止 Safari 中的 HTML5 视频。
最终，该问题与 PHP
exit语句无关。事实上，问题是我使用$_SESSION变量来验证请求，而 Safari 使用单独的进程来处理无法访问相同$_SESSION的视频播放> 数据（与 Chrome 不同）。令人困惑的是，原来的 Safari 进程和播放进程都分别请求视频文件。我只查看了原始请求，它确实通过了基于
$_SESSION的身份验证，因此我认为这不是问题的一部分。无论如何，如果您使用
$_SESSION数据来验证来自 Safari 中 HTML5播放器的请求，查看解决方案。In the interest of anyone who comes across this question, here's the explanation:
I asked what I thought was an unrelated question about another Safari-specifc HTML5 video problem: Single PHP “exit;” statement prevents HTML5 video in Safari.
Ultimately the problem had nothing to do with a PHP
exitstatement. In fact the problem was that I was using a$_SESSIONvariable to authenticate requests, and Safari uses a separate process to handle video playback that does not have access to the same$_SESSIONdata (unlike, say, Chrome).What was confusing was that both the original Safari process and the playback process requested the video file separately. I was only looking at the original request, which did pass the
$_SESSION-based authentication, so I assumed it wasn't part of the problem.Anyway, if you are using
$_SESSIONdata to authenticate a request from an HTML5<video>player in Safari, check out the solution.您是否尝试过修改通过 php 发送的标头以匹配直接文件发送的标头，然后一一删除它们/更改它们以查看哪一个是您自己的？
Have you tried modifying the headers sent via php to match those sent by the direct file, then one by one removing them / altering them to see which it is yourself?
正如我昨天发现的，iPhone 版本的 Safari 将 mp4 文件的播放推迟到 iPhone 中集成的 QuickTime 播放器。该播放器首先获取 mp4 的前两个字节（我想是为了以某种方式确定关键帧）。为此，它使用了接受范围标头。然后再次使用接受范围请求整个文件。
我也使用 PHP 提供这些 mp4 文件，我发现支持这个接受范围标头，一切都突然开始工作。它也可以解决桌面版 Safari 的问题，尽管在没有接受范围支持的情况下这对我来说一直有效。
成功。
鲍勃.
As I've discovered yesterday the iPhone version of Safari defers the playing of an mp4 file to the quicktime player integrated in the iPhone. This player first fetches the first two bytes of the mp4 (to somehow determine keyframes I suppose). It uses the accept-range header for this. Then the entire file is requested, again using accept-range.
I was serving these mp4 files with the use of PHP aswell, and I discovered that supporting this accept-range header everything started working all of a sudden. It might solve your problems with the desktop version of Safari aswell, although that has always worked for me without the accept-range support.
Success.
Bob.
我在 safari 上也遇到了类似的问题。我有一个 php 脚本，可以将 mp4/webm/ogv 流式传输到 html5 视频播放器。直到几周前，它在 safari 中还运行良好。它继续在所有其他浏览器中工作，并且所有请求/响应标头信息对我来说看起来都很好，尽管我在 safari 中不断收到插件无法加载错误。我最终意识到，由于我已将虚拟主机更改为 https 并使用 openssl 签署了自己的证书，因此 safari 会阻止对媒体内容的 GET 请求。这个故事的寓意...如果您使用 openssl 并在本地进行开发，如果 safari 不信任您的 ssl 证书，它将不会为您检索视频数据。
I ran into a similar issue on safari as well. I have a php script that streams mp4/webm/ogv to an html5 video player. Until a couple of weeks ago it was working fine in safari. It continued to work in every other browser and all of the request/response header info looked fine to me, although I kept getting a plugin-in failed to load error in safari. I eventually realized that since I had changed my virtual host to https and signed my own certificates with openssl, safari was blocking GET requests for media content. Moral of the story... if you are using openssl and developing locally, safari will not retrieve video data for you if it doesn't trust your ssl certificate.