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

[r0lZ]

Oops, sorry. My fault. The previous version was installed in portable mode, and I forgot to rename the new x264_launcher.exe to x264_launcher_portable.exe. The bug happens only when I launch the old x264_launcher.exe. Of course, it tries to use the new files, hence the version mismatch.
The problem is now solved.

[LoRd_MuldeR]

The bug happens only when I launch the old x264_launcher.exe.

It's not a bug, it's a feature! ;)

(This will prevent an executable from running with a "wrong" library version, i.e. iff library version used at runtime doesn't match library version used at compile-time, program launch will abort with error)

[r0lZ]

OK. Bug is the wrong word. But when the error message happens, it looks like a bug. And it is surprising. And it is not really obvious that it's because there are two different exes in the same folder, due to the portable+normal manual installations.

BTW, perhaps you can do something to detect that situation, and issue a more user friendly error message, and invite the user to rename the exe correctly. I'm sure I'm not alone to use the portable version, and normally, when a new version of a portable program is available, it is sufficient to extract the ZIP archive in the program directory. It's not the case with your Laubncher, and that's surprising. Not a big deal, but I would appreciate if you can avoid that issue.

[LoRd_MuldeR]

You do not get this error message, because you have "two different exes in the same folder". You do get this error message, because you are trying to use the program (EXE file) together with a the wrong/incompatible library (DLL file). If we didn't detect and intercept this situation, the alternatives range from "appears to work properly" to random and difficult-to-reproduce crashes. I think the error message is as is clear as it can be: The version of the MUtilities library doesn't match!

BTW: No user who uses the program in the proper way will ever get to see this error message. Use the EXE file together with the DLL file from the same release package – or even better: let the installer take care of everything – and you will be fine. By mixing the EXE file from one release with the DLL file from a different release, you are asking for trouble! You can try the same thing with any other program out there, and the result will either be crash or error message - or sheer luck ;)

[r0lZ]

I agree, but the fact is that you distribute your program in a zip archive. (There are also installers, I agree, but the ZIP is present, and you should take it into account. And by definition, portable programs should never use installers, because they leave traces on the system.) It is also your method to install the program in portable mode that requires to rename the exe file. Other methods exist, such as creating an empty dummy file in the programs folder, and IMO that methods are better because they do not require to modify the installation after each update.

