ATV Advanced Settings (DVD Source)

[Cavalicious]

@dynaflash

Here is a set of captures:





1st pic using (CRF):
-m -p -e x264 -q 0.70 -Q -r 23.976 -E facc -B 384 -R 44.1 -6 6ch -v -x keyint=300:keyint-min=30:bframes=6:ref=3:subq=5:me=umh:mixed-refs=1:no-fast-pskip=1:trellis=1:vbv-maxrate=3900:vbv-bufsize=2100

File Size=2.04GB / Data Rate=2391.75 kbits/s

2nd pic using (CQ):
-m -p -e x264 -q 0.64 -r 23.976 -E facc -B 160 -R 44.1 -6 6ch -v -x keyint=300:keyint-min=30:bframes=6:ref=3:mixed-refs=1:subq=5:me=umh:no-fast-pskip=1:trellis=0:no-dct-decimate=1
(Plus I **cough** deinterlaced **cough**)

File Size=1.39GB / Data Rate=1634.56 kbits/s

1st pic color is a tad bit richer. But is it worth the longer encode time (not much longer) and Larger file size? Maybe the color will even out if I do a -Q with 2nd encode settings?

2nd encode is jitter free, haven't put 1st encode through jitter test (4:20am). Will do and report in the am.

[Cavalicious]

Update: Both encodes are jitter free!

[dynaflash]

Cavalicious, have you been doing any more crf 70 encoding for the atv ? I have done probably twenty vids and have not had skipping yet.

Only caveat I see, is if a particular title is extremely noisy I need to apply weak denoising to keep the overall bitrate down. But am happy with 99% of the results.

I do have one video made with a specific atv killer vob just for testing this that will jitter a touch, though I believe it to be a deinterlacing, detelecining issue, not bitrate related.

I am now trying a slightly higher buffer to see just where the stuttering starts, then will back it down a bit. Also, playing with the buffer duration. Sure would be nice to have some apple info on the atv's buffer for sure, but barring that, empiricle testing is the only way.

Interesting sidenote on using crf instead of abr for my movies. I have found that for at least half of them, i actually end up with a bitrate lower than 2500 so it appears that overall, it likely results in a library the sames size or a bit lower than if they were all encoded using 2500 abr. Of course, that depends on a persons video library content and whether its noisy or complex, but on average, for me, I think this is the way to go.

[eddyg]

I've been using crf 0.67 with dynaflash's advanced prefs, so far so good. I found 0.70 too high on noisy material, even with denoising.

Cheers, Ed.

[Cavalicious]

I've been using 65% with no VBV cap...

1. I too notice lower bitrates and smaller file sizes (a few under 1gb!), but damn good quality. even when I connect my ATV to my 110" screen.

2. I too have been jitter/problem free except on two DVDs:

1. Tina Turner concert - had to put a vbv cap on it because with all the light shows and constant panning, bitrate sky rocketed and file in up being 6gb. Vbv cap got it down to ~ 3 gb I believe (and still looked great).

2. Troy - 65% and no vbv cap, caused a slight jitter when all of Sparta rushed the walls of Troy.

3. If I'm not mistaken, I believed I used a 3500 VBV cap with the concert, and it was jitter free.

Let me know if you need me to do some diff. test.

~Cav

[eddyg]

After a bit more testing I'm thinking that we should change the ATV preset in HB to be CRF.

I love the fact that most of my files are smaller than 2500ABR, and yet the quality looks just as good.

Cheers, Ed.

[dynaflash]

Well, I think it *could* be risky as a factory preset, but I definitely have not used abr since buffering my crf encodes. Everything for atv is crf now, it is true sweetness!!

The vbv buffering just added that safety net I needed for those problem titles.

eddyg: I will try some 67-68 encodes, in all likelihood, they will look just as good as 70, also trying a longer buffer duration just for kicks on my "problem child" source

[dynaflash]

Cav, went ahead and moved this topic to AppleTV forum as it may prove useful to other atv users that want to try this out.

[qwerty123]

