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.
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.
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.
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.
“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.
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.
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…
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.
This didn’t work for me. I tried re-ripping Red Dawn using HandBrake and the ‘Normal’ setting along with -r 29.97 and it has the re-buffering problem after the hour mark.
The problem you are describing, is one I have seen when trying to rip DVDs with an extra layer of protection against ripping. The way I understand the problem is the the DVD directory is intentionally written with errors. These errors cause Handbrake-GTK (and several other ripping programs) to find 99 tracks on the disk. One of these will be the correct one, and the others will be dummies. These errors don’t seem to affect a DVD player because it gets instructions from the menu how to find the right data.
Disney DVDs are especially likely to have this extra protection.
I have read that Handbrake reads the track information from the menus and shouldn’t have this problem. My experience is that it still has problems. I have also read in the Handbrake support forums that there are more clever and faster solutions to avoid this problem, but I have not been smart enough to make them work.
When I run into this problem I resort to capturing the stream out of VLC (a media player). It takes longer and is certainly processor intensive, but VLC can capture a high-quality stream with numerous options for encoding. VLC plays the disk like a regular DVD player and doesn’t seem to have the same issues.
