Roku Developer Program

[zimbra]

"bcl" wrote:

That's the only solution I found. I'm re-ripping my DVDs using Handbrake and the iPod-HiRez preset. I have had 0 problems with rebuffering on any of the new files.

Ok, wow. The iPod preset is at 700 kbps, which gives me video with ridiculously low quality.

I've been looking at the requests the roku is making to my server, and I'm not sure there's not a problem there; it seems to request the full file, then a byte range, then the full file, then a byte range again

[TommyTheKid]

I also noticed that my "media library" doesn't play. I don't know if I am running into the "buffer" thing, as I have no picture, so I haven't spent a lot of time "watching" :).


Quality wise though, I found that I needed around 1000-1100 kbps on the video stream to make the picture mostly acceptable. I also did "Two pass" encoding, I think? such that it could get an idea where the bit rate could be lower for slower scenes and save some bits for the higher action parts.

SuperFudge:Movies tommy$ mp4info Incredibles.mp4 
mp4info version 1.9.1
Incredibles.mp4:
Track	Type	Info
1	video	MPEG-4 Simple @ L3, 6923.850 secs, 1049 kbps, 720x304 @ 29.970031 fps
2	audio	MPEG-4 AAC LC, 6922.913 secs, 128 kbps, 44100 Hz
3	od	Object Descriptors
4	scene	BIFS
SuperFudge:Movies tommy$ mp4info Finding\ Nemo.mp4 
mp4info version 1.9.1
Finding Nemo.mp4:
Track	Type	Info
1	video	MPEG-4 Simple @ L3, 6033.027 secs, 1049 kbps, 720x400 @ 29.970030 fps
2	audio	MPEG-4 AAC LC, 6032.981 secs, 131 kbps, 48000 Hz
3	od	Object Descriptors
4	scene	BIFS
SuperFudge:Movies tommy$ 

I will also note that I made these like forever ago, and they don't say "h264" .. I also note that it looks like the "BIFS" are built into the file, maybe thats confusing it. I am sure I made these with handbrake, but I would never remember all the settings. They play fine in VLC. I use them to take movies on the airplane or whatever so I dont have a bunch of stupid DVDs to lose. It would be neat to be able to watch them on the big tv too 🙂

Tommy

[zimbra]

I re-encoded one of my movies at 700kbs, and got the same buffering issue at about an hour. I'm going to do some debugging on the network this evening, and see if I can get a better picture of what exactly is being requested.

I may also try to re-encode with the web-optimized option set, see if that helps.

[DeftOne]

Wasn't it found that the 1-hour rebuffering issue that most people were running into was caused by a second audio stream that the Roku DVP didn't like? I could be wrong, but I do recall seeing it discussed previously. You might want to check into that.

[zimbra]

"DeftOne" wrote:
Wasn't it found that the 1-hour rebuffering issue that most people were running into was caused by a second audio stream that the Roku DVP didn't like? I could be wrong, but I do recall seeing it discussed previously. You might want to check into that.

The movie I'm testing with only contains one stream, AAC(CoreAudio) - Stereo mixdown at 128kbps.

[TommyTheKid]

OK, so I just fresh encoded a movie, using all the defaults, and my audio is out of sync. It plays fine in VLC of course. I think it might be that its "LC" (AC3?) audio instead of "Stereo"? I also fast forwarded to 1:10+ and it does the "loading" (buffering) every 60 seconds or so. It seems like the first time it starts playing (after fastfowarding) it plays for a few mins, then it starts having problems every 60 seconds. I wonder if the problem is related to the web server having to continuously seek through the file to find the place to start sending the segment from. It may just not be sending the segments fast enough? I could use "dtrace" to find out what was really happening, but then I'd have to learn dtrace... might be worth trying this on a system with "superfast" disks instead of "laptop" disks.

Note that I am using a MacBookPro with 10.6.2, using an external USB disk. I also tried using the internal disk, same result. As per below, I did encode with HandBrake on the same machine.

$ mp4info MonstersInc.m4v 
mp4info version 1.9.1
MonstersInc.m4v:
Track	Type	Info
1	video	H264 Main@3, 5529.873 secs, 1179 kbps, 710x468 @ 23.975957 fps
2	audio	MPEG-4 AAC LC, 5530.517 secs, 128 kbps, 48000 Hz
3	text
 Encoded with: HandBrake 0.9.4 2009112300

[RokuKevin]

zimbra,

could you post the mp4info from your encoding? From your description, it sounds like you've chosen compatible settings...

tommythekid,

RushCreek.mov looks like an HD stream. Did you set the StreamQualities array to ["HD"] and the StreamBitrates to [5600000]?

Incredibles.mp4 and Nemo.mp4: these should be H.264 encodings

MonstersInc.m4v: you may want to try removing the text stream you can do this with ffmpeg as in the earlier post about removing extra audio streams.

[TommyTheKid]

Thanks for the reply...

"RokuKevin" wrote:

tommythekid,

RushCreek.mov looks like an HD stream. Did you set the StreamQualities array to ["HD"] and the StreamBitrates to [5600000]?

Yes, it is supposedly HD. Hmmm, 5600000, I think I thought (for some reason) they were in kbps (guess I have no idea why, given the examples)...

SuperFudge:Sites tommy$ mp4info RushCreek.mov 
mp4info version 1.9.1
RushCreek.mov:
Track	Type	Info
1	video	H264 Main@4, 357.256 secs, 5593 kbps, 1280x720 @ 29.970105 fps
2	audio	MPEG-4 AAC LC, 357.056 secs, 64 kbps, 48000 Hz
SuperFudge:Sites tommy$ bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
5593*1024
5727232
(5593+64)*1024
5792768

