Mobile Video Consumption – Serving it Up

So now we’ve looked at how to produce some content – both experimenting with some output formats and some specific input formats. If you’re still following me here’s the last part in this introduction to consuming video at home and on the go. (I might make follow-up articles but at this point I’m sure you’d like to get started actually doing something.)

There’s nothing wrong with transferring the files to your device through a USB cable or similar, but this is about mobility – what will we do when we aren’t at home and need to watch a video or two? We load the content on a server, and test out the streaming options of course!

I store all my content on a Windows Storage Server 2008 R2 box where I share it as a plain Windows Share (SMB). This way I can easily access it from my HTPC and other computers at home. I can also setup things like DFS replication to other sites for backup purposes if so desired, although I suspect it would take a lot of time to sync all those gigs of video over a WAN link. Just dump it on a regular NAS box if that’s what you’ve got at hand.

In addition to my storage server I installed a separate web server to serve as the front-end for the content.


The server doesn’t need it explicitly at this point in time, but I also add “IIS Media Services 4.0”. This is a plug-in that is designed to work in tandem with Expression Encoder and serving both on-demand and live streaming scenarios. This way you can do transcoding on the fly to tailor the files specifically for the connecting clients. More on how to use this later down the page.

It can be installed by heading over to on the web server where you intend to install it:


After I had completed the install I had to reboot the server to get it to show up in the view:


Smooth streaming is a nice thing, but for now just accept it as something that is there, and we’ll move along to ordinary content presentation.

I created a new virtual directory on the web server, and I pointed this to the share I created on the Storage Server.

I’m still relying on Big Buck Bunny as my test material, and I’ve now encoded a 30-second clip with the same four presets as before:
– H.264 HD 1080p VBR, File size: 15,6 MB.
– H.264 HD 720p VBR, File size: 22,8 MB.
– H.264 Zune HD (AV Dock Playback), File size: 10,8 MB.
– H.264 iPhone / iPod Touch, File size: 6,04 MB.

I have tested these settings previously, but streaming might behave different than local playback so re-testing is necessary.

Only the fourth clip plays on the 3GS. This is due to the low resolution of this device, and on the iPhone 4 you should be able to play 720p as well. Remember that the 3GS only supports H.264 Baseline.

Did not play the fourth clip, but the three with higher quality had no problems. The error message states the file format isn’t supported for streaming, possibly something with the baseline profile? The same file does play back when stored locally on the device, so it does seem to be isolated to streaming.

Windows Phone 7
The first clip (1080p) threw up a playback error, but the remaining three worked nicely. Remember that transcoding occurs automatically when transferring with Zune, but this seems to indicate that 720p content is supported without transcoding (or rather the device does it on the fly) when streaming. And 1080p content simply isn’t supported either way (that’s actually documented so no complaints on that).

To make sure this was reproducible outside my own lab I headed over to to test a clip. Microsoft are nice enough to provide a couple of different formats for our test:

– MP4 (iPod, Zune HD) : 480×272
Works on iPhone and WP7, but not on Android.
– High Quality MP4 (iPad, WP7): 1280×720
Works on Android and WP7, but not on iPhone 3GS.
High Quality WMV : 1280×720
This file was essentially too large for mobile playback, and I did not test it.

I do not know which presets was used for producing these files (or if they used Expression Encoder even if they are MSFTSmile ), but I would say the results are similar to what I’m seeing with my locally produced files.

I used the mobile network for all my tests – no cheating with Wi-Fi which would not have produced a “proper” test scenario. I clocked my network connection to roughly 0.9 Mbps on HSDPA. The larger files had intermittent stops, and if you are on the go you might want to consider sacrificing some quality for something that will actually stream at a steady rate. If you usually have access to Wi-Fi this is of course of no concern to you. If you have an allotted amount of GBs you can use each month over the mobile network you would need to consider this as well, as it’s not a problem to go over the limit even with the compressed files if you stream daily. I found that “in real life” I transfer some content via USB, and do some over 3G – your mileage may vary.

The “optimal” solution to streaming
Well, sort of…depending on your infrastructure… Since I installed IIS Media Services I wanted to test out smooth streaming (install instructions a few paragraphs up). It’s a really cool feature where you have the content available at different bit rates, and the client will dynamically request higher or lower bit rates depending on the network conditions and/or CPU load. You can do this both on-the-fly and with pre-encoded files. You can use an additional plug-in for IIS Media Services called Transform Manager that can be configured to watch specific folders and automatically “transform” the files. Transform Manager is just in an Alpha release currently so it’s got a few kinks, but it is promising. The whole process is slightly manual at the moment though, but I expect there might be some optimizations in Service Pack 1 for Expression Encoder and I will probably return to smooth streaming when that becomes available.

I did test it out though, and found it to work very nicely on the iPhone, but not on the Android. Windows Phone 7 also supports it, but I’m waiting for the January update of Windows Phone before investigating that specific device further. While the content is optimized “automatically” this way I did find some drawbacks. Encoding the source material takes a lot more time since you need to encode multiple bitrate outputs. Which in turn also requires more disk space. And the output is intended for streaming only, so while Windows 7 will let you playback the files you’ll still need to encode a regular H.264 file as well for the non-streaming scenarios.

