Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

HTTP Pseudo Streaming from IIS

I thought I'd share what I found with regards to Pseudo Streaming from IIS and it's impact on iOS devices.

I've been experiencing issues with iPad/iPhone videos, with the error message "The video could not be loaded, either because the server or network failed or because the format is not supported". I spent some time searching the Internet for this error and found several responses from many other people seeing this.

Initially I thought it was video encoding issues, so I spent a lot of time looking for h.264 supported profile/bitrate/resolution tables from Apple for all of their devices. After recoding from Main 3.2 to Main 3.1 for iPad and Base 3.0 for iPhones, I soon discovered it made no difference. I even downloaded the bunny video from Longtail, which was often suggested, and same result; it would not play.

It turns out, that the problem in my case is with the H264 Streaming Module for IIS 7. I expect the same problem exists with 5/6. I did find in one article that it's known to break iOS devices, but the Apache module works just fine.

Their suggested fix is to create another virtual server in IIS that contains all of the *.mp4 files, and not activate the streaming module. This solution would be fine, but if you're using forced authentication to track who views videos, such as a publicly accessible corporate site with training videos, you're going to have to do some fancy footwork with your coding (assuming you're using .NET, which is why you're using IIS in the first place).

I have no advice yet, but I'll be trying a few alternative ideas to make it work. Duplicating files as *.m4v and altering the jwPlayer code to use *.mp4 for flash and *.m4v for HTML5 might work, but seems ridiculous to have store everything twice. I'm going to also see if there's a neat way for IIS to exclude the module from the execution pipeline, based on client browser settings.

It took me a while to nut this one out, and I'm sure I can't be the only one with this problem. Disabling the module all together, of course, loses you pseudo streaming abilities so people can't seek beyond what's already downloaded, and that's not an option either.

Alex.

5 Community Answers

Up Down

Ethan Feldman

JW Player Support Agent  
0 rated :

Hi Alex,

Thanks for sharing this. This is incredibly helpful.

One other work around I can think of here is using the modes feature of the JW Embedder – http://www.longtailvideo.com/support/jw-player/jw-player-for-flash-v5/18508/jw-embedder-modes

What you can do in this case is set the provider to http and http.startparam for Flash mode only, but then for iOS, set the provider variable to video, that might do the trick, instead of having to create another virtual server.

-Ethan

Up Down

JW Player

User  
0 rated :

I have good news and bad news to update this issue.

The bad news is that whilst I was initially excited by your idea since it'd be a lot easier to implement, it didn't work. I tried a few variations as well, but bottom line is that as long as Mod264Streaming is processing the mp4 files, it simply didn't work on iOS.

The good news, is that I did find a solution without a whole second virtual server in IIS, but using vdirs using the method below. Assume all videos are in d:videofiles. Obviously the vdir names can be altered as you wish. This method also works if one of the folders is real in your site structure, and the 2nd is a vdir pointed at the first.

<ol>
<li>In the IIS administrator, add a vdir to your site /video-> d:videofiles</li>
<li>Add a 2nd vdir to your site /html5video -> d:videofiles</li>
<li>Edit /web.config in the site and add the following:

bc.. <configuration>
<location path="video">
<system.webServer>
<handlers>
<modules runAllManagedModulesForAllRequests="true" />
<add name="ModH264Streaming" path="*.mp4" verb="*" modules="ModH264Streaming" resourceType="File" preCondition="bitness32" />
</handlers>
</system.webServer>
</location>
</configuration>



</li>
</ol>

Alternatively you can enable the module globally in <configuration><system.webServer> and then use a location element on the html5video path, and remove the module by name. I prefer to enable what I need only where I need it.

Finally, when you embed the player, do something like this:

bc.. jwplayer('feature_video').setup({
provider: 'http',
file: '/video/bunny.mp4',
dock: true,
modes: [
{ type: 'flash', src: '/jwplayer/player.swf', config: { provider: 'http', file: '/video/bunny.mp4' } },
{ type: 'html5', config: { provider: 'video', file: '/html5video/bunny.mp4' } }
]
});



This isn't a complete snippet, just stripped back to demonstrate the principle.

Benefits of this solution for me are:
<ol>
<li>No duplication of video files, since the vdirs point at the same source location.</li>
<li>The streaming module is selectively applied, so it don't even get tested against other content requests.</li>
<li>Other site configuration carries to both versions (authentication for example), which would be a nightmare with a 2nd virtual server.</li>
</ol>

Alex.

Up Down

JW Player

User  
0 rated :

Please disregard the following element in my previous post. I can't go back and edit it.

bc.. <modules runAllManagedModulesForAllRequests="true" />



This is related to MVC3 and not the H264 Streaming Module, and has nothing to do with this workaround/solution.

Alex

Up Down

Ethan Feldman

JW Player Support Agent  
0 rated :

Thank you for letting me know the workaround Alex, this will help others for sure, and I am glad you were able to get this all working!

Up Down

JW Player

User  
0 rated :

Thanks for posting your problem/ solution! I ran into the same problem with ModH264 on my IIS7 server. Two virtual directories and JWPlayer fallback works great! Thanks,
Aaron

This question has received the maximum number of answers.