Is there a detailed guide/comparison on x264 settings?

[osgZach]

I know that there are several places where the settings themselves are pretty much documented, with what they affect, etc.

But has anyone done a detailed comparison of the quality impacts certain settings may have, at certain bit rates? what the optimal configuration for a given setting might be ? (i.e Setting A can be set between Y and Z, but setting above X doesn't usually show much improvement for the speed cost)

Most importantly, if anything like this exists, would it be relatively up-to-date ?

[Blue_MiSfit]

The main purpose (IMO) of the presets and tuning system in x264 is so that the average user doesn't need to know much, if anything about the actual settings.

The advice I always give people is this:

0) Identify your decode requirements (i.e. do you need VBV, a certain profile / level, or other restriction etc)
1) Do some benchmarks using different presets, and see how fast your system can encode a given source
2) Pick the slowest acceptable speed, and use a tune if you want
3) Encode everything like this, and adjust up and down if needed

:)

Running "x264.exe --fullhelp" will give you all the information you would ever need to know. If you have questions that doesn't answer, you can always post a thread here, and hopefully a kind soul will help you out.

So, are there any settings in particular you're curious about?

~MiSfit

[osgZach]

Well I'm pretty happy with CRF modes. I understand why the presets are there, etc.. But I'm more interested in understand the trade-offs of going above or below a given value for a given option, is the best way I can explain it.

I understand WHAT the option effects in relation to the encode, but the help documentation doesn't really go into detail on each setting, as to let's say merange - what kind of perceptible difference you might get from jacking it all the way up, vs using the minimum setting, versus an arbitrary value inbetween the two. ie is merange 32 really worth it over, say... merange 25, or is 20 worth it over 16, when considering the performance impact, etc.

I think what you say is true though.. I likely just have to make some minor adjustments and compare.. I will say it is interesting that placebo wants to take around 5 hours (estimated after a couple hundred frames) versus the next preset up (slower I think) which doesn't even take an hour. So I guess I'm interested in finding a "medium" between placebo and the next preset up... Getting an encode time of around 1.5 to 2 hours for any given 18minute - 20minute file.

I know I'll at least be going with max Ref & B frames since it helps with compression on Animation.

Typically I always stuggle trying to find a medium setting on merange/subme type stuff .. Also on rc-lookahead.

I'm also curious on opinions about establishing a good average bitrate with a CRF mode, then going back and doing a 2-pass on that.. I screwed up my first attempt at that.. went from an 86mb CRF 18.5 file (700kbps) to a 199mb 800kbps file.. lol. I know 2-pass was very good for Xvid and all but I've heard conflicting opinions about whether or not a 2-pass would truly improve much over a CRF that averages the same bitrate. At least in terms of perceptability.

I suppose its worth noting the primary vehicle for watching these is intended to be a WDTV Live. Even as high as vanilla CRF19 / High lvl4.1 looks great on my big screen with the unit in 1080i (watching SD, 16:9 content). But looking good on a PC screen would also be nice where possible, without bloating the filesize too much. I'd like for them to come in under 150mb on average if not consistently smaller

[Dark Shikari]

Well I'm pretty happy with CRF modes. I understand why the presets are there, etc.. But I'm more interested in understand the trade-offs of going above or below a given value for a given option, is the best way I can explain it.

I understand WHAT the option effects in relation to the encode, but the help documentation doesn't really go into detail on each setting, as to let's say merange - what kind of perceptible difference you might get from jacking it all the way up, vs using the minimum setting, versus an arbitrary value inbetween the two. ie is merange 32 really worth it over, say... merange 25, or is 20 worth it over 16, when considering the performance impact, etc.

I think what you say is true though.. I likely just have to make some minor adjustments and compare.. I will say it is interesting that placebo wants to take around 5 hours (estimated after a couple hundred frames) versus the next preset up (slower I think) which doesn't even take an hour. So I guess I'm interested in finding a "medium" between placebo and the next preset up...The "next preset up" is veryslow, which is much less than 5 times faster than placebo.

[osgZach]

Well the only thing I changed on the command line was the preset level, although I was just testing some stuff and didn't save anything so I don't know the exact calls I made.

