Log in

View Full Version : Please comment on my x264 settings


Chainmax
30th December 2011, 00:48
After a long time, I am starting to dip my toes again in ripping, filtering and encoding. My previous CLI line for animated content was as follows:

program --crf 18.0 --deblock 1:1 --keyint 240 --bframes 16 --ref 16 --qpmin 10 --qpmax 51 --me umh --direct auto --subme 9 --psy-rd 0.50:0 --no-dct-decimate --no-fast-pskip --output "output" "input"

After rewatching mewiki's x264 settings explanation, it seems like the settings are still valid (I only changed weightp to Smart). Still, I would like for you guys to offer some suggestions/alternatives.

I would also like to try 10-bit encoding a try, but I am seeing no option on MeGUI to enable that. I am using core 2070, data 2039, and x264 2120.

golagoda
30th December 2011, 01:42
I can't comment on your particular settings but the reason you can't simply enable and disable Hi10p encoding in MeGUI is that x264 needs to be compiled with '--bit-depth=10'.

AMED
30th December 2011, 03:14
I'm currently using this command line for my encodes.
program --level 4.1 --preset veryslow --tune grain --crf 18 --deblock -1:-1 --output "output" "input"

Keiyakusha
30th December 2011, 03:28
Yes, as golagoda says, 10bit doesn't needs to be enabled. This is simply different x264build.
As for the settings. They are look a bit outdated. There is new mode for b frames but with this mode you want to use something like --bframes 3. Crf values are changed a bit so I gues you probably want to use 16 right now. --ref 16 is a overkill. Well, you can use it, but personally I use --ref 8 even if I have free resources for encoding. This makes encoding faster, decoding a bit easier and has no impact on quality. --subme i believe there are better than 9th now but not sure what to recommend.
Well this is all I can say, not really helpful. Since presets and tunings systhem was introdused, I'm not really watching for these settings, I simply use something like:
--crf 16 --preset slower --tune animation --ref 8 (or without --ref at all). Why? Because I trust Dark Shikari on that, I think that the settings that x264 picks based on these presets/tunings are very good. However note that this settings I use for 10bit encode. For 8bit I probably want to adjust something depending on if there any problems with introduction of banding.


P.S.: I'm sorry to tell that, but the settings that posted AMED I find totally unacceptable for animation. They are for american live action movies.

nibus
30th December 2011, 07:12
--subme goes to 11 now.

http://taoteaching.files.wordpress.com/2009/11/spinal_tap_but_it_goes_to_eleven1.jpg

Audionut
30th December 2011, 07:23
AMy previous CLI line for animated content was as follows:

program --crf 18.0 --deblock 1:1 --keyint 240 --bframes 16 --ref 16 --qpmin 10 --qpmax 51 --me umh --direct auto --subme 9 --psy-rd 0.50:0 --no-dct-decimate --no-fast-pskip --output "output" "input"

Based on that, I would switch to this.

--preset veryslow --tune animation --crf 18 --keyint 240 --no-dct-decimate --no-fast-pskip --output "output" "input"

As stated above, to encode to 10bit requires a 10bit executable.

Also, as Keiyakusha pointed out, you might want to re-explore your crf setting.

Also note, that --tune animation should only be used for true animated content. With CG you should stick to --tune film.

Chainmax
2nd January 2012, 00:04
Ok, I downloaded the 64bit 10-bit depth executable from x264.nl, it should have 10-bit encoding as default, I assume.

I will try --preset veryslow --tune animation, as after all I did create the previous CLI by reading DS's recommendation on a thread and reading the old mewiki page.

I am a bit intrigued though, the animation tuning option does not set Trellis to 1 or 0...wasn't Trellis a bad idea for animation? Also, doubling the number of reference frames sounds overkill, in this case it would mean having 32. :eek:

sneaker_ger
2nd January 2012, 00:19
Refs are capped at 16 anyways, so doubling has no effect with preset veryslow.

Chainmax
3rd January 2012, 01:17
Got it. Where could I read some more about this change in crf behavior, by the way?

Snowknight26
3rd January 2012, 01:49
http://git.videolan.org/?p=x264.git;a=commit;h=22bfd310abced4df0b11c9620b152e5cfe746d43

thebigmunch
3rd January 2012, 05:02
I am a bit intrigued though, the animation tuning option does not set Trellis to 1 or 0...wasn't Trellis a bad idea for animation?
At one time, yes. Those days are long gone. If you would like to set detail retention manually, you could play around with the deadzone settings. Your encode will be faster with deadzones, as well.

parent5446
3rd January 2012, 22:57
At one time, yes. Those days are long gone. If you would like to set detail retention manually, you could play around with the deadzone settings. Your encode will be faster with deadzones, as well.

So trellis is no longer bad for animation sources?

Chainmax
6th January 2012, 14:36
x264.exe stops working right after indexing the file. Here's a screenshot showing the error:

http://i40.tinypic.com/21176vk.png

Any idea as to why it's happening?

Snowknight26
6th January 2012, 14:37
You'll get an idea if you click 'View problem details.'

Audionut
6th January 2012, 22:25
What build are you using?

Chainmax
7th January 2012, 16:13
Snowknight26, no idea:

Problem signature:
Problem Event Name: BEX64
Application Name: x264.exe
Application Version: 0.0.0.0
Application Timestamp: 4ee1adf8
Fault Module Name: StackHash_2264
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Offset: 00000000000002c0
Exception Code: c0000005
Exception Data: 0000000000000008
OS Version: 6.1.7601.2.1.0.768.3
Locale ID: 14346
Additional Information 1: 2264
Additional Information 2: 2264db07e74365624c50317d7b856ae9
Additional Information 3: 875f
Additional Information 4: 875fa2ef9d2bdca96466e8af55d1ae6e


Audionut: I downloded the 64bit 10bit-depth version from x264.nl sometime last week, so it was JEEB's 2120.

Audionut
8th January 2012, 01:34
I downloded the 64bit 10bit-depth version from x264.nl sometime last week, so it was JEEB's 2120.

I've had problems with Jeeb's patched builds. But from memory the clean builds have always been fine.

You could try adding --demuxer lavf

Or using a different build - http://komisar.gin.by/


Also, any reason you are reducing b-frames to 14?

--preset veryslow will set them to 8.
Then --tune animation will double them, so 16.

sneaker_ger
8th January 2012, 04:08
--preset veryslow will set them to 8.
Then --tune animation will double them, so 16.

Tune animation doubles refs, while only adding two bframes.

Audionut
8th January 2012, 11:40
Tune animation doubles refs, while only adding two bframes.

Indeed. I need to learn how to read again.:o

Chainmax
8th January 2012, 17:01
Come to think about it, user settings overwrite presets, so for 16 bframes total I have to put 16 there.

By the way, the problem was solved by using the 32bit version. I don't understand: my CPU is a Core i5 2410 (which is 64bit), and
I am using Windows7 Home Premium 64bit...

Also, is ~4.8fps encoding speed normal for this CPU on these settings?