Anyway, with a renamed exe file in the directory AND a non-renamed file in the ZIP, it is not surprising that some users end up with two exes in the same folder. One of the exe is obsolete and causes the problem. Your method forces the user to be very cautious when extracting the files from the ZIP. I agree that I haven't been cautions enough, but your method of implementing the portable mode is the primary culprit. It's why I suggest to add a safety check before loading any library to verify if there is a mismatch (if it's possible), and if it's the case, inform the user with a message that is not destined to programmers. Most newbie users will probably never imagine what can be the cause of the current obscure error message. I haven't said that it is not correct. It is just too complex for most users, who do not even know what a library is. And if I have been able to understand the problem (and post the oops message above) it's because, like you, I'm a programmer. You cannot assume that it's the case of everybody.

Anyway, I know that I will not convince you. After all, do what you want. I have had the problem once and if it happens again, I know what to do. My suggestion is for you and the other users, not for me. I don't want to force you to make your program more user friendly. It is excellent anyway.

[LoRd_MuldeR]

I agree, but the fact is that you distribute your program in a zip archive. (There are also installers, I agree, but the ZIP is present, and you should take it into account.

It's the same with every program that exists and that will ever exist: If you download the program as a ZIP file, you will have to extract all program files from the ZIP archive into the destination directory - preferably a new, empty directory - in order to make the program work properly. And if the ZIP includes some DLL's, this means that you will have to put these DLL's into the proper place too. Missing out some of the DLL's or, even worse, throwing in some other DLL's that weren't even included in the ZIP archive (unless explicitly stated in the installation instructions, of course), means that you are asking for trouble! The Simple x264 Launcher isn't an exception here.

BTW: I'm not the biggest fan of distributing software in ZIP files, exactly because it can result in various kinds of problems, if users aren't careful. But people insist, because installers are inherently "evil" :p


It is also your method to install the program in portable mode that requires to rename the exe file. Other methods exist, such as creating an empty dummy file in the programs folder, and IMO that methods are better because they do not require to modify the installation after each update.

Yes, other methods exist. And if I had decided for another method, I'm pretty sure that somebody would come along and proclaim why that method wasn't a good decision. Overall, I think that the current method works fairly well and it's simple to use. Furthermore, changing the method now would only cause even more confusion. So I think we will simply stick with this method, until I get bored and come up with something more nifty ;)


It's why I suggest to add a safety check before loading any library to verify if there is a mismatch (if it's possible), and if it's the case, inform the user with a message that is not destined to programmers. Most newbie users will probably never imagine what can be the cause of the current obscure error message. I haven't said that it is not correct. It is just too complex for most users, who do not even know what a library is. And if I have been able to understand the problem (and post the oops message above) it's because, like you, I'm a programmer. You cannot assume that it's the case of everybody.

This "safety check" already is implemented. That's why the situation is detected and intercepted (i.e. you see an error message telling you about the problem), instead of just going on with an incompatible library and potentially running into random, difficult-to-reproduce crashes. Anyway, as soon as I add new functions to the library (and the program actually makes use of these new function), trying to run the program with an "old" library version, which is lacking the new function, is unavoidably going to produce a cryptic (http://i.imgur.com/pPwz50A.png) error message directly from the operating system. There is nothing that can be done about this. That's because the operating system will never actually start our program, if a required DLL is missing or if a required entry point is missing from a required DLL. And, if the program is never actually started, it never gets a chance to do any kind of error handling.

Anyway, maybe the second part of the error message should be changed from "Please re-build the complete solution in order to fix this issue!" into "Please perform a clean re-install in order to fix this issue!" :confused:

[r0lZ]

I did know that I have no chance to convince you. But I have to certify that I have extracted ALL files from the ZIP into the target folder. It's NOT my fault if I had to rename the exe of the previous install. My only fault is that I did not remember that your program IS difficult (or should I say "special") to install in portable mode. And, of course, you cannot imagine that the users will re-install all files in an empty directory at each update. The old files must be overwritten, and it's what I did. But one file is an exception due to your method of implementing the portable mode, and has not been overwritten as it should. And I got the problem. I have almost all my programs installed in portable mode (including programs distributed only with an installer and not supposed to be installed in portable mode) and I have never had a problem when updating the files in the old directory. Except today.

With the new libraries, the old program CAN start, since it displays an error message. (AFAIK, that message does not come from the OS.) Therefore, changing it to be more descriptive of what could have produced the problem is a good solution. If it's possible, yes, the message that you suggest in the last paragraph is already much easier to understand. But given the "programmer oriented" nature of the original message, I guess it is coming from the library itself, and that you haven't written it yourself. It may therefore be difficult to change it. I persist to suggest to change it if it's possible.

Anyway, do whatever you want...

[LoRd_MuldeR]

I did know that I have no chance to convince you. But I have to certify that I have extracted ALL files from the ZIP into the target folder. It's NOT my fault if I had to rename the exe of the previous install. My only fault is that I did not remember that your program IS difficult (or should I say "special") to install in portable mode. And, of course, you cannot imagine that the users will re-install all files in an empty directory at each update. The old files must be overwritten, and it's what I did. But one file is an exception due to your method of implementing the portable mode, and has not been overwritten as it should. And I got the problem. I have almost all my programs installed in portable mode (including programs distributed only with an installer and not supposed to be installed in portable mode) and I have never had a problem when updating the files in the old directory. Except today.

Well, probably you have extracted all files into the directory. But you also left an old EXE file there, while replacing one of its required DLL files with a new (different) version that this old EXE file was never supposed to work with. Doing such thing with any program that exists (or that will ever exist) is only asking for trouble. The Simple x264 Launcher is no exception here. And it's exactly why I said that, if you are installing a program manually form ZIP file, you should extract the complete ZIP file into a new/empty directory, rather than "mixing" the new files into an existing installation. The latter method is prone to producing an inconsistent mess, no matter what.


With the new libraries, the old program CAN start, since it displays an error message. (AFAIK, that message does not come from the OS.) Therefore, changing it to be more descriptive of what could have produced the problem is a good solution. If it's possible, yes, the message that you suggest in the last paragraph is already much easier to understand. But given the "programmer oriented" nature of the original message, I guess it is coming from the library itself, and that you haven't written it yourself. It may therefore be difficult to change it. I persist to suggest to change it if it's possible.

The "old" program will be able to start with a "new" library, if and only if none of the functions or classes that the "old" program uses have been removed or renamed in the "new" library. Otherwise, the program just won't start. And in that case you would see (an rather cryptic (http://i.imgur.com/pPwz50A.png)) error message directly from the operating system. But even if the program still does start with the "wrong" library, this certainly does not mean that everything is going to work flawlessly. Au contraire! Just because a function or class still exists under the same name, it doesn't mean it still works in the same (expected) way. In particular, some data structures may have changed in the meantime, which means that the main program will be assuming a different memory layout than the library does! This will cause nice little memory corruptions, resulting in undefined behavior, including random crashes. So, obviously, it makes sense to detect and intercept this situation. That's what the library does.

[r0lZ]

You have the speciality to endlessly repeat the same thing. I know that the old exe should have been removed and the new exe renamed. But it's because the distribution of your program and its method of implementing the portable mode is what it is that the problem occurs. And it's why YOU have a responsibility in the problem. Anyway, "Il n'est pire sourd que celui qui ne veut rien entendre."

[OT] I have learned the C language when I had an Amiga, and at that time, it was considered that a library HAS TO BE BACKWARD COMPATIBLE. Always. Any exception to that rule is bad programming. Dot. Unfortunately, under Windows (and also Linux), that rule is rarely respected, and therefore it is often necessary to adapt the code and recompile the programs (when it's not the whole OS) when a dynamic library is updated. (BTW, it's why Windows has to keep all old versions of their DLLs in a complex directory structure. And it's also why the same DLL is distributed 100 times, with 100 different programs, because each program must be sure to use the good version. If it's not bad programming, what is it?) It's a pity, because there are methods to add new features and/or entry points to an existing library without breaking the compatibility (even when old functions requires new arguments). IMO, any programmer should use only libraries written with that backward compatibility in mind. I know that it's not easily feasible today, and of course I don't blame you or your libs, but it's a general problem of the modern methods of programming the libraries. A library without backward compatibility must therefore add safeguards such as the error message I have seen. It's mandatory for obvious reasons, but it's certainly NOT a feature! It's just an appalling workaround for the lack of backward compatibility.[End of OT]

[LoRd_MuldeR]

You have the speciality to endlessly repeat the same thing.

There is no need to get impolite here :rolleyes:

I know that the old exe should have been removed and the new exe renamed. But it's because the distribution of your program and its method of implementing the portable mode is what it is that the problem occurs. And it's why YOU have a responsibility in the problem. Anyway, "Il n'est pire sourd que celui qui ne veut rien entendre."

The distribution of my program as a ZIP file is what people demand. I recommend using the installer, and leave the ZIP for the "pro" users and the "portable" enthusiast. If you decide for the manual installation method (ZIP file), you should know that you are supposed to extract the ZIP file into a new empty directory - rather than "mixing" the new files into an existing installation. The way how portable mode works is pretty much unrelated here! Whether you had renamed the program file before or not: If had made a clean install rather than just throwing the new files into the existing installation directory (overwriting some files, keeping some others), there would have been no problem whatsoever.


[OT] I have learned the C language when I had an Amiga, and at that time, it was considered that a library HAS TO BE BACKWARD COMPATIBLE. Always. Any exception to that rule is bad programming. Dot. Unfortunately, under Windows (and also Linux), that rule is rarely respected, and therefore it is often necessary to adapt the code and recompile the programs (when it's not the whole OS) when a dynamic library is updated. (BTW, it's why Windows has to keep all old versions of their DLLs in a complex directory structure. And it's also why the same DLL is distributed 100 times, with 100 different programs, because each program must be sure to use the good version. If it's not bad programming, what is it?) It's a pity, because there are methods to add new features and/or entry points to an existing library without breaking the compatibility (even when old functions requires new arguments). IMO, any programmer should use only libraries written with that backward compatibility in mind. I know that it's not easily feasible today, and of course I don't blame you or your libs, but it's a general problem of the modern methods of programming the libraries. A library without backward compatibility must therefore add safeguards such as the error message I have seen. It's mandatory for obvious reasons, but it's certainly NOT a feature! It's just an appalling workaround for the lack of backward compatibility.[End of OT]

If you create a library that is supposed to be used as a system-wide library, i.e. the exactly same DLL files is supposed to be used by many different applications, then keeping the ABI (http://en.wikipedia.org/wiki/Application_binary_interface) backwards-compatible is an important goal, yes! And if you cannot keep the ABI of a system-wide library backwards-compatible for whatever reason, then the library should be renamed, so that the "old" and the "new" version can be installed side-by-side and each program can use the required one. BUT: A private library, which resides in a program's installation directory, which forms an integral part of that program and which was never designed to be used by any other program, is a fundamentally different thing! Here you have a fixed bundle, so you know which exact program binary is going to use which exact library binary (provided user hasn't messed up his installation, yes). Consequently any effort on keeping the ABI backwards-compatible is a waste of time and an unnecessary burden.

Furthermore, C++ libraries are fundamentally different from pure C libraries, regarding the interface. In contrast to a pure C library, a C++ library exports classes, not just functions. Heck, you can't even mix C++ libraries from different compilers, due to non-standardized name mangling (http://en.wikipedia.org/wiki/Name_mangling). If you extend a class, it unavoidably changes the class' memory layout! And the memory layout is defined in the header (.h) file, not in the DLL! Consequently, if you extend a class in the library (DLL), then the main program (EXE) needs to be re-compiled with the updated header (.h) file. Otherwise, memory corruptions follow! Of course you can also keep the ABI of a C++ library backwards compatible, but that would mean that you are required to not change (not even extend!) any of the classes which are exported from your library! That is a very harsh restriction and a huge burden on development. And it's far to easy to break the ABI of a C++ library, even if you intend to not do it... So, to make a long story short, if we are talking about C++ libraries, you better get rid of the idea of sharing the same DLL between different applications in a "system wide" fashion - let alone making the same binary (EXE file) work with different DLL versions.


Here is a pretty good article on creating binary-compatible C++ interfaces:
http://chadaustin.me/cppinterface.html

As you can see, while it is doable, it requires a whole lot of extra effort and makes you code much more complex/obscure - something you certainly do not want for a "private" library, which doesn't really need binary compatibility.

(Would you pay extra money for an travel insurance, just because the salesman told you that it's good to have one, although you know for sure that you won't go on a journey anytime soon?)

[johnchoi]

I just upgraded (it nagged me about being 6 months out of date) and the CLI options I was passing no longer seem to work. For instance, if I pass the following CLI:

"C:\Program Files (x86)\Video\Simple x264 Launcher v2\x264_launcher.exe" --add-job "D:\Output Dir\Random.Test.avs" "D:\Output Dir\Random.Test.mp4" 404pSD


All I get is the Simple x264 Launcher window. It doesn't add the job or give any errors. The templates are all present in the dropdown and I can add the job via the GUI just fine and get it to run. Just can't get it add a job and start from CLI. Any ideas? Thanks!

[LoRd_MuldeR]

I just upgraded (it nagged me about being 6 months out of date) and the CLI options I was passing no longer seem to work. For instance, if I pass the following CLI:

"C:\Program Files (x86)\Video\Simple x264 Launcher v2\x264_launcher.exe" --add-job "D:\Output Dir\Random.Test.avs" "D:\Output Dir\Random.Test.mp4" 404pSD


All I get is the Simple x264 Launcher window. It doesn't add the job or give any errors. The templates are all present in the dropdown and I can add the job via the GUI just fine and get it to run. Just can't get it add a job and start from CLI. Any ideas? Thanks!

In the course of my efforts to consolidate all my different software projects, most of my projects are now built on top of a common "core" library (MUtilities).

This also effects the code for parsing the command-line parameters. As a result, the command-line syntax has changed slightly!

The bad news is that people will have to adjust their scripts. But the good news is that the CLI syntax is now more consistent between all my applications :)

Try updating your command-line call like this:
x264_launcher.exe" --add-job="D:\Output Dir\Random.Test.avs|D:\Output Dir\Random.Test.mp4|404pSD"

Also see the README file for details :sly:

[johnchoi]

Also see the README file for details :sly:
Sorry, READWHAT? That seems like a lot of effort.

Thanks for the quick response. I was able to edit my scripts and it all works flawlessly as usual. Thanks!

[LoRd_MuldeR]

Here is a new TEST build:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2015-08-02.R2.exe/download

This one updates x264 and x265 to the latest versions. Also, for x265, there now is a "12-Bit" encoding option available. But be aware that 12-Bit HEVC is still considered experimental!

Furthermore, various things "behind the scenes" have been rewritten completely, to make the code more clean and flexible. Expect a few regressions ;)