Setting it to "HD" and setting the bitrate properly does seem to help. with it at 5600000, it only re-buffered twice in 5 mins. I tried setting it to 5800000, and it only re-buffered once, towards the beginning, so I am going to *add* the video and audio bitrate and multiply by 1024, and maybe round up a little. I guess?

OMFG this helmet cam video is making me ill at full screen 🙂

Incredibles.mp4 and Nemo.mp4: these should be H.264 encodings

I have 100's of mp4 files like these that are regular mp4. I realize it may not be the most efficient, but most of them were ripped before I had a system that could play x264 files. (800MHz Ti PowerBook) I was hoping to re-use those, but if there is just no chance (without re-encoding) cause its not x264, then so be it 🙂

MonstersInc.m4v: you may want to try removing the text stream you can do this with ffmpeg as in the earlier post about removing extra audio streams.

I am starting to think the audio sync issues *were most likely* my setup, I have my Roku plugged into my computer monitor, but the sound output is plugged into LINE-IN on my mac, which means I have Rogue Amoeba's "Line In" software sampling line-in and re-playing it. Sometimes it gets out of sync. I should have tested that before I piped up about audio sync issues. The 1 hour rebuffer thing is still an issue though. We may need to figure out a way to get "more" debug like output from the video.show() command... I may also try streaming from my Solaris box, then I can ask for help on the dtrace stuff 😉

I bumped up the bitrate per the previous discussion, but this is SD only (DVD). I played from 50mins-1:10 without a problem, but then at 1:10 it re-buffered, then at 1:13, and at 1:14 ...

It seems to occur every time it requests the whole file from the web server (HTTP 200 response). As long as it only requests partials, it seems to feed ok.

68.100.89 - - [25/Jan/2010:21:18:54 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 643505
192.168.100.89 - - [25/Jan/2010:21:19:13 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 1647629
192.168.100.89 - - [25/Jan/2010:21:20:08 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 2599525
192.168.100.89 - - [25/Jan/2010:21:20:57 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 577969
192.168.100.89 - - [25/Jan/2010:21:21:30 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 2121425
192.168.100.89 - - [25/Jan/2010:21:21:45 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 1614861
192.168.100.89 - - [25/Jan/2010:21:23:04 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 545201
192.168.100.89 - - [25/Jan/2010:21:24:18 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 2566757
192.168.100.89 - - [25/Jan/2010:21:24:44 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 1582093
192.168.100.89 - - [25/Jan/2010:21:25:27 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 512433
192.168.100.89 - - [25/Jan/2010:21:28:50 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 1549325
192.168.100.89 - - [25/Jan/2010:21:29:27 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 2533989
192.168.100.89 - - [25/Jan/2010:21:31:02 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 446897
192.168.100.89 - - [25/Jan/2010:21:33:10 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 1516557
192.168.100.89 - - [25/Jan/2010:21:33:54 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 414129
192.168.100.89 - - [25/Jan/2010:21:35:28 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 2501221
192.168.100.89 - - [25/Jan/2010:21:37:03 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 32461
192.168.100.89 - - [25/Jan/2010:21:37:04 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 381361
192.168.100.89 - - [25/Jan/2010:21:37:38 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 1483789
192.168.100.89 - - [25/Jan/2010:21:18:55 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 420436005
192.168.100.89 - - [25/Jan/2010:21:41:39 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 200 906736426
192.168.100.89 - - [25/Jan/2010:21:41:08 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 348593
192.168.100.89 - - [25/Jan/2010:21:44:05 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 2468453
192.168.100.89 - - [25/Jan/2010:21:41:40 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 185946115
192.168.100.89 - - [25/Jan/2010:21:44:46 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 200 906736426
192.168.100.89 - - [25/Jan/2010:21:44:06 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 1451021
192.168.100.89 - - [25/Jan/2010:21:44:47 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 206 149211419
192.168.100.89 - - [25/Jan/2010:21:47:45 -0700] "GET /~tommy/MonstersInc.m4v HTTP/1.1" 200 906736426

Not sure if any of that is useful, but thats what I see...

Tommy

[bcl]

"DeftOne" wrote:
Wasn't it found that the 1-hour rebuffering issue that most people were running into was caused by a second audio stream that the Roku DVP didn't like? I could be wrong, but I do recall seeing it discussed previously. You might want to check into that.

Not for me. All of my eencodings had only 1 stream. Here's what I'm currently using:

#!/bin/sh
./HandBrakeCLI -i /dev/sr0 -l 480 -e x264 -b 1500 -B 160 -R 48 -E faac -f mp4 -I -m -x level=30:bframes=0:cabac=0:ref=1:vbv-maxrate=1500:vbv-bufsize=2000:analyse=all:me=umh:subme=6:no-fast-pskip=1 -L -o $1

And here's mp4info for a new rip that plays all the way through:

bcl@wyatt:~/Movies$ mp4info BackToTheFuturePartI.mp4 
mp4info version 1.5.0.1
BackToTheFuturePartI.mp4:
Track	Type	Info
1	video	H264 Baseline@3, 6964.415 secs, 1499 kbps, 896x480 @ 23.976027 fps
2	audio	MPEG-4 AAC LC, 6964.330 secs, 160 kbps, 48000 Hz
3	text
 Metadata Tool: HandBrake 0.9.2 2008021900

[zimbra]

"TommyTheKid" wrote:
I think I thought (for some reason) they were in kbps

According to the xml in the examples, and the Roku Component Reference pdf, StreamBitrates is an "Array of bitrates in kbps for content streams"