Fascinating as Mr. Spock might say. Been using CRF from the start, as it just seemed the right thing. Been struggling to finalise my settings, but Cavalicious's settings to control bit rate peaks and Dynaflash's feedback looks promising...

I went off on a tangent and started wondering about your other advanced options. A little Doom9ing later, I wondered if Manao's comment about using 16 B-Frames (near the end of the page) is relevant. There are also other settings different from the Constant Quality Rate preset.

Sorry if you've explained your thinking elsewhere that I've missed. Quick testing I've done, shows no difference to my eye. But it sounded like a something for nothing tip...

[qwerty123]

Quick testing I've done, shows no difference to my eye. But it sounded like a something for nothing tip...

I changed my mind looking at my test again, I spotted a picture break-up on the 6 B-Frame version that was dealt with on the 16 B-Frame encode. See below:

Sorry about the childish content, my boy's Baby Bach DVD!

6 B-Frame


16 B-Frame

[dynaflash]

qwerty123, good stuff Never even thought to try bframes=16 on an appleTV. Though as Manao points out, it just gives the encoder the freedom to use them, not that it necessarily will.

So, you have used bframes=16 with an atv before with no problems, I will have to try it. Manao is the one who helped me develop the vbv buffer settings we are using ( or at least was good enough to explain the concept, which I initially found very obtuse but almost makes some sense now ).

As you, a couple of us went right to crf as soon as we got our atv's to determine a good setting in developing the atv preset. However, as we were not aware of how to implement vbv buffering at the time, we felt it far too risky to use as a built in preset.

The actual HB Constant Quality preset is not targeted at the AppleTV at all. It is just a general purpose Constant Quality preset for people to try.

Am interested to hear back on your success using 16 bframes on the appleTV, as well as what constant quality settings you are using. I may try comparing 67 -68 percent against my 70 percent encodes and use more bframes as long as the atv doesnt have an issue with them.

[qwerty123]

So, you have used bframes=16 with an atv before with no problems, I will have to try it. Manao is the one who helped me develop the vbv buffer settings we are using.

Yes, I recognised the name from some our your IRC I'd read some time ago - so I knew it was knowledgeable info. I have only wound B-Frames maximum up to 16 last night for the first time, so make no claims as to it's practical reliability. Although Manao's comments seemed to suggest there were no downsides (very unusual for these type of things)!

The whole vbv-maxrate thing reminded me of some tweaks I did with a Sorenson 3 Video codec for a live video stream once. There I wanted very low normal bit rate, but controlled the size of huge spikes to accommodate any occasional movement within the scene. Back to this subject, it looks to me like CRF is a way to keep the quality I like irrespective of the particular source (mostly), yet put an upper limit on how many bits I want to through at the job. Great to limit choking on ATV, but also cool to say don't bother going beyond what I would have had with, say 3000 ABR. Best of both worlds to me, and all in one pass!

