I apologise for asking a question asked ten thousand times on SO before. This situation seems different from the others. In short, video playback via always works on Firefox and Chrome but always fails in Internet Explorer, all versions, all Windows versions.
I have a web page set up according to Microsoft's HTML5 suggestions. A modal window supplies the video:
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" />
</head>
<body>
<div class="popupwindow">
<video controls autoplay preload="auto" style="width:100%">
<source src="streamvideo.rails?file=$fileName" type="video/mp4" />
</video>
</div>
</body>
</html>
streamvideo.rails is a Castle Monorail C# function that acquires a video file in a cloud server as a Stream and streams it back as a range request.
First off, I'm sure it's not the usual problems: the codec is probably OK, the response's Content-Type is right (video/mp4) and IE is even picking up the video correctly, at least initially. The in-browser network sniffer shows it received a small chunk of an MP4 file and then stopped.
One oddity I noticed: IE is not framing the video request as a range request whilst Chrome/FF are. Chrome's headers:
GET [my URL]?fileName=e65b0b0d-0911-4e3f-bc71-7b5d5a65db57.mp4 HTTP/1.1
Host: localhost
Connection: keep-alive
Accept-Encoding: identity;q=1, *;q=0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36
Accept: */*
DNT: 1
Accept-Language: en-US,en;q=0.8
Range: bytes=0-6130
IE's headers:
GET [same URL] HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept: */*
GetContentFeatures.DLNA.ORG: 1
Pragma: getIfoFileURI.dlna.org
Accept-Language: en-US
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
DNT: 1
Host: localhost
I speculate that if I fix this discrepancy, the problem will go away. So: why is IE deciding not to make a range request? How can I force it to? If you think I'm chasing a bogus clue, what else can I check?
This is a little late for a response. Just thought if somebody searches this, my answer would help them. What I found is that when IE requests the video content the "Accept-Ranges: Bytes" header is not present as with Firefox and Chrome, thus on first request set the response as follows (This is an ASP.Net Core example):
response.Headers.Add("Accept-Ranges", "bytes");
response.ContentLength = [length of actual video file];
response.StatusCode = (int)HttpStatusCode.OK;
response.ContentType = [ContentType of requested content];
When the response hits the browser again it will evaluate the headers and setup the video control as well as the next request with the correct headers. Now when you validate for the existence of the Range header it will be there and the code to stream will work as normal.
Hope this helps, it worked for me.
Elaborating on Jean Roux's response:
HTML5 video streaming is supported via range requests and responses. MDN has a good introduction: https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests
IE10 and IE11 on W7 and W8 do NOT make range requests (there is no Range header). Per the RFC, the server may respond with a 200 response and the entire file contents. But doing so will cause IE to not play the file (I'm not sure why, but based on the network tab in dev tools, the content is truncated, e.g. server sent ~10MB but IE was only looking at the first few KB). I had to rejigger my server so that I respond with a 206, the entire file contents, and Accept-Ranges and Content-Range headers.
BTW: you asked this before W10 was released. Both Edge and IE11 on W10 DO make the range requests.
I'm having the same issue with Chrome on Android. The range header is missing. For Internet Explorer I did something like this:
$http_range = (isset($_SERVER["HTTP_RANGE"])) ? $_SERVER["HTTP_RANGE"] : "bytes-0";
Thats in my PHP script that serves the video/mp4 data. All it does is check if the range header is set, if not, it will assume that the start of the file has been requested. Internet Explorer seems to be smart enough to then take over if the user seeks to a different part of the video, i.e. generates the required range header.
Works great in IE... however, I tried the above in Chrome and it's still not happy :((
I had the same problem.
MIME was set correctly. It was video/mp4.
I checked apache config. It supported video/mp4 and audio/mp4.
The video was encoded by H.264.
I could see the video in chrome, not in IE( from 9, 10, 11 ).
I changed the video size from 1920 x 1280 to 720 x 720 and encoded.
And it worked magically.
Now I'm searching why it worked by changing the video's width and height.
Related
I have a slideshow that I preview (custom html/js) and to make sure that I get the most recent version from the DB every time I start the slideshow preview, I have these cache statements in my html file
<!DOCTYPE html>
<!-- preview:[true]-->
<HEAD>
<title>screen</title>
<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="0" />
<meta http-equiv='Content-Type' content='text/html; charset=utf-8' />
However sometimes I still need to empty out the browser cache in order to get the most recent updates.
Is there anything else I can put in the head of my html file to prevent browsers from caching this for me? Chrome is what I mainly use, and where I have sometimes experienced this effect, but I would like a generic answer for all browsers.
---------------- UPDATE -------------------
So I included some cache control headers (thanks arkascha) but am still a bit suspicious =)
Here is what I added to my response (php/sym2)
$response->expire();
$now = new \DateTime("now");
$response->setCache(array(
'last_modified' => $now,
'max_age' => 0,
's_maxage' => 0,
'private' => true,
));
And that gives me the following Response headers
Cache-Control:max-age=0, private, s-maxage=0
Connection:Keep-Alive
Content-Type:text/html; charset=UTF-8
Date:Wed, 31 May 2017 08:41:19 GMT
Keep-Alive:timeout=5, max=100
Last-Modified:Wed, 31 May 2017 08:41:20 GMT
Server:Apache/2.2.25 (Unix) mod_ssl/2.2.25 OpenSSL/0.9.8zh DAV/2 PHP/5.5.3
Transfer-Encoding:chunked
X-Powered-By:PHP/5.5.3
... and Request Headers displays as:
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch, br
Accept-Language:sv-SE,sv;q=0.8,en-US;q=0.6,en;q=0.4
Cache-Control:max-age=0
Connection:keep-alive
Cookie:main=1111111; PHPSESSID=70c2e1a6f81a9d3dad59ed908f25b585
Host:localhost
If-Modified-Since:Wed, 31 May 2017 08:40:18 GMT
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
But on my network tab (chrome) I still see a lot of "from memory cache" and "from disk cache" in the "size" column for different resources (what is the difference between those two by the way?).
Does the http header only affect the current page and not the associated resources such as .json files?
I dynamically generate an html page in an .aspx file like this:
Response.Clear()
Response.ClearContent()
Response.ClearHeaders()
Response.Buffer = True
Response.ContentType = "text/HTML"
Response.AddHeader("Content-Disposition", "inline")
Response.OutputStream.Write(FilledBuffer, 0, FilledBuffer.Length)
Response.OutputStream.Flush()
Response.OutputStream.Close()
Response.End()
where FilledBuffer (a byte array) is valid html like:
<!DOCTYPE html>
<html>
<head>
<title>My Page</title>
</head>
<body>
<div>content</div>
</body>
</html>
When I view this in IE8+ it renders an as html page, however in Chrome it displays the html as text. My first thought is the MIME type but text/HTML is correct for html, so I am at a loss.
I must be missing something very simple here...or the internet would not work...
In fiddler the request between a standard aspx page that renders html and the above non-working page are identical, specifically:
GET http://localhost:1202/test.aspx HTTP/1.1
Host: localhost:1202
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36
Referer: http://localhost:1202/Mypage.aspx
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
The byte array used by the response stream was created with unicode encoding, thus the output was indeed unicode. Interesting that IE does not seem to care about this but Chrome recognized this was not html and simply rendered the page as text. The giveaway unicode double charter width was not displayed by Chrome and inspecting page source showed a perfectly valid looking html file. It was not until inspection in fiddler that the unicode was detected which lead to the discovery of the incorrect conversion.
In Chrome, when you look in the Developer Tools, you can see the HTML5-video calls it is making. (I'm serving them chunked per MB, so every 10-12s there is 1 file downloaded).
But in Firefox (with Firebug), I can't see these calls?
How is that possible, and what can I do to show these?
This is the HTML page I'm showing:
<html>
<head>
<link rel='stylesheet' href='/icons.css' />
<!--
<link href="/video-js.min.css" rel="stylesheet">
<script src="/ie8/videojs-ie8.min.js"></script>
-->
<link rel='stylesheet' href='/style.css' />
</head>
<body>
<video id="my-video" class="video-js vjs-default-skin vjs-big-play-centered" controls preload="auto" width="640" height="360" poster="/thumbs/movie.jpg" data-setup="{}" preload="none">
<source src="/movie.mp4?read=1" type='video/mp4'>
<p class="vjs-no-js">
To view this video please enable JavaScript, and consider upgrading to a web browser that
supports HTML5 video
</p>
</video>
<!--
<script src="/video.min.js"></script>
-->
</body>
</html>
In Chrome I can see this:
GET /movie.mp4?read=1 HTTP/1.1
Host: ******
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Accept-Encoding: identity;q=1, *;q=0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Accept: */*
Referer: http://*****/movie.mp4
Accept-Language: nl,en-GB;q=0.8,en;q=0.6,en-US;q=0.4,fr;q=0.2
Range: bytes=4000000-
In Firebug... Nothing...
I tried already looking it up on Google, but or I am not using the right terms, or noone else had the same issue before.
I'm hoping that someone here can point out what I could do about this.
Thanks!
First I thought this might be a bug in Firebug. And as Firebug is officially discontinued, the Firefox DevTools should be used instead. But I realized that the DevTools have the same problem, which gave me the idea that this must be an underlying issue.
So, the actual reason is that the video is cached once it's downloaded and reloading the page circumventing the cache with Ctrl+F5 or disabling the browser cache doesn't cause to it to be downloaded again.
You need to clear the cache (via the dialog available via Firefox menu > History > Clear Recent History... or by pressing Ctrl+Shift+Del). Then the video is downloaded again and shown in the network request lists in Firebug and the Firefox DevTools.
Firebug:
Firefox DevTools
There are several bugs filed for this. One of them, related to the Firefox DevTools, is bug 1277514.
I have a indexedDB web app which works fine in IE10 but not in IE11. The problem is that in IE11 window.indexedDB is undefined. Is IndexedDB still supported in IE11? If so, how do you open a IndexedDB database without window.indexedDB?
My Test HTML:
<!DOCTYPE html>
<html>
<head>
</head>
<body>
Hello
</body>
</html>
Output from F12 Developer Tools console:
window.indexedDB
undefined
window.msIndexedDB
undefined
window.navigator.userAgent
"Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; Touch; .NET4.0E; .NET4.0C; Tablet PC 2.0; rv:11.0) like Gecko"
After resetting the IE settings to the defaults, everything now works fine.
the problem is that in debug mode, default document mode is set to 9.
IE 9 doesn't support indexeddb.
Go to Developer tool, and set Documentation mode to 10 or above.
br,
Jan
I'm confused.
If I point by browser (Chrome or Safari on OSX) to this web site, it shows all the SVG perfectly:
http://emacsformacosx.com/
Now, if I view source on that page, copy it, and paste it into a new HTML document on my desktop, then view that with either browser, I get no SVG at all.
Why the difference?
Why does SVG work on the web site, but not in the local HTML file?
Thanks!
You renamed it to HTML, and the browser assumes html content.. while the page is text/xml ..
if you rename it to .xml and open it, you will see it just fine..
The HTTP response header information causes the browser to interpret the information as XML:
HTTP/1.1 200 OK
Date: Sun, 21 Feb 2010 02:32:02 GMT
Server: Apache/2.2.14 (Debian)
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: text/xml; charset=UTF-8
You see, the server that served up the page was smart enough to detect that this was an XML document, and told the browser. When you load the file from disk, your browser may not be smart enough to do this, and tend to rely on the file's extension to supply this information.
You could try inserting the following into the <head> element:
<meta http-equiv="Content-Type" content="text/xml; charset=UTF-8" />
You see what I did there? It's just a mirror of the HTTP response header that would have specified the document type and encoding.
The purpose of this tag is to make browsers think, "Hey, the server is telling me that this document is HTML, but the document is telling me it's XML. The document probably knows better than the server, so I'll trust it... ::interprets as XML::"