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.

There are some great filmmaking forums out there, including the excellent dvinfo.net forum and also the VFX-slanted Creative Cow forums but you need to use common sense in deciphering posts. The ProRes codec family has been a fantastic addition to the Final Cut arsenal of tools to use when doing video editing on a NLE, but there seems to be wild misunderstanding about the value of using it, at least to my mind.

Some background on bit depth and codecs: most all prosumer cameras such as the Sony V1U which we used for two of our documentary productions record to tape in 8-bit format. This means that in addition to potential compression artifacts associated with squeezing so much data into such a small space, the component images of the video only support  256 gray levels. In comparison, 10-bit images support 1024 discrete levels of information and 16-bit images ~65K levels. HDV therefore has the effect of reducing the dynamic range in comparison to film capture; from a practical perspective it reduces dramatically the information you can extract from shadow and highlights when working with footage that has extremes of highlights and shadow. There are other problems also associated with HDV such as the 4:2:0 color space, that you butt your head up against when shooting green screen material (never ever have contrast enhancement switched on when shooting green screen footage!!!!).

When we first started using FCP a few years ago, which codec to use on the timeline for my 24P HDV footage was answered in several posts in the above forums: Apple Intermediate Codec (AIC) was recommended. At the time I thought it was overkill - the size of the converted files was about three times that of the native MPEG stream formatted M2T HDV files from the camera. In practice though, it's worked out OK, although my hard drive space requirements are astronomical (something like 10TB and counting). With Final Cut Studio 2 came the first release of ProRes codecs. These promised smaller file sizes for handling HD material whilst being 10-bit. The only reason I can see for using ProRes for 8-bit material such as HDV is when performing FX/compositing in post. The file size in my experience with ProRes 422 is that they are at least twice the size of AIC-formatted files. As for ProRes HQ, it won't even play in real time on our Mac Pro quad core without stuttering. Fortunately, there is ProRes LT (released with Final Cut Studio 3), which produces files just slightly larger than AIC, but has the advantages of a 10-bit codec. I can see no reason whatsoever for using ProRes 422 or (heaven forbid) ProRes HQ owith 8-bit footage for regular editing. None. Period. In fact, aside from using HDV on the final cut timeline, which I wouldn't recommend especially if using any kinds of VFX, AIC still holds a very useful place in the editor's toolbox. For example, rendering out clips that have filters applied to them is the bain of FCP users. With AIC, a clip that's been rendered out as AIC can be edited for length, without destroying the render. Because ProRes is temporally compressed, editing the length of a rendered clip on the timeline results in a re-render being required.

Just my 0.02c worth, but AIC still rocks, isn't a resource hog on the timeline and can speed editing tremendously. If you read some posts in forums, you see  folks advocating Apple retire it  in favor of ProRes - I really hope they don't.



 

We've put together three installments with our friend Sean Bonniwell called "A Conversation Beyond the Garage", in which he talks about his beginnings in folk up until he created the iconic Music Machine band. Further installments will include his work with the Music machine, as a film score composer (notably for "Day of the Wolves") and his conversion to Christianity.

Work has at last progressed on Debbie's documentary, which will ironically be the first of our two docs to be released later this year/early next. We've a wealth of really cool footage of Debbie as she prepared for her win at the 2007 Master's body building tournament in Pittsburgh, ably supported by Tom DiNardo and her trainer Derik Farnsworth.

The trailer is online at YouTube (embedded below) and the "Winning Big" project website is slowly growing in size and completeness.

http://winningbig-themovie.com

At some point "Day of the Wolves" is going to get remade; I don't know when or by who, but it's going to happen. It's a no-brainer; everyone who sees the movie talks about a remake. In his documentary interview, Ferde Grofe mentions that no one has seriously proposed a remake until recently when a major studio indicated that it wanted to option the remake rights.

For those of us who are fans of the movie it's difficult to best the original cast, but there are certainly fine actors around now who would be great in the principal roles. Here are some of my suggestions;

• Pete Anderson: Kurt Russell
• Maggie Anderson: Sharon Stone
• Number one: Kathy Bates
• Number two: Sam Rockwell
• Number three: Paul Reubens
• Number four: Kevin Pollak
• Number five: Eddie Izzard
• Number six: Neal McDonough
  
• Number seven: Ice Cube 

What is your suggested cast?

We are auctioning off an original poster of "Day of the Wolves" that was autographed by director Ferde Grofe and Assistant Director Peter MacGregor-Scott during their filmed meeting together in the documentary, to help our finances in finishing the project. We got the poster off Ebay some time back, and it does looks original (but who knows, it may not be). The poster is a one-page from Goldkey Entertainment which was the company that commissioned the film from Ferde way back in 1971. My guess is that Goldkey did some selective theatrical release in the US, Canada or the UK and that's where they came from (Ferde Grofe retained the rights to other territories).

So if anyone has more money than sense, get in touch - you'll be playing a role in helping us to complete the project, as well as being Erika and my fave person in the whole world

