plays in other browsers, but not Safari
up vote
9
down vote
favorite
We have an MP4 video on our site; it plays fine in IE9+, Firefox, Chrome, and Chrome on mac. However, on Safari, the video doesn't play at all - it does trigger a "stalled" event and then nothing loads. I would post our HTML, but I traced the problem further by finding that Safari wouldn't play it even when navigating to the original MP4's URL. When downloaded and played locally, the video works fine in Quicktime.
The weirdest part of this is that of all our developers, I can get the video to work on Safari when I run the related server from my development computer. What's more, other MP4 files in the same directory have a similar problem. This has been the key to me, and I've been searching for any little difference in the way the videos transfer from the server - request/response headers, exact filesize, etc.
Headers copied from Chrome (only since Safari is harder to copy/paste from)
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
DNT:1
Host:*************:8443
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36
Response Headers
Accept-Ranges:bytes
Content-Length:44875102
Content-Type:video/mp4;charset=UTF-8
Date:Tue, 30 Dec 2014 21:11:51 GMT
ETag:W/"44875102-1419959755000"
Last-Modified:Tue, 30 Dec 2014 17:15:55 GMT
Server:Apache-Coyote/1.1
(Also, just in case this reminds you of an older issue; I'm aware Safari on Windows has been dead for ages. This issue is occurring on OS X)
EDIT: New info that might help a bit. I took a personal video from my own webserver, which was able to work from there on the problematic Safari browsers in question, and downloaded it to our server's local video directory. From there, it encounters the same issue as our other videos. This suggests to me that the MP4 itself may not matter - this is probably a server issue of some sort with our Tomcat 7 webserver. We do have the Content-Types registered correctly, which at least covers the basics, but I am curious if there are other necessary parts.
MORE INFO: I didn't think to mention this initially, but we are loading our webpages and videos over an HTTPS connection. Most of our test servers do not have valid certificates, and so we need to click through the standard browser warning that "This server might not be who it says". We are now looking into what it would take to have correct certificates on all our servers.
html5 video safari mp4
|
show 1 more comment
up vote
9
down vote
favorite
We have an MP4 video on our site; it plays fine in IE9+, Firefox, Chrome, and Chrome on mac. However, on Safari, the video doesn't play at all - it does trigger a "stalled" event and then nothing loads. I would post our HTML, but I traced the problem further by finding that Safari wouldn't play it even when navigating to the original MP4's URL. When downloaded and played locally, the video works fine in Quicktime.
The weirdest part of this is that of all our developers, I can get the video to work on Safari when I run the related server from my development computer. What's more, other MP4 files in the same directory have a similar problem. This has been the key to me, and I've been searching for any little difference in the way the videos transfer from the server - request/response headers, exact filesize, etc.
Headers copied from Chrome (only since Safari is harder to copy/paste from)
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
DNT:1
Host:*************:8443
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36
Response Headers
Accept-Ranges:bytes
Content-Length:44875102
Content-Type:video/mp4;charset=UTF-8
Date:Tue, 30 Dec 2014 21:11:51 GMT
ETag:W/"44875102-1419959755000"
Last-Modified:Tue, 30 Dec 2014 17:15:55 GMT
Server:Apache-Coyote/1.1
(Also, just in case this reminds you of an older issue; I'm aware Safari on Windows has been dead for ages. This issue is occurring on OS X)
EDIT: New info that might help a bit. I took a personal video from my own webserver, which was able to work from there on the problematic Safari browsers in question, and downloaded it to our server's local video directory. From there, it encounters the same issue as our other videos. This suggests to me that the MP4 itself may not matter - this is probably a server issue of some sort with our Tomcat 7 webserver. We do have the Content-Types registered correctly, which at least covers the basics, but I am curious if there are other necessary parts.
MORE INFO: I didn't think to mention this initially, but we are loading our webpages and videos over an HTTPS connection. Most of our test servers do not have valid certificates, and so we need to click through the standard browser warning that "This server might not be who it says". We are now looking into what it would take to have correct certificates on all our servers.
html5 video safari mp4
Can you provide a link to a video where this issue occurs?
– Alexander O'Mara
Jan 30 '15 at 20:21
@AlexanderO'Mara Sorry, but no; this is a part of a product under development. I'd put together a small example fiddle, but it seems very likely headers are relevant, and of course basic examples of properly encoded videos on default-config Apache servers work correctly.
– Katana314
Jan 30 '15 at 20:24
I tried configuring my local server to serve a video with similar headers and still can't reproduce it. Unless we can get an example video, I'm not sure there's much we can do but guess.
– Alexander O'Mara
Jan 30 '15 at 20:48
@AlexanderO'Mara That's unfortunately true. It is difficult for me to pass along all factors in some fiddle, like typical JS problems though. I don't think that the MP4 file in question is a factor in the problem (I may retest that thought, but I think I remember finding similar problems with other video files). otherwise, it could be to do with certain headers, or server support of a special HTTP operation, or Safari minor revisions, etc.
– Katana314
Jan 30 '15 at 21:53
2
NOTE: Some discoveries since I posted this question; Safari might have issues playing a video on a page with a self-signed certificate. In Safari, you can expand the cert's details and tell it to permanently accept a self-signed certificate, which may cause videos to work. Also, thestalled
event may fire even if it's just taking a long time to retrieve data from the server over a distant connection. This might or might not help you.
– Katana314
Aug 13 '15 at 13:49
|
show 1 more comment
up vote
9
down vote
favorite
up vote
9
down vote
favorite
We have an MP4 video on our site; it plays fine in IE9+, Firefox, Chrome, and Chrome on mac. However, on Safari, the video doesn't play at all - it does trigger a "stalled" event and then nothing loads. I would post our HTML, but I traced the problem further by finding that Safari wouldn't play it even when navigating to the original MP4's URL. When downloaded and played locally, the video works fine in Quicktime.
The weirdest part of this is that of all our developers, I can get the video to work on Safari when I run the related server from my development computer. What's more, other MP4 files in the same directory have a similar problem. This has been the key to me, and I've been searching for any little difference in the way the videos transfer from the server - request/response headers, exact filesize, etc.
Headers copied from Chrome (only since Safari is harder to copy/paste from)
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
DNT:1
Host:*************:8443
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36
Response Headers
Accept-Ranges:bytes
Content-Length:44875102
Content-Type:video/mp4;charset=UTF-8
Date:Tue, 30 Dec 2014 21:11:51 GMT
ETag:W/"44875102-1419959755000"
Last-Modified:Tue, 30 Dec 2014 17:15:55 GMT
Server:Apache-Coyote/1.1
(Also, just in case this reminds you of an older issue; I'm aware Safari on Windows has been dead for ages. This issue is occurring on OS X)
EDIT: New info that might help a bit. I took a personal video from my own webserver, which was able to work from there on the problematic Safari browsers in question, and downloaded it to our server's local video directory. From there, it encounters the same issue as our other videos. This suggests to me that the MP4 itself may not matter - this is probably a server issue of some sort with our Tomcat 7 webserver. We do have the Content-Types registered correctly, which at least covers the basics, but I am curious if there are other necessary parts.
MORE INFO: I didn't think to mention this initially, but we are loading our webpages and videos over an HTTPS connection. Most of our test servers do not have valid certificates, and so we need to click through the standard browser warning that "This server might not be who it says". We are now looking into what it would take to have correct certificates on all our servers.
html5 video safari mp4
We have an MP4 video on our site; it plays fine in IE9+, Firefox, Chrome, and Chrome on mac. However, on Safari, the video doesn't play at all - it does trigger a "stalled" event and then nothing loads. I would post our HTML, but I traced the problem further by finding that Safari wouldn't play it even when navigating to the original MP4's URL. When downloaded and played locally, the video works fine in Quicktime.
The weirdest part of this is that of all our developers, I can get the video to work on Safari when I run the related server from my development computer. What's more, other MP4 files in the same directory have a similar problem. This has been the key to me, and I've been searching for any little difference in the way the videos transfer from the server - request/response headers, exact filesize, etc.
Headers copied from Chrome (only since Safari is harder to copy/paste from)
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
DNT:1
Host:*************:8443
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36
Response Headers
Accept-Ranges:bytes
Content-Length:44875102
Content-Type:video/mp4;charset=UTF-8
Date:Tue, 30 Dec 2014 21:11:51 GMT
ETag:W/"44875102-1419959755000"
Last-Modified:Tue, 30 Dec 2014 17:15:55 GMT
Server:Apache-Coyote/1.1
(Also, just in case this reminds you of an older issue; I'm aware Safari on Windows has been dead for ages. This issue is occurring on OS X)
EDIT: New info that might help a bit. I took a personal video from my own webserver, which was able to work from there on the problematic Safari browsers in question, and downloaded it to our server's local video directory. From there, it encounters the same issue as our other videos. This suggests to me that the MP4 itself may not matter - this is probably a server issue of some sort with our Tomcat 7 webserver. We do have the Content-Types registered correctly, which at least covers the basics, but I am curious if there are other necessary parts.
MORE INFO: I didn't think to mention this initially, but we are loading our webpages and videos over an HTTPS connection. Most of our test servers do not have valid certificates, and so we need to click through the standard browser warning that "This server might not be who it says". We are now looking into what it would take to have correct certificates on all our servers.
html5 video safari mp4
html5 video safari mp4
edited Feb 4 '15 at 21:48
asked Dec 30 '14 at 21:24
Katana314
6,65221630
6,65221630
Can you provide a link to a video where this issue occurs?
– Alexander O'Mara
Jan 30 '15 at 20:21
@AlexanderO'Mara Sorry, but no; this is a part of a product under development. I'd put together a small example fiddle, but it seems very likely headers are relevant, and of course basic examples of properly encoded videos on default-config Apache servers work correctly.
– Katana314
Jan 30 '15 at 20:24
I tried configuring my local server to serve a video with similar headers and still can't reproduce it. Unless we can get an example video, I'm not sure there's much we can do but guess.
– Alexander O'Mara
Jan 30 '15 at 20:48
@AlexanderO'Mara That's unfortunately true. It is difficult for me to pass along all factors in some fiddle, like typical JS problems though. I don't think that the MP4 file in question is a factor in the problem (I may retest that thought, but I think I remember finding similar problems with other video files). otherwise, it could be to do with certain headers, or server support of a special HTTP operation, or Safari minor revisions, etc.
– Katana314
Jan 30 '15 at 21:53
2
NOTE: Some discoveries since I posted this question; Safari might have issues playing a video on a page with a self-signed certificate. In Safari, you can expand the cert's details and tell it to permanently accept a self-signed certificate, which may cause videos to work. Also, thestalled
event may fire even if it's just taking a long time to retrieve data from the server over a distant connection. This might or might not help you.
– Katana314
Aug 13 '15 at 13:49
|
show 1 more comment
Can you provide a link to a video where this issue occurs?
– Alexander O'Mara
Jan 30 '15 at 20:21
@AlexanderO'Mara Sorry, but no; this is a part of a product under development. I'd put together a small example fiddle, but it seems very likely headers are relevant, and of course basic examples of properly encoded videos on default-config Apache servers work correctly.
– Katana314
Jan 30 '15 at 20:24
I tried configuring my local server to serve a video with similar headers and still can't reproduce it. Unless we can get an example video, I'm not sure there's much we can do but guess.
– Alexander O'Mara
Jan 30 '15 at 20:48
@AlexanderO'Mara That's unfortunately true. It is difficult for me to pass along all factors in some fiddle, like typical JS problems though. I don't think that the MP4 file in question is a factor in the problem (I may retest that thought, but I think I remember finding similar problems with other video files). otherwise, it could be to do with certain headers, or server support of a special HTTP operation, or Safari minor revisions, etc.
– Katana314
Jan 30 '15 at 21:53
2
NOTE: Some discoveries since I posted this question; Safari might have issues playing a video on a page with a self-signed certificate. In Safari, you can expand the cert's details and tell it to permanently accept a self-signed certificate, which may cause videos to work. Also, thestalled
event may fire even if it's just taking a long time to retrieve data from the server over a distant connection. This might or might not help you.
– Katana314
Aug 13 '15 at 13:49
Can you provide a link to a video where this issue occurs?
– Alexander O'Mara
Jan 30 '15 at 20:21
Can you provide a link to a video where this issue occurs?
– Alexander O'Mara
Jan 30 '15 at 20:21
@AlexanderO'Mara Sorry, but no; this is a part of a product under development. I'd put together a small example fiddle, but it seems very likely headers are relevant, and of course basic examples of properly encoded videos on default-config Apache servers work correctly.
– Katana314
Jan 30 '15 at 20:24
@AlexanderO'Mara Sorry, but no; this is a part of a product under development. I'd put together a small example fiddle, but it seems very likely headers are relevant, and of course basic examples of properly encoded videos on default-config Apache servers work correctly.
– Katana314
Jan 30 '15 at 20:24
I tried configuring my local server to serve a video with similar headers and still can't reproduce it. Unless we can get an example video, I'm not sure there's much we can do but guess.
– Alexander O'Mara
Jan 30 '15 at 20:48
I tried configuring my local server to serve a video with similar headers and still can't reproduce it. Unless we can get an example video, I'm not sure there's much we can do but guess.
– Alexander O'Mara
Jan 30 '15 at 20:48
@AlexanderO'Mara That's unfortunately true. It is difficult for me to pass along all factors in some fiddle, like typical JS problems though. I don't think that the MP4 file in question is a factor in the problem (I may retest that thought, but I think I remember finding similar problems with other video files). otherwise, it could be to do with certain headers, or server support of a special HTTP operation, or Safari minor revisions, etc.
– Katana314
Jan 30 '15 at 21:53
@AlexanderO'Mara That's unfortunately true. It is difficult for me to pass along all factors in some fiddle, like typical JS problems though. I don't think that the MP4 file in question is a factor in the problem (I may retest that thought, but I think I remember finding similar problems with other video files). otherwise, it could be to do with certain headers, or server support of a special HTTP operation, or Safari minor revisions, etc.
– Katana314
Jan 30 '15 at 21:53
2
2
NOTE: Some discoveries since I posted this question; Safari might have issues playing a video on a page with a self-signed certificate. In Safari, you can expand the cert's details and tell it to permanently accept a self-signed certificate, which may cause videos to work. Also, the
stalled
event may fire even if it's just taking a long time to retrieve data from the server over a distant connection. This might or might not help you.– Katana314
Aug 13 '15 at 13:49
NOTE: Some discoveries since I posted this question; Safari might have issues playing a video on a page with a self-signed certificate. In Safari, you can expand the cert's details and tell it to permanently accept a self-signed certificate, which may cause videos to work. Also, the
stalled
event may fire even if it's just taking a long time to retrieve data from the server over a distant connection. This might or might not help you.– Katana314
Aug 13 '15 at 13:49
|
show 1 more comment
10 Answers
10
active
oldest
votes
up vote
10
down vote
Safari requires webserver to support "Range" request header in order to play your media content.
https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariWebContent/CreatingVideoforSafarioniPhone/CreatingVideoforSafarioniPhone.html#//apple_ref/doc/uid/TP40006514-SW6
For a legit "Range" request response, your webserve need to return status code "206".
1
This is true. It also means you have to either add an extra layer (e.g. Varnish or Nginx) or completely reimplement range handling in your application code for dynamically generated or converted content.
– Austin Burk
Sep 21 '17 at 4:20
add a comment |
up vote
3
down vote
Make sure controls='true' type='video/mp4' is given in your html code.
<video loop controls='true' width='100%' height='100%' src='//some_video.mp4' type='video/mp4'></video>
Hm...To my knowledge, 'controls' is a boolean attribute, meaning it doesn't need='true'
, and no resource I know of mentions a 'type=etc' attribute on the video tag. I never did give my HTML itself, but basically I have it very similar to yours, except with the src / type defined inside asource
element inside the video.
– Katana314
Feb 6 '15 at 14:18
@Katana314 I agree with you in most of cases but not this one.
– John Hua
Feb 7 '15 at 1:30
@huazihihao Agree about what?
– Katana314
Feb 7 '15 at 16:54
what was the conclusion? did anyone get this working?
– nelsonic
Mar 13 '17 at 11:06
type="*"
was the catch
– Gaurav Sharma
Mar 20 at 11:19
add a comment |
up vote
1
down vote
I uploaded a new MP4 file, but it played in SAFARI only (on both my MAC and my iPhone), not Chrome, Oasis, Firefox, or Brave. HTML code was identical to previous successes. File size and Dimensions were fine. But the Codecs on the old, working files were "H.264, AAC". The Codecs on the new, not working files were "MPEG-4, AAC". I edit my video files on VideoPad. So I looked at the specification selections on the "Export file as" options, and, sure enough, the Codecs was defaulted to MPEG-4. I selected H.264 and exported the file. Uploaded to AWS and made public. Retried my new files in the four failure browsers and BINGO!, they all worked. There is a God!
add a comment |
up vote
0
down vote
...
On a side note, does charset make any sense on the video/mp4 type at all? Try removing the charset on it.
EDIT: Yes, charset might be the problem, see: Specify content-type for documents uploaded in Magnolia
EDIT2: Not charset, woops, reading comprehension fail. Might be byte range?
To quote: "[...] we found out that Safari/iOS "uses HTTP byte-ranges for requesting audio and video files." Now we guess that the Magnolia DMS file serving doesn't support this feature, and hence the streaming fails."
What's really annoying is that I'd like an easy way of confirming this, but in Safari's developer tools, when I click on the network request for the MP4 file, it incorrectly claims that there were no request or response headers. Maybe I'll find another way of verifying.
– Katana314
Jan 30 '15 at 20:39
No chance of a test link? Private message me if need be (twitter = @nexii)
– Nexii Malthus
Jan 30 '15 at 20:44
add a comment |
up vote
0
down vote
What happens if you add these to your .htaccess
?
AddType video/ogg .ogv
AddType video/mp4 .mp4
AddType video/webm .webm
It's not an apache server, so not htaccess. It does have the MIME types through other configuration files, though.
– Katana314
Feb 6 '15 at 16:12
if you save the generated HTML as an html file, and load that into Safari (after fixing any broken urls), does it work?
– neokio
Feb 6 '15 at 16:19
No; it doesn't even work if the video url is loaded directly in the browser.
– Katana314
Feb 6 '15 at 18:05
add a comment |
up vote
0
down vote
This could indeed be an issue of missing byte-range support, depending on the version you are using. It was added to the DMSDownloadServlet in MAGNOLIA-3855 (Magnolia fix version 4.4.6).
add a comment |
up vote
0
down vote
Recently, my team ran into a particular issue that resulted in the same behavior. We were using Apache 2.4 and noticed that if we had an authentication layer such as .htpasswd enabled, Safari would not display videos at all even after authenticating. It's almost as if it does not continue to honor the initial authentication clearance for certain types of subsequent HTTP requests.
Sorry I don't have anything more technical to provide, but it's something to check for anyone experiencing video issues only in Safari.
add a comment |
up vote
0
down vote
I ran into the same problem and solved it but no other answer here is not involved to mine, so I'll remain the solution here for someone following.
I've been making my own video streaming server, which, in the questioned case, simply returns a "Ranged" mp4 file, and I found Safari does not play video carried in HTTP response lacking of "Connection" response header for some reason.
add a comment |
up vote
0
down vote
Please, forgive me if you already solve this issue!
I've had the same problem with my server videos in Safari. I was abled to solve this using POSTMAN/INSOMNIA for check the headers that my server is sending. Chrome may can trick your, once that in this browser the video works fine!
If the video is not ranged(full video request) your server must return status(200) and check it out if the 'Accept-Ranges:bytes' is sent from your server.
Header sample status 200:
Server: nginx
Date: Wed, 25 Jul 2018 17:34:18 GMT
Content-Type: video/mp4
Content-Length: 22995782
Connection: keep-alive
X-Powered-By: Express
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, PATCH, DELETE
Access-Control-Allow-Headers: X-Requested-With,content-type
Access-Control-Allow-Credentials: true
Accept-Ranges: bytes
if the video is ranged your server must return status(206) with range headers correctly.
Header sample status 206:
Server: nginx
Date: Wed, 25 Jul 2018 18:13:07 GMT
Content-Type: video/mp4
Content-Length: 1023
Connection: keep-alive
X-Powered-By: Express
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, PATCH, DELETE
Access-Control-Allow-Headers: X-Requested-With,content-type
Access-Control-Allow-Credentials: true
Accept-Ranges: bytes
Content-Range: bytes 1-1023/22995782
I hope this help you! my best regards,
Paulo Durço
add a comment |
up vote
0
down vote
Safari requires the server to support byte ranges and it also ignores mime type in preference to a file type suffix.
Please see my answer at https://stackoverflow.com/a/51901198/1047992
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f27712778%2fvideo-plays-in-other-browsers-but-not-safari%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
10 Answers
10
active
oldest
votes
10 Answers
10
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
10
down vote
Safari requires webserver to support "Range" request header in order to play your media content.
https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariWebContent/CreatingVideoforSafarioniPhone/CreatingVideoforSafarioniPhone.html#//apple_ref/doc/uid/TP40006514-SW6
For a legit "Range" request response, your webserve need to return status code "206".
1
This is true. It also means you have to either add an extra layer (e.g. Varnish or Nginx) or completely reimplement range handling in your application code for dynamically generated or converted content.
– Austin Burk
Sep 21 '17 at 4:20
add a comment |
up vote
10
down vote
Safari requires webserver to support "Range" request header in order to play your media content.
https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariWebContent/CreatingVideoforSafarioniPhone/CreatingVideoforSafarioniPhone.html#//apple_ref/doc/uid/TP40006514-SW6
For a legit "Range" request response, your webserve need to return status code "206".
1
This is true. It also means you have to either add an extra layer (e.g. Varnish or Nginx) or completely reimplement range handling in your application code for dynamically generated or converted content.
– Austin Burk
Sep 21 '17 at 4:20
add a comment |
up vote
10
down vote
up vote
10
down vote
Safari requires webserver to support "Range" request header in order to play your media content.
https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariWebContent/CreatingVideoforSafarioniPhone/CreatingVideoforSafarioniPhone.html#//apple_ref/doc/uid/TP40006514-SW6
For a legit "Range" request response, your webserve need to return status code "206".
Safari requires webserver to support "Range" request header in order to play your media content.
https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariWebContent/CreatingVideoforSafarioniPhone/CreatingVideoforSafarioniPhone.html#//apple_ref/doc/uid/TP40006514-SW6
For a legit "Range" request response, your webserve need to return status code "206".
answered Mar 30 '16 at 3:42
Reeve Lau
10817
10817
1
This is true. It also means you have to either add an extra layer (e.g. Varnish or Nginx) or completely reimplement range handling in your application code for dynamically generated or converted content.
– Austin Burk
Sep 21 '17 at 4:20
add a comment |
1
This is true. It also means you have to either add an extra layer (e.g. Varnish or Nginx) or completely reimplement range handling in your application code for dynamically generated or converted content.
– Austin Burk
Sep 21 '17 at 4:20
1
1
This is true. It also means you have to either add an extra layer (e.g. Varnish or Nginx) or completely reimplement range handling in your application code for dynamically generated or converted content.
– Austin Burk
Sep 21 '17 at 4:20
This is true. It also means you have to either add an extra layer (e.g. Varnish or Nginx) or completely reimplement range handling in your application code for dynamically generated or converted content.
– Austin Burk
Sep 21 '17 at 4:20
add a comment |
up vote
3
down vote
Make sure controls='true' type='video/mp4' is given in your html code.
<video loop controls='true' width='100%' height='100%' src='//some_video.mp4' type='video/mp4'></video>
Hm...To my knowledge, 'controls' is a boolean attribute, meaning it doesn't need='true'
, and no resource I know of mentions a 'type=etc' attribute on the video tag. I never did give my HTML itself, but basically I have it very similar to yours, except with the src / type defined inside asource
element inside the video.
– Katana314
Feb 6 '15 at 14:18
@Katana314 I agree with you in most of cases but not this one.
– John Hua
Feb 7 '15 at 1:30
@huazihihao Agree about what?
– Katana314
Feb 7 '15 at 16:54
what was the conclusion? did anyone get this working?
– nelsonic
Mar 13 '17 at 11:06
type="*"
was the catch
– Gaurav Sharma
Mar 20 at 11:19
add a comment |
up vote
3
down vote
Make sure controls='true' type='video/mp4' is given in your html code.
<video loop controls='true' width='100%' height='100%' src='//some_video.mp4' type='video/mp4'></video>
Hm...To my knowledge, 'controls' is a boolean attribute, meaning it doesn't need='true'
, and no resource I know of mentions a 'type=etc' attribute on the video tag. I never did give my HTML itself, but basically I have it very similar to yours, except with the src / type defined inside asource
element inside the video.
– Katana314
Feb 6 '15 at 14:18
@Katana314 I agree with you in most of cases but not this one.
– John Hua
Feb 7 '15 at 1:30
@huazihihao Agree about what?
– Katana314
Feb 7 '15 at 16:54
what was the conclusion? did anyone get this working?
– nelsonic
Mar 13 '17 at 11:06
type="*"
was the catch
– Gaurav Sharma
Mar 20 at 11:19
add a comment |
up vote
3
down vote
up vote
3
down vote
Make sure controls='true' type='video/mp4' is given in your html code.
<video loop controls='true' width='100%' height='100%' src='//some_video.mp4' type='video/mp4'></video>
Make sure controls='true' type='video/mp4' is given in your html code.
<video loop controls='true' width='100%' height='100%' src='//some_video.mp4' type='video/mp4'></video>
answered Feb 6 '15 at 7:58
John Hua
1,001814
1,001814
Hm...To my knowledge, 'controls' is a boolean attribute, meaning it doesn't need='true'
, and no resource I know of mentions a 'type=etc' attribute on the video tag. I never did give my HTML itself, but basically I have it very similar to yours, except with the src / type defined inside asource
element inside the video.
– Katana314
Feb 6 '15 at 14:18
@Katana314 I agree with you in most of cases but not this one.
– John Hua
Feb 7 '15 at 1:30
@huazihihao Agree about what?
– Katana314
Feb 7 '15 at 16:54
what was the conclusion? did anyone get this working?
– nelsonic
Mar 13 '17 at 11:06
type="*"
was the catch
– Gaurav Sharma
Mar 20 at 11:19
add a comment |
Hm...To my knowledge, 'controls' is a boolean attribute, meaning it doesn't need='true'
, and no resource I know of mentions a 'type=etc' attribute on the video tag. I never did give my HTML itself, but basically I have it very similar to yours, except with the src / type defined inside asource
element inside the video.
– Katana314
Feb 6 '15 at 14:18
@Katana314 I agree with you in most of cases but not this one.
– John Hua
Feb 7 '15 at 1:30
@huazihihao Agree about what?
– Katana314
Feb 7 '15 at 16:54
what was the conclusion? did anyone get this working?
– nelsonic
Mar 13 '17 at 11:06
type="*"
was the catch
– Gaurav Sharma
Mar 20 at 11:19
Hm...To my knowledge, 'controls' is a boolean attribute, meaning it doesn't need
='true'
, and no resource I know of mentions a 'type=etc' attribute on the video tag. I never did give my HTML itself, but basically I have it very similar to yours, except with the src / type defined inside a source
element inside the video.– Katana314
Feb 6 '15 at 14:18
Hm...To my knowledge, 'controls' is a boolean attribute, meaning it doesn't need
='true'
, and no resource I know of mentions a 'type=etc' attribute on the video tag. I never did give my HTML itself, but basically I have it very similar to yours, except with the src / type defined inside a source
element inside the video.– Katana314
Feb 6 '15 at 14:18
@Katana314 I agree with you in most of cases but not this one.
– John Hua
Feb 7 '15 at 1:30
@Katana314 I agree with you in most of cases but not this one.
– John Hua
Feb 7 '15 at 1:30
@huazihihao Agree about what?
– Katana314
Feb 7 '15 at 16:54
@huazihihao Agree about what?
– Katana314
Feb 7 '15 at 16:54
what was the conclusion? did anyone get this working?
– nelsonic
Mar 13 '17 at 11:06
what was the conclusion? did anyone get this working?
– nelsonic
Mar 13 '17 at 11:06
type="*"
was the catch– Gaurav Sharma
Mar 20 at 11:19
type="*"
was the catch– Gaurav Sharma
Mar 20 at 11:19
add a comment |
up vote
1
down vote
I uploaded a new MP4 file, but it played in SAFARI only (on both my MAC and my iPhone), not Chrome, Oasis, Firefox, or Brave. HTML code was identical to previous successes. File size and Dimensions were fine. But the Codecs on the old, working files were "H.264, AAC". The Codecs on the new, not working files were "MPEG-4, AAC". I edit my video files on VideoPad. So I looked at the specification selections on the "Export file as" options, and, sure enough, the Codecs was defaulted to MPEG-4. I selected H.264 and exported the file. Uploaded to AWS and made public. Retried my new files in the four failure browsers and BINGO!, they all worked. There is a God!
add a comment |
up vote
1
down vote
I uploaded a new MP4 file, but it played in SAFARI only (on both my MAC and my iPhone), not Chrome, Oasis, Firefox, or Brave. HTML code was identical to previous successes. File size and Dimensions were fine. But the Codecs on the old, working files were "H.264, AAC". The Codecs on the new, not working files were "MPEG-4, AAC". I edit my video files on VideoPad. So I looked at the specification selections on the "Export file as" options, and, sure enough, the Codecs was defaulted to MPEG-4. I selected H.264 and exported the file. Uploaded to AWS and made public. Retried my new files in the four failure browsers and BINGO!, they all worked. There is a God!
add a comment |
up vote
1
down vote
up vote
1
down vote
I uploaded a new MP4 file, but it played in SAFARI only (on both my MAC and my iPhone), not Chrome, Oasis, Firefox, or Brave. HTML code was identical to previous successes. File size and Dimensions were fine. But the Codecs on the old, working files were "H.264, AAC". The Codecs on the new, not working files were "MPEG-4, AAC". I edit my video files on VideoPad. So I looked at the specification selections on the "Export file as" options, and, sure enough, the Codecs was defaulted to MPEG-4. I selected H.264 and exported the file. Uploaded to AWS and made public. Retried my new files in the four failure browsers and BINGO!, they all worked. There is a God!
I uploaded a new MP4 file, but it played in SAFARI only (on both my MAC and my iPhone), not Chrome, Oasis, Firefox, or Brave. HTML code was identical to previous successes. File size and Dimensions were fine. But the Codecs on the old, working files were "H.264, AAC". The Codecs on the new, not working files were "MPEG-4, AAC". I edit my video files on VideoPad. So I looked at the specification selections on the "Export file as" options, and, sure enough, the Codecs was defaulted to MPEG-4. I selected H.264 and exported the file. Uploaded to AWS and made public. Retried my new files in the four failure browsers and BINGO!, they all worked. There is a God!
answered Nov 12 at 4:27
David Shoup
111
111
add a comment |
add a comment |
up vote
0
down vote
...
On a side note, does charset make any sense on the video/mp4 type at all? Try removing the charset on it.
EDIT: Yes, charset might be the problem, see: Specify content-type for documents uploaded in Magnolia
EDIT2: Not charset, woops, reading comprehension fail. Might be byte range?
To quote: "[...] we found out that Safari/iOS "uses HTTP byte-ranges for requesting audio and video files." Now we guess that the Magnolia DMS file serving doesn't support this feature, and hence the streaming fails."
What's really annoying is that I'd like an easy way of confirming this, but in Safari's developer tools, when I click on the network request for the MP4 file, it incorrectly claims that there were no request or response headers. Maybe I'll find another way of verifying.
– Katana314
Jan 30 '15 at 20:39
No chance of a test link? Private message me if need be (twitter = @nexii)
– Nexii Malthus
Jan 30 '15 at 20:44
add a comment |
up vote
0
down vote
...
On a side note, does charset make any sense on the video/mp4 type at all? Try removing the charset on it.
EDIT: Yes, charset might be the problem, see: Specify content-type for documents uploaded in Magnolia
EDIT2: Not charset, woops, reading comprehension fail. Might be byte range?
To quote: "[...] we found out that Safari/iOS "uses HTTP byte-ranges for requesting audio and video files." Now we guess that the Magnolia DMS file serving doesn't support this feature, and hence the streaming fails."
What's really annoying is that I'd like an easy way of confirming this, but in Safari's developer tools, when I click on the network request for the MP4 file, it incorrectly claims that there were no request or response headers. Maybe I'll find another way of verifying.
– Katana314
Jan 30 '15 at 20:39
No chance of a test link? Private message me if need be (twitter = @nexii)
– Nexii Malthus
Jan 30 '15 at 20:44
add a comment |
up vote
0
down vote
up vote
0
down vote
...
On a side note, does charset make any sense on the video/mp4 type at all? Try removing the charset on it.
EDIT: Yes, charset might be the problem, see: Specify content-type for documents uploaded in Magnolia
EDIT2: Not charset, woops, reading comprehension fail. Might be byte range?
To quote: "[...] we found out that Safari/iOS "uses HTTP byte-ranges for requesting audio and video files." Now we guess that the Magnolia DMS file serving doesn't support this feature, and hence the streaming fails."
...
On a side note, does charset make any sense on the video/mp4 type at all? Try removing the charset on it.
EDIT: Yes, charset might be the problem, see: Specify content-type for documents uploaded in Magnolia
EDIT2: Not charset, woops, reading comprehension fail. Might be byte range?
To quote: "[...] we found out that Safari/iOS "uses HTTP byte-ranges for requesting audio and video files." Now we guess that the Magnolia DMS file serving doesn't support this feature, and hence the streaming fails."
edited May 23 '17 at 12:25
Community♦
11
11
answered Jan 30 '15 at 20:12
Nexii Malthus
573411
573411
What's really annoying is that I'd like an easy way of confirming this, but in Safari's developer tools, when I click on the network request for the MP4 file, it incorrectly claims that there were no request or response headers. Maybe I'll find another way of verifying.
– Katana314
Jan 30 '15 at 20:39
No chance of a test link? Private message me if need be (twitter = @nexii)
– Nexii Malthus
Jan 30 '15 at 20:44
add a comment |
What's really annoying is that I'd like an easy way of confirming this, but in Safari's developer tools, when I click on the network request for the MP4 file, it incorrectly claims that there were no request or response headers. Maybe I'll find another way of verifying.
– Katana314
Jan 30 '15 at 20:39
No chance of a test link? Private message me if need be (twitter = @nexii)
– Nexii Malthus
Jan 30 '15 at 20:44
What's really annoying is that I'd like an easy way of confirming this, but in Safari's developer tools, when I click on the network request for the MP4 file, it incorrectly claims that there were no request or response headers. Maybe I'll find another way of verifying.
– Katana314
Jan 30 '15 at 20:39
What's really annoying is that I'd like an easy way of confirming this, but in Safari's developer tools, when I click on the network request for the MP4 file, it incorrectly claims that there were no request or response headers. Maybe I'll find another way of verifying.
– Katana314
Jan 30 '15 at 20:39
No chance of a test link? Private message me if need be (twitter = @nexii)
– Nexii Malthus
Jan 30 '15 at 20:44
No chance of a test link? Private message me if need be (twitter = @nexii)
– Nexii Malthus
Jan 30 '15 at 20:44
add a comment |
up vote
0
down vote
What happens if you add these to your .htaccess
?
AddType video/ogg .ogv
AddType video/mp4 .mp4
AddType video/webm .webm
It's not an apache server, so not htaccess. It does have the MIME types through other configuration files, though.
– Katana314
Feb 6 '15 at 16:12
if you save the generated HTML as an html file, and load that into Safari (after fixing any broken urls), does it work?
– neokio
Feb 6 '15 at 16:19
No; it doesn't even work if the video url is loaded directly in the browser.
– Katana314
Feb 6 '15 at 18:05
add a comment |
up vote
0
down vote
What happens if you add these to your .htaccess
?
AddType video/ogg .ogv
AddType video/mp4 .mp4
AddType video/webm .webm
It's not an apache server, so not htaccess. It does have the MIME types through other configuration files, though.
– Katana314
Feb 6 '15 at 16:12
if you save the generated HTML as an html file, and load that into Safari (after fixing any broken urls), does it work?
– neokio
Feb 6 '15 at 16:19
No; it doesn't even work if the video url is loaded directly in the browser.
– Katana314
Feb 6 '15 at 18:05
add a comment |
up vote
0
down vote
up vote
0
down vote
What happens if you add these to your .htaccess
?
AddType video/ogg .ogv
AddType video/mp4 .mp4
AddType video/webm .webm
What happens if you add these to your .htaccess
?
AddType video/ogg .ogv
AddType video/mp4 .mp4
AddType video/webm .webm
answered Feb 6 '15 at 15:50
neokio
4,1442748
4,1442748
It's not an apache server, so not htaccess. It does have the MIME types through other configuration files, though.
– Katana314
Feb 6 '15 at 16:12
if you save the generated HTML as an html file, and load that into Safari (after fixing any broken urls), does it work?
– neokio
Feb 6 '15 at 16:19
No; it doesn't even work if the video url is loaded directly in the browser.
– Katana314
Feb 6 '15 at 18:05
add a comment |
It's not an apache server, so not htaccess. It does have the MIME types through other configuration files, though.
– Katana314
Feb 6 '15 at 16:12
if you save the generated HTML as an html file, and load that into Safari (after fixing any broken urls), does it work?
– neokio
Feb 6 '15 at 16:19
No; it doesn't even work if the video url is loaded directly in the browser.
– Katana314
Feb 6 '15 at 18:05
It's not an apache server, so not htaccess. It does have the MIME types through other configuration files, though.
– Katana314
Feb 6 '15 at 16:12
It's not an apache server, so not htaccess. It does have the MIME types through other configuration files, though.
– Katana314
Feb 6 '15 at 16:12
if you save the generated HTML as an html file, and load that into Safari (after fixing any broken urls), does it work?
– neokio
Feb 6 '15 at 16:19
if you save the generated HTML as an html file, and load that into Safari (after fixing any broken urls), does it work?
– neokio
Feb 6 '15 at 16:19
No; it doesn't even work if the video url is loaded directly in the browser.
– Katana314
Feb 6 '15 at 18:05
No; it doesn't even work if the video url is loaded directly in the browser.
– Katana314
Feb 6 '15 at 18:05
add a comment |
up vote
0
down vote
This could indeed be an issue of missing byte-range support, depending on the version you are using. It was added to the DMSDownloadServlet in MAGNOLIA-3855 (Magnolia fix version 4.4.6).
add a comment |
up vote
0
down vote
This could indeed be an issue of missing byte-range support, depending on the version you are using. It was added to the DMSDownloadServlet in MAGNOLIA-3855 (Magnolia fix version 4.4.6).
add a comment |
up vote
0
down vote
up vote
0
down vote
This could indeed be an issue of missing byte-range support, depending on the version you are using. It was added to the DMSDownloadServlet in MAGNOLIA-3855 (Magnolia fix version 4.4.6).
This could indeed be an issue of missing byte-range support, depending on the version you are using. It was added to the DMSDownloadServlet in MAGNOLIA-3855 (Magnolia fix version 4.4.6).
answered Feb 23 '15 at 20:42
user667
16124
16124
add a comment |
add a comment |
up vote
0
down vote
Recently, my team ran into a particular issue that resulted in the same behavior. We were using Apache 2.4 and noticed that if we had an authentication layer such as .htpasswd enabled, Safari would not display videos at all even after authenticating. It's almost as if it does not continue to honor the initial authentication clearance for certain types of subsequent HTTP requests.
Sorry I don't have anything more technical to provide, but it's something to check for anyone experiencing video issues only in Safari.
add a comment |
up vote
0
down vote
Recently, my team ran into a particular issue that resulted in the same behavior. We were using Apache 2.4 and noticed that if we had an authentication layer such as .htpasswd enabled, Safari would not display videos at all even after authenticating. It's almost as if it does not continue to honor the initial authentication clearance for certain types of subsequent HTTP requests.
Sorry I don't have anything more technical to provide, but it's something to check for anyone experiencing video issues only in Safari.
add a comment |
up vote
0
down vote
up vote
0
down vote
Recently, my team ran into a particular issue that resulted in the same behavior. We were using Apache 2.4 and noticed that if we had an authentication layer such as .htpasswd enabled, Safari would not display videos at all even after authenticating. It's almost as if it does not continue to honor the initial authentication clearance for certain types of subsequent HTTP requests.
Sorry I don't have anything more technical to provide, but it's something to check for anyone experiencing video issues only in Safari.
Recently, my team ran into a particular issue that resulted in the same behavior. We were using Apache 2.4 and noticed that if we had an authentication layer such as .htpasswd enabled, Safari would not display videos at all even after authenticating. It's almost as if it does not continue to honor the initial authentication clearance for certain types of subsequent HTTP requests.
Sorry I don't have anything more technical to provide, but it's something to check for anyone experiencing video issues only in Safari.
answered Aug 25 '17 at 13:10
RedYetiCo
300223
300223
add a comment |
add a comment |
up vote
0
down vote
I ran into the same problem and solved it but no other answer here is not involved to mine, so I'll remain the solution here for someone following.
I've been making my own video streaming server, which, in the questioned case, simply returns a "Ranged" mp4 file, and I found Safari does not play video carried in HTTP response lacking of "Connection" response header for some reason.
add a comment |
up vote
0
down vote
I ran into the same problem and solved it but no other answer here is not involved to mine, so I'll remain the solution here for someone following.
I've been making my own video streaming server, which, in the questioned case, simply returns a "Ranged" mp4 file, and I found Safari does not play video carried in HTTP response lacking of "Connection" response header for some reason.
add a comment |
up vote
0
down vote
up vote
0
down vote
I ran into the same problem and solved it but no other answer here is not involved to mine, so I'll remain the solution here for someone following.
I've been making my own video streaming server, which, in the questioned case, simply returns a "Ranged" mp4 file, and I found Safari does not play video carried in HTTP response lacking of "Connection" response header for some reason.
I ran into the same problem and solved it but no other answer here is not involved to mine, so I'll remain the solution here for someone following.
I've been making my own video streaming server, which, in the questioned case, simply returns a "Ranged" mp4 file, and I found Safari does not play video carried in HTTP response lacking of "Connection" response header for some reason.
answered Sep 4 '17 at 9:11
findall
1,92111020
1,92111020
add a comment |
add a comment |
up vote
0
down vote
Please, forgive me if you already solve this issue!
I've had the same problem with my server videos in Safari. I was abled to solve this using POSTMAN/INSOMNIA for check the headers that my server is sending. Chrome may can trick your, once that in this browser the video works fine!
If the video is not ranged(full video request) your server must return status(200) and check it out if the 'Accept-Ranges:bytes' is sent from your server.
Header sample status 200:
Server: nginx
Date: Wed, 25 Jul 2018 17:34:18 GMT
Content-Type: video/mp4
Content-Length: 22995782
Connection: keep-alive
X-Powered-By: Express
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, PATCH, DELETE
Access-Control-Allow-Headers: X-Requested-With,content-type
Access-Control-Allow-Credentials: true
Accept-Ranges: bytes
if the video is ranged your server must return status(206) with range headers correctly.
Header sample status 206:
Server: nginx
Date: Wed, 25 Jul 2018 18:13:07 GMT
Content-Type: video/mp4
Content-Length: 1023
Connection: keep-alive
X-Powered-By: Express
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, PATCH, DELETE
Access-Control-Allow-Headers: X-Requested-With,content-type
Access-Control-Allow-Credentials: true
Accept-Ranges: bytes
Content-Range: bytes 1-1023/22995782
I hope this help you! my best regards,
Paulo Durço
add a comment |
up vote
0
down vote
Please, forgive me if you already solve this issue!
I've had the same problem with my server videos in Safari. I was abled to solve this using POSTMAN/INSOMNIA for check the headers that my server is sending. Chrome may can trick your, once that in this browser the video works fine!
If the video is not ranged(full video request) your server must return status(200) and check it out if the 'Accept-Ranges:bytes' is sent from your server.
Header sample status 200:
Server: nginx
Date: Wed, 25 Jul 2018 17:34:18 GMT
Content-Type: video/mp4
Content-Length: 22995782
Connection: keep-alive
X-Powered-By: Express
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, PATCH, DELETE
Access-Control-Allow-Headers: X-Requested-With,content-type
Access-Control-Allow-Credentials: true
Accept-Ranges: bytes
if the video is ranged your server must return status(206) with range headers correctly.
Header sample status 206:
Server: nginx
Date: Wed, 25 Jul 2018 18:13:07 GMT
Content-Type: video/mp4
Content-Length: 1023
Connection: keep-alive
X-Powered-By: Express
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, PATCH, DELETE
Access-Control-Allow-Headers: X-Requested-With,content-type
Access-Control-Allow-Credentials: true
Accept-Ranges: bytes
Content-Range: bytes 1-1023/22995782
I hope this help you! my best regards,
Paulo Durço
add a comment |
up vote
0
down vote
up vote
0
down vote
Please, forgive me if you already solve this issue!
I've had the same problem with my server videos in Safari. I was abled to solve this using POSTMAN/INSOMNIA for check the headers that my server is sending. Chrome may can trick your, once that in this browser the video works fine!
If the video is not ranged(full video request) your server must return status(200) and check it out if the 'Accept-Ranges:bytes' is sent from your server.
Header sample status 200:
Server: nginx
Date: Wed, 25 Jul 2018 17:34:18 GMT
Content-Type: video/mp4
Content-Length: 22995782
Connection: keep-alive
X-Powered-By: Express
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, PATCH, DELETE
Access-Control-Allow-Headers: X-Requested-With,content-type
Access-Control-Allow-Credentials: true
Accept-Ranges: bytes
if the video is ranged your server must return status(206) with range headers correctly.
Header sample status 206:
Server: nginx
Date: Wed, 25 Jul 2018 18:13:07 GMT
Content-Type: video/mp4
Content-Length: 1023
Connection: keep-alive
X-Powered-By: Express
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, PATCH, DELETE
Access-Control-Allow-Headers: X-Requested-With,content-type
Access-Control-Allow-Credentials: true
Accept-Ranges: bytes
Content-Range: bytes 1-1023/22995782
I hope this help you! my best regards,
Paulo Durço
Please, forgive me if you already solve this issue!
I've had the same problem with my server videos in Safari. I was abled to solve this using POSTMAN/INSOMNIA for check the headers that my server is sending. Chrome may can trick your, once that in this browser the video works fine!
If the video is not ranged(full video request) your server must return status(200) and check it out if the 'Accept-Ranges:bytes' is sent from your server.
Header sample status 200:
Server: nginx
Date: Wed, 25 Jul 2018 17:34:18 GMT
Content-Type: video/mp4
Content-Length: 22995782
Connection: keep-alive
X-Powered-By: Express
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, PATCH, DELETE
Access-Control-Allow-Headers: X-Requested-With,content-type
Access-Control-Allow-Credentials: true
Accept-Ranges: bytes
if the video is ranged your server must return status(206) with range headers correctly.
Header sample status 206:
Server: nginx
Date: Wed, 25 Jul 2018 18:13:07 GMT
Content-Type: video/mp4
Content-Length: 1023
Connection: keep-alive
X-Powered-By: Express
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, PATCH, DELETE
Access-Control-Allow-Headers: X-Requested-With,content-type
Access-Control-Allow-Credentials: true
Accept-Ranges: bytes
Content-Range: bytes 1-1023/22995782
I hope this help you! my best regards,
Paulo Durço
answered Jul 25 at 18:21
Paulo Sérgio Durço
1
1
add a comment |
add a comment |
up vote
0
down vote
Safari requires the server to support byte ranges and it also ignores mime type in preference to a file type suffix.
Please see my answer at https://stackoverflow.com/a/51901198/1047992
add a comment |
up vote
0
down vote
Safari requires the server to support byte ranges and it also ignores mime type in preference to a file type suffix.
Please see my answer at https://stackoverflow.com/a/51901198/1047992
add a comment |
up vote
0
down vote
up vote
0
down vote
Safari requires the server to support byte ranges and it also ignores mime type in preference to a file type suffix.
Please see my answer at https://stackoverflow.com/a/51901198/1047992
Safari requires the server to support byte ranges and it also ignores mime type in preference to a file type suffix.
Please see my answer at https://stackoverflow.com/a/51901198/1047992
answered Aug 17 at 18:42
David
809914
809914
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f27712778%2fvideo-plays-in-other-browsers-but-not-safari%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Can you provide a link to a video where this issue occurs?
– Alexander O'Mara
Jan 30 '15 at 20:21
@AlexanderO'Mara Sorry, but no; this is a part of a product under development. I'd put together a small example fiddle, but it seems very likely headers are relevant, and of course basic examples of properly encoded videos on default-config Apache servers work correctly.
– Katana314
Jan 30 '15 at 20:24
I tried configuring my local server to serve a video with similar headers and still can't reproduce it. Unless we can get an example video, I'm not sure there's much we can do but guess.
– Alexander O'Mara
Jan 30 '15 at 20:48
@AlexanderO'Mara That's unfortunately true. It is difficult for me to pass along all factors in some fiddle, like typical JS problems though. I don't think that the MP4 file in question is a factor in the problem (I may retest that thought, but I think I remember finding similar problems with other video files). otherwise, it could be to do with certain headers, or server support of a special HTTP operation, or Safari minor revisions, etc.
– Katana314
Jan 30 '15 at 21:53
2
NOTE: Some discoveries since I posted this question; Safari might have issues playing a video on a page with a self-signed certificate. In Safari, you can expand the cert's details and tell it to permanently accept a self-signed certificate, which may cause videos to work. Also, the
stalled
event may fire even if it's just taking a long time to retrieve data from the server over a distant connection. This might or might not help you.– Katana314
Aug 13 '15 at 13:49