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

[LoRd_MuldeR]

When i want to setup VapourSynth it gives me this error.

http://i.imgur.com/4wPdToE.jpg

http://www.python.org/download/windows/ ;)

[docholliday]

I'm downloaded this file ( http://www.python.org/ftp/python/3.3.2/python-3.3.2.amd64.msi ) and installed,but when i want to setup VapourSynth it gives again same above error.What should i do?

[LoRd_MuldeR]

I'm downloaded this file ( http://www.python.org/ftp/python/3.3.2/python-3.3.2.amd64.msi ) and installed,but when i want to setup VapourSynth it gives again same above error.What should i do?

This is getting off-topic, because this thread is not a VapourSynth support thread, but I think you should try:
http://www.python.org/ftp/python/3.3.2/python-3.3.2.msi

(VapurSynth for Windows currently is only available as 32-Bit, so you will probably require a 32-Bit version of Python 3.3)

[docholliday]

One more thing,I would like to know what is the benefit to install VapurSynth ?

[LoRd_MuldeR]

One more thing,I would like to know what is the benefit to install VapurSynth ?

You can use VapourSynth input !?!?

[Chumbo]

...It's not easily possible to add a checkbox into a QMessageBox. You will find a few hacks, if you google for "QMessageBox + checkbox", but the result is not satisfying.

QErrorMessage does provide a checkbox, but it is not suitable for other reasons. That's why I implemented a different solution (see "preferences" dialog).
I understand. Would you consider adding the option to the Preferences dialog? Thanks again.

[LoRd_MuldeR]

I understand. Would you consider adding the option to the Preferences dialog? Thanks again.

That's what I have done :devil:

It's not easily possible to add a checkbox into a QMessageBox. You will find a few hacks, if you google for "QMessageBox + checkbox", but the result is not satisfying.

QErrorMessage does provide a checkbox, but it is not suitable for other reasons. That's why I implemented a different solution (see "preferences" dialog).

[Chumbo]

That's what I have done :devil:
LOL, I checked, but didn't see it. ;) I guess I had not grabbed the latest version that's out there. Thank you. :D

[Evil_Burrito]

Simple x264 Launcher (Build #568), built 2013-08-11
...
Custom: --opencl
...
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSEMisalign LZCNT
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTX 660
x264 [info]: OpenCL: unable to open clbin file for write

If I right click Simple x264 Launcher then Run as administrator, this error doesn't appear. But Simple x264 doesn't prefer to run with these privileges. Could you tell me how to fix this?

[LoRd_MuldeR]

Try adding the following to the custom parameters:
--opencl --opencl-clbin "C:\Some path where you have write-access even WITHOUT admin privileges\x264_lookahead.clbin"

You might even try something like this:
--opencl --opencl-clbin NUL

In any case, if the "clbin" file cannot be written, x264 should go on anyway. The OpenCL kernel simply won't be cached, i.e. it gets recompiled every time. So don't worry ;)

[Evil_Burrito]

Ok, I will try it. Thanks for the input.

[Rodger]

Hey mulder,

just tried vapursynth and have to say that it is nice to have an alternative but avisynth(64) seems a bit faster.
3-5% more speed with avisynth and my settings (medium, ABR, 5Mbit for FullHD content from TV)
I think I saw that after about 2% it looses some power....it gets slower.

But this is just my first impression.
What´s your opinion on this?

Want to compare results?
Want me to use some special settings?
Want to use a special video?

Just tell me if interested.


/EDIT: A second attempt....more accurate
5 minute timerun...

vapoursynth 9560 frames
avisynth64 9575 frames
this time I didn´t see any drop down in frames after 2-3%.
Very close...

[LoRd_MuldeR]

Hey mulder,

just tried vapursynth and have to say that it is nice to have an alternative but avisynth(64) seems a bit faster.
3-5% more speed with avisynth and my settings (medium, ABR, 5Mbit for FullHD content from TV)
I think I saw that after about 2% it looses some power....it gets slower.

But this is just my first impression.
What´s your opinion on this?

Want to compare results?
Want me to use some special settings?
Want to use a special video?

Just tell me if interested.


/EDIT: A second attempt....more accurate
5 minute timerun...