[alkoon]

Hi.

I have problem! ><"

actually I encoded video by X264 launcher , the format of the video after encoding is hevc!

http://im58.gulfup.com/HfX9q7.png


so when i tried to open the video by MPC I can't toggle between elapsed and remaining time , the the only thing appearing is elapsed time ?

http://im58.gulfup.com/MhxEl4.png


I don't know why!!

[sneaker_ger]

The HEVC data was written without any index or outer container. Once you put it into a container like mkv or mp4 it will become seekable in every player. (You can use mkvtoolnix, for example)
Some players may allow a bit of seeking even without a container/index so you can see if the encode is good. (Try VLC)

[alkoon]

The HEVC data was written without any index or outer container. Once you put it into a container like mkv or mp4 it will become seekable in every player. (You can use mkvtoolnix, for example)
Some players may allow a bit of seeking even without a container/index so you can see if the encode is good. (Try VLC)



ِActually when I tried to encoder mp4 to (mkv format / H265 encoder), it's directly saving in HEVC format -_-, so I tried to convert it to MKV by MKVtoolnix but the software not supporting Hevc!

[sneaker_ger]

MKVToolNix does support HEVC. Not sure what you are doing. Maybe your version is outdated? 8.2.0 is the latest one.

[LoRd_MuldeR]

