ATV Advanced Settings (DVD Source)

[dynaflash]

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...

Well, it does help smooth out seeking. At the very least.

Side note: am thinking of retitling this thread something like "Advanced ATV encoding" or something since we seemed to hijack it from Cavalicious (sorry Cav).

[Cavalicious]

No Prob...as long as we're making some kind of progress! I'm too busy trying to defeat Copy Protection on Blades of Glory

[qwerty123]

No Prob...as long as we're making some kind of progress!

Not sure progress is a good description at the moment...

Lobbed a few more encodes into the mix to try to get a non blocky scene. Nothing helped - I tried winding up maxrate to 5900 then 9900 at b-frames 6 & 16, weighted b-frames and bidirectional refinement, oh and keyint-min down to 10. Threw in merange=64 for a giggle and that seemed worse. Now got 37 different flavours kicking around. Oh, thanks for the use of your thread Cav.

[Cavalicious]

Maxrate of 5900 is going to get you in trouble. AppleTV max bitrate is 5000mb/s (I could have swore it used to be 4000mb/s.

New settings that I used for Blades of Glory:

Code: Select all

./HandBrakeCLI -i /Volumes/Encode/d2ox2/BLADES_OF_GLORY_16X9/  -o /Volumes/New\ Downloads/DVD_Film.m4v -m -p  -F -q 0.65 -Q -e x264 -r 23.976 -E facc  -B 384 -R 44.1 -6 6ch -v -x keyint=240:keyint-min=24:bframes=6:ref=3:mixed-refs=1:subq=5:me=umh:no-fast-pskip=1:trellis=0:no-dct-decimate=1:vbv-maxrate=4900:vbv-bufsize=2500

Looks great and smooth as butter!

[dynaflash]

Cav, keep an eye on vbv buffer underflows with your settings. When I was doing my initial testing DejaVu have me a pile of them right at the beginning when I was up in your range.

Hence going with 3900/2100

Your settings allow for > 14000 bitrate for .25 seconds. Just a caution.

Also, what abr did blades of glory end up coming out at with your settings ?

Also, we are all on the same page that the vbv-maxrate does not indicate a literal bitrate cap for the encode, right ?

[Cavalicious]

Cav, keep an eye on vbv buffer underflows with your settings. When I was doing my initial testing DejaVu have me a pile of them right at the beginning when I was up in your range.

I didn't get any underflows, but the encode was so nasty due to copy protection it prob didn't matter (a lot of PTS disc. and Video trashing). But came out fine in the end (after a MTR (Title only) and a dtox edit).

Your settings allow for > 14000 bitrate for .25 seconds. Just a caution. Also, we are all on the same page that the vbv-maxrate does not indicate a literal bitrate cap for the encode, right ?

That is what I wasn't sure of, so decided to try it out as if literal. Going to try another (The Score) and see what I get. I figured BoG would bend on me with all the Ice Skating panning...but it held out.

Also, what abr did blades of glory end up coming out at with your settings ?

Blades of Glory:

• Size - 1.74GB
  Video Bitrate - 2347.06 kb/s
  Audio Bitrate - 391.98 kb/s

[Anamonde]

okay... so just to try out these settings ive been encoding with this:

Code: Select all

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

For some reason the picture comes out all white...

I've been using 70% CRF. MKV (chapter markers turned off).

MacOSX (latest), G5, Handbrake 9.0.

[Cavalicious]

This Thread is for Advanced Settings for the AppleTV (unhacked). The fact that you used .mkv, shows that anything in this thread isn't applicable to your situation.

You may want to start a new thread under the proper Forum.

[Anamonde]

This Thread is for Advanced Settings for the AppleTV (unhacked). The fact that you used .mkv, shows that anything in this thread isn't applicable to your situation.

You may want to start a new thread under the proper Forum.

Seriously?
The fact that I use these encoding settings in a different container shouldn't make any difference. The appleTV (hacked or standard) is still only a piece of hardware that can only handle so much data-rate at a time... which is the point of this thread.

[Cavalicious]

I understand your point, but my point is to eliminate variables and maintain common denominators. Hacked and unsupported containers are variables none the less.

That said, I'm just explaining the focus of this thread. Nothing says the "preset" we're trying to come up with shouldn't work with hacked ATVs. I just don't think we're at that point of testing.

But hell, maybe we are. Since you already started a thread "Best Setting for HACKED appleTV", Your responses should be more to your focus in that thread.

[duncanidaho]

I used this code from Cavalicious to encode Indiana Jones and the Temple of Doom for my ATV...

Code: Select all

./HandBrakeCLI -i /Volumes/INDIANAJONES_TOD_169/VIDEO_TS/ -o /Volumes/Media\ HD/Movies/INDIANAJONESTOD.mp4 -m -p -e x264 -q 0.67 -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

I had the same problem as as qwerty123, there was evident blocking on some frames. Such as this one.

Otherwise the movie played perfectly (over wireless) and looked great, I would just like to find a way of removing the blocking. I noticed it on other movies as well when using those settings. If anyone comes up with an idea I'll test it. Thanks for all the good information by the way!

[Cavalicious]

You could try a "-7", but I would do a search on "deblocking" for proper settings and warnings.

[dynaflash]

Cavalicious: have you had any issues with your

Code: Select all

vbv-maxrate=4900:vbv-bufsize=2500

buffer settings ? I am curious as I have played with it a bit with no ill effects. I am going to try it on my "atv_killer.vob" tonight to see if it chokes.

So far, 3900/2100 has been stutter free for me on all of my encodes.

[Cavalicious]

Cavalicious: have you had any issues with your

Code: Select all

vbv-maxrate=4900:vbv-bufsize=2500

buffer settings ? I am curious as I have played with it a bit with no ill effects. I am going to try it on my "atv_killer.vob" tonight to see if it chokes.

So far, 3900/2100 has been stutter free for me on all of my encodes.

Hey dynaflash,

With DVD sources, vbv-maxrate=4900:vbv-bufsize=2500 has been working great. BUT, with HD sources (MPEG Program Streams) vbv-maxrate=4900 has gotten me jitter and audio sync issues. I'm going to go down to 3900 and will report progress in the HD Source thread.

[dynaflash]

Thanks for the report cav. And therein lies the rub, for it to fail, you have to have a source that you *know* can spike the bitrate way up. Makes it tough to test.

Look forward to hearing your results with 3900/2100. I have used it on the only HD .ts source I have and it worked just fine.

[Cavalicious]

@dynaflash

Re-encoded Training Day and The Last Samurai with:

Code: Select all

-m  -p -F  -q 0.65 -Q -e x264 -r 23.976 -E facc  -B 384 -R 44.1 -6 6ch -v -x keyint=240:keyint-min=24:bframes=6:ref=3:mixed-refs=1:subq=5:me=umh:no-fast-pskip=1:trellis=0:no-dct-decimate=1:vbv-maxrate=4900:vbv-bufsize=3000

Fixed my stutter issue completely. Possible new AppleTV Preset? I think between the two of us, we've proved it out. Plus it will allow the users smaller (most of the time) and better quality with CRF.

-just a thought.

[eddyg]

Should the keyint and keyint-min vary on framerate?

I encode mainly PAL, so I'm using the following recipe for my ATV:

Code: Select all

time $HB --longest -i "$FROM/$dvd" -o "$TO/$dvd.mp4" -e x264 --crf --quality 0.66 --ab 256 --markers --verbose --pixelratio --x264opts keyint=250:keyint-min=25:bframes=6:ref=3:subq=5:me=umh:mixed-refs=1:no-fast-pskip=1:trellis=1:vbv-maxrate=3900:vbv-bufsize=2100:cabac=0 --subtitle-scan --native-language eng --subtitle-force --denoise 2:1:2:3 2> "$TO/$dvd.log"

But I've changed it to the following to test out your one for a while:

Code: Select all

time $HB -i "$FROM/$dvd" -o "$TO/$dvd.mp4" -e x264 --crf --quality 0.66 --ab 256 --markers --verbose --pixelratio --x264opts keyint=250:keyint-min=25:bframes=6:ref=3:subq=5:me=umh:mixed-refs=1:no-fast-pskip=1:trellis=0:vbv-maxrate=4900:vbv-bufsize=3000:no-dct-decimate=1 --subtitle-scan --native-language eng --subtitle-force --denoise 2:1:2:3 --longest 2> "$TO/$dvd.log"

[dynaflash]

Should the keyint and keyint-min vary on framerate?

Yes, absolutely it should. one thing jbrjake and I have been seriously discussing is having HB's default keint and keyint-min be detected fps * 10 and detected fps, that way you wouldnt have to specify it at all.

But for now, you are correct.

[Leo]

Fixed my stutter issue completely. Possible new AppleTV Preset? I think between the two of us, we've proved it out. Plus it will allow the users smaller (most of the time) and better quality with CRF.

I know this will disappoint you a bit Cav, but I think most users would rather have no-dct-decimate turned off in a preset, to get files 10% or more smaller. (Advanced users can always edit the preset anyway.)

Also, I have been wondering if no-dect-deimate could cause a worse output when one is using vbv limits? My reasoning it that it may effectively be reducing te vbv limits by around 10%.

Have you (or anyone) noticed any scenes where the vbv limits cause blocking, compared to an encode with the same settings except for the vbv limits? I mention this cause I found CRF 60% on the iPod with vbv-maxrate=1500:vbv-bufsize=2000 causes a lot of problems on certain scene changes (as I mentioned in another post).

Anyway, thanks guys for establishing some vb limits; I'll be adding them to my encodes.

one thing jbrjake and I have been seriously discussing is having HB's default keint and keyint-min be detected fps * 10 and detected fps, that way you wouldnt have to specify it at all.

yes, would nice

[dynaflash]

Leo, no-dict-decimate should really have no effect on vbv.

And, frankly, if you use crf for an iPod, you will definitely get some strange things happening. The iPod is just too restrictive buffer wise to expect any kind of consistency with playable crf encodes.

In fact, I would really resist the idea of a built in preset from HB for even the appleTV using crf. Even though for myself I use it exclusively.

[Cavalicious]

I know this will disappoint you a bit Cav, but I think most users would rather have no-dct-decimate turned off in a preset, to get files 10% or more smaller. (Advanced users can always edit the preset anyway.)

It's relative, I have a few movies that come in under 1gb. On average, I'm running ~2.2gb. What's 10% really buying you. The current Preset (unchanged) may yield around the same sizes (most likely larger), but with worse quality....but I guess thats relative also.

That said, the built in Presets aren't for the "advanced" user, more so the casual noob that wants an easy way to get decent quality...quickly without thought. I'm just trying to squeeze out a little more for them.

[Leo]

-m -p -F -q 0.65 -Q -e x264 -r 23.976 -E facc -B 384 -R 44.1 -6 6ch -v -x keyint=240:keyint-min=24:bframes=6:ref=3:mixed-refs=1:subq=5:me=umh:no-fast-pskip=1:trellis=0:no-dct-decimate=1:vbv-maxrate=4900:vbv-bufsize=3000

sorry to perhaps be slightly tangential, but is the -R 44.1 part important, or beneficial at all?

Leo, no-dict-decimate should really have no effect on vbv.

It makes vbv about 10% bigger though, no? Would this not cause some complex parts to max out the vbv limits?

And, frankly, if you use crf for an iPod, you will definitely get some strange things happening. The iPod is just too restrictive buffer wise to expect any kind of consistency with playable crf encodes.

dynaflash, I have found that CRF 60% works very well with 320x240 for iPod onscreen viewing, with not a single problem ever (even when I didn't set vbv limits). Often 640x480 CRF 65% without any vbv limits stutters only occasionally.

For example, 576x320 CRF 58% with vbv limits would probably be almost always completely fine with iPod. I know it's not top quality, but it is still very watchable on iPod, PC and TV, and would be useful for those wanting to keep file size down, or for those who encode a high quality full resolution anamorphic PC (and/or AppleTV compatible) version too, as I do.

Also, I am a bit surprised (happily) if the vbv limits for AppleTV aren't causing any problems in encodes at 65%. I know the iPod limits, 1500 and 2000, are about a third and two thirds of the ApppleTV limits, but 640x368 compared to PAL 720x576 is about 60% of the resolution, or number of macroblocks, so in terms of bits per macroblock it's not hugely different, especially as CRF 65% should be about 50% bigger than CRF 60%. Having said that, I must admit you do have all those nice bframes and cabac to help.

[sorry, I'm not trying to fork this thread]

[Leo]

It's relative, I have a few movies that come in under 1gb. On average, I'm running ~2.2gb. What's 10% really buying you. The current Preset (unchanged) may yield around the same sizes (most likely larger), but with worse quality....but I guess thats relative also.

soz, not sure if you understood what I was saying. I almost never encode at a set bitrate. I mean that if I do an encode at CRF 65% with no-dct-decimate=1 then it will typically be around 10% bigger than if I do a CRF encode at CRF 65% with no-dct-decimate=0 (the default). I mean, that from what I've read about no-dct-decimate and my brief tests aeons ago it seemed that most people wouldn't want it (which is why no-dct-decimate=0 by default).

Further to this, if it is increasing the video bitrate 10% then I would think it is more likely to cause problems when vbv limits are being set, and that when those problems do occur they would be worse, e.g. equivalent to have vbv limits 10% less... or perhaps even worse? I don't know.

[dynaflash]

dynaflash, I have found that CRF 60% works very well with 320x240 for iPod onscreen viewing, with not a single problem ever (even when I didn't set vbv limits). Often 640x480 CRF 65% without any vbv limits stutters only occasionally.

I can give you three title off the top of my head that will make it drop frames at those settings in a heartbeat. Also, realize that if you average bitrate == your vbv-maxsize, then for all practical intents and purposes you get a constant quality encode.

Also, I am a bit surprised (happily) if the vbv limits for AppleTV aren't causing any problems in encodes at 65%. I know the iPod limits, 1500 and 2000, are about a third and two thirds of the ApppleTV limits, but 640x368 compared to PAL 720x576 is about 60% of the resolution, or number of macroblocks, so in terms of bits per macroblock it's not hugely different, especially as CRF 65% should be about 50% bigger than CRF 60%. Having said that, I must admit you do have all those nice bframes and cabac to help.

[sorry, I'm not trying to fork this thread]

Picture size has nothing to do with vbv. So please do not confuse the issue. vbv is all about bitrate for a given buffer duration. x264 doesnt care if its from an HD source or a 320 x 240 source.

Oh, and yes, you are forking this thread. This is about the atv, and no, crf is not going to be a HB supplied preset for either the atv or the iPod.

If you people want to use it. They can always create their own preset.

[Cavalicious]

May be confusing, but this thread initiated from the IRC about switching from ABR to CRF and cabac=0 vs cabac=1...all encompassing what can/will break the AppleTV. Hence my comparisons.

File Size was not an issue...
Encode Speed was not an issue...
iPod compatibility was not an issue...

Simply getting bang-for-buck without blowing up the AppleTV.

Now, as far as a "Preset" go, I can understand why not to substitute the current preset (safety net). I just want to save those the trouble of using the preset (for x amount of time) and then finding out that there were "better" settings known. Better to the point where they would want to re-encode there movies. Bitter sweet I guess.

I mean, we are testing, adjusting, testing and adjusting for a reason...right?

-2cents