vapoursynth 9560 frames
avisynth64 9575 frames
this time I didn´t see any drop down in frames after 2-3%.
Very close...

Thanks for sharing your results.

Haven't done any extensive VapourSynth vs. Avisynth performance tests myself yet. But I guess for a simpple script where pretty much all time is spent for decoding the source, it is expected that you don't see much of a performance difference. More complex script with a lot of filtering might reveal the more differences. In theory, VapourSynth should have some advantage, due to the better multi-threading support. On the other hand, this probably depends a lot on how much the individual filters (can) make use of that.

Any details are best discussed in the VapurSynth thread...

[Evil_Burrito]

--opencl --opencl-clbin NUL
Ok, I will try it. Thanks for the input.
Your suggestion is working, no more error.

[STJAM]

Locate your shortcut.
Right-click the shortcut and click "Properties."
Place your cursor to the right of the "Target" box, next to the quotes enclosing the path to the application.
Click "Space" and then enter your command-line switch, such as "C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\x264_launcher.exe" --skip-vapoursynth-check

[LoRd_MuldeR]

Locate your shortcut.
Right-click the shortcut and click "Properties."
Place your cursor to the right of the "Target" box, next to the quotes enclosing the path to the application.
Click "Space" and then enter your command-line switch, such as "C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\x264_launcher.exe" --skip-vapoursynth-check

It has to be added, that this should only be used as the last resort, e.g. if the program hangs or crashes during the VapourSynth check - which of course is not supposed to happen ;)

(If you don't like to install VapourSynth and you want to skip the warning message, you can simply disable the warning in the preferences dialog now)

[Rodger]

Maybe you split this option into avisynth AND/OR vapoursynth.

[RTW47]

hello, I want to use VapourSynth input;

installed:
1) Python 3.3.2 for Windows x86
2) VapourSynth r19
3) Simple x264 Launcher v2.20.568

despite that, still getting the warning that VapourSynth is missing on my computer. A bug? :confused:

[LoRd_MuldeR]

despite that, still getting the warning that VapourSynth is missing on my computer. A bug? :confused:

Hard to say from here :p

I suggest you run Simple x264 Launcher with "--console" parameter to get some more detailed information. Then we might be able to see what's wrong.

Also: If you use "vspipe.exe" (this is a part of VapurSynth) directly, does it work as expected?

[RTW47]

I suggest you run Simple x264 Launcher with "--console" parameter to get some more detailed information.

vs registry key is missing;
http://imageshack.us/a/img844/8706/d5cv.png

Also: If you use "vspipe.exe" (this is a part of VapurSynth) directly, does it work as expected?"vspipe.exe" works as expected;

[LoRd_MuldeR]

Please use Regedit and check whether this registry key (folder) exists:
SOFTWARE\\Wow6432Node\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\VapourSynth_is1

This is generated by the VS installer and should be there, if VS was installed properly.

There also should be an entry "InstallLocation" in this key, containing the correct VS install path...

[RTW47]

