Simple x264/x265 Launcher v3.02 (2022-06-16)

[wiak]

hey lord, please add basic audio demux/muxing support and it will be perfectly simple :)
no need for any encoding like MeGUI, just demux the original audio and mux it into mkv with the time delay if there is any
keep up the good work, its seems stable on my computer

[LoRd_MuldeR]

hey lord, please add basic audio demux/muxing support and it will be perfectly simple :)
no need for any encoding like MeGUI, just demux the original audio and mux it into mkv with the time delay if there is any
keep up the good work, its seems stable on my computer

Please read the section about audio encoding from the Readme file!

[docholliday]

Hi Dude
How To use (Simple x264 Launcher) software...?
Can you Help me ?
Example : I want to encode m720p and how to setup software
Thanks Mate
---------------
I want this command-line to enter simple x264 software

x264-- 1280*544 -- bitrate 2600 -- ac3 5.1 48000 448 Kbps -- mkv -- 23.976 fps

what is the command-line ?

Thanks mate

[LoRd_MuldeR]

Hi Dude
How To use (Simple x264 Launcher) software...?
Can you Help me ?
Example : I want to encode m720p and how to setup software
Thanks Mate
---------------
I want this command-line to enter simple x264 software

x264-- 1280*544 -- bitrate 2600 -- ac3 5.1 48000 448 Kbps -- mkv -- 23.976 fps

what is the command-line ?

Thanks mate

This is a GUI program. The program itself does not use or need a command-line.

Moreover it will generate the command-line that is needed to call the encoder for you. And, as this is a front-end to x264, audio encoding is not currently possible.

...with the exceptions mentioned in the README file.

[michaelusa]

...with the exceptions mentioned in the README file.

Is the Readme file up to date? or am I missing something?
I pulled down the latest (I think..) JEEB x264 revision 2184 from http://x264.nl/, tested the --acodec option and it worked fine. Copying that version to the Launcher/toolset folder invokes an out-of date message. "Your revision of x264 is too old. Minimum required revision is 2189"
Please help, Regards Michael.

[LoRd_MuldeR]

Is the Readme file up to date? or am I missing something?
I pulled down the latest (I think..) JEEB x264 revision 2184 from http://x264.nl/, tested the --acodec option and it worked fine. Copying that version to the Launcher/toolset folder invokes an out-of date message. "Your revision of x264 is too old. Minimum required revision is 2189"
Please help, Regards Michael.

I don't think the builds from http://x264.nl/ (although built by JEEB too now) include the audio support patch!

The builds from JEEB's web-site do include that patch. But, as you have noticed, JEEB has't updated these builds for a while. They're still at r2184.

You either have to wait for JEEB to update his patched builds or you must decrease the minimum required x264 version manually.

(The Simple x264 Launcher contains that check to prevent people from encoding with outdated x264 versions - as many people tend to do)

[michaelusa]

Thanks for the quick response. I sent JEEB a question regarding an upgrade, Lets see what comes back.

[shinchiro]

I think option to minimize to system tray when close might become handy too

[LoRd_MuldeR]

I think option to minimize to system tray when close might become handy too

I will look for a way to implement this.

[VideoFanatic]

Hi, I have a 4:3 720 x 576 video. Is the following the correct SAR to use?: 12:11

[LoRd_MuldeR]

720/576 * 12/11 = 1,363 ≈ 4/3

[dado023]

isnt --fps valid x264 parameter? why do i get this error:
http://i48.tinypic.com/2j3h7yf.jpg

[stinman]

Haven't been here in awhile, once again this gets better and better. I know audio is important but most will just re-mux the same audio back in, I would think, or just use the dts core. I love "Simple" x264 launcher and don't want it bloated up. Thanks again LoRd MuldeR!

[dado023]

how can i force it to encode in 24fps?

[Kaiser Bill]

Hi LoRd_MuldeR. Want to thank you for this great app, which has now become the only one I use for converting from Avisynth scripts.

