CODEWITHSUNDEEP
htmlinternet-explorervideohttp-headers
spamguy
spamguy

Reputation: 1566

HTML5 video playback fails in IE (or: Missing range request)

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?

Upvotes: 5

Views: 3487

Answers (4)

Bee Dice
Bee Dice

Reputation: 11

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.

Upvotes: 1

Al.T.Os
Al.T.Os

Reputation: 72

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.

Upvotes: 0

Jean Roux
Jean Roux

Reputation: 388

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.

Upvotes: 4

arvy3
arvy3

Reputation: 136

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 :((

Upvotes: 0

Related Questions