AppleTV Advanced Settings (Post PsyRDO)

[djdeejay]

How much percentage wise can i except to see an increase in bit-rate/file size now?

With the chapter I was testing with, omitting weighted b-frames increased the filesize by about 1-2%. I'm not sure if that percentage carries over to a full-length encode, though.

Ill do a test code on some problem sources ive got and see what happens...

[ozmosis82]

8x8dct still seems to be working just fine. I tested with a couple chapters from a few movies: Final Fantasy: Advent Children, The Fugitive, Eyes Wide Shut, Sunshine, and Miami Vice. There wasn't a single hiccup with any of them.

[Starhawk]

After many tests, I've discovered that the culprit behind the issue with fades is the weighted b-frames option.

Removing Weighted B-Frames was the only thing I changed about Cav/Dynaflash's settings from the beginning of this thread. I just didnt like how it made my Macbook struggle more to play the file. IIRC, my CPU was running about 20% harder to play the file (not really a problem, just an observation), the files would stall a bit when initially starting, and it was difficult to scan through a file if you were looking for a particular scene.

The other side of the argument was that under normal usage, you would just start the file and watch it, to which Weighted B-Frames did not pose any problems. Just a personal preference and I chose the former. Happy to see I also do not have the fade problem!

[Cytrix]

Hi Folkz,

this is a wunderful thread cause I am also trying to reach a really good encoding image quality!
So Folkz could you also test your encoding settings with blue ray material as reference?

DVD Material is encoded in mpeg-2 and blue ray movies have a much better quality as everboy would know.

I will make a comparison with the settings of Abulia with the movie "Wanted"

ref=4:mixed-refs=1:bframes=6:weightb=1:direct=auto:no-fast-pskip=1:me=umh:subq=7:analyse=all:b-adapt=2

See ya later,
Cytrix

[nightstrm]

Turn off "Large File Size"

Unless you're planning on playing those same files on some other device that doesn't accept files larger than 4GB (or can't read 64-bit files), I would leave that on. Just in the off-chance that you encode a really long/big movie that ends up being bigger than 4GB (like, say, the director's cut of JFK).

Thanks for the feedback on that. I somehow had the impression that the "Large File Size" option impeded the performance in some fashion, and it's unlikely I'll run into a 4GB+ file. That being said, if my assumption about performance is incorrect (not sure where I got it from in the first place) I'll leave it on.

I have to admit here devs, i must say "Large File Size" is one of the worst option names in a program ever.

I realise you were trying to simplfy the 64bit option for beginners, but i now i just know 90% of newbies are going to think

"no, i dont want a large file"

From some of the discussion I've seen, that option may be going away sometime in the future anyways.

[Cavalicious]

Turn off "Large File Size"

Unless you're planning on playing those same files on some other device that doesn't accept files larger than 4GB (or can't read 64-bit files), I would leave that on. Just in the off-chance that you encode a really long/big movie that ends up being bigger than 4GB (like, say, the director's cut of JFK).

Thanks for the feedback on that. I somehow had the impression that the "Large File Size" option impeded the performance in some fashion, and it's unlikely I'll run into a 4GB+ file. That being said, if my assumption about performance is incorrect (not sure where I got it from in the first place) I'll leave it on.

I have to admit here devs, i must say "Large File Size" is one of the worst option names in a program ever.

I realise you were trying to simplfy the 64bit option for beginners, but i now i just know 90% of newbies are going to think

"no, i dont want a large file"

From some of the discussion I've seen, that option may be going away sometime in the future anyways.

Associated posts have been deleted and rule 12 of the first post in this thread enforced.

[blazo]

What's the (visual, file size, etc) difference between option "bframes=6" and "bframes=3:b-adapt=2"?

I am using "bframes=6" since 0.92 but my encodes finished pretty large (~2G on average, CRF 68%) so I will redo my library with 0.93 (CRF 60%); a few encodes show some >25% reduction in file size without visual artifacts.

Sorry for noob question and a bit off-topic, but I was not satisfied with wiki description on b-adapt (on multiple sites).

[GMcDowellJr]

If, as the Wiki suggests, CABAC "makes the AppleTV struggle" why insist on using it for this setting?

Honest question, I don't mean to imply that turning CABAC on is incorrect here I just don't understand and would like too. Thanks.

[dynaflash]