Quite possible the ETA on placebo would have dropped some, but I'm not about to let it sit over a trivial argument like that.

[osgZach]

A couple more newb-ish questions...

I decided to go with this command line, for the time being.. Just testing various CRF values to find one I'm happy with. Probably going to be either 15, 16, or 17. I know the SAR is kind of weird, but I just went with the numbers I got from 16 * 480 and 9 * 720 for this particular content.. Although my WDTV doesn't seem to respect the overscan tag (I can zoom out just below 1x and still get picture running up to the sides, even though it was cropped a couple pixels and resized back to 720x480 to get rid of some edge noise and of course black borders)

--profile High --level 4.1 --preset placebo --crf 17 --sar 7680:6480 --thread-input --overscan show --keyint 300 --min-keyint 30 --output "file.h264" "file.avs"


Although I do have one curiosity.. Regarding SD content (which most of my stuff is) is there any benefit to going with a higher level and/or profile? I've seen recommendations ranging from Baseline/Main level 3.1 up to High level 4.1 - if you were to lower the profile and/or level would you lose potential compression efficiency and/or quality due to using less complex options, etc? In general I just encode everything @ High 4.1 as it is. WDTV Live plays everything back like a champ so far, although I haven't had the chance to really test 16 ref/bframes on HD content (not a lot of HD Anime out there en masse, at least nothing that catches my interest except re-releases of Gundam ,etc).

The encoding time is not -too- bad. CRF17 took about 2.5 hours which is quite reasonable to me, although its been a smidge over 3 hours now testing the same file @ CRF 15. Which is still reasonable to me, potentially. I do most of my long encodes in overnight / working hours batches anyway.

Also aspect ratios still kind of confuse me.. Or more precisely, the variations there seem to be.. There is plain old 16:9 - but then there is NTSC 16:9, PAL 16:9, etc.. I've never seen an ITU rating on a box before, so it makes me wonder.. If its coming off an R1 disc should I just use the ITU NTSC 16:9 anyway? I know that one seems to make the picture stretch a little shorter (height) than vanilla 16:9 (these are all values I'm references from MeGUI btw.. in case anyone is wondering).

Are there any rules people have come up with for the best standard to use in a situation, based on whats found on the box? Obviously I would trust a decimal more if it were listed, but sometimes its just stuff like "Anamorphic Widescreen" or "Enhanced for 16:9/(or) Widescreen Television".. Any guidance on this would be especially appreciated.

[nurbs]

Baseline Profile is only necessary if you target portable devices like ipods, but then you probably can't use the resolution and bitrate you want. Almost no hardware (AppleTV maybe) is restricted to Main Profile, so there is no problem with using high. Level 3.1 has a VBV maxrate of 17.5 Mbps which is plenty for SD content and you could still use 11 reference frames with 720*576 footage. With level 4.1 you could use 16 refs, but the gain in compression efficiency is probably very small. If you are aiming for hardware compatibility you should think about using High Profile at level 3.1, because there are some portable devices out that support that and I've seen announcements for more to be released in the future.

[Dark Shikari]

Baseline Profile is only necessary if you target portable devices like ipods, but then you probably can't use the resolution and bitrate you want. Almost no hardware (AppleTV maybe) is restricted to Main ProfileNope, AppleTV does High (with some limitations). And it's not hardware, the thing is run by a Pentium 3.

[nurbs]

Maybe I misremembered it. I knew that it uses a Pentium 3, but the problem with all the apple hardware is usually the uncooperative software that refuses to put files on the device even if they could be played because of the restrictions they put on it.

[osgZach]

Maybe I should clarify a little. The hardware I am concerned with is mainly set top boxes / network media tanks / whatever you wish to call them. Stuff like my WDTV Live. So yeah I figured I'm pretty safe w/High 4.1. Also worth mentioning I mainly am encoding Anime, from what I read using the max reference frames can be very beneficial in that case. Although in either case it happily plays my encodes so far. I can usually save quite a few MB by doing that.. I don't remember how many exactly, as any testing I did was some months ago... Also I do not specify VBV (no problems so far?).