Would it be possible to add an option to hibernate after finishing any jobs rather than just shutdown? I very rarely use shutdown on my PC any more so hibernate would be a welcomed option, and the only addition I would really like to see.

[VideoFanatic]

OK here's another one. I have a 352 x 576 PAL video. I would like an aspect ratio of 2.39:1. What calculation would I do in Wolfram Alpha to find out the SAR to use?

[kypec]

OK here's another one. I have a 352 x 576 PAL video. I would like an aspect ratio of 2.39:1. What calculation would I do in Wolfram Alpha to find out the SAR to use?
I'd use --sar 43:11 which yields to 2.3888888888888888888888888888889 display aspect ratio. If you wanted to have 2.39:1 DAR precisely, the resulting SAR would be 2151:550 and I'm not sure if x264 (or H.264 specs) allow for such big numbers :(
The final error from 43:11 is negligible anyway, less than a pixel in horizontal resolution so no one cares about anyway.:)

[SeeMoreDigital]

OK here's another one. I have a 352 x 576 PAL video. I would like an aspect ratio of 2.39:1. What calculation would I do in Wolfram Alpha to find out the SAR to use?Here you go: -

http://i45.tinypic.com/2zdu9hj.png

[VideoFanatic]

Awesome tool. Thanks I will use that from now on. Just a question though. Mulder said for a 720 x 576 clip I should use 12:11 however your tool says 16:15. Which is correct? I tried both methods and both videos look the same as each other.

[SeeMoreDigital]

Awesome tool. Thanks I will use that from now on. Just a question though. Mulder said for a 720 x 576 clip I should use 12:11 however your tool says 16:15. Which is correct? I tried both methods and both videos look the same as each other.12:11 conforms to the ITU (International Telecommunication Union) standard. And is the method used for correcting the shape of non-square pixel standard-definition media.

16:15 is mathematically correct. And is the method used for correcting the shape of non-square pixel high-definition media.

[VideoFanatic]

So is it OK to use either method? I want the video to look the same no matter what device it's played on.

[Keiyakusha]

Can someone give me some tips how should I run avs2yuv to encode 10bit YV16 interleaved avisynth_x86 input into 10bit high422 profile? What should I add in commandline with or without Simple x264 Launcher?
For example with avs4x264mod this works for me:
avs4x264mod.exe --x264-binary "x264_10bit_x64.exe" --output-csp i422 --input-depth 10 --output "out.mkv" "xx.avs"
But with avs2yuv I always end up with corrupted video...

[icon]

I have a question about performance. Normally I use an avs script for the input. Simple script with mostly cropping. I seem to be able to utilize my 8 virtual cores, nearly 100% utilization.

Now I am using an avs script to resize using this filter command:

LanczosResize(480,272) # Lanczos (Sharp)

and it seems that my cpu utilization is around 20%. What gives? Is it cause this resize filter is not multithreaded? Any way to fix it? I know when I tried similar settings within Handbrake, it seemed to utilize my cpu 100%. Thanks for any help and great job with this program.

[dado023]

cant you use inbuilt x264 filter to do this?

[LoRd_MuldeR]

AFAIK, there is no multi-threading implemented in the Avisynth built-in resize filters. At least in the "official" (non-MT) version of Avisynth. With Avisynth-MT your may be able to use multi-threading.

Nonetheless I doubt a simple LanczosResize() alone can be the bottleneck. Compared to the CPU time spent in x264 (even with rather "fast" settings), the CPU time spent for the resize filter should be negligible!

So I suspect there is more than this going on in your Avisynth script or the bottleneck is not Avisynth. Anyway, dropping Avisynth and using x264's built-in FFMS2 and built-in filters is definitely worth a try...

[VideoFanatic]

Where do I find the log file for Simple x264 Launcher? There doesn't seem to be an option in the program to display the log.

[LoRd_MuldeR]

Where do I find the log file for Simple x264 Launcher? There doesn't seem to be an option in the program to display the log.

The lower pane is showing the log, when you select a job from the upper pane ;)