If, as the Wiki suggests, CABAC "makes the AppleTV struggle" why insist on using it for this setting?

Honest question, I don't mean to imply that turning CABAC on is incorrect here I just don't understand and would like too. Thanks.

Well, because several of us use cabac due to its much better compression over cavlc and have no issues ( I have not used cavlc for my atv's for a very long time). Some reported some issues on their streaming setup, but some of us have had very good results.

[TedJ]

It's my understanding that CABAC tends to cause problems with HD encodes - for SD material you should be fine.

[dynaflash]

Note that if you are using either of the last two snapshots, 2742 or the latest 2829, the options I am using for atv are:

Code: Select all

ref=3:mixed-refs=1:bframes=3:me=hex:subq=7:b-adapt=2:8x8dct=1:weightb=0:trellis=0

which is slightly different than the old options due to a change in the x264 defaults introduced in HB 2742 snapshot.

[Rodeo]

Note that if you are using either of the last two snapshots, 2742 or the latest 2829, the options I am using for atv are:

Code: Select all

ref=3:mixed-refs=1:bframes=3:me=hex:subq=7:b-adapt=2:8x8dct=1:weightb=0:trellis=0

which is slightly different than the old options due to a change in the x264 defaults introduced in HB 2742 snapshot.

That would be the svn 2773 rather than 2742 (but the new defaults were introduced in 2742 which was not a snapshot)

Also, FWIW, with the new defaults your string is a bit overkill, you could just use:

Code: Select all

b-adapt=2:weightb=0:trellis=0

and get the same results (I'm sure you know that, but others might not).

More info on x264 defaults change:

http://trac.handbrake.fr/changeset/2742

BTW, may I suggest this be added to the svn2829 announcement (i.e. at least mention there are new defaults like the svn2773 announcement does)?

[dynaflash]

Correct, I did know that about the string being overkill. However if someone is using a snapshot and wants to go back to 0.9.3, specifying the opt settings for that back on 0.9.3 requires the extra opts since the default changed back

That way the string works on both. Good observation though.

[Rodeo]

Hadn't though about backwards compatibility. To be honest, I see no reason to use 0.9.3 for real encodes anymore…

[dynaflash]

I cannot disagree, but like to cover the bases.

[jbjoret]

I have been using Handbrake to convert for years now and started to convert BDs to AppleTV HD about 9 month ago. Now the new x264 level introduced around svn2824 has blown me away. Using the same settings, my Movies went (I have reencoded 4 of them to compare) from 4,5 GB to 2,5 GB !!! That is huge considering that I have an AC3 and a AAC stream. It is about 50%. Now I am wondering if the settings recommended "http://trac.handbrake.fr/changeset/2742" are still the best for >= svn2829 especially for AppleTV HD content.

[nightstrm]

I have been using Handbrake to convert for years now and started to convert BDs to AppleTV HD about 9 month ago. Now the new x264 level introduced around svn2824 has blown me away. Using the same settings, my Movies went (I have reencoded 4 of them to compare) from 4,5 GB to 2,5 GB !!! That is huge considering that I have an AC3 and a AAC stream. It is about 50%. Now I am wondering if the settings recommended "http://trac.handbrake.fr/changeset/2742" are still the best for >= svn2829 especially for AppleTV HD content.

Agreed; I encoded "X-Men Origins: Wolverine" a few nights ago using the latest dev snapshot and the resulting file was around 2.5GB -- and that includes a 640kbps AC3 track, a 256kbps AAC track, and two 160kbps commentary tracks. Streams well to my AppleTV and looks great!

[jbjoret]

I have been using Handbrake to convert for years now and started to convert BDs to AppleTV HD about 9 month ago. Now the new x264 level introduced around svn2824 has blown me away. Using the same settings, my Movies went (I have reencoded 4 of them to compare) from 4,5 GB to 2,5 GB !!! That is huge considering that I have an AC3 and a AAC stream. It is about 50%. Now I am wondering if the settings recommended "http://trac.handbrake.fr/changeset/2742" are still the best for >= svn2829 especially for AppleTV HD content.

Agreed; I encoded "X-Men Origins: Wolverine" a few nights ago using the latest dev snapshot and the resulting file was around 2.5GB -- and that includes a 640kbps AC3 track, a 256kbps AAC track, and two 160kbps commentary tracks. Streams well to my AppleTV and looks great!

I am a litte familiar with the algorithm used to compress videos, and I was blown away by this huge step. Not only it has become incredibly smaller, but my iMac (2,66Ghz - 2008) used to convert those movies with 8-9fps (32 Bits / GCC 4.0 / standard compile options). Now I am compiling Handbrake for 64Bits / GCC 4.2 / optimized for sse4.2) and I get an average of 12-13fps which is 50% more !). I am not sure why this is happening, but I am very happy with this.