Wish the aspect ratio stuff wasn't so confusing though.. However I guess a simpler question would be this.. Is it true that for x264 mod/16 isn't that big of an issue anymore? I read something to that effect in a thread around here at some point, I think.. So I was just thinking of cropping off whatever and then doing no padding or resizing.. Any reason not to do that w/x264? There wouldn't be playback issues on devices or TV's would there? Or deep impacts on compression or encoding time because of an "odd" resolution?

[nurbs]

Maybe I should clarify a little. The hardware I am concerned with is mainly set top boxes / network media tanks / whatever you wish to call them. Stuff like my WDTV Live. So yeah I figured I'm pretty safe w/High 4.1. Also worth mentioning I mainly am encoding Anime, from what I read using the max reference frames can be very beneficial in that case. Although in either case it happily plays my encodes so far. I can usually save quite a few MB by doing that.. I don't remember how many exactly, as any testing I did was some months ago... Also I do not specify VBV (no problems so far?).
In that case you'll be OK with HP@4.1
Since you are encoding SD content you are unlikely to have VBV problems even if you don't set it.
You should probably add --tune animation so that the psy-rd and AQ settings are tuned for your content.

As a personal note: I'd consider --preset placebo --crf 17 to be both a waste of space and time. I think you could easily get away with --crf 20 without noticing a difference and placebo takes a lot more time to encode than veryslow while offering only a couple of percent (less than 2% IIRC) quality gain.

[osgZach]

I'm comfortable going as low as CRF 19, however I am a little paranoid about the potential difference between our rear-projection HDTV and any LCD based replacement in the future.. Obviously it doesn't look so hot @ 1080p on my SyncMaster XL2370 in full screen, so the WDTV must be doing one hell of an upscale or something (TV runs 1080i).. But I may also want to fall back on my PC from time to time and watch on that. So I feel better having a higher bitrate. It's really not that much extra anyway in terms of space.

I'm aiming for average sizes of 250MB (Video + 1 or 2 AC3 tracks) or less. One of the larger episodes comes in at a respectable 205MB with Video + Audio. Although it will be much closer to 250MB when the director commentary is added. Either way I'm pretty happy with it overall and the extra bitrate isn't a waste to me. Much like the placebo settings.

As for --tune animation, I read somewhere it doesn't really impact as much once you start getting to CRF's like 17 and lower ?
Anyway I don't like messing with psy-stuff.. I prefer to leave it default. I'm pretty happy with the results overall.

[Lyle_JP]

Almost no hardware (AppleTV maybe) is restricted to Main Profile, so there is no problem with using high.

Well, the iPad is restricted to Main Profile Level 3.1, so there's one. Also, some devices that claim to support high profile actually only support a restricted subset of high (the PSP, for example, barfs on all b-pyramid, and I seem to recall XBox not liking 8x8DCT), so Main Profile, which on standard def material looks pretty much the same as High, is often a safe "maximum compatibility and portability" option. Just use the Slow preset with it and you'll get output comparable to High profile on the Medium preset. By that I mean roughly the same quality at a similar bitrate/filesize (not the same speed. Sorry).

[Dark Shikari]

Well, the iPad is restricted to Main Profile Level 3.1, so there's one.Nope, it supports High Profile just fine, much like the iPhone 3GS.(the PSP, for example, barfs on all b-pyramidThat's because B-pyramid requires dpb >= 4, while the PSP only supports dpb <= 3.and I seem to recall XBox not liking 8x8DCTWorks just fine last I saw., so Main Profile, which on standard def material looks pretty much the same as High, is often a safe "maximum compatibility and portability" option.Since when is B-pyramid a "high profile feature"?

[OvejaNegra]

Wish the aspect ratio stuff wasn't so confusing though.. However I guess a simpler question would be this.. Is it true that for x264 mod/16 isn't that big of an issue anymore? I read something to that effect in a thread around here at some point, I think.. So I was just thinking of cropping off whatever and then doing no padding or resizing.. Any reason not to do that w/x264? There wouldn't be playback issues on devices or TV's would there? Or deep impacts on compression or encoding time because of an "odd" resolution?