If you are looking for the location where the log's are achieved, when the "automatically save log" option is enabled, look at:
%LOCALAPPDATA%\LoRd_MuldeR\Simple x264 Launcher\logs

[VideoFanatic]

The lower pane is showing the log, when you select a job from the upper pane ;)

If you are looking for the location where the log's are achieved, when the "automatically save log" option is enabled, look at:
%LOCALAPPDATA%\LoRd_MuldeR\Simple x264 Launcher\logs

Where is the "automatically save log" option as I don't see it. I'm using version 2.04.295 of your program. I also can't see any log files in that location! Is this the correct location?

C:\Users\Dave\AppData\Local\LoRd_MuldeR\Simple x264 Launcher

My problem is I'm using the MT version of Avisynth and I've replaced the avisynth.dll in the System 32 folder with the file from MT. However when I try to encode the video in Simple x264 Launcher it crashes and I get the following message "avs2yux_x86.exe has stopped working". Yet if I encode with HC Encoder I don't get any problems.

[LoRd_MuldeR]

Where is the "automatically save log" option as I don't see it.

Look at preferences dialog ;)

I'm using version 2.04.295 of your program. I also can't see any log files in that location! Is this the correct location?
C:\Users\Dave\AppData\Local\LoRd_MuldeR\Simple x264 Launcher

Time to update. Also log's won't be saved unless you enable that option.

My problem is I'm using the MT version of Avisynth and I've replaced the avisynth.dll in the System 32 folder with the file from MT. However when I try to encode the video in Simple x264 Launcher it crashes and I get the following message "avs2yux_x86.exe has stopped working". Yet if I encode with HC Encoder I don't get any problems.

I can't tell you why Avisynth MT is crashing with your script. Also I can't tell you why the crash isn't triggered with HC Encoder.

But the "MT" branch of Avisynth is known to be an unstable mess. And there are various Avisynth MT builds of quite varying "quality" floating around.

So I guess you'll have to ask SEt or whoever is currently working on this, if you want that crash fixed...

[VideoFanatic]

I want to install the new version of your program . Should I uninstall the old version first? Also I can't see any option to uninstall it from the start menu. How do I uninstall it?

[LoRd_MuldeR]

I want to install the new version of your program . Should I uninstall the old version first? Also I can't see any option to uninstall it from the start menu. How do I uninstall it?

The application does not "install" anything (the setup program simply extracts the required program files to the selected directory), so there is no need to "uinstall" it.

You can simply delete the folder containing the program files, if you don't need it any longer. And of course you can simply "install" a newer version into the same folder, replacing the older version.

[icon]

cant you use inbuilt x264 filter to do this?

What would be the extra command to do this in x264?

I want the width to be 480 and the height to be whatever is necessary to keep the same sar as the original source. I can't quite get my arms around the syntax.

Edit - I figured out the syntax. Works pretty well. Actually like it better than using avisynth scripts. It gives me about a 25% boost on encoding performance, but still under utilizing my cpu. It looks like when I resize with avisynth, it uses 4 cores and when I resize with x264 it uses 6 cores. When I don't resize at all it uses 8 cores. - weird.

[LoRd_MuldeR]

Given that you haven't screwed up the "--threads" option, if x264 doesn't produce 100% CPU load, this usually has one of the following two reasons: Either you are bottlenecked by slow input (slow decoder, slow pre-processing filters, etc) or you are using very "fast" x264 settings. In the latter case it can happen that the non-parallelizable parts of x264 become more dominant. By using "slower" settings, you may be able to increase the CPU load in that case...

[icon]

Simple tests show it must be something to do with the resize filters. Resizing in Avisynth script or directly through x264 gives a low cpu utilization. No resizing, not changing anything else, gives me 100% cpu utilization. If that's the way it is, then that's the way it is.

On a separate note, could you consider putting the container format as an option that can get saved with the profile? I seem to be making 1/2 encodes in mkv format and 1/2 in mp4 format. Unfortunately, I seem to forget a lot to switch between the 2 formats manually, causing a lot of extra demuxing. Thanks.