ِActually when I tried to encoder mp4 to (mkv format / H265 encoder), it's directly saving in HEVC format -_-, so I tried to convert it to MKV by MKVtoolnix but the software not supporting Hevc!

At this time, the x265 encoder only supports "raw" HEVC output - wrapping into MKV or MP4 is not supported yet. You'd have to ping the x265 team to change this ;)

Muxing "raw" HEVC into MKV container with MKVToolNix (https://www.bunkus.org/videotools/mkvtoolnix/downloads.html) works fine for me though. Same for muxing into MP4 with current MP4Box (http://www.videohelp.com/software/mp4box)...

[alkoon]

At this time, the x265 encoder only supports "raw" HEVC output - wrapping into MKV or MP4 is not supported yet. You'd have to ping the x265 team to change this ;)

Muxing "raw" HEVC into MKV container with MKVToolNix works fine for me though...

Isee, Ok for example if I encode Raw MP4 output into HEVC I can't toggle between elapsed and remaining time?, as happened to me?!

[LoRd_MuldeR]

Isee, Ok for example if I encode Raw MP4 output into HEVC I can't toggle between elapsed and remaining time?, as happened to me?!

Not sure what you mean with "Raw MP4" (MP4 is a container format!?), but if you create "raw" HEVC output, i.e. not muxed into MP4 or MKV container, then the playback software may not be able to seek and/or determine the total duration.

That's because, as sneaker_ger said, the "raw" HEVC stream does not contain any kind of index. So the player would have to parse the entire file to determine the total duration - which would take a very long time, every time you open the file.

Solution for this is quite easy: Just mux the "raw" HEVC stream into an MKV or MP4 container, using MKVToolNix (https://www.bunkus.org/videotools/mkvtoolnix/downloads.html) or MP4Box (http://www.videohelp.com/software/mp4box), respectively... :)

[alkoon]

Not sure what you mean with "Raw MP4" (MP4 is a container format!?), but if you create "raw" HEVC output, i.e. not muxed into MP4 or MKV container, then the playback software may not be able to seek and/or determine the total duration.

That's because, as sneaker_ger said, the "raw" HEVC stream does not contain any kind of index. So the player would have to parse the entire file to determine the total duration - which would take a very long time, every time you open the file.

Solution for this is quite easy: Just mux the "raw" HEVC stream into an MKV or MP4 container, using MKVToolNix (https://www.bunkus.org/videotools/mkvtoolnix/downloads.html) or MP4Box (http://www.videohelp.com/software/mp4box), respectively... :)


Thank you very much :rolleyes:

[knight_]

Hi,
great tool altogether. Love it!!

I have trouble though, using the command-line switches, probably due to my inexperience concerning command lines.
In some rare cases i would need the --no-deadlock-detection switch, because of intense filtering that takes a lot of time to get started since not all filters support multithreading.
I tried every possible way I could think of, to insert it into the GUI and also started the job via CLI. Allways with the same result, abortion after 5 min.
How do I use the switch? Is it only possible using the CLI? If so, can somebody give me a command line example that would work, pls.

[LoRd_MuldeR]

Hello, knight_. Please be aware that "--no-deadlock-detection" is an option for the Simple x264 Launcher itself.

It is not an option for x264 or x265, so you can not enter this into the "Custom Encoder Parameters" edit box. Instead, you have to pass it directly to x264_launcher.exe, when you start it.

The easiest way is to create a new shortcut to "x264_launcher.exe", go to the Properties of that shortcut and append "--no-deadlock-detection" into the "Target" box.

[knight_]

Works as explained. Thank you LoRd_MuldeR!!!

Lord you are the king :sly:

[alkoon]

Hi Mr MulderR!

actually my friend have problem, when he starts your tool

http://im54.gulfup.com/4SoduI.png

it's going well with H264 unlike H265!!

[LoRd_MuldeR]

This error message means that Avisynth is not currently installed. You need to install Avisynth (http://avisynth.nl/index.php/Main_Page#What_is_AviSynth.3F), if you want to use an Avisynth Script (.avs) as input.

(Whether this message box appears, or not, depends on whether Avisynth is installed. This is detected at application startup. The selected encoder does not matter here!)

[alkoon]

He reinstall Avisynth, it's working now . thanx

[Marban]

nice work, but i cant find the Resolution, Crop and Audio Settings :D

[praosv]

I have seen this program very recently and started using with x264.
I tried suceesfully the crop and resize commands as
"--vf crop:0,188,0,214/resize:width=1920,height=816"
But I could not succeed in exexcuting the command
"addLogo: x=1510, y=622, alpha=255, logo=E:/DEVARAYA3.jpg"
Please correct where I am going wrong.
Thank you.

[LoRd_MuldeR]

But I could not succeed in exexcuting the command
"addLogo: x=1510, y=622, alpha=255, logo=E:/DEVARAYA3.jpg"
Please correct where I am going wrong.
Thank you.

To the best of my knowledge, there is no "addLogo" filter in x264. Available video filters in x264 include "crop", "resize" and "select_every".

For more advanced filtering tasks, I highly recommend you use Avisynth or VapourSynth as input.

[r0lZ]

I forgot to report a little bug I've encountered recently.

I have added an argument similar to this in the x264 options field:
--qpfile "path to/series name - S01E01.qpfile"

And the launcher insists to say that there is an error, with a message similar to "Invalid argument -". It appears that it considers the - within quotes as the beginning of an argument. Of course, it should not.

OK, the error message itself is not important and can be ignored, but the launcher refuses to launch the encoding. And that's much more problematic. It should either parse the arguments correctly and ignore the -, or provide an option to ignore the error message and launch the encoding anyway (at the risk of the user of course).

In this precise case, I have had to rename the qpfile, but it's not the best solution.

[LoRd_MuldeR]

It's because the StringValidator breaks the input string into space-separated tokens. It does not parse the string like the C-Runtime does to create argv[] array, i.e. allow spaces in sequences wrapped into double-quotes.

I'll have to see what can be done about this...

[LoRd_MuldeR]

Here is a new Test build:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2015-09-20.exe/download

This one has a re-written validator for custom commad-line arguments. Please report any regressions you may find.

[r0lZ]

Thanks!

[rsotome]

Thank you for the most recent build, but now I get an "Invalid syntax" when I try to use ANY negative numbers in the first space of the deblock setting.

--deblock -2:-1 , Invalid syntax
--deblock 0:-1 , no problems

was that done for a reason, or just a bug?

[LoRd_MuldeR]

Thank you for the most recent build, but now I get an "Invalid syntax" when I try to use ANY negative numbers in the first space of the deblock setting.

--deblock -2:-1 , Invalid syntax
--deblock 0:-1 , no problems

was that done for a reason, or just a bug?

Yeah, I see what's wrong here:

If a token starts with "-" or "--" it is considered an option. Generally, options starting with "-" have exactly one character, like e.g. "-o", while options starting with "--" have multiple characters, like e.g. "--output".

However, "-2:-1" starts with "-", but it has more than one character in the following. That is detected as a syntax error. So, clearly, we need special handling for (negative) numeric values!

[LoRd_MuldeR]

Thank you for the most recent build, but now I get an "Invalid syntax" when I try to use ANY negative numbers in the first space of the deblock setting.

--deblock -2:-1 , Invalid syntax
--deblock 0:-1 , no problems

was that done for a reason, or just a bug?

Yeah, I see what's wrong here:

If a token starts with "-" or "--" it is considered an option. Generally, options starting with "-" have exactly one character, like e.g. "-o", while options starting with "--" have multiple characters, like e.g. "--output".

However, "-2:-1" starts with "-", but it has more than one character in the following. That is detected as a syntax error. So, clearly, we need special handling for (negative) numeric values!

Okay, please try with the latest TEST build:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2015-09-22.exe/download

If there are no regressions found in this build, I'm probably going to make a new release very soon.

[rsotome]

So far so good. :)

[LoRd_MuldeR]

Simple x264 Launcher v2.60
https://github.com/lordmulder/Simple-x264-Launcher/releases/tag/v2.60

Simple x264/x265 Launcher v2.60 [2015-10-12]
* Much improved validation of custom parameters
* Massive code clean-up
* Some minor fixes and improvements
* Updated x264 to revision 2597
* Updated x265 to version 1.8+2

[Dion]

You really don't want people using custom x264 builds do you. Completely breaks tMod with this update. So had to delete it.. going back to MeGUI.

[LoRd_MuldeR]

You really don't want people using custom x264 builds do you. Completely breaks tMod with this update. So had to delete it.. going back to MeGUI.

The Simple x264/x265 Launcher is designed to work with "official" x264 and x265 binaries. It should be obvious that I can not test with every "custom" build that might be floating around somewhere on the Internet.

Anyway, there certainly is nothing in the Simple x264/x265 Launcher that intentionally "blocks" custom builds. Consequently, if a certain "modified" x264 or x265 binary doesn't work, then this is because the affected binary has broken something!

You missed to give us any details on what exactly went wrong, but there are (at least) two possibilities I can think of:
The patch has modified x264's text output in an incompatible way, so that the Simple x264/x265 Launcher cannot parse the x264 output.
The patch has removed (or renamed) one of the standard CLI parameters, so that the command-line generated by Simple x264/x265 Launcher (which is targeted for standard x264) couldn't be processed by the modified x264.

[LoRd_MuldeR]

Simple x264 Launcher v2.61

Simple x264/x265 Launcher v2.61 [2015-10-19]
* Refined custom parameters validation code, again
* Fixed processing of CLI arguments for Launcher (regression in v2.60)
* Remove "junk" Trolltech registry key when application quits
* Updated x264 to revision 2638
* Updated x265 to version 1.8+31

[kypec]

Hi Lord Mulder, any chance you could make columns Status and Progress resizable too?
It's hard to see which pass is running at the moment unless looking in the Job Details output very closely... :thanks:
http://i60.tinypic.com/2a7efr7.jpg

[LoRd_MuldeR]

kypec,

judging from your screenshot, it looks like you have messed with your DPI settings, which is probably why the text has been cut off.

Anyway, I can't remember why I set these columns to use a fixed size in the first place :confused:

Here is a new TEST build, which has the last two columns set to the "ResizeToContents" mode, which makes more sense, I suppose:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2015-10-24.exe/download

[kypec]

No, I didn't mess with my DPI settings, at least I'm not aware of any special settings that I'd made (using Windows 8.1 on laptop with FullHD screen resolution).
Anyway, your test build works fine so :thanks: once again for your wonderful tool!

[LoRd_MuldeR]

No, I didn't mess with my DPI settings, at least I'm not aware of any special settings that I'd made (using Windows 8.1 on laptop with FullHD screen resolution).
I think you use non-standard DPI configuration, but maybe Windows now sets this automatically for "High DPI" screens? (although a screen with "only" Full HD resolution would be an unusual candidate)

Anyway, you can use this tool to check your current DPI settings:
http://sourceforge.net/projects/muldersoft/files/Whats%20My%20DPI/WhatsMyDpiAgain.2015-10-25.zip/download

This is how the Simple x264 Launcher looks at different DPI settings:
96 dpi (100%): http://i.imgur.com/vEyoYUc.png
120 dpi (125%): http://i.imgur.com/JrWJefK.png
144 dpi (150%): http://i.imgur.com/itXiKsw.png

In theory, Qt should be "DPI aware", so at least the UI doesn't look totally blurred at non-standard DPI settings. But you never know what layout issues may appear, when UI elements get scaled up to 125% or even 150% of the original size...

[kypec]

You were right, according to your diagnostic tool my display is set to DPI = 144 currently. Anyway, since it's only 14" screen and my sight is getting worse every year I don't complain about Windows setting DPI so high this time. Your launcher looks OK even at 150% so keep up the good work!

[almosely]

Hello, hello ;-)

At first: Great work - thank you!

I am using your launcher quite a while now (1-2 years, I think). And sometimes it happened, that I forgot to switch the "Shutdown computer ..." gadget within the preferences, so my computer shuts down accidentally. Maybe you could place this button outside this "hidden" window to the main windows top area instead?

[r0lZ]

I second that idea. Or, if it's not possible, maybe reset that option to off each time the program is closed.