No, mod 16 is not a big deal (unless your hardware/software decoder does not knows how to deal with non mod 16 content) i'm encoding to non mod 16 and everything is fine. Yes, mod 16 is maybe more efficent but not for a big amount. And remember 1080 is not mod 16. x264 will pad to mod 16 (thats even better that use black bars).


Aspect ratios is confusing.

SAR (sample aspect ratio on X264) is related to the shape of the pixel (its like a multiplier for the horizontal resolution for correcting the shape of the picture in the analog world)

for example: A 4:3 NTSC DVD -> 720 * 480 (thats not 4:3) -> we crop the overscan pixels -> 702 * 480 (is not yet 4:3) -> SAR is 0.911 or 10:11 if i remember right -> 702 * 0.911 = 639.522 ok thats 640 -> 640*480 YES it is 4:3.

4:3 is Picture aspect ratio and it represents the relation that should exist betwen high and width of the picture:
640 / 4 * 3 =480.

SAR is not affected by the croppping, is always the same if you crop the picture or not.

PAR changes if you crop the picture (640 * 400 is not 4:3)

MKV toolnix uses PAR for correcting the picture during playback (you put 702 * 480 on mkvtoolnix and set the aspect ratio field to 4:3 or 4/3= 1.333 wich is the same and the picture is corrected during playback.

If you write the SAR on the x264 and use the encoded file on mkvtoolnix it will make the conversion for you, dont worry.

If you crop your 4:3 or 16:9 anamorphic DVD before encoding, the SAR for x264 is the same, the PAR for mkv must be adapted (most of the time if you crop the black bars on your anamorphic DVD you will end with the original PAR of the movie, the same you see on the dvd box like 1.85:1).

A 1920 * 1080 picture has an PAR of 16:9 (1920 / 16 * 9 = 1080) and a SAR of 1:1 (the pixels are just as you see them)
One anamorhic DVD has a SAR of 40:33 or 1.21 (the pixels are squeezed) you need to make the corrections -> 702*1.21 (crop overscan if you like) = 849*480, 849 *480 is 16/9? let me see -> 849 /16*9 = 477 (allmost 480), yes. it is.

I dont know if im 100% correct or not. But thats how i use it and it works correctly for me.

PAR can be picture aspect ratio or pixel aspect ratio (is not the same).
DAR also is display aspect ratio, and is the same as picture aspect ratio
Yes, it is very confusing.

Take a look here:
http://mewiki.project357.com/wiki/Glossary#SAR
http://developer.divx.com/docs/divx_plus_hd/Creation_with_x264 (read to the SAR part)
http://en.wikipedia.org/wiki/Pixel_aspect_ratio
http://www.divxland.org/aspect_ratios.php

and
finally:
http://lipas.uwasa.fi/~f76998/video/conversion/

[Blue_MiSfit]

I hope third party apps for the iPad expose the full decode capabilities, and let you simply play files over CIFS / SMB. I don't want to have to re-encode all my files so an iPad can play them...

[JEEB]

finally:
http://lipas.uwasa.fi/~f76998/video/conversion/

I'd also like to introduce an aspect ratio calculator for NTSC/PAL content that follows that article's rules: pochitto (http://ps-auxw.de/cgi-bin/ar-calc.pl)

Has been a great help when you've still not read (or understood) the whole uwasa article, but want to be able to make "more correct", say, DVD rips.

[roozhou]

MKV toolnix uses PAR for correcting the picture during playback (you put 702 * 480 on mkvtoolnix and set the aspect ratio field to 4:3 or 4/3= 1.333 wich is the same and the picture is corrected during playback.

Does mkvtoolnix modify the sar in AVC bitstream? AFAIK most players ignore DAR information in container.

[nurbs]

I'm comfortable going as low as CRF 19, however I am a little paranoid about the potential difference between our rear-projection HDTV and any LCD based replacement in the future.. Obviously it doesn't look so hot @ 1080p on my SyncMaster XL2370 in full screen, so the WDTV must be doing one hell of an upscale or something (TV runs 1080i).. But I may also want to fall back on my PC from time to time and watch on that. So I feel better having a higher bitrate. It's really not that much extra anyway in terms of space.
I can understand that. With SD content I'm comfortable with CRF 21, so I encode at 20 just to feel better. Generally I wouldn't worry about upscaling on the PC since you can select a scaling method so you could use a higher quality scaler than the hardware uses.
A note since you have a WDTV (I also have one): You said you mainly encode SD, but should you ever encode HD don't forget to add --colorprim bt709 --transfer bt709 --colormatrix bt709 to the command line or you'll get wrong colours on playback.

As for --tune animation, I read somewhere it doesn't really impact as much once you start getting to CRF's like 17 and lower ?
Anyway I don't like messing with psy-stuff.. I prefer to leave it default. I'm pretty happy with the results overall.
Well, you wouldn't be messing with it, you'd just be selecting the settings the developers think work best for such content. I find it a bit strange that you spend all the extra time getting the last bit of quality out of the encode by using preset placebo, but then you throw away quality by not using the appropriate tuning.

Well, the iPad is restricted to Main Profile Level 3.1, so there's one.
The newer apple portable devices (iPhone GS, newest iPod Touch, iPad) can all decode high profile. The only problem is iTunes won't let you transfer the files, so you'd have to get around that.
Apple is AFAIK the only manufacturer that limits its devices to main profile and the limitation is purely artificial.

Does mkvtoolnix modify the sar in AVC bitstream?
Nope.

[me7]

The newer apple portable devices (iPhone GS, newest iPod Touch, iPad) can all decode high profile. The only problem is iTunes won't let you transfer the files, so you'd have to get around that.
Apple is AFAIK the only manufacturer that limits its devices to main profile and the limitation is purely artificial.

The devices you mentioned all support syncing High Profile via iTunes, iTunes only limits the Level to 3.0.

[nurbs]

Then my information is outdated. I remember reading here that when the GS came out you had to use different software to get high profile files on it.

[osgZach]

Well like I stated the main reason I haven't used --tune is my impression was it was not very useful for the settings I was using. I'm not adverse to trying it though. Quality is certainly important to me, but I don't really know much about Psy optimizations and how they work / what they do either.. My impression was it discards stuff it thinks you won't notice, to save on wasted bit rate allocation or something like that.. I guess my concern is what if I notice it?

I will invariably test it at some point. I think I'm starting to cave in on lowering some of the other options as it is anyway.. The one thing I feel paranoid about keeping at max for some reason, is Motion Estimation. I know UMH is a LOT faster but I have this attatchment to TESA (or potentially ESA) as well as Subme= 10, and I can't rationally explain why I feel this way. It's like I'm afraid its gonna come out looking worse or something. ME Range I usually like around 20 +/- 4.


Thanks for those links Oveja, I'll have to try and understand it better.. I always set the PAR on x264 because even if I playback an anamorphic 720x480 with MPC-HC it will show up 1.5 if the flag is not set, regardless of what I set in MKVmerge GUI and my WDTV Live definitely ignores the container tag as well.

[Mr VacBob]

Well like I stated the main reason I haven't used --tune is my impression was it was not very useful for the settings I was using. I'm not adverse to trying it though. Quality is certainly important to me, but I don't really know much about Psy optimizations and how they work / what they do either.. My impression was it discards stuff it thinks you won't notice, to save on wasted bit rate allocation or something like that.. I guess my concern is what if I notice it?

That's how all compression works. Psy compression doesn't "discard" stuff explicitly, it's just (nearly always) better at choosing which things need to be discarded to meet the compression target.

[LoRd_MuldeR]

Some info on how Psy optimizations work:

the human eye doesn't just want the image to look similar to the original, it wants the image to have similar complexity. Therefore, we would rather see a somewhat distorted but still detailed block than a non-distorted but completely blurred block. The result is a bias towards a detailed and/or grainy output image, a bit like xvid except that its actual detail rather than ugly blocking.

So instead of only trying to minimize the error (as defined by Mean Squared Error), which has a tendency to create "blurry" video, the psy optimizations also try to keep as much detail/complexity as possible and thus retain more sharpness, even if that results in a somewhat bigger "error". Therefore psy optimizations inherently hurt "quality" metrics, such as PSNR, but they can improve the perceived quality greatly.

See also: http://x264dev.multimedia.cx/?p=164

[osgZach]

Good stuff, thank you.


edit:

Thinking of a way to get rid of my Aspect Ratio headaches, so I'm wondering if this might work well.
I don't want to fuss with getting meGUI to work w/x64 or use any flimsy betas, etc.. But I do like the Anamorphic options it has. As many surely know, it uses its own global variables to pass the values it comes up with (I assume thats how it works) to x264. Although sometimes getting really weird numbers put me off in the past, I think I'm over that.

I was thinking of just using it as a source to get my SAR values to include in my x264 command lines - would transplanting those values work without any issues ? No further calculations needed, for instance?

Also this still leads back to one of my original questions.. setting the Input DAR.. ITU 16:9 (1.822784) vs 16:9 (1.777778)

Using ITU and doing some cropping and resizing and I can get different X/Y numbers, although if I choose plain 16:9 (1.777778) it doesn't seem to matter what amount I crop on what edge, and resize back to 720 - its numbers still seem to come out X16 / Y9

[Zathor]

Also this still leads back to one of my original questions.. setting the Input DAR.. ITU 16:9 (1.822784) vs 16:9 (1.777778)

The ITU-R BT.601 value for 16:9 NTSC with 720x480 is 1.823169 (or exact 8640/4739) based upon 5760/4739 for the pixel aspect ratio and not 1.822784. 1.822784 is calculated with 96/79 (for 710.85 active pixel).
EDIT: Sorry for the slight off topic and the headache.

[osgZach]

I'm just posting what values MeGUI gave me.

I'm just confused which is considered the appropriate one.. I wish boxes would just list the actual decimal value, but I've rarely (if ever in fact) seen that on Anime.. They usually just say "4:3" or "16:9" and I am unsure which one to go with.. The ITU spec gives me a slightly shorter (height wise) picture, while the vanilla "16:9" spec gives me a slightly taller one... Just want to make sure I'm using the right one I guess.. For now I am sticking with vanilla 16:9 as googling laid me to comments saying ITU spec is hardly "ever used" in practice ?

[JEEB]

I'm just posting what values MeGUI gave me.

I'm just confused which is considered the appropriate one.. I wish boxes would just list the actual decimal value, but I've rarely (if ever in fact) seen that on Anime.. They usually just say "4:3" or "16:9" and I am unsure which one to go with.. The ITU spec gives me a slightly shorter (height wise) picture, while the vanilla "16:9" spec gives me a slightly taller one... Just want to make sure I'm using the right one I guess.. For now I am sticking with vanilla 16:9 as googling laid me to comments saying ITU spec is hardly "ever used" in practice ?

picture (http://img19.imageshack.us/img19/6374/efmarucheck.png)

Used the uwasa (ITU) numbers via the related calculator (http://ps-auxw.de/cgi-bin/ar-calc.pl), looks good enough (didn't use Photoshop to check the roundiness from the renderer, though). Started using the uwasa numbers as my base from then on.

[osgZach]

Source resolution: 720x480
Source AR: Widescreen
Final resolution: 720x480
Final PAR: 687360/563941 = 1.21885090816238
Final display resolution: 878x480
Final DAR (square pixels): 1425309696000/779592038400 = 1.82827636224357

Transforms

1. Crop: 716, 476
2. Scale: 720, 480



So I use the above, in bold, as the SAR for x264 according to what the page says then.. ?

Test file still comes out saying 16:9 so I am guessing I did everything right..

[Caroliano]

Answering the original question of the thread, in the past, long long time ago, there was some extensive comparisons with almost all settings of x264 posted on forums. But that is now partially lost thanks to free hosting. And is outdated anyway. I was thinking in doing something similar, but I need quite a bit of time to prepare, execute and organize the results of such a test... so I haven't started yet.

http://forum.doom9.org/showthread.php?t=107699
http://forum.doom9.org/showthread.php?p=791504#post791504

The one thing I feel paranoid about keeping at max for some reason, is Motion Estimation. I know UMH is a LOT faster but I have this attatchment to TESA (or potentially ESA) as well as Subme= 10, and I can't rationally explain why I feel this way. It's like I'm afraid its gonna come out looking worse or something.
I had to LOL at it. That is exactly what --preset placebo is for! :p

I'm not sure if that is your fear, but the image will not come out mangled if the codec fails to correctly detect the motion. It will just waste some extra bits to make the not perfectly fitting block fit well, or to encode that region from zero using I-blocks (I'm not sure if this is the righ terminology).

[osgZach]

Hmm Tune Animation does not give bad results at all.. Especially on some MB savings.. However I am not happy with the whole 1:1 deblock setting. I just find it too blurry. It's almost like it totally undid whatever sharpening I got from LSFMod. Or maybe I just have bad eyes, I dunno. I don't want to say it looks "almost out of focus" but more like it could be heading in that direction, very sutbtley.

Can -tune profiles be overridden like presets ?

[sneaker_ger]

Yes, "manual" settings override tunings.

[osgZach]

I take that to mean simply adding a deblock call on the CLI? Or would I have to look at one of my files and write one out everything listed? Some of the reading on presets/profiles suggests you can't manually overwrite some things, so I'm a little confused on that..

Funny thing, is I tested in on the TV (being the intended viewing target and all) and it actually looks a bit better... Don't you love modern technology? I guess I'll have to compare a few of the other finished ones, and decide whether or not to keep it.
Can always break out a sharpener for PC viewing anyway..

Thanks

[sneaker_ger]

Yes, just add it to your commandline.
Example:
x264 --preset slow --tune animation --deblock -3:-3

[nurbs]

Some of the reading on presets/profiles suggests you can't manually overwrite some things, so I'm a little confused on that..
That's because some of the stuff is simply wrong. If you add --ref 3 to the command line it will use 3 reference frames no matter what preset, tuning or level you specify.

[osgZach]

So.. is there an x264 white paper hiding on the interweb somewhere? The only real source of information I know of is the MeWiki, which apparently is not very accurate about stuff like this.

[nurbs]

x264 --help
.
--preset Use a preset to select encoding settings [medium]
Overridden by user settings.
--tune Tune the settings for a particular type of source
or situation
Overridden by user settings.
--longhelp or --fullhelp if you need more detailed information.

[osgZach]

Hmm.. never noticed that text before... O_o

Humor me though.. I used to know how but can't remember. How can I dump the output of -fullhelp to a txt file?

[nurbs]

Copy and paste usually does the trick.

[Dark Shikari]

x264 --fullhelp 2> file

[MasterNobody]

x264 --fullhelp 2> file
Help use printf so it output to stdout and the correct command line is x264 --fullhelp >file

[osgZach]

Thank you

[OvejaNegra]

Does mkvtoolnix modify the sar in AVC bitstream? AFAIK most players ignore DAR information in container.


NO. In fact mkvtoolnix reads SAR from a mp4 container (and maybe from a raw avc stream) and sets the correct aspect ratio value. So you can just use the SAR values on x264 (with the --sar x:x) because those are always the same (10:11 and 40:33 on ntsc), does not matter if you crop or not.

I havent seen yet a player ignoring aspect ratio information on mkv files (depens on what renderer you have) but most of them get it correct

If you need the correct picture aspect ratio after croppping for mkvtoolnix you can use GK:
http://img199.imageshack.us/img199/2162/66639435.png

[osgZach]

It's been my experience that MPC-HC & my WDTV Live both ignore the container flag, even if the AR is no present in the video stream.. I didn't know what was going on at first, and it drove me mad trying to figure out why my anamorphic H264's were displaying at 1.5 AR

[jpsdr]

Is adding the --non-determinist option will increase quality with the following command line (and also on the 1rst pass) :

x264_x86.exe --profile "high" --preset "placebo" --tune %TUNING% --bitrate %2 --pass 2 --stats %STAT_FILE% --level "4.1" --qpmin 0 --qpstep 2 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 24 --min-keyint 2 --mvrange 511 --ref 4 --bframe 3 --slices 4 --b-pyramid "strict" --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --qpfile %5 --threads 0 --thread-input --output %E_DST% %E_SRC% 2> %LOG_FILE_2%

[LoRd_MuldeR]

Using "--non-deterministic" potentially improves the results (slightly), at the cost of reproducibility.

But since you use VBV anyway and VBV is inherently non-deterministic, using "--non-deterministic" shouldn't hurt in your case.