X264 encoding: use presets or advanced configuration?

Started by EasyLee, January 31, 2021, 09:40:51 PM

Previous topic - Next topic

EasyLee

Is there any information available on how to use the x264 encoding presets (v. 2.7.6)? I read Avidemux' tutorial on x264 encoding, but the presets are not described there. I guess they were not yet implemented when the tutorial was written.

With the preset feature, is it recommended for guys like me with little technical knowledge to use presets rather than the advanced configuration? Is it worth using the slower and very slow presets over the slow one? And should I set fast first pass to on or off?



eumagga0x2a

I mostly use presets unless I need to test a particular feature :-D

https://dev.beandog.org/x264_preset_reference.html

I would recommend current 2.7.7 nightlies over 2.7.6 release --> https://avidemux.org/nightly/

Quote from: EasyLee on January 31, 2021, 09:40:51 PMIs it worth using the slower and very slow presets over the slow one?

No, it is mostly not worth using the slow preset either.

Quote from: EasyLee on January 31, 2021, 09:40:51 PMAnd should I set fast first pass to on or off?

Let it be on, this is also the x264 default. Unless you encode with bandwidth or size constraints in mind, there is hardly any benefit in using the 2-pass mode. I would recommend to use the constant quality mode instead.

butterw

#2
Use presets + crf. Set the h264 profile to high.

The main reason to save and use a custom x264 profile would be to force the interval between keyframes lower (default keyint is 250frames).

The question about which preset is best depends on your use case (do your own testing to get the right answer).
Based on https://trac.ffmpeg.org/wiki/Encode/H.264, if encoding time is an issue, medium is fine. If it isn't slow and slower can decrease filesize (10, 5%).
x264 settings of an encoded file are stored by default and can be viewed with mediainfo.

 

EasyLee

Thanks guys, these links are very helpful!

How come different software (Avidemux, Handbrake, FFmpeg) uses the exact same encoding preset names and tunings? I take it that the presets do the same thing under the hood in all programs. Are these presets a kind of industry standard or have they just been copied by some developers from others?

What's better about the latest nightly version? How can I be sure it's not buggy?

eumagga0x2a

#4
Quote from: EasyLee on February 01, 2021, 10:07:32 AMHow come different software (Avidemux, Handbrake, FFmpeg) uses the exact same encoding preset names and tunings?

It is one and the same library (libx264) doing the job, no matter what the client (FFmpeg, Handbrake, Avidemux). Exposing the preset names as used in libx264 verbatim in these shells simplifies the usage.

Quote from: EasyLee on February 01, 2021, 10:07:32 AMWhat's better about the latest nightly version?

Dozens of substantial bugs, present in 2.7.6, especially cut points checking code in copy mode and rate control in encoders fixed, but also a lot of issues in external audio track handling corrected, new features like support for 24-bit PCM audio and some nice new video filters added.

Quote from: EasyLee on February 01, 2021, 10:07:32 AMHow can I be sure it's not buggy?

It is buggy. Just less than the last release or any of the earlier ones.

butterw

The presets come from the x264 encoder itself.

If you care about stability, you probably shouldn't be using the latest dev version (by definition it has the latest changes, some of them will be bugfixes, but some will create new issues...).

eumagga0x2a

Most of the time dev builds are both more stable and more bug-free relative to the last release. The only known bad strife so far was the time between Dec 1 2020 and Jan 3 2021 (bogus audio blockalign check broke audio with some important demuxers). Not using the latest dev build ensures the bugs live on.

butterw

Quote from: eumagga0x2a on February 01, 2021, 10:41:35 AMMost of the time dev builds are both more stable and more bug-free relative to the last release. The only known bad strife so far was the time between Dec 1 2020 and Jan 3 2021 (bogus audio blockalign check broke audio with some important demuxers). Not using the latest dev build ensures the bugs live on.

I think it would help to have a single thread for feedback on dev builds in this subforum. It's not possible to easily follow the current status otherwise, meaning fewer people will trust dev builds.



eumagga0x2a

Quote from: butterw on February 01, 2021, 11:18:40 AMI think it would help to have a single thread for feedback on dev builds in this subforum.

I would prefer to track different issues separately.

Quote from: butterw on February 01, 2021, 11:18:40 AMIt's not possible to easily follow the current status otherwise, meaning fewer people will trust dev builds.

If you mean that some sort of blogging WRT current development would help, that may be true.

butterw

#9
Quote from: eumagga0x2a on February 01, 2021, 12:06:29 PM
Quote from: butterw on February 01, 2021, 11:18:40 AMI think it would help to have a single thread for feedback on dev builds in this subforum.

I would prefer to track different issues separately.

Quote from: butterw on February 01, 2021, 11:18:40 AMIt's not possible to easily follow the current status otherwise, meaning fewer people will trust dev builds.

If you mean that some sort of blogging WRT current development would help, that may be true.

A single rolling dev/release updated thread on the subject of changes, known bugs/issues would make Avidemux versions easier to follow and provide feedback on.
Specific issues/further discussions should probably be handled in separate threads.

Also, why is this subforum titled: Main version 2.6 ? Why is there 2.5 subforum.

eumagga0x2a

Quote from: butterw on February 01, 2021, 12:33:54 PMAlso, why is this subforum titled: Main version 2.6 ? Why is there 2.5 subforum.

I am probably not the right person to ask as I don't run this forum. I can only speculate that altering the old structure may be cumbersome and/or invalidate references to existing topics from elsewhere.