I do encourage you to take a look at it if you find this interesting though, and these links might help you along:

As I said, I have not ruled this scenario out, but will need to wait for a couple of updates and re-visit.

You can do a directory browsing and just click on the file you want to play back. On the desktop side of things it’s what I often end up doing (and since it’s available on an SMB share that works quite nicely too). Doesn’t look all that fancy that way though. While I haven’t created a grand pimped up design yet, I decided to try to make the appearance at least a little bit classier than that and have it presented through a web page. For the desktop scenario I made it available through a Silverlight player. Expression Encoder comes with templates for Silverlight, and you can further edit the player in Expression Blend if you want a different design. Then you can wrap it all up with Expression Web.

Yes, I know. Silverlight is dead – HTML5 is the future, and so on. I have not made the final choice in this department either, but the quickest thing to do here was to use one of the Silverlight templates available in Expression Encoder. If I later decide to use HTML5 I don’t have to re-encode the files or anything like that. This is for the desktop though – with the mobile clients Silverlight is what you would call less available. (Even Windows Phone 7 which relies heavily on Silverlight doesn’t support this in the browser yet…)

For the mobile bits I took a look at iWebKit. It’s some CSS and stuff that enables you to create web apps that look just like native apps on the iPhone. It works on Android too (the Galaxy Tab actually reports the browser info as being Safari), and if you don’t make it too much Apple-like I think it looks good there as well. The design I made actually turned out viewable even on Windows Phone 7 Winking smile

Check it out:

Here’s a couple of snapshots of what it could look like:
Desktop browser with Silverlight player

iPhone Safari

Why didn’t I use HTML5 for the mobile browsers to get video directly in the browser? I did test that as well. iOS required the HTML markup written in one way, and Android required it written another way…Clearly some work left in this department too. As for the smaller screens of the Windows Phone and the iPhone I’m not sure if it adds that much to the experience as opposed to just get a list of episodes. I’ll have to both get more familiar with HTML5 and contemplate the overall design. It will surely get more standardized in the next iterations of the browsers so it will probably/hopefully become more easy to work with. (As a slight off-topic; I have no clue as to what Google’s announcement last week of dropping H.264 support for Chrome means for Android.)

I didn’t go all the way with creating a “proper” web site in the sense of using .aspx or any other dynamic generation of HTML. Apart from the Silverlight template I just created HTML by hand as a quick-and-dirty solution. It would of course make more sense to do some coding, include browser detection and use the Encoder SDK to generate titles and descriptions based on metadata embedded in the video file. I felt that testing out different designs was easier when I didn’t have to consider any coding aspects and “forget” that programming was an option. Filling out the metadata for the file when encoding is however always a good thing to do, even though it’s no fun at all.

Some numbers
While it can be highly individual how much time it takes getting things done I thought I’d present a few numbers on the amount of time/work involved. (Note that the encoding process takes a lot of time, but doesn’t require much interaction once it’s started.) I ripped Season 04 of Miami Vice. This consists of 6 discs and has a running time of 16 hours, 41 minutes approx..
Ripping VOB files: 30 minutes
Encoding “desktop” mp4 files: 22 hours
Encoding “mobile” mp4 files: 4 hours
Manual labor (setting encoding parameters, tagging metadata, fixing html manually): 1 hour
Size of VOB files: 41,2 GB 
Size of desktop mp4 files: 20,9 GB
Size of mobile mp4 files: 10,9 GB

The manul labor involved is a very rough estimate as there was a certain amount of trying and failing the first time around. I expect this to take less time if I rip another season.

This means that you can set aside some time if you want to rip your entire collection this way, but everyone who feels even slightly like a collector knows the satisfaction of having plenty of content to show off Smile

It’s difficult to present the definitive conclusion on this, but I can share some of my thoughts. I really like the whole Zune interface – it works nicely on the desktop and it works nicely on Windows Phone 7 as well. The iPod/iTunes interface works of course, but it feels more dated sort of. The video player on the Galaxy Tab was the less satisfying visually of the mobile devices. (As previously mentioned I’m using the player supplied by the OS.) That being said the fact that it had a 7” screen, and was able to playback all resolutions made the actual “cinematic” feel much better. Coupled with a decent pair of head phones it’s almost the perfect viewing companion.

I’m also very unsure as to whether I should bother with encoding two different outputs, or if I can get by with just one file. This would of course also be dependent on whether I really want the content to be playable on all of my current devices or if I choose one or two preferred players. The iPhone 3GS is the only one really requiring the lower resolution, and as it’s not exactly a new device any longer I don’t think I’ll be using it for years coming anyways. If you choose the iOS route and want to play video you should consider getting an iPhone 4 (or standing in line for the yet to be released, and unannounced, iPhone 5).

Still, it has been fun. While I’ve had a lot of different smartphone devices for the last couple of years this scenario has really only been possible for the last year and a half or so. The devices are finally getting resolutions suitable for playback, and hardware decoding that will let the device actually process a fair amount of pixels per second. If you are the kind of guy who buys DVDs, or have an existing collection, and are the kind of person who keeps backups of the discs on your NAS you’ll definitely want to consider the mobile portion of the scenario the next time you rip a DVD.

Leave a Reply

Your email address will not be published. Required fields are marked *