Roku Developer Program

[bcl]

Thanks to buaboo I seem to have found HandBrake settings that are working. So far I've only tested with Firefly Episode 1 but both the 'iPhone / iPod Touch' and the 'iPod High-Rez' settings from v0.9.2 are playing just fine past the 1 hour mark.

I think the aspect ratio is also coming out correct, but that may just be luck.

I'm also going to try the AppleTV setting to see how well it works (running now, still has an hour before it is done).

One obvious difference with these settings is that they don't do a 2nd pass for the encode.

[KennyJ]

I used High Profile and removed the extra audio track and it worked fine for me.

[bcl]

The mp4info for the two that are working:

mp4info version 1.5.0.1
Firefly-S01E01-iPod-High-Rez.mp4:
Track   Type    Info
1       video   H264 Baseline@3, 5202.405 secs, 1485 kbps, 640x368 @ 23.976026 fps
2       audio   MPEG-4 AAC LC, 5202.304 secs, 160 kbps, 48000 Hz
3       text
 Metadata Tool: HandBrake 0.9.2 2008021900

Firefly-S01E01-iPod.mp4:
Track   Type    Info
1       video   H264 Baseline@3, 5202.405 secs, 949 kbps, 480x272 @ 23.976026 fps
2       audio   MPEG-4 AAC LC, 5202.304 secs, 128 kbps, 48000 Hz
3       text
 Metadata Tool: HandBrake 0.9.2 2008021900

The original rip that rebuffers after an hour is:

mp4info version 1.5.0.1
old-rips/Firefly-1-Serenity.mp4:
Track   Type    Info
1       video   H264 Main@5.1, 5202.363 secs, 700 kbps, 720x480 @ 23.976028 fps
2       audio   MPEG-4 AAC LC, 5202.261 secs, 160 kbps, 48000 Hz
3       text
 Metadata Tool: HandBrake 0.9.2 2008021900

Oh, and the AppleTV preset didn't work, aspect ratio is totally off and no audio. So I'm going to start re-ripping using the iPod-High-Rez preset but with the height set to 480 instead of setting the width.

./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 -t 1 -o Firefly-S01E01-Serenity.mp4

[Shlepzig]

Did you ever find out what the cause was of the rebuffering?

It feels like some sort of memory overflow error.

I recreated your rebuffering error at about 1 hour, then it comes in more frequently as you keep going to the end of the file. It would successfully come back to the right spot in the file.

Did you ever find a file long enough that it would stop playing all-together?

And I appreciate your input here, it has been really helpful.

-Shlep'
Ubuntu 9.10, Handbrake 0.9.4

[bcl]

Its almost impossible to tell for sure without more detailed debugging info from the player. But it may be related to the Baseline@3 vs. Main@5.1 in the mp4info description above (note: I have no idea what either of those mean).

The parameters above are working fine for me, I've now watched Firefly Episode 1 and Smokey and the Bandit all the way through with no problems at all.

Brian

[KennyJ]

"KennyJ" wrote:
I used High Profile and removed the extra audio track and it worked fine for me.

I take it back. The first one I encoded that way worked fine (played with no rebuffering all the way through). The next one, however did rebuffer after only a few minutes in.

I'll try your settings.

[Shlepzig]

BCL,

from
http://trac.handbrake.fr/wiki/CLIGuide

Multiple Audio Tracks
HandBrake can encode more than one audio track at a time, or the same track multiple times, and use different settings for each encode. It is common for AppleTV users to make one file that includes the main audio track from the source encoded once to AAC for playback on iPods, and also pass it through as a secondary track.

This is achieved by using the command:

-E aac,ac3
If you do not specify which audio tracks to encode with the -a option, then HandBrake uses the first track in the source. When you include more than setting for an audio option, separated by a comma, it implicitly tells HandBrake: "The output should have two audio tracks." And without a source audio track specified, it will just use the first track for both.

You can also do complete settings for multiple tracks:

-a 1,1,2 -A "Main Audio", "Downmixed Audio", "Director's Commentary"-E ac3,aac,aac -B auto,160,128 -R auto,auto,44100 -6 auto,dpl2,stereo
There will be 3 audio tracks in the output, named "Main Audio", "Downmixed Audio", and "Director's Commentary" in turn. The first 2 will be the first audio track from the source: once as AC3 passed-through untouched, once as AAC with a bitrate of 160 and a Dolby Pro Logic II mixdown. The third track will use the second audio track from the source, encoded to AAC at a bitrate of 128, with a samplerate of 44.1kHz, and a stereo mixdown.

When you don't want to specify any particular setting for one of the tracks, use "auto" as a placeholder.

Looks like it is audio track information, specifically the different names for the audio tracks. I am guessing one is 5.1 surround and the other is a 3 channel surround.

-Shlep

[buaboo]

I agree that the 5.1 thing is causing the issue. Using my encoding application (dvdfab), I encoded a movie w/5.1 and stereo with everything else being the same.. The stereo encoded worked fine while the 5.1 did a constant rebuffering.

Not sure what that means, nor do I care, since I don't have a surround sound system... 🙂

[ereiamjh3]

Baseline@3 and Main@5.1 refer to the profile@level of the H.264 encode. See the following for description:

http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC

According to the table on page 8 of the developer guide, an H.264 SD file should be Main@4.0 or High@4.0.

I still haven't figured out Handbrake settings to get a file which will play without rebuffering as described above. The settings shown in bcl's post didn't work for me.

[bcl]

Here is what I'm using now. This is with v0.9.2 of Handbrake

#!/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

This is the iPod Hi-Rez setting with the height forced to 480