VapourSynth_is1 registry key is in a different location:
SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\VapourSynth_is1 (this is not inside Wow6432Node folder)
there are no registry keys containing VS install paths inside Wow6432Node folder.[link (http://imageshack.us/a/img708/7120/92sl.png)]

[LoRd_MuldeR]

RTW47, do you use 32-Bit or 64-Bit Windows?

After thinking about this a bit more, I believe my code works for 64-Bit Windows only, but may fail on 32-Bit Windows - because of the Registry Redirection on 64-Bit Windows.

This should be easy to fix though. Will upload a new version tonight...

[RTW47]

I use 32-bit Windows. And thank you so much for helping me!

[CarlPig]

#L_M

Please check the new x264 build 2358 with your GUI.

Because it does not work properly.

It convert, but the log is blank, and it only says "Starting up, please wait..."

[LoRd_MuldeR]

I use 32-bit Windows. And thank you so much for helping me!

Should be fixed now. Thanks for reporting that issue.

#L_M

Please check the new x264 build 2358 with your GUI.

Because it does not work properly.

It convert, but the log is blank, and it only says "Starting up, please wait..."

Cannot confirm. I just updated my x264 binaries to r2358 (the Komisar's build, as always) and it works flawlessly for me.

Probably some build issue. Which build did you try?

[LoRd_MuldeR]

Update:

Okay, at first I tried only Avisynth and VapourSynth input and that worked fine. But it seems FFMS2 input is broken with the latest builds.

Try running a command-line like this from the console:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x64\x264_8bit_x64.exe" --crf 20.0 --preset medium --output C:\Temp\Out.mkv
--index C:\Users\MuldeR\AppData\Local\Temp\{f09c5198-585b-4ff2-ba65-8319632307ce}.ffindex E:\Samples\Lossless\crew.704x576.avi

It will deadlock x264 with no output at all, but with 100% CPU load (on a single core). So definitely not a GUI issue. I suspect something is wrong in the new Unicode support code.

[CarlPig]

DGIndexNV seems to have the same problem as FFMS2

[LoRd_MuldeR]

Looks like a fix for the FFMS2 index bug in x264 r2358 is on the way now:
http://forum.doom9.org/showpost.php?p=1641859&postcount=1984

This clearly is related to FFMS2 input, so I don't see have this should be related to DGIndexNV. DGIndexNV is an Avisynth filter and Avisynth input works just fine for me with latest x264...

[LoRd_MuldeR]

Looks like a fix for the FFMS2 index bug in x264 r2358 is on the way now:
http://forum.doom9.org/showpost.php?p=1641859&postcount=1984

This clearly is related to FFMS2 input, so I don't see have this should be related to DGIndexNV. DGIndexNV is an Avisynth filter and Avisynth input works just fine for me with latest x264...

I have uploaded a new release that contains a fixed (http://komisar.gin.by/x.patch/check_idx_file.diff) build of x264 r2358, which should resolve the deadlocking issue with FFMS2 input. There are no other changes.

[Dion]

This build is not letting me use old x264 builds again. :(

[LoRd_MuldeR]

The minimum supported revision is r2350 at this time. Why would you want to use a version that is older than the current "stable" branch of x264?

(If there's some regression in the new version, like the recent deadlock issue, it should be reported and fixed)

[Dion]

The minimum supported revision is r2350 at this time. Why would you want to use a version that is older than the current "stable" branch of x264?

(If there's some regression in the new version, like the recent deadlock issue, it should be reported and fixed)

I use a custom x264. And it is on 2348.. Far from outdated. And newer builds aren't always the most stable. Just annoying having to re-install an old build :/ Guess i will wait.

[LoRd_MuldeR]

The version check exists for several reasons. First of all, the GUI requires a compatible version of x264. As soon as either the text output of x264 or the command-line switches change, the GUI needs to be adapted for those changes. And since I don't feel like bloating my code with a zillion of "backward compatibility" branches (just for retaining compatibility to ancient versions), this will often break compatibility to older versions. Of course I could try to determine the oldest possible revision of x264 that currently works with the GUI and use that revision as the minimum. However, I don't think this is worth the effort. Furthermore, the version check also exists to encourage people to use an up-to-date version of x264. As any software developers knows from experience, customers tend to be extremely lazy about updates and often would complain about bugs that have been fixed months or sometimes years ago! So we want to provide a little incentive ;)

Finally, I usually do not set the minimum supported revision to the latest version (which would be the "master" header), but to the latest stable revision of x264 (from the "stable" header).

I understand that some people may which to use "custom" builds. But, if you build x264 yourself with custom patches, you should also be able to build an up-to-date x264. Either that, or you build the Simple x264 Launcher yourself - with any modifications you may need. Remember that this is OpenSource software released under the GPL, giving you the freedom to adapt it to your needs! And in case you don't know how to build software from the sources, I have to assume that you are using somebody else's "custom" x264 build. In that case you should ask yourself: If that specific custom build apparently isn't updated/maintained any longer, are those patches still relevant nowadays?

[VideoFanatic]

I'm converting MPEG2 720 x 480i files to h264 with your program. I've been using it a long time but more and more lately I've been getting a problem where the video encodes at around 10-11FPS instead of 13-14FPS. It seems to happen at random. For example a video encodes at around 13 FPS then the next video in the queue with the same script encodes at 10FPS or slower for no apparent reason. If I cancel the encoding then wait 5 minutes and try again it then it usually encodes at the correct speed. However that doesn't seem to be working anymore. I notice as well that when encoding at those slow speeds they will frequently fail with an error which I would rarely get if it encoded at the correct speed.

Sometimes I can get it to encode at the correct speed again simply be restarting my PC. Or I could install a different motherboard firmware then go back to the one I was on and it will encode at the correct speed!

I thought it was DGIndex that may have been the problem however I made a lossless AVI and then re-encoded that to h264 with your program (the AVI doesn't need a project file created for it) and that too was encoding slowly. So it seems like your program may be causing the problem.

I'm using the same Avisynth scripts that I've been using for ages. I'm using the 2.22.576 version of your program. I see a vapoursynth missing message when I load your program. Do I actually need to install that?

[LoRd_MuldeR]

First of all, the GUI front-end (e.g. Simple x264 Launcher) does not have any impact on encoding speed. The actual work is happening in the x264 process, so that's the place where 99.9% of the CPU cycles are spent. When using Avisynth input, the Avs2YUV process may use a considerable amount of CPU cycles too. But in any case, the CPU cycles used by the GUI process should be negligible! Whatever "effect" you are experiencing here, it probably is not related to Simple x264 Launcher.

Secondly, if you see "slow" encoding speeds when starting a new encode right after a previous encode has finished, while encoding speeds are back to "normal" if you wait a few minutes before starting the encode, then this sounds very much like CPU overheating! During the previous encode, the CPU probably reached its thermal limit and thus reduced the clock speed in order to avoid damage. Then, if you start the next encode immediately, you will see slower encoding speed due to the lower clock speed - not much of surprise. But if you wait a few minutes before starting the new encode, the CPU has enough time to cool down, so it will be able to encode at "full" clock speed again - for a limited period of time. Also note that, when GPU-based Avisynth filters are involved or when "--opencl" is being used, the same thing may happen with your GPU, not only with the CPU.

Finally, as I told you before, the FPS value displayed by x264 is not the "current" encoding speed, but an average for the entire encode. So, if your encode was running "slow" (for whatever reason) for a certain amount of time and then goes back to "full speed" again, you will not see the FPS jump to a higher value all of a sudden! Instead, since it is an average, it will go up very slowly. And it never reachs the value that you would have gotten when encoding with "full speed" all the time.

(BTW: If you don't want to use VapourSynth input, then you don't need to install VapourSynth, of course. You can disable the notification about VapourSynth in the preferences)

[ChiDragon]

Dumb question: is there any capacity to re-queue a cancelled job?

[LoRd_MuldeR]

Dumb question: is there any capacity to re-queue a cancelled job?

Not quite sure what you mean :confused:

But you can restart a job that was cancelled or that has failed. It will then be enqueued, just like any new job.

[ChiDragon]

For me, clicking on Restart involves several unexpected behaviours:

I'm presented with the Add Job dialog
After clicking on Add Job, my "restarted" job is appended to the end of the list with an incremented number rather than replacing the aborted attempt
The job starts immediately rather than being queued to wait for any currently running job, in spite of having it set to only 1 at a time


The one that's actually bothersome is the third, of course.

[LoRd_MuldeR]

For me, clicking on Restart involves several unexpected behaviours:
I'm presented with the Add Job dialog

So you can edit the job settings before giving it another try.

(If the job was aborted by the user or it failed, that's most likely because something was configured wrong, which the user may which to fix)

After clicking on Add Job, my "restarted" job is appended to the end of the list with an incremented number rather than replacing the aborted attempt

It is appended as a new job, because it is a new job. The old job has failed (or was aborted). Think of it as adding a new job, which inherits the settings of the old one.

The job starts immediately rather than being queued to wait for any currently running job, in spite of having it set to only 1 at a time

If you select the "Start Job Immediately" option, then yes. Otherwise not (I hope).

[ChiDragon]

I didn't explicitly select it, but no doubt that is what caused it to run right away. Thanks.

[LoRd_MuldeR]

I didn't explicitly select it, but no doubt that is what caused it to run right away. Thanks.

The "Start Job Immediately" box should be checked initially, if (and only if) the number of running jobs is less than the limit - at the moment when the dialog pops up.

[ChiDragon]

Just tested that. 1 job aborted, 1 job running, 1 job enqueued. When I hit Add New Job the dialog box has no checkmark. When I hit Restart Job the dialog box has a checkmark.

[LoRd_MuldeR]

Just tested that. 1 job aborted, 1 job running, 1 job enqueued. When I hit Add New Job the dialog box has no checkmark. When I hit Restart Job the dialog box has a checkmark.

I just checked the code again. And indeed, the "Start Job Immediately" checkbox is always checked when the dialog is created after "Restar Jobt" was selected. Can't remember now why I made it that way. But I think I will make it behave just like the "Add New Job" button with the next release ;)

[VideoFanatic]

First of all, the GUI front-end (e.g. Simple x264 Launcher) does not have any impact on encoding speed. The actual work is happening in the x264 process, so that's the place where 99.9% of the CPU cycles are spent. When using Avisynth input, the Avs2YUV process may use a considerable amount of CPU cycles too. But in any case, the CPU cycles used by the GUI process should be negligible! Whatever "effect" you are experiencing here, it probably is not related to Simple x264 Launcher.

Secondly, if you see "slow" encoding speeds when starting a new encode right after a previous encode has finished, while encoding speeds are back to "normal" if you wait a few minutes before starting the encode, then this sounds very much like CPU overheating! During the previous encode, the CPU probably reached its thermal limit and thus reduced the clock speed in order to avoid damage. Then, if you start the next encode immediately, you will see slower encoding speed due to the lower clock speed - not much of surprise. But if you wait a few minutes before starting the new encode, the CPU has enough time to cool down, so it will be able to encode at "full" clock speed again - for a limited period of time. Also note that, when GPU-based Avisynth filters are involved or when "--opencl" is being used, the same thing may happen with your GPU, not only with the CPU.

Thanks for your help. I know it's not the GUI that's the problem but I don't know who else to contact and thought you might know what the problem is.

I have a Core i7 2700K overclocked to 4.4Ghz. The max temp I'm reaching is 70c but most of the time the temp is around 65c. I asked Intel was the max safe temp is and they said 72c. So the CPU should not be going slower due to overheating. Also it worked fine in the past. I was getting over 13FPS but now I'm getting around 10.7 FPS - 12 FPS. I don't know why it's encoding slower. Even while I'm in bed when it's cold during the night and the temps are lower - it's still encoding slowly.

[Darksoul71]

The most straightforward approach for me would be lowering the clock so that you CPU runs within the standard clock speed. Then you should check both the encoding speed you get and the temperature you have. Also you could monitor your CPU clock if it changes when you overclock and the CPU gets warmer. I do not know how to do it in Windows but under Linux I usually can monitor my CPU clock via "cat /proc/cpuinfo"

[VideoFanatic]

I tried lowering the overclock but as you would expect it lowered the speed of the encodings. At the highest overclock I can get of 4.4Ghz the max temp is 70c which is within the max safe temp of 72c.

[Darksoul71]

Well, then thermal throttling because of overclocking might not be the reason for your recent drop in conversion speed. You are pretty vague about your previous encoding speed (above 13 FPS). Personally I would not waste my time investing things unless you get a serious drop (e.g. 20 FPS down to 10 FPS).

Also x264 offers a large variety of settings to fine-tune both encoding speed and quality (e.g. presets). If you want to squeeze out some more FPS this is where I would look for.

YMMV,
D$

[VideoFanatic]

OK thanks. It's just frustrating that I don't know why it's encoding slower. A couple of FPS slower might not seem a lot to you but that's 45 minutes extra time it takes to encode. When I'm encoding several videos per day, 24 hours a day that adds up to a lot of time wasted! I've already determined in the past that the Very Fast preset is the best preset for me to use so there's nothing else I can do there.

[Darksoul71]

24hrs a day ? Holy Moly...what do you do ? Transcode something like 2000 movies ?
If I am in a hurry I typically sometimes use the preset faster in CRF mode which gives me about 50-60 FPS in 1080p. Although I can not tell a big difference here, I usually use slow as default preset for BD backups which translates to something like 3-4 BDs each night.