Just before Christmas 2009 Roku publicly released the SDK to create channels for their amazing little $99 Roku Player, which streams movies from Netflix, Amazon and other sources. This may not sound like a big deal for the indie filmmaker, but I think it's huge. For the first time, indie's have the chance to get their movies to the TV screens of the public in a way that's not been available to them before. Not just that, but movies can be streamed in both standard definition and 720P high definition, with the only costs being your ISP costs. Also, the Roku Player is currently selling like hot cakes still, rating high on the Amazon.com best seller list over Christmas.

I've had the Roku player for about six months and have been impressed by both it and the Netflix streaming service; a $99 player and a Netflix sub as little as $8.99 month is a killer combination. Each entity that delivers content has their own "channel", through which you can navigate to various streaming content in various ways. With a Netflix subscription, you can select any movie that you've added to your instant view list on a computer. This kind of sucks since you can't browse available streaming titles through the Roku, you need to first do this via a web browser, and then they'll show up as selectable in your instant queue in the Roku. For Amazon's channel, you can search for titles directly in the Amazon Roku channel, which is a useful feature.

We're still in the process of editing and completing two movies, but recently had created a YouTube channel and had gotten several high definition clips together for that, including a three part webisode series of Sean Bonniwell's history. My day job is working as a programmer at the San Diego Supercomputer Center and so when a new SDK gets released like this I'm always interested. Presented here are my experiences in setting up a Roku channel from scratch using the SDK and the examples provided; hopefully it will be useful to others attempting to do the same...