[LoRd_MuldeR]

I still believe you must be using very "fast" encoder settings, if the resize filter becomes the bottleneck.

Try to use a lower x264 preset. Of course this won't be improve the encoding speed, but you may at least be able to squish out better quality at the same speed - by utilizing the CPU time that your CPU cores are idling at the moment...

[icon]

I always use 'slow'. I have never resized before, so I have no benchmarks really besides my recent observations. But I agree something doesn't make sense.

[VideoFanatic]

If my video is interlaced I was using the following: --tff

If the video is progressive do I simply delete that text?

[LoRd_MuldeR]

If my video is interlaced I was using the following: --tff

If you interlaced source is "top-field first" and you want to keep it interlaced, then that is the right option to set.

If the video is progressive do I simply delete that text?

Correct. Progressive video isn't field-based, thus you don't need interlaced encoding mode (and of course setting a field-order makes no sense either).

[mini-moose]

I was just told about this app and trying it now. It's very useful.

A couple things I wanted to ask/suggest

1) --level setting seems to not be added. Sure I can add it to custom parms and save it as a profile but in my opinion it's something important enough to be part of the main settings as it contributes a lot to compatibility.

2) 2-pass option - doesn't offer adding custom parms for each pass. For example I think it's not really necessary to use -o on first pass if you're using 2-pass.

3) the main difference between the builds is the x264 revision I assume? In which case I can just replace the exe when a new one is out. Unless the avs2yuv builds are often updated too?

thanks

[LoRd_MuldeR]

1) --level setting seems to not be added. Sure I can add it to custom parms and save it as a profile but in my opinion it's something important enough to be part of the main settings as it contributes a lot to compatibility.

There is no need to to use "--level", because x264 will automatically set the proper H.264 Level, based on the properties of your video and based on your encoding settings.

You would only need to set "--level" manually, if you want to enforce a different Level than x264 would set normally. But there is no guarantee that enforcing a lower Level will work!

For example, the minimum required Level depends (not only) on the resolution and frame-rate of the video - there is nothing x264 could do about that...

See also:
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels

2) 2-pass option - doesn't offer adding custom parms for each pass. For example I think it's not really necessary to use -o on first pass if you're using 2-pass.

The identical parameters should be used for both passes of a 2-Pass encode!

Note that x264 will automatically "speed up" some of the encoder settings in the first pass of a 2-Pass encode, unless "--slow-firstpass" is added explicitly.

Also you don't need to set "-o" at all. The Simple x264 Launcher will set that option for you and thus it won't allow you to enter it for a second time.

3) the main difference between the builds is the x264 revision I assume? In which case I can just replace the exe when a new one is out. Unless the avs2yuv builds are often updated too?

The difference, of course, is not only the revision number ;)