[deepsiks]

Are you guys using CLI or GUI? I'm currently using HandBrake svn2845 (2009092801) - Linux x86_64 CLI and trying to figure out the best CLI options for ATV. Looking at your previous posts and others from around the forum the current CLI I'm using for the ATV is:

Code: Select all

HandBrakeCLI -C4 -L -i /dev/sr0 -o $OUTPUT -e x264  -q 20.0 -a 1,1 -E faac,ac3 -B 160,auto -R 48,Auto -6 dpl2,auto -f mp4 -4 -X 960 --loose-anamorphic -m -2 -x cabac=0:ref=3:mixed-refs=1:bframes=3:me=hex:subq=7:b-adapt=2:8x8dct=1:weightb=0:trellis=1

New server with quad core AMD/ 4GB ram ran through Mr. and Mrs. Smith in just under 2 hours - very happy!

Although I am completely satisfied with this outcome, can you guys offer any suggestions that might increase video or sound quality?

Thanks.

[vidjock]

IIRC cabac is required for trellis. So cabac=0 turns off trellis. I used to never use cabac because it made the apple tv struggle on most of my encodes, but I have been using it again lately (so I could improve detail with trellis) and haven't had any problems. I think with the changes (improvements) to x264 it has made the use of cabac not as bad on the apple tv. That is what I have found anyway.

[deepsiks]

Thanks vidjock, going to try this CLI later:

Code: Select all

HandBrakeCLI -C4 -L -i /dev/sr0 -o $OUTPUT -e x264  -q 16.0 -a 1,1 -E faac,ac3 -B 160,auto -R 48,Auto -6 dpl2,auto -f mp4 -4 -X 960 --loose-anamorphic -m no-fast-pskip -2 -x ref=3:mixed-refs=1:bframes=3:me=umh:subq=7:b-adapt=2:analyse=all:8x8dct=1:weightb=0:trellis=1

[vidjock]

deepsiks, I think the crf of 16 is way to much. I don't think you will see any improvement in quality, but you will get a much higher bit rate and large file size. From all the tests I have run I think going any lower then 19 just makes for a bigger file/higher bit rate with no improvement. I have also stopped using no-fast-pskip as I have found that on some encodes lately it has actually hurt the quality in flat areas/blue sky. By the way no-fast-pskip is a x264 option so you have to put it with the rest of the options after the "-x".

Here is what I have been using lately. It is really dynaflash's setting with the addition of trellis. I have been very happy with the results.

Code: Select all

-q 21.0 -x ref=3:mixed-refs=1:bframes=3:me=hex:subq=7:b-adapt=2:8x8dct=1:weightb=0:trellis=1:cabac=1

Yes I know that the string above is over kill (a lot of x264 default settings already) but I find I play with the settings in the string the most. Next I am going to start encoding with weightb on to see if it kills the Apple tv. As always, test, test, test and let your eyes be the judge.

[deepsiks]

Thanks, did just see a 1gb increase in file size... Not too much increase in quality.

[deepsiks]

Anyone have suggestions on using second pass?

[mithrandir]

The CRF you choose depends on at least the source and your playback device (i.e. TV).

I've encoded SD videos (720x480) at CRF 21.5 for display on a 36" analog CRT TV and found that using a lower CRF barely improved perceptual quality.

However, I recently purchased a 50" plasma TV and now those videos don't look so good: I can see compression artifacts introduced by x264 since the displayed image is so much larger (over 2x). As a result I am now using CRF 19 though I am not sure that is good enough. Because the 50" screen is so "large" and the source is SD I can see psy-RDO effects in high-motion scenes where I did not notice them on the smaller 36" set...so I may need to dial down the psy-rd strength as well.

That said even at CRF 19 the average video bitrate on encodes can remain below 1000 kb/s. This is great compression considering the average MPEG2 source (DVD) is about 5000 kb/s.