Now it's past this point that I get a little hazy. The controls (probably rightly) don't give hard and fast limits, but rather so much for so long combined limits. This is why I was so pleased to see your empirical testing results. Can't beat a trusted source reporting on a bunch of legwork. I'll play some more with the other settings tonight, but so far I'm really only getting started after adopting Cav's suggestions at the start of this thread. (I noticed he's recommending similar CRF settings elsewhere on the board, but without the VBV limits...) Previously I was using very simple CRF settings without any significant advanced settings.

My gut feeling, it that once the ATV boundary limits are set for buffersize and maxrate, most of the other settings that work well on other occasions will work well here (and be as subjectively argued). I'll post back, with any other thought/discoveries/recommendations.

Oh, that example above was from a sustained rapid rotating motion of the toy slowly coming into focus over 6 seconds. A real hard encoding task! I bet the peak rate was high. Which raises a question - what tool can I use to examine the instantaneous bitrate at different points in a movie? My friend Google couldn't help...

[dynaflash]

Well, for taking a look at bitrates, I have been using the VLC Info Panel, where you can see bitrate samples as the movie plays. However, it only shows every x seconds, (I think its one second polling) so ymmv. Would be great to be able to see a graph or something so we could really see whats going on for indepth testing.

Ultimately as my target is the ATV, I am simply using the atv for all of my testing.

One other note about my testing, all encodes are with CABAC on. I know its not officially supported by apple, but frankly, I think the vids look better with it on and it does seem to be able to play it cabac as long as bitrate spikes do not get over 12Mbps. ALso, I test each movie streaming on a wireless "N" network. As its quite obvious that if the movie can stream, it will play just as well sync'd.

[jbrjake]

Never even thought to try bframes=16 on an appleTV.

Err...the reason the ATV preset only uses 6 is that when the device came out I had you try more than that and you said it didn't work....

You people saying 16 b-frames work on the appletv--are you sure about this? Or are you using adaptive b-frames?

The actual HB Constant Quality preset is not targeted at the AppleTV at all. It is just a general purpose Constant Quality preset for people to try.

To be precise, it's a port of the CRF profile Sharktooth has in MEGui.

[qwerty123]

You people saying 16 b-frames work on the appletv--are you sure about this? Or are you using adaptive b-frames?

I've only tried the one encode myself so far. Busy elsewhere. Not sure about the type of b-frame - it's the bframe=16 option I've used...

[jbrjake]

Not sure about the type of b-frame - it's the bframe=16 option I've used...

Then you're using adaptive b-frames. That means x264 can use *up to* 16 b-frames which changes the frame-type decisions. But unless the AppleTV can actually smoothly play video with 16 b-frames in a row, we can't use that in a preset. Because when x264 *did* decide to use 16, it would screw up the @tv.

To test this, you need to do

Code: Select all

bframes=16:no-b-adapt

...which dynaflash tested for me when he first got his, and it didn't work reliably. As I recall, we settled on 6 because that was the most the @tv would consistently handle.

[dynaflash]

Come to think of it, jbrjake is jogging my memory, we tried alot of things when I got the atv. He threw all kinds of advanced opts at me which I tried as it was right before a release. 16 bframes in a row did not play at all well on the atv. So, while using bframes=16 may yield a playable movie with one source. the next source very well may not play well on your atv.

I will be sticking to bframes=6. Sorry for the confusion and my failing memory jbrjake

[jbrjake]

I will be sticking to bframes=6

I dunno...it'd be worth testing if other numbers fared better. I think the @tv might be able to handle up to 9 before problems crop up. And maybe fewer b-frames would fix it...though that would cause a perceived quality drop at the same bitrate.

I'd also be interested if changing the b-bias or the key intervals would similarly fix the problem qwerty123 experienced.

[qwerty123]

To test this, you need to do

Code: Select all

bframes=16:no-b-adapt

Ok tried no adaptive. Got slightly lower overall bitrate, but got more blocking on that scene I posted a still from earlier. So one conclusion reflects what Manao suggested - let the encoder choose how many b-frames it needs. Forcing too many made it worse for me in this example.

The atv didn't seem to be bothered by the b-frames though. It played back the same as in Quicktime on my Mac.

[qwerty123]

I'd also be interested if changing the b-bias or the key intervals would similarly fix the problem qwerty123 experienced.

Ok, been researching how best to adjust these settings. Didn't find too much specifics on b-bias other than in c code excerpts, so haven't tried anything there. Key frames, I jumped in and changed keyint from 300 to 30 and got more blocking on that scene and a 6% increase in file size. I'd call that a lose/lose situation...

I'm having trouble with how keyint interacts with min-keyint and max-keyint. Haven't found anything documenting it. Other encoders I've used allow keyframe insertion every n frames and controls to make auto insertion more or less likely on scene events. This must be the same, but I'm sorry I can't get my head around how they interact to be able to do further sensible trials without some hand holding.

[dynaflash]

Just to verify the 16 bframe capabilities of the atv, I ran an encode of the first few chapters of A Night At The Museum, which has several long slow, fairly complex pans at the beginning.

I ran my usual crf 70% encode with a modified version of my crf vbv opt string:

Code: Select all

keyint=240:keyint-min=24:bframes=16:no-b-adapt=1:ref=3:subq=5:me=umh:mixed-refs=1:no-fast-pskip=1:trellis=1:vbv-maxrate=3900:vbv-bufsize=2100

As you can see, I forced x264 to use 16 consecutive bframes, just to see if the atv could play it. It did, and I might add very smoothly. So, it appears that from a capability standpoint, bframes=16 is playable on the atv. Of course, in practice I am removing the no-b-adapt=1 to let x264 make the decision on how many bframes to use as manao suggested.

As usual, the next step is to run several full length test encodes and see how it works.

Note: looking back, as I said before, I am sure that jbrjake had me test bframes=16 when the atv first came out as we were probing its capabilities. My only thought as to why it is working now is possibly the last atv update ? Not sure, but it definitely works. Whether or not it is a desireable setting is yet to be determined imho.

Good stuff

[jbrjake]

Key frames, I jumped in and changed keyint from 300 to 30 and got more blocking on that scene and a 6% increase in file size. I'd call that a lose/lose situation...

No...I meant like use 240 instead of 300 and 24 instead of 30.

Keyint is the max keyint, max GOP size. Keyint-min is the min GOP size. Usually good to use the framerate for the min-keyint and 10*framerate for keyint.

For b-bias, 0 is the default -- no bias, it decides on its own -- and 100 is non-adaptive b-frames -- total bias, it uses them at all times. By using a number > 0 you tell x264 to be biased in favor of using more b-frames more often. So try, like, b-bias=30 or something.

Basically, I'm looking for a way to fix the problems in your screenshots without letting x264 actually use 16 b-frames, because I'd like HandBrake encodes to bear at least some resemblance to MEGui encodes, and that program's presets usually limit the b-frames to well under 6, despite Manao's position.

[qwerty123]

For b-bias, 0 is the default -- no bias, it decides on its own -- and 100 is non-adaptive b-frames -- total bias, it uses them at all times. By using a number > 0 you tell x264 to be biased in favor of using more b-frames more often. So try, like, b-bias=30 or something.

I tried a bias of 30. Got a 4% smaller file but had more blocking. Bit puzzled how allowing up to 16 b-frames (from stills shown earlier) gives less blocking. Here's why, I assume it's not the I frames that block, so it must be the b frames. So why does allowing more of them help? Cos if I allowed fewer of them I'd get a keyframe sooner - which should help avoid blocking. Circular argument, hmmm.

No...I meant like use 240 instead of 300 and 24 instead of 30.

I'm PAL, but tried 240/24. More blocking than with b-frames=16. Tried 250/12 for the hell of it. More blocking. Both file sizes normal. OK, so tried 500/25 on the basis that key frames might be bad :-\. Got just a little blocking! Got suspicious and backtracked and upped the b-frame limit to 16 at 500/25. Oddly still had just a little blocking.

If anyone is still with me; I then filled in the gaps with 500/50 b-frames=6 and then 16. Each gave a little blocking. Decided to repeat my gold standard of 300/30 b-frames=16 and got a little blocking! Argh! Non of these 'little blocking's' are as bad as the earlier image, but my gold standard now has a little blocking, unlike 2 days ago. It's the same chapter of the same iso using the same Cav settings from the start of the thread but with b-frames=16. The blocking is in a different place, but in a spot where there was no blocking before. So I ran it yet again - guess what - blocking in a different place!

Starting to think I'm chasing a ghost. It seems there is something non-causal about this whole lark. I'll shut up now and leave it to simmer... Wild geese? - or worth another look??

[dynaflash]

um for PAL would you want to use key-int=250 and key-min=25 ?

[qwerty123]

um for PAL would you want to use key-int=250 and key-min=25 ?

Tried that with b-frames=16 and with b-frames=6 and got same blocking.

Can't see why syncing the key frames to the frame rate can be important. Surely it is arbitrary if key frames occur at 1 second internals or say 25/24th second intervals. Think this is an old egg and a tangent for another thread...