Roku Developer Program

Join our online forum to talk to Roku developers and fellow channel creators. Ask questions, share tips with the community, and find helpful resources.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
zimbra
Visitor

Re: 1 hr. rebuffering issue

"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
0 Kudos
TommyTheKid
Visitor

Re: Advice for Debugging playback?

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
0 Kudos
zimbra
Visitor

Retested at lower bitrate, no improvement

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.
0 Kudos
DeftOne
Visitor

Re: Advice for Debugging playback?

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.
Roku2 XS (13A166000325) HDMI to LG 42" LCD 1080p (42LH30)
Roku XDS (K0A073000137)
Netgear WNDR3400 (all Rokus wireless)
25 Mbps
0 Kudos
zimbra
Visitor

Re: Advice for Debugging playback?

"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.
0 Kudos
TommyTheKid
Visitor

Re: Advice for Debugging playback?

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
0 Kudos
RokuKevin
Visitor

Re: Advice for Debugging playback?

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.
0 Kudos
TommyTheKid
Visitor

Re: Advice for Debugging playback?

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
0 Kudos
bcl
Channel Surfer

Re: Advice for Debugging playback?

"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
0 Kudos
zimbra
Visitor

bitrate in bps, not kbps?

"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"
0 Kudos