1. Go to the Roku.com website and register (it's free). Then click on the 'developer' link at the top right of the page. You'll need to OK the TOS before you can access the SDK. Also, do checkout the Roku forum for developers - essential viewing for anyone who's developing a channel. Don't hold your breath for a Roku dev/rep to answer an urgent question; they can be absurdly slow in responding.

2. Download the SDK and unpack it. What you'll find inside are:

• PDF documents covering various development aspects
• Several complete example projects

The smart move would be to read the documentation thoroughly first (they're written very well), but if you're like me you'll crash in head first to the code. You code projects using a commercial scripting language called BrightScript, which for all intents and purposes is VBScript. For those of us who work in java development (or C, C++, C# etc) the syntax for BrightScript can seem iffy at best and it's not clear why they would have chosen this instead of something more Javascript-like. But it is what it is.

3. Enable the Roku box for development

There is no Roku player emulator in the SDK (or anywhere else, as far as I'm aware) so in order to develop for the Player, you need to have one somewhere on your network. The cheapest (non-HD) version is $79, ranging to $129 for a HD player with 802.11N, so relatively speaking they aren't that expensive. I needed an extra Roku Player for development and found a Roku HD player on the San Diego Craig's List for $50. Enabling the Roku Player as a development box involves following the Development guide instructions by pressing the Player's remote control keys in a specific order (press the 'Home' button three times, 'Up' button twice, Right, Left, Right, Left, Right - if that doesn't bring up the dev screen first time, keep trying - it requires some cadence in the button presses), and then the box will reboot. Once activated for development, you can write and load channels onto your local Roku for testing. In fact, you have to do this since you'll also use the Player to package the channel for uploading to your collection of private channels (more about private channels later).

4. Start monkeying around with the example code!

The code examples include the codebase for the Flickr channel and some audio channel examples, but of interest to me were the SimpleVideoPlayer and VideoPlayer example code since I wanted to develop a channel that can act as an outlet for our documentary film productions. I found the SimpleVideoPlayer channel useful for getting my feet wet in understanding the various components required for setting up a channel. Creating a channel involves using a combination of the screen components and controller, with BrightScript acting as the glue between them. The component Reference guide goes into some detail about these components, but in essence they are specialized visual and/or control widgets that are programmatically instantiated, initialized with data and then activated. For those coming from a non-programming background, this might seem like very low level programming indeed, but it's not; components such as the roVideoScreen which displays video to the user encapsulate many different kinds of functionality that's performed for you automagically, ranging from choosing the most appropriate stream based on the end-user's network bandwidth, to providing fast forward and reverse capability.

Files (for example image files) are referenced as being in the installation package or through a web server URL. Also, the examples have a lot of very useful utility methods that you'll want to use again and again.

My first endeavors involved simply learning how to package up the working examples and load them onto the player (see below); as I got more adventurous I would modify the code and reload, noting any bugs hit and changes in the appearance of the UI. This kind of small tweeking at the start gives you some confidence to move forward. I then started more significant modification of the VideoPlayer app.

5. Test the code on the Player

You load your test channels onto your Roku development box by using a web interface that's accessible on the player on the standard web port (80). First they need to be zipped up. I work on a Mac, and I figured that the "compress" option in the right menu click would be OK to zip them, but I needed to use the command line zip instead.  Using a browser like FireFox, you open the installation page, select your zip file and then press the button. After a few seconds it will respond with a result (you can also delete the channel via the same page). For the VideoPlayer app, 'make install' will both zip and upload your zipfile to the Roku box and can save a lot of dev time (make sure to set the appropriate environment variable indicating the target IP address).

Once the zip file is uploaded, on the player file is immediately uncompressed, compiled and the application starts. You can see the newly uploaded channel in the top menu channel lineup, and you can start to use it. If that was the limit of feedback from the sytem, it would be problematic. Fortunately the system has a debugger on board, that you can access by telnetting to port 8085 on the player, which immediately provides you with the debug output. If it gives you the debugger command line prompt it means that you've hit a majort problem; you can check variables and if you press "c" you can move ahead. Depending on the severity of the problem, the app can continue or it can cause the player to reboot. The biggest problem about rebooting seems to be the time factor in waiting for the box to come online again. Sometimes I've noticed that it can come online with a different IP address that it's pulled from my local DHCP, which is annoying but worth checking for (you can check the IP address under setting-> player info). 

6. Modifying the VideoPlayer application

The included VideoPlayer demo example in the SDK is a Godsend it basically provides all of the demo code that you need to create a sophisticated video channel. The way that it works is as follows:

The Channel requests a xml category file (termed a feed) from a webserver when the user clicks on the VideoPlayer channel in the top menu. This file contains different categories of videos that will show up in the next menu level under different images. You supply the locations of images for the categories in the Category feed. For example, my category feed looked something like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<categories>
    <category title="Free Trailers and Clips" description="Trailers of features films coming soon!" sd_img="http://mydomain.com/videoplayer/images/trailersandclips.jpg" hd_img="http://mydomain.com/videoplayer/images/trailersandclips.jpg">
        <categoryLeaf title="Winning BIG! with Debbie Bramwell" description="Female Bodybuilder sensation Debbie Bramwell trains for the event of her life!" feed="https://mydomain.com/videoplayer/xml/debbie_trailer.xml"/>
        <categoryLeaf title="Return to Lake Havasu" description="The incredible story behind the 1971 cult classic film Day of the Wolves" feed="https://mydomain.com/videoplayer/xml/return_trailers.xml" />
    </category>
    <category title="Full Length Feature Films" description="Watch full length feature films on your TV" sd_img="http://mydomain.com/videoplayer/images/featurefilms.jpg" hd_img="http://mydomain.com/videoplayer/images/featurefilms.jpg">
           <categoryLeaf title="Full length feature films" description="requires registration" feed="https://mydomain.com/videoplayer/xml/features.xml" />   
    </category>
    <category title="Free Webisodes" description="Bite-sized episodes" sd_img="http://mydomain.com/videoplayer/images/webisodes.jpg" hd_img="http://mydomain.com/videoplayer/images/webisodes.jpg">
        <categoryLeaf title="A Conversation Beyond the Garage" description="Rock music icon Sean Bonniwell discusses his early years in music" feed="https://mydomain.com/videoplayer/xml/sean.xml" />
    </category>

</categories>

The categoryLeaf nodes under each category provides a URL to a further XML feed for specific category entries. Note that the feed URL's are 'https', i.e. they are using a secure HTTP server. The Roku box supports TLS web access, but it can be a bit finicky to set up since you need to include server public certificates (discussed later).

7. Packaging and uploading

Once you've got a tested application you'll want to upload it to your private channel collection at the Roku site. To do this, you'll need to package the application first; this involves generating a dev ID and password key from the Roku Player, and then packaging the zip file. The instructions to do this are clear and the procedure works without any problems. Once you have a package file, you use the Roku.com website channel interface to upload the package into your list of private channels. Once the channels are in your collection, you can provide the channel ID to anyone and they can subscribe by going through to a specific URL and entering the channel ID. If I read correctly Roku apparently has no interest in policing private channels, and apparently porn channels have started to appear. Once in your private channel list, you can submit a channel for inclusion in the Roku Channel store.

8. Optimum encoding of streaming videos

There's a lot of interest, as judged by posts in the Roku forum for a Roku app to stream local content (for example, ripped DVD's, etc.). For our work, we are starting with high bitrate HD video so we should be in a good position to transcode for streaming in very high quality. The roku player accepts H264 and VC-1 encoding. H264 is now fairly ubiquitous, with even Flash supporting 264 streams. VC-1 is otherwise known as Windows Media 9 Advanced Profile. Netflix uses VC-1 at 3800mbs for their highest bitrate HD streams, in contrast to Amazon, which streams HD at 2500mbs. To my eyes, the difference between the Amazon and Netflix streams are significant; Netflix looks noticeably sharper. Amazon also streams via SSL for added security (not sure why, since the component outputs on the Roku are HD, but I discuss this later in respect to stream security. Netflix have been very open about their streaming, and blogged with specifics about their streams.

Getting SD content to stream via Quicktime H264 was fairly straightforward. We're Mac-based, so ideally we were looking for a Quicktime-based streaming solution from a plain old Apache webserver. From our YouTube channel, we had a small library of 1280x720 high bitrate movies that we could use to generate our Roku Channel HD content. The dev docs provide a table describing acceptable formats, bitrates etc. This worked fine for SD content, but we hit a brick wall trying to get HD content running without continual (and frustrating) rebuffering. AAC audio is a must, but however I tweeked H264 settings with either Compressor or exporting directly from Quicktime7 Pro, we got rebuffering issues with 720P HD content. I even tried using the free Microsoft Expressions encoder that can create VC-1 Advanced profile media, but got nowhere. As a last resort, I installed the x264 codec, a fast and excellent open source implementation of H264. It seemed, immediately our rebuffering problems were resolved and we are now getting excellent quality in HD at 3700mbs

9. Suitable content hosting sites

Once we'd developed the basic VideoPlayer application based on the demo code, we were keen to get a Roku service up and running for testing outside of our local network. Our ISP for some time has been GoDaddy.com, which has generally been fine although we hadn't used our account much apart from light web hosting duties. Anecdotal reports seem to indicate that GoDaddy doesn't like its servers effectively being used as a web-based repository/db. Being confrontation averse, I decided to open an account at HostGator.com, which I'd heard was both cheap and more flexible than GoDaddy in respect to the use of web accounts. I got their business account at something like $14/month, which has unlimited storage and bandwidth on a shared server. It also comes with a free SSL certificate (see below). So far I've found HostGator very responsive to technical requests (usually implemented within an hour, day or night) and  don't have to go through a sales rep to get to them, as with GoDaddy, which can be a timewasting nightmare ("...before you go, let's just review your account").

10. Stream security

As I eluded to above, the app we developed pulls XML feeds via HTTPS (TSL) to minimize our security issues. For most of our content in the channel, it's also available on YouTube so our assumption is that it's already out there and there's no good reason to stream via SSL. In an ideal world (ideal for content providers, not for the public's) the component outputs on the back of the Roku Player would max out at DVD quality so that the only HD output would be via the Player's HDCP-encoded HDMI output. Although in Roku forum posts dating back to 2008, Roku reps indicated this would be the case, in practice they haven't enabled this and 720P HD is coming out from both the HDMI and component cable outputs. This is presumably to increase the appeal of the unit to not only include legacy HDTV's, but also because many folks have maxed out their HDMI TV connections and may only have a component connection available. Roku can of course switch off HD on component at any time, but it's unlikely to happen soon, especially since Hollywood hasn't switched on the image control token in current Blu-Ray disks that would downrez component output on Blu-Ray players to 480P. So at this time, SSL encryption of Roku Player streams appears somewhat like "putting lipstick on a pig". But Amazon does this.

From the SDK's perspective, SSL video streams are not an option since (at the time of writing)  it appears that SSL is broken in the screen components so that only feeds can be accessed via SSL. To get SSL feeds working, you'll need to point the roUrlTransfer object that you use to a certificate file that contains the public certificate in PEM format of the certificate authority that signed your server's certificate. This seems to be required before SSL will function. Debugging SSL connections can be fun, but is made easier if you remember that the Roku Player uses the Linux Curl library to access URL's. This means that you can test out the certificate file you intend to use in your application via the command line version of CURL (the component manual also gives the CURL error response codes).

From a practical perspective, you could provide username/password access to the SSL URL so that only your app could access the files on it (you'll need something to protect direct access to the URL if you don't want general web access). What we decided to do was to add the Roku public certificate authority cert (yes, they self-sign?!) to your webserver's PEM bundle so that you can verify that only a Roku player can access your SSL directories ( further check is that your developer ID is referred to in the SSL environment variables). The .htacces file on the server looks something like:

SSLRequireSSL
SSLVerifyClient require
SSLVerifyDepth 1
SSLRequire ( %{SSL_CLIENT_S_DN_O} eq "Roku, Inc.")

As I indicated, HostGator was cool with performing the requested tasks on the serverside to do all of this.

Conclusion

I hope this has been of some help to those getting started on creating a Roku Player channel. Though I've only scratched the surface of the development process (for example, I've missed out a registration component completely), I hope that I've conveyed that this is a very do-able process. In general, the SDK works fine, and I've learned a lot about Internet streaming issues in the process. For Roku, although the sales numbers are good now, nearly all Blu-Rays seem now to come with Netflix and/or Amazon streaming built in. As Blu-Ray prices drop to $100 a pop, it's difficult to see what appeal the Roku will have. My guess is that's clearly part of the reason that Roku opened up the Player platform; the kind of indie channel development described above needs to reach a critical mass pretty quickly so that the Roku Player can reinvent itself as the "Peoples Streamer".

Drop me a comment if you disagree with anything, for further info or to correct anything here.

Greg

[UPDATE - April 1 2010]

OK, talk about bad timing. It turns out that in Sept 2009 a bug was found in OpenSLL which drives secure connections on a webserver. This involves SSL regenotiation and would allow an attacher to inject text though not see the resultant stream. Esoteric, but an exploit has been demonstrated on Facebook. So renegotiation has been switched off in recent versions of OpenSSL code. Now, unfortunately renegotiation is needed with Client certificate verification, at least on a per-directory basis. So I found out recently that HostGator hasd updated my SSL webserver to the most recent version of OpenSSL which broken client side verification and hence access via the above mentioned config file. I believe that the only solution is to switch on client side verification globally in the ssl server config file. I had an open ticket with HostGator to fix this but none of the tech support staff correctly did this. Now moving to VPS server to seek a solution.