The music in Day of the Wolves is just terrific; it's contemporary and still sounds fresh, almost forty years after it was written and performed by 60's rock music icon Sean Bonniwell. Sean is a great guy who I've gotten to know well since the project started. He still writes and performs his music, and was recently (as of November 2008) at a music fanfest in Los Angeles (well, to be strictly correct, he tried to attend but couldn't get through the ring of forest fires circling LA at that time). There's currently a documentary in production at this time about Sean from filmmaker John Hudgens,

Sean Bonniwell caught in a moment of musical inspiration

You can find out a lot more about Sean at his web site:
www.bonniwellmusicmachine.com

We used a Sony V1U for collecting most of our footage during the doc shoots, and it's a great camera. As always it's up to the operator to get the most out of a scene. For sure though there are some real disadvantages with using a cam that has a 1/4 inch chip. I could also go on for hours about the issues of of dealing with the 8 bit 4:2:0 chroma subsampling which makes color keying potentially problematic, not to mention very limited dynamic range. But for many sit down interviews, the built-in lens and the small chip size are issues in terms of what's in focus and what isn't. This is very important in controlling where the viewer's attention goes. Coupled to this is the background brightness, particularly when you have to run an interview in less than ideal locations. There are adapters that screw to the lens and allow you to attach a 35mm camera prime lens, but we don't have one of these and there would still be the issue of controlling background brightness.

The sit down interview with Floyd Hamilton, who was the production coordinator on Day of the Wolves (he was also in the roles of chauffeur and pilot, but if you blink while watching the movie, you'll miss that).He's a great guy and any success that the doc has will be in no small part due to his help. We filmed him driving around Lake Havasu in May of '07. Looking at the footage afterwards, it was clear that Floyd was a central figure in the story. I wanted a further sit down interview with him, but by that time he was out of town but offered the opportunity to visit with him which I accepted. There was no electricity that I could use for basic lighting and it looked like it would be an outdoor interview, which I find challenging. A major problem shooting out of doors is controlling background brightness. OB units will often use something like a a Scrim Jim to hold netting placed behind the interviewee that drops the background brightness one or more stops. I didn't have the luxury of a Scrim Jim or focus adapter, so I've needed to perform a lot of work in post on many of the interviews to bring them up to snuff.

In essence, the work has been to isolate the interviewee from the background, process the background and then place them back over it a convincing way. This is pretty basic compositing work, but tedious none-the-less, and I used Apple Shake for most of this work. If anyone wants a more detailed explanation, holler; but the steps were:

1. Check to see which parts of the interviewee can be easily isolated from the environment using luma or color keying (in the case of 4:2:0 color sampling on HVDV material, luma keying potentially provides better edge definition). Image 1 below shows the interview scene and there are a couple of areas (such as parts of Floyd's hat) which I keyed from. Much of the rest is roto'd, and if you look at the trailer, you can see this since the roto was done in Shake for speed (Shake roto really sucks) and it was done quickly for the trailer.
2. As a last resort, use rotoscoping to isolate areas of the interviewee that can't be keyed.
3. Once you've successfully isolated the subject, create a clean plate from a frame in the scene. The camera is locked off and the subject was pretty much static, so any frame will do. It doesn't need to be a 100% clean frame, just make sure that the edges are cleaned away. The reason for this is that we will later apply a defocus to the background. If we don't eat into Floyd's element in the background, it will cause a dark halo around the foreground element. We use the matte derived from the foreground element to insert the clean plate into the background.
4. We now apply a defocus to the background, but we want this to look realistic, i.e. things closer to Floyd appear more in focus than those further away. To achieve this I added Z-channel information to the background via an appropriately angled color ramp. This was fed into a z-defocus node and voilla
5. The final step was to use an edge matte to blend Floyd in with the background
6. A further step is to regrain the background, since it's averaged out by the blurring, but for the small trailer this wasn't necessary.

And there you have it; I think the difference is pretty noticeable. We were able to both defocus the background, change it's levels and color balance in post. Is that recommended? Probably not, but the take home message is that you shouldn't give up on a shoot if it's not turned out exactly how you would have liked it to. There's plenty that can be done in post.

Image 1: Unaltered image with a distracting, in focus and bright background

image 2: Shake setup (how *not* to order nodes!!!)

image 3: Creating the background. a: background with clean plate mapped in. b: gamma/color adjusted background. c: background with defocus node. d: defocused background with Z-channel mapping

Image 4: Finished comp used edge matte

We're really pleased to announce that we have a short article in the Fall edition of the magazine MovieMaker. Called "The Documenting of a Cult Classic", it gives an overview of the process of how we came to make the documentary and also talks about Ferde Grofe.

"Return to Lake Havasu", our documentary about the 1971 movie "Day of the Wolves" will be released early in 2009. It's been a long hard slog to get the project to this stage, but we think worth it.

Our documentary "Winning Big" about Debbie Bramwell, the pro female bodybuilding champion is also coming, planned for release Q2 2009. 

I have no idea who the dudes are on the top right (not me and Erika for sure), but I can't figure out how to swap the image - and this, from someone with a computer science background...