The difference is whatever has changed in the x264 code between those revisions - see the x264 changelog (http://mirror01.x264.nl/x264/changelog.txt) for details! The revision numbers are only used to distinguish the different revisions.

Furthermore different x264 builds created by different people may also differ in which "unofficial" patches have been included (if any) or in which compiler has been used to make the build.


Generally you can replace the x264 binary that ships with Simple x264 Launcher with some newer revision. Replacing it with an older revision is not supported.

Nonetheless if the x264 "core" version has changed, the binary may not be compatible anymore. Therefore Simple x264 Launcher will throw a warning, if an unknown "core" version is encountered.

Also there should be no need to replace the avs2yuv binary. Stick with the one that ships with Simple x264 Launcher and that's it!

[VideoFanatic]

I currently have a Dual Core PC with 32-bit Windows Vista. I use Avisynth (with Set's MT mode) with Simple x264 Launcher to encode a 1 hour 30 minute standard definition video to h264:

Here is my script:

setmtmode(5,2)
Mpeg2Source("H:\New\Raw 1996 March 11 new.d2v", CPU=6)
setmtmode(2,0)
Load_Stdcall_plugin("C:\Program Files\AviSynth 2.5\plugins\yadif.dll")
QTGMC(Preset="Ultra Fast")
Vinverse()
TTempSmoothF(maxr=3, lthresh=8, cthresh=5, strength=4, interlaced=true)

It takes 8 hours to encode at around 10 FPS. How much faster would a quad core be with Vista 64-bit?

How much faster would an 8 core be?

Does having a better graphics card speed up encoding? Should I get a graphics card with CUDA if that will speed up encoding?

[LoRd_MuldeR]

Switching from a Dualcore to an Octocore processor of the same processor generation (same microarchitecture) will roughly multiply your throughput by four :)

That's because the x264 encoding speed scales almost linearly with the number of CPU cores. At least up to something like ~16 cores.

Of course the above only applies if x264 itself is your performance bottleneck! If your Avisynth script is the bottleneck, then it highly depends on what filters/plugins your are using.

Some Avisynth plug-in's are multi-threaded nicely, while others are not multi-threaded at all. Also note that the Avisynth core itself is not multi-threaded at all.

(There is an "MT" branch of Avisynth available, but it is known to be an unstable mess. Feel free to experiment with Avisynth-MT tough!)


As for CUDA: x264 currently does not use/need/support CUDA or any other form of GPGPU (such as OpenCL or DirectCompute) at all. Thus a faster graphics card won't speed up x264 encoding at all!

If you have followed the discussion on this forum, then you should know that the hype around "GPU accelerated" video encoders is nothing but a marketing hoax :rolleyes:

Company xyz will tell you "our GPU-based encoder is 10x faster than x264", but they won't tell you that they compared the "crap quality" setting of their encoder to x264 running with "very slow" settings :p

If GPU's really were as suitable for video encoding as the GPU vendors try to make you believe, then somebody would already have developed a GPU-based encoder that can keep up with x264 in a fair comparison.

We are still waiting to see this happen! This all doesn't mean that you can't use a GPU-based decoder (e.g. DGDecodeNV) to feed x264. But you really don't need a "high end" graphics card for that...

[mini-moose]

There is no need to to use "--level", because x264 will automatically set the proper H.264 Level, based on the properties of your video and based on your encoding settings.

well, if you encode 1920x1080 with --profile high --preset slower, the ref will be set to 8 which exceeds the max ref h264 specs allows for that resolution. if you use --level 4.1 it will be set to 4 as it needs to be. That's mainly what I'm talking about. Try encoding a short clip with and without --level 4.1, mediainfo it and see.
Blu-Rays of course use those h264 specs - High@L4.1 and ref 4.

Here are the results from a quick test I just did (both on the same source of course):

1920x1080 using --preset slow --profile high --level 4.1 :
mediainfo : High@L4.1, ref=4

1920x1080 using --preset slow --profile high :
mediainfo : High@L5.0, ref=5


The identical parameters should be used for both passes of a 2-Pass encode!
unless "--slow-firstpass" is added explicitly.


First pass doesn't use the same parms as 2nd. As you said it's it reduces certain parms to speedup by using profile main.
personally I sometimes change certain elements that are lower on first pass (and of course much higher on 2nd pass) that my differ from --slow-firstpass, which is why I would have liked to be able to make my own modifications for first pass as well.

Also you don't need to set "-o" at all. The Simple x264 Launcher will set that option for you and thus it won't allow you to enter it for a second time.

that's not what I meant. The way it is now, first pass uses -o as well, which means it writes a video file to hdd for first pass and then overwrites it on 2nd. IMO there is no need to for that on 1st pass.
so first pass can be set to use -o NUL.

from the log file (I modified the paths):

"x264_8bit_x64.exe" --bitrate 5212 --pass 1 --stats test.stats --preset slow --profile high --output test.mkv --frames 401 --demuxer y4m --stdin y4m -


The difference, of course, is not only the revision number ;)

