Safari 9.0 can not play mp4 video on the storage server

Asked 7/10, 2015 at 15:30 Answered 3/8, 2022 at 14:14

The following video link cannot be played with safari 9.0 (latest version). But older versions of safari, chrome and firefox can play.

http://assets00.grou.ps/0F2E3C/wysiwyg_files/Videos/saksuka/20150928104628-lhmkkfbhnkiisbhht.mp4

I can play with safari 9.0 when i download the video from the server to my computer.

That's why I don't think this problem stems video encoding.

I have done these settings;

mime.types
video/mp4   mp4 m4v
video/ogg   ogv
video/webm  webm

httpd.conf
AddType video/mp4 mp4 m4v
AddType video/ogg ogv
AddType video/webm webm

.htaccess
AddType video/mp4 mp4 m4v
AddType video/ogg ogv
AddType video/webm webm

Given answered 7/10, 2015 at 15:30 Comment(3)

I have this same problem when serving a small video through S3 and Cloudflare. Works fine on a server responding with streaming headers so the problem is not the video encoding. – Adjunct 16/10, 2015 at 9:37

Add a CORS header to the video – Kienan 27/11, 2019 at 18:8

Does this answer your question? Failed to Load Resource, Plugin Handled Load on iOS – Lakeishalakeland 3/4, 2023 at 0:14

Update 2 - June 2020

The most common root cause of this issue appears to be servers that are not configured to handle range requests properly.

Safari expects to see a '206' response when it sends a request with a byte range. If the server responds with a '200' request it appears Safari cannot handle this. Some other browsers seem to be ok with this - for example Chrome.

The inspection network tab screenshot below shows a successful video playback with range requests and a 206 'Partial Content' response:

While this example below shows a video which fails to play in Safari but does play in Chrome - and it can be seen that the server is simply responding with a 200 request:

You can test if the server is properly accepting range requests using a CURL command - see info from apple here:

If you are not sure whether your media server supports byte-range requests, you can open the Terminal application in OS X and use the curl command-line tool to download a short segment from a file on the server:

curl --range 0-99 http://example.com/test.mov -o /dev/null

If the tool reports that it downloaded 100 bytes, the media server correctly handled the byte-range request. If it downloads the entire file, you may need to update the media server. For more information on curl, see OS X Man Pages.

(from: https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/CreatingVideoforSafarioniPhone/CreatingVideoforSafarioniPhone.html#//apple_ref/doc/uid/TP40006514-SW6)

Using the CURL command in the above reference for the first video which plays correctly, we can see the response is that just the range requested is returned as expected:

Using the same CURL command with the example above which does not play in Safari (but does in Chrome) shows that the server is responding with the full file, instead of just with the range requested:

This CURL test is probably the quickest way to check whether your server is correctly try handling the request.

Original Answer

This seems to be recurring problem with some mp4 files on Safari.

I tested your video on a localhost node.js static server and it played fine in Safari, which means the video itself should be fine.

If you look at the web inspector in Safari you will see that the web request is not including some headers. This causes some servers problems and they do not respond the way Safari is expecting, or do not respond at all.

You can see similar problems being discussed (the second one is not your case I think but illustrates that the info included in the request sent to the server can cause the server to 'decide' not to respond as you want):

Update 1:

Using wireshark to capture the request from Chrome, it can be seen to result in a response from the server with the video to be played while the request from Safari (on the same machine) results in no response from the server.

The requests are generally similar and both do include the referrer header. The Safari browser is only asking for the first 2 bytes to be returned from the server initially - it does this by using the 'range' header, which is used to specify the bytes range that a file returns:

Range: bytes=0-1\r\n

Chrome on the other hand requests the entire video in its range request:

Range: bytes=0-\r\n

However, using a HTTP tool (e.g. Postman) on Chrome and changing the range to 0-1 does not seem to stop the server responding in the Chrome case. In fact using the tool to set, as far as possible, all the same headers as Safari sets seems still seems to return the video ok.

Amperage answered 7/10, 2015 at 17:26 Comment(3)

Could you clarify a bit what the solution is? It seems that this answer doesn't provide a solution and instead just points us to other SO questions. – Charleton 8/11, 2017 at 16:30

@Charleton Thats a fair comment - the answer is a little like an investigation log, I have to admit. The original video link is not working so I can't test again now, but if you have an example that does not work send it on and as I'd like to look with the latest Safari version. It is possible that the file server was recognising the browser type and changing its response based on this, but its hard to say for sure, What was certain was that the video played fine locally and that the server responded differently to different browsers making the request. – Amperage 8/11, 2017 at 17:21

This was super useful to me. I would've never guessed that Safari failed when the server could not respond to range requests. – Walliw 5/12, 2017 at 11:16

The issue is that safari or iOs expects chunks. Meaning from a streaming server. If your video is from a blob or file server then safari will throw an error. You can relate it to this post Failed to Load Resource, Plugin Handled Load on iOS

Almucantar answered 10/4, 2018 at 10:31 Comment(0)

To shed some more light on mp4s not playing in the video tag, I'd like to share my experience here. I spent a good while troubleshooting an issue recently that was preventing mp4s from playing in Safari.

As mentioned in one of the previous answers, Safari first sends a byte range request for a Video tag that expects a 206 response. However, if you use a Service worker, the response returns with a 200 and it appears Safari doesn't know how to handle this. Our solution was to exclude using a Service Worker for Safari.

We found this by using the network tab of the Safari debugger on a MacBook to troubleshoot the issue we were seeing on the iPad. Attached is a screenshot for comparison/reference. The left tab shows what the call should look like by default. The right tab shows what you would see if using a Service Worker.

Leatherneck answered 6/7, 2018 at 15:8 Comment(2)

Would you expand on your 'service worker' comment? Not everyone will be using the same web server as you. – Complexion 1/10, 2018 at 21:48

Yes, here's a bit more information: by Service Worker, I'm talking about a web browser's Service Worker rather than anything that lives on a web server. Our front-end application makes use of this functionality in the browser. We had put some additional code in to not use the Service Worker if Safari was detected. – Leatherneck 2/10, 2018 at 15:22

In my case Safari 15+ the browser would return the same 206 error but would play the video regardless

Rhizogenic answered 3/8, 2022 at 14:14 Comment(0)

Recommended topics

Hot tags