Roku Developer Program

[tfritz28]

Hello, I'm new to Roku and love it so far. I'm interested in starting my own video site and creating a channel for it on Roku. I've been reading through the SDK material and think I have a decent grasp on how it works. I originally was going to have the videos in the .flv format because of the quality and smaller filesizes, but read that I would need to use .mp4 to work with Roku. So now I have a few questions.

1. YouTube uses the .flv format, so how did they get this to work with Roku?
2. After looking through the examples, I can see how to hardcode each file individually, but what if I want it to just read a directory and create the links automatically?
3. Does anybody have an example of my #2 question so I can see it in action?
4. How can I create a link for an upcoming event that would be streaming live and can that be automated as well or would that need to be hardcoded?

Thanks ahead of time,
Tony

[renojim]

I guess I'll take a stab at your questions.

1. YouTube uses the .flv format, so how did they get this to work with Roku?
YouTube also has the videos in mp4 format. I assume the YouTube channel is using that format.

2. After looking through the examples, I can see how to hardcode each file individually, but what if I want it to just read a directory and create the links automatically?
The usual way to do this is to create an xml file on your server from the directory and request that from the Roku.

3. Does anybody have an example of my #2 question so I can see it in action?
The examples from the SDK have examples of xml usage.

4. How can I create a link for an upcoming event that would be streaming live and can that be automated as well or would that need to be hardcoded?
Again, an xml file with the information that your app on the Roku requests when it starts, or periodically, would accomplish this. You can request any kind of file from your server, so you don't have to use xml, but since there is a nice interface to parse xml as part of the SDK, it's just convenient to use xml. If you're planning on using HTTP Live Streaming for this, then just having a link to the m3u8 file that you can pass to the video player should be enough.

-JT

[tfritz28]

Thanks JT. I didn't know YouTube stores videos in two different formats. That's double the space (roughly). Wow.

In looking through the examples again, I assume you were referring to the "videoplayer" example. I'm not very knowledgeable with xml so I'll have to investigate that further, but at least I think I understand how that should work. I'm also looking at the "filebrowser" example and that looks like it would work too (and maybe a little easier for me). So would I just replace the "file://" items with "http://" links?

Also, in doing some testing with the videos I would be posting...I ripped them from dvd to mp4 (720x480, 800kbps Video & 96kbps Audio) and ended up with a 612MB file for a 1 hour video. Is that a normal file size for an hour video? Seems rather large to me. Is there a way to get the filesizes smaller?

Tony

[tfritz28]

Anybody have some help for me or answers to above questions?

[renojim]

Replacing "file://" with "http://" would be hardcoding your links, would it not? I thought that's what you were trying to avoid. Also, keep in mind that that file browsing example is using a local device connected to the USB port, not a networked device.

I'm no expert on video encoding, but that size sounds about right from what I've seen. The only way to get smaller files is to go to lower quality by either lowering the bit rate or resolution.

-JT

[tfritz28]

Thanks again JT. And yes, I would like to avoid hardcoding, but somewhere the xml file has to point to a file on the server correct? I guess there's a function built into xml to find those files (sort of like the readdir function in php)...or am I way off on that? I have a lot to learn with xml.

And with those file sizes, I'm expecting the shows to be around 2 1/2 - 3 hrs...so that would equal about a 1.5GB file...correct?

[renojim]

Right, you have to have some way of getting the listing from the server and you have to have something running on the server to create the list in the first place. xml is basically just a text file with tags, so there's no "functions" built into it. You have to have some way of creating it on your server. Don't get too hung up on xml; you don't have to use it. You could just have a text file with the file list on your server that you request that looked something like:
file1 http://serverip/dir/filename.ext
file2 http://serverip/dir/filename2.ext
etc.

In xml you would use tags to accomplish the same thing. It's just that with a plain text file list you have to parse it yourself whereas it's built-in with xml. You can also have several sub-tags within a tag, like:
<file>
<url>http://serverip/dir/filename1.ext</url>
<ContentType>movie</ContentType>
<Length>3600</Length>
</file>
<file>
<url>http://serverip/dir/filename2.ext</url>
<ContentType>movie</ContentType>
<Length>3600</Length>
</file>

Look at the "Content Meta-Data" section 3.3 in the RokuDvp-ComponentReference.pdf for things that might be useful to include in an xml listing.

Video file size pretty much scales with the length of the video, so if you're getting 612MB for an hour you can expect about 1.5GB for 2 1/2 hours. If my math is correct, that's about 1.3 Mbits/sec which is fine for most people's connection, but pushing it for people at the low end of the broadband experience.

Hope this helps!
-JT

[tfritz28]

Excellent. Thanks JT. Let me see if I can get this figure out now.

[kbenson]

Also, remember that the SDK docs show ballpark streaming bitrates for different quality settings, which can be used to get ballpark sizes for the files.

E.g. for a 1.5 megabit a seconds stream:
(1.5 megabits/second) / (8 bits/byte) = 0.1875 megabytes/second = 187.5 kilobytes/second
187.5 kilobytes/second * 60 seconds/minute = 11,250 kilobytes/minute = 11.25 megabytes/minute

That's about right for your 600+ MB file for an hour, give or take a few percent either direction for actual bandwidth used and network overhead. If an HD version takes 3 times as much bandwidth to stream, it will take about the same amount on disk.