Fair enough, I wanted to be clear on that.
I don't think however that the various tweaks/changes/fixes made on each revision really effect the main settings available on the launcher. the presets/profiles/psy tunes are still the same as far as the cmd goes (unless there is some major change which happens once in a long time). They may have internal changes but that shouldn't effect the cmds themselves.
If I'm wrong with my assumptions I apologize in advance :) I'm perfectly fine with getting new versions and just wanted to be be clarify that subject.

Anyway, I'm happy I found out about your launcher it seems to be very useful.

[VideoFanatic]

Switching from a Dualcore to an Octocore processor of the same processor generation (same microarchitecture) will roughly multiply your throughput by four :)

As for CUDA: x264 currently does not use/need/support CUDA or any other form of GPGPU (such as OpenCL or DirectCompute) at all. Thus a faster graphics card won't speed up x264 encoding at all!

This all doesn't mean that you can't use a GPU-based decoder (e.g. DGDecodeNV) to feed x264. But you really don't need a "high end" graphics card for that...


http://www.videohelp.com/tools/DGAVCDec. That page says The DGDecNV version (costs money) is similar to the DGAVCDec program but it uses your Nvidia card to decode video much faster using CUDA video decoding.

So are you still saying that there's no need to buy a CUDA supported card because it won't speed up x264 encoding? If CUDA is useless then do I only need a basic £30 graphics card?

Any idea why the "DGVC1DecNV" link doesn't work. Where do I go to get that program?

[mini-moose]

So are you still saying that there's no need to buy a CUDA supported card because it won't speed up x264 encoding? If CUDA is useless then do I only need a basic £30 graphics card?

Any idea why the "DGVC1DecNV" link doesn't work. Where do I go to get that program?

I'm not an expert but from what I've experienced and read, using dgavcnv will make decoding your video faster (serve the frames faster to your encoder) depending on what pure video engline your cuda card has. for it to drastically effect the encoding speeds you'll need a kick ass cpu too as at the end the bottle neck is how fast your cpu can handle encoding under high 264 settings. You do not need a high end card to get faster decoding, what you need is one with the latest vp engine. the vp engine doesn't change. i.e if you buy a $50 card with vp5 or a $500 card with vp5, it will still do the same job as it's the same vp on both.
http://neuron2.net/dgdecnv/dgdecnv.html is the software's webpage.

[LoRd_MuldeR]

http://www.videohelp.com/tools/DGAVCDec. That page says The DGDecNV version (costs money) is similar to the DGAVCDec program but it uses your Nvidia card to decode video much faster using CUDA video decoding.

DGAVCDec is a "dead" project. It has a lot of problems that are never going to be fixed, as the developer dropped that project. Also it only handled AVC/H.264.

DGDecNV supports H.264/AVC, VC-1 and MPEG-2 via "hardware" decoding. And it's under active development. It does not neccesarrily decode "faster" (a decent CPU can actually decode faster than the graphic card's built-in video decoder unit), but it does keep the CPU free for other work...

So are you still saying that there's no need to buy a CUDA supported card because it won't speed up x264 encoding? If CUDA is useless then do I only need a basic £30 graphics card?

For DGDecNV you need a supported NVidia card. There is a list of supported cards on the web-site. You do not need a "high end" model though. For video decoding the actual GPU is not used! Instead a dedicated decoder unit (NVidia calls it "Pure Video") integrated on the graphic's card is used. The video decoder unit is pretty much identical between "high end" and "low end" cards. A cheap one will do the job just as well...

And, as explaind before, x264 itself doesn't use the graphic's card. It doesn't even notoice what graphics card you have. You could be running x264 on a server machine without any graphics card ^^

[LoRd_MuldeR]

well, if you encode 1920x1080 with --profile high --preset slower, the ref will be set to 8 which exceeds the max ref h264 specs allows for that resolution. if you use --level 4.1 it will be set to 4 as it needs to be. That's mainly what I'm talking about. Try encoding a short clip with and without --level 4.1, mediainfo it and see.

