Shutter and Audio sync

[eddyg]

Ah - in that case, set both bitrate and vbv_maxrate to 5000, I thought it was published as 2500 for H.264.

Rodney

2500 was chosen for the average bitrate as a good compromise between quality and file size. I find 2500 average quite good myself except for the stutter when changing scenes to a panning shot.

So I'd have thought that bitrate=2500 and vbv_bitrate=4500ish would be about right.

I'll try this later on today after work if I get a chance.

Cheers, Ed.

[eddyg]

When using vbv-maxrate do you need to use two-pass? I was thinking that it may need the first pass in order to know the bitrate in the first place?

Cheers, Ed.

[fwhite]

So I just learned about Cabac. Where can I find other info about all the advance settings in Handbrake? Thanks for all of your help. I think I finally found the settings that is to my liking. I will try and compare Cabac to nonCabac and see if I can tell the difference. I as so glad that I finally got rid of the shuttering. Again, thanks all.

[roundy]

Just to confirm. Setting cabac=0 in the preferences does seem to fix the pause/stuttering problem on AppleTV. I've created a new preset with all the same stuff as the HB-AppleTV plus cabac=0.

Thanks for all the help! Looking forward to the next version of HB!

roundy

[rhester]

When using vbv-maxrate do you need to use two-pass? I was thinking that it may need the first pass in order to know the bitrate in the first place?

It will also work with (and was originally implemented for) one-pass, since it is merely a ceiling throttle.

Rodney

[SicMX]

Seems the problem is solved!

I entered "cabac=0" in the x264 encoder advanced setting flag, and the stuttering problem in the beginning of the movie totally disappeared!

I'm gonna try once more, this time without the cabac=0 to be sure it wasn't ripping circumstances or coincidens that it stuttered at that moment in the original rip.

Also the original clip seems to play very smoothly if moved to the Apple TV HDD, but now when streaming from a G network.

What exactly does cabac=0 do btw?

[rhester]

It turns off CABAC *laughs* (but leaves CAVLC enabled). (CABAC is a way of improving encoder efficiency, thus offering higher quality or a lower bitrate. It is not required.)

Rodney

[SicMX]

Wierd how that could remove the stuttering cause i had the average bitrate set at only 3000kbps. You'd think it wouldn't go anywhere near the max (5000kbps) Also wierd how when streamed the same exact place stuttered and when on the harddrive it didn't.

Gonna continue to do some experiments

[SicMX]

Ok, tests done.

Same exact settings for both files: AppleTV, 3000kbps. One has cabac=0 and one does not.

When streaming from a wireless G network the video with cabac=0 is smooth as butter (even smoother than the same rip with Mediafork!), but the one without stutters and even the screen freezes at a certain scene!

Setting cabac=0 really seems to do the trick! Now i'm gonna see if i can rip the 12 Monkeys scene smoothly.

[rhester]

CABAC puts more strain on the decoder. It's just more evidence that the Apple TV is grossly underpowered.

Rodney

[eddyg]

I can confirm that cabac=0 does work. Movies that had nasty jitter are now jitter free.

FYI here is my recipe using two pass:

Code: Select all

HandBrakeCLI --longest -i "$dvd" -o "$dvd.mp4" -e x264 -q0.75  -v -x bframes=3:subme=1:me=dia:trellis=0:analyse=none:cabac=0:pass=1:stats=$dvd.stats

HandBrakeCLI --longest -i "$dvd" -o "$dvd.mp4" -e x264 -b 2500 -B 160 -m -v -p -x bframes=3:ref=1:subme=5:me=umh:no-fast-pskip=1:trellis=2:vbv-maxrate=4800:pass=2:cabac=0:stats=$dvd.stats 

This is working very well after a couple of tries, I'll do some more and see how I go. Could do with speeding up the first pass a bit, it's quick but could be quicker. The second pass is basically a modified AppleTV template one with vbv-maxrate added to stop it going near the AppleTV limit, and CABAC off because the AppleTV is low on oomph.

Cheers, Ed.

[rils]

"CABAC puts more strain on the decoder. It's just more evidence that the Apple TV is grossly underpowered. "

Or CABAC isn't implemented...

H264 480P with CABAC and higher bitrates decodes fine on a single core/GMA900 hardware. A 1GHz processor matched with a GeForce7300 and 64MB of Vram isn't particularly underpowered, especially since scaling, motion compensation and anti-aliasing are performed by the video IC. Additionally, 720p is a pretty poor resolution for a computer monitor. If really ATV was running out of juice, then playing back a 480p movie WITH CABAC should not be an issue - half the number of pixels compared to 720p, for some added complexity decoding CABAC...

Until Apple got into the movie rental business, all media was distributed in a format supported by all Apple devices- why implement CABAC on ATV while iPods will not be able to play back the content?

However, with the desire to propose 720p movies at a higher cost, implementing CABAC on ATV 2.0 would make sense for Apple. Those 720p downloads are dedicated to home viewing, and are not be compatible with portable media players from the brand. Additionally, 720p movies are getting a bit cumbersome, so the 15% extra compression brought by CABAC would be justified as it would improve user experience (read: users who buy media from Apple, obviously not us!).

I start to see some posts here and there hinting at ATV2.0 supports CABAC; it would makes sense.. in every possible sense!
In essence, ATV2.0 is exactly ATV1.0 with the latest software update... This may be what all of us were waiting for!

[Ritsuka]

ATV use QuickTime like every other apple os x based devices in the world, QuickTime H.264 has always supported cabac. It was just slower.
And quicktime hasn't got any kind of graphic card acceleration.

[rils]

Well actually...

If your assumption is right, then there was no reason to integrate an external video IC into ATV...Please note that the mentioned 7300 does not include HDMI and HDCP, performed by a companion chip. In essence, a GMA900 would have done the job just fine if all the decoding was purely software, something Apple could not be ignoring when they added $15 to the design with that video solution (IC+ external memory).

Let's look a little closer to what that GeForce7300 can do:
* Dedicated on-chip video processor
* High-definition H.264, MPEG2 and WMV9 decode acceleration
* Advanced spatial-temporal de-interlacing
* Inverse telecine (2:2 and 3:2 pull-down correction)
* High-quality video scaling
* Video color correction

Well well, what a surprise! It looks like they picked the one 7300 that has all those features, for a box that is dedicated to the living room... Alike ATV, the 7300 doesn't support CABAC, as can be seen on the following comparison chart:

http://www.nvidia.com/docs/CP/11036/Pur ... arison.pdf

So I surmise something else: ATV is using a subset of quicktime (with a limited set of Codecs), optimized for home theater use. They modified parts of the QT H264 decoder to make use of the renderer integrated in the 7300, renderer that does not render CABAC. Of course, the accelerated API was likely provided "as is" by nVidia, so adding CABAC support (by the main CPU) will prove quite complex... This can be partially confirmed by doing power consumption measurements between ATV running its version of QT, and ATV running OSx and software QT. Not the same at all!

So it looks like ATV is the exception confirming both rule that "all OS X platforms are running quicktime in software" and "Quicktime isn't accelerated". Cheers!

[ozonew4m]

Exactly the informkation i was looking for... thank you very much people