Roku Developer Program

[DeftOne]

Handbrake really isn't a DVD ripper. It's a video transcoder. So people aren't using Handbrake to rip DVDs. They are using some other software first, and then using Handbrake to convert the ripped file(s) to a Roku-friendly format.

There are many DVD rippers out there. Here is a pretty good list courtesy of videohelp.com: http://www.videohelp.com/tools/sections ... vd-rippers

[calicommando]

"DeftOne" wrote:
Handbrake really isn't a DVD ripper. It's a video transcoder. So people aren't using Handbrake to rip DVDs. They are using some other software first, and then using Handbrake to convert the ripped file(s) to a Roku-friendly format.

There are many DVD rippers out there. Here is a pretty good list courtesy of videohelp.com: http://www.videohelp.com/tools/sections ... vd-rippers

That's the info I needed. That makes sense. Thank you!

[el_wubo]

renojim and all who have had trouble with larger videos:

Here's the technical issue as I understand it right now:

The problem appears to be with the way the server sends the video stream to the Roku. There's a metadata block that the Roku player needs to get before it can start playing and my experiments show that the Roku will download and buffer until it finds this block or runs out of buffer space.

When you encode a video for playing it from your hard drive it's fine for this metadata to show up at end of the file (because it's easy for your local video player to seek to the end of the file and find it.) In fact (for reasons I don't understand) this seems to be the favored location for the metadata... but in the case of streaming video that metadata needs to appear as early in the file as possible. What I'm working towards is embedding the necessary data in the stream as the server sends it to the Roku regardless of how the file is encoded, but this is tough and could take a while.

In the mean time, if you encode your video using presets intended for web streaming ("web-optimized' in handbrake) your file will be created with the necessary metadata block closer to the beginning and the Roku should be able to handle it (any size file, I expect.) But, if your file has the metadata at the end, the Roku will buffer until it finds the data... or it will exhaust its buffer and fail (and in some cases require a reboot.)

There are utilities for converting 'metadata-at-the-end' files into 'metadata-at-the-beginning' files that may solve this problem for some of you. I haven't tested this. Search the web for 'mp4 moov atom' and you should find the tool.

[scrager]

I downloaded and installed and it seemed to go fairly smoothly. I've played MP3s and a video encoded with High Profile.

I did notice one bug. If I am several folders deep and press the home key, when I press left, I am taken back in to My Music, up one level from where I was, then scroll left. I have to press Home the same number of times as I am folders deep to actually stay on the home screen.

Thanks for all the hard work!

[el_wubo]

scrager:

I can reproduce that. Thanks for the report. I'll add it to the issues list.

[RokuMarkn]

"el.wubo" wrote:
In fact (for reasons I don't understand) this seems to be the favored location for the metadata...

Some encoders prefer to put the metadata at the end because they don't have the information needed to write the metadata until after the content has been encoded. It's easy to append the metadata to the end of the file after writing the encoded content. The other way requires them to reserve space at the beginning, encode the content, then go back and overwrite the reserved space (and hope that it was big enough).

However, I would have expected the Roku player to play such files, by issuing a byte range request to seek to the metadata (which would cause a slightly slower startup). Can you send me the URL of a file that behaves this way?

--Mark

[el_wubo]

Mark,

I haven't been able to reproduce this since I noticed earlier today.

What I have noticed is the player doing a lot consecutive range requests. I'm guessing it's searching the tail of the file for the metadata. I've included the log of the headers for one video screen launch and the media that I was fetching.

Is there anything I can do to help the player find the data in these cases quicker? Also, what's the ideal case for getting a quick stream startup? Am I right to assume that putting the moov atom at the head of the file would speed up stream-startup?

Log of HTTP request headers:
http://wubo.org/requests_for_media.txt

Sample media (uploading.. ETA 11:45 EST):
http://wubo.org/davethomas.m4v

Thank you.

[canaws]

Anyone mind helping me? I can't figure out what I'm doing wrong.

Problem...
When I go to the channel on the roku box it only says receiving. It never changes.

Info...
I downloaded all the files fresh today.
I have the MyMusic Channel on my roku box, so installation when a-ok.
My file path for python is C:\Python26\python.exe
My file path for the media server files is C:\roku_media_server (all subfolders are in place with no name changes).
The ip addresses for my roku box and laptop are correct.
The directory for my music is correct.
When I launch the server (via springboard.vbs) I get the small stop server box. My task manager shows two instances of python.exe every time. When I click stop server only one instance of python closes. I have to close the other one via the taskbar.
I can see the feed page, but is nothing on it except for the title & subtitle.
I'm running Vista.
I'm behind a router w/firewall.

Things I've tried...
I thought the size of my music file might be a problem, so I temporarily moved all my music files and left a single mp3 file in the music folder, but no luck. It still only says retrieving.
I made sure that python can get through Windows firewall.
I've tried it with Windows firewall and the router firewall off.
I ran the debug for springboard and launch server. I don't really know what I'm supposed to look for with these, but I only got 200 OKs.

Any idea what I'm missing?

Thanks!

[srankin]

I've been able to successfully convert and play a few short video files.

Has anyone had any success converting video to play with 5.1 (dolby digital) on the roku? I think Amazon does it, so it is possible . . .

cheers,

Sam

[renojim]

el.wubo and umbighouse,

Thanks for the explanation and verification that it should work, but I'm not getting anywhere. The information about the metadata makes sense, but I've tried all of the following without any luck:
FormatFactory
HandBrakeCLI with default settings
HandBrakeCLI with default settings and -O (--optimize) option
Handbrake GUI with Normal, High Profile, and iPod Legacy presets all with "Web optimized" checked

I looked at the resulting files with a hex editor and it appears that the metadata is at the beginning of the file. I even dumped the first 64MB of a file that won't play (gives a "format not supported" error message from the client) and the resulting file plays fine. The Roku player "thinks" the file is the full length since pressing pause shows the length of the non-truncated file on the progress bar.

The one interesting thing I've noticed with the files that won't play is that the server never receives (or at least never displays) any "player requested range" messages. There are three identical (except for the port) SERVER_PROTOCOL messages that end in "HTTP/1.1 GET /media" - 200 OK and then no more messages. On the working files there are only two of those messages before the "player requested range" messages.

I'm kind of at a loss as to what to try now. If anyone has a 70MB or so file that works for them that they could upload somewhere, I'd like to try it.
Edit: el.wubo, I tried your Dave Thomas video, but I wasn't clear on whether that was one that should work or does not work. Anyway, it doesn't work for me.

On a totally unrelated note, since it appears that this is becoming much more than a music player, might I suggest changing the name of the channel to "my media"? I think with the addition of some sort of jpeg support like a slideshow this would do everything I'd need it to do.

Thanks for reading!
-JT