Each H.264 Level defines a "Decoded Picture Buffer" (DPB) size. It is the DPB size and the resolution of the video that defines the maximum number of references. Now if you feed x264 with 1080p video and set 8 referfences (either explicitely or implicitely via Preset), then x264 will of course pick the Level that can support 8 referneces for 1080p. The result will perfectly comply to the H.264 specifictions! It may not come out as Level 4.1 though, because x264 cannot magically know that you are expecting Level 4.1. It selects the Level that is suitable for your input video and for your settings! If you need Level 4.1 for whatever reason, then you may enforce this by setting "--level 4.1". But generally this won't be needed...

First pass doesn't use the same parms as 2nd. As you said it's it reduces certain parms to speedup by using profile main.
personally I sometimes change certain elements that are lower on first pass (and of course much higher on 2nd pass) that my differ from --slow-firstpass, which is why I would have liked to be able to make my own modifications for first pass as well.

What I mean is that x264 is designed to use the exactly same command-line parameters for both passes. It will automatically lower certain settings in the first pass (those that are "safe" to be lowered in a first pass), even when you use the identical parameters (except for "--pass" of course) in both passes. Thus there is no need to enter different parameters for pass1/pass2. Using different parameters can even be dangerous, because there are many options that are NOT supposed to be changed between the passes...

that's not what I meant. The way it is now, first pass uses -o as well, which means it writes a video file to hdd for first pass and then overwrites it on 2nd. IMO there is no need to for that on 1st pass.
so first pass can be set to use -o NUL.

It could be done, yes. But it doesn't have to. The way it currently is, we can inspect the temporary file while the first pass is still running...

Fair enough, I wanted to be clear on that.
I don't think however that the various tweaks/changes/fixes made on each revision really effect the main settings available on the launcher. the presets/profiles/psy tunes are still the same as far as the cmd goes (unless there is some major change which happens once in a long time). They may have internal changes but that shouldn't effect the cmds themselves.
If I'm wrong with my assumptions I apologize in advance :) I'm perfectly fine with getting new versions and just wanted to be be clarify that subject.

Most of the time the command-line interface of x264 doesn't change, so we can update the x264 binary without modifying the GUI. Nevertheless changes to the command-line interface may happen and may break compatibility. Also keep in mind that the GUI needs to read x264's console output. If the console output changes, it may (and probably will) also break the compatibility.

[mini-moose]

It may not come out as Level 4.1 though, because x264 cannot magically know that you are expecting Level 4.1. It selects the Level that is suitable for your input video and for your settings!
I'm well aware that the level is auto chosen in relevance to presets etc. The thing I'm saying that using anything over level 4.1 might cause compatibility issues with certain hardwares. Sure you can set it to whatever you want but if you spent several hours making your video and your hardware chokes on it you end up with wasting your time.
http://mewiki.project357.com/wiki/X264_Settings#level :
"Level 4.1 is often considered the highest level you can rely on desktop consumer hardware to support. Blu-ray Discs only support level 4.1, and many non-mobile devices like the Xbox 360 specify level 4.1 as the highest they officially support"

[LoRd_MuldeR]

Well, not everybody is encoding for consumer hardware decoders. A lot of people encode to watch the result on a PC and there Levels are pretty much irrelevant (for software decoders). If you need to hit a specific Level, well, go ahead an add "--level x.y" to the custom parameters. It will even be included in your template! But I don't think we should enforce a specific Level by default. Especially because enforcing, e.g. Level 4.1, can be far too high - depending on the source. I can't remember what x264 does when the request Level is higher than needed. But we either get a video with a "wrong" (too high) Level flag or we get a video whose Level will be different from what the user has selected. And you know, user will be confused if selected Level is 4.1, but the video comes out at Level 3.0, for example...

[mini-moose]

Well, not everybody is encoding for consumer hardware decoders.
fair enough. I didn't suggest forcing a certain level just adding a lever selector next to tune/preset/profile.
Every one of the main settings can cause some confusion.
All such confusions can be resolved after some trial and error and spending some time reading mans (or do a bit of research).