x264 Presets


I don't use VRD to recode files but..

1. There are really only 3 speeds, the top three settings map to "ultrafast", middle 4 to "fast", and bottom 3 to "slowest"
Why artificially map the presets to just 3? Each preset has a noticable difference in speed so I can't understand why you'd map the options to just 3. Especially without a note in the GUI. I can imagine people wasting a lot of time testing those 9 presets not knowing their actually mapped to just 3 behind the scenes. IMHO the unused presets shouldn't be listed in the GUI.

2. Supposedly the speeds trade off quality vs speed. I.e. Fastest has slightly lower quality. However, quality doesn't seem that noticeable for the recoding that I've done, which is mostly from MPEG2 to iPad.
When using CRF the presets "trade off compression efficiency against encoding speed". So the quality should be the same with every preset but the files sizes increase with the faster presets. In practice the slower presets do give better quality and the fastest ones can look truely awful. Post 2 and 3 here are a good read.

When using fixed bitrate the quality differences between the presets is probably negligable if using a high enough bitrate.

3. The default for current and previous versions has been the middle setting "fast".
The Medium Preset is the x264 default and it generaly gives the best Speed/Quality/Size tradeoff, I'd suggest VRD also defaults to Medium rather than Fast.

4. On a fast Core I7, when changing from fast to ultrafast, we've seen the encoding speed, as measured by frames / second, increase by 50% to 75%.
There is a big speed gap between the fastest and slowest presets, on the fastest presets the bottleneck can even shift from the CPU to the storage.

That's how I understand it, I'm not an expert so if I have anything wrong please correct.

P.S. There is a good Preset comparison here.
Last edited:


Senior Developer
Staff member
We don't actually use x264. We use a MainConcept encoder. Those setting were put into the profile when we were testing x264 but did nothing when used with the MC encoder. DanR simply mapped the settings to equivalent settings in the MC encoder. However in MC there are only 3 settings so that's why he mapped them in groups of three. We still have an x264 encoder internally but it's currently not being used due to licensing issues. We may enable it some day but no promises.


Oh I see. Should definitely be removed then.

Not being x264 could explain the poor results when I tested it way back when, although it may of improved since then to be fair.
Top Bottom