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

[LoRd_MuldeR]

I don't really use VirtualDub. Do I just drag the script into VirtualDub then click on the play button?

Yes.

So if there's an error will VirtualDub give a popup showing what plugin is at fault?

If Avisynth reports an error, you will get a message box showing that error. And if Avisynth (or one of the plug-in's involved) crashes, you will see a crash dialog (stack trace).

In case of a crash, it is not easy to figure out what exactly caused it, because the problem may be the result of a specific plug-in combination and/or a specific Avisynth version/variant.

(Especially the "MT" and "x64" forks of Avisynth are anything but rock stable)

[BlockABoots]

Is there a selection of Template profiles i could download anywhere? For 1080p Youtube use mainly

[LoRd_MuldeR]

Is there a selection of Template profiles i could download anywhere? For 1080p Youtube use mainly

Nope. And that's because you don't have to ;)

Generally you would simply pick the slowest possible Preset you can afford (speed-wise) and then choose the highest possible CRF you can accept (quality-wise).

You can then save your personal choice as a Template, for convenience.

As for Youtube: They are going to re-encode your clip anyway, so all you can do is provide a "decent" quality source and hope that they won't mess it up too bad.

It's not worth to worry about the details, because their re-encoding is going to hurt the quality anyway...

(The only thing for which I think pre-defined "Templates" could be useful is BluRay encoding, because that requires not-so-trivial combination of parameters)

[r0lZ]

(The only thing for which I think pre-defined "Templates" could be useful is BluRay encoding, because that requires not-so-trivial combination of parameters)Interesting BTW. Do you know exactly what options must be used? I've read somewhere that they have to be this:
--bluray-compat --profile high --level 4.1 --vbv-maxrate 40000 --vbv-bufsize 30000 --keyint 24 --slices 4
--open-gop --colorprim bt709 --transfer bt709 --colormatrix bt709 --b-pyramid strict --fake-interlaced --aud
Is it correct? Is --fake-interlaced really necessary? And why is it not sufficient to specify --bluray-compat to force all options as they must be?

[LoRd_MuldeR]

"Fake Interlaced" is needed where you want N fps progressive (because you have a progressive source at N fps), but the BluRay standard only allows for N fps interlaced (i.e. 2xN fields/second) - not N fps progressive. x264 will then create an "interlaced" stream (to make BluRay happy), but simply code all blocks as "progressive". That's possible because even in "interlaced mode" H.264 still allows to select between interlaced/progressive for each block (MBAFF). And about the "--bluray-compat" option: It is required but not sufficient to get 100% BluRay compatibility. I guess that's because there are some things that are always needed for BluRay compat and other things that need to be adjusted.

For details see:
http://www.x264bluray.com/

[r0lZ]

Many thanks for your reply. But "Authoring a professional Blu-ray Disc with x264" page doesn't have much information. It specifies only that --fps 24000/1001 --force-cfr must be used if the source has not the correct frame rate. Nothing else. I suppose I'll have to search for "blu-ray" in http://mewiki.project357.com/wiki/X264_Settings

[EDIT] Oops, found how to use the site. The information is in other pages. Thanks again!

[LoRd_MuldeR]

It has very detailed info. Just choose your type of source from the left-side menu ;)

[r0lZ]

Yes, I figured it. I have updated my previous post, but you haven't seen the edit. Anyway, it's perfect. Thanks again.

[VideoFanatic]

I'm fixing VHS-to-DVD conversions with Avisynth. I've found that CRF 17 gives the lowest file size and I've been encoding videos for ages without problems - if I use a higher setting then I can see artefacts.

The problem is that I've got some videos that have a darkness problem that I need to fix with this Avisynth code:
ColorYUV(gamma_y=200, off_y=-32)

But when I encode a video the bitrate is double than what it would be if I didn't use that code. These are just colour corrections so I don't understand why this happens?

[LoRd_MuldeR]

I'm fixing VHS-to-DVD conversions with Avisynth. I've found that CRF 17 gives the lowest file size and I've been encoding videos for ages without problems - if I use a higher setting then I can see artefacts.

The problem is that I've got some videos that have a darkness problem that I need to fix with this Avisynth code:
ColorYUV(gamma_y=200, off_y=-32)

But when I encode a video the bitrate is double than what it would be if I didn't use that code. These are just colour corrections so I don't understand why this happens?

Don't know what your script does exactly to perform the "color correction", but if, for example, it adds any dithering (noise) during the process it should be obvious why the file will be "harder" to compress afterwards and thus needs more bits (at the same CRF).

[r0lZ]

I have a frame rate problem with some versions of x264. The versions included with your launcher work perfectly, but some versions downloaded from x264.nl are not so good. The problem, when the .nl version is used, is that MkvMerge cannot find the frame rate in the h264 stream, and it assumes 25p. When you mux such a x264 file manually with MkvMerge GUI (mmg.exe), it issues a warning that explains that the frame rate must be specified, but I want to automate the encoding and muxing and mkvmerge.exe (CLI) doesn't issue that warning. When the same video is encoded with Simple x264 launcher (or with the exes in your toolbox), there is no warning, and the correct frame rate is used.

Is it a fix included only in some builds, or starting with a specific version number? Where do you download the versions included in your toolbox? Is it possible to test if the user of a GUI uses a version that sets correctly the frame rate in the video stream?

Sorry to ask this question here, as your tool works perfectly, but I think you know certainly what's the origin of that problem, and how to avoid it.

[LoRd_MuldeR]

I have a frame rate problem with some versions of x264. The versions included with your launcher work perfectly, but some versions downloaded from x264.nl are not so good. The problem, when the .nl version is used, is that MkvMerge cannot find the frame rate in the h264 stream, and it assumes 25p. When you mux such a x264 file manually with MkvMerge GUI (mmg.exe), it issues a warning that explains that the frame rate must be specified, but I want to automate the encoding and muxing and mkvmerge.exe (CLI) doesn't issue that warning. When the same video is encoded with Simple x264 launcher (or with the exes in your toolbox), there is no warning, and the correct frame rate is used.

Is it a fix included only in some builds, or starting with a specific version number? Where do you download the versions included in your toolbox? Is it possible to test if the user of a GUI uses a version that sets correctly the frame rate in the video stream?

Sorry to ask this question here, as your tool works perfectly, but I think you know certainly what's the origin of that problem, and how to avoid it.

As long as you output the stream as MKV file, there should be FPS information included. Storing as a "raw" H.264 stream may not have FPS information included, so then MkvMergeGUI will default to 25 fps. I don't think there should be any differences between x264 builds, as the MKV muxer is a part of x264 code, not from an external library (like GPAC is needed for MP4 muxing). I just include Komisar's builds.

[r0lZ]

Hum, strange. There IS a difference when I encode with the 64bit 8bit-depth version downloaded from x264.nl, and with your x264_8bit_x64.exe. I don't have to specify the frame rate when muxing (with mkvmerge.exe) the files encoded with your version, but I must specify it if I encode with the .nl version (except if the frame rate is 25fps of course). So, there must be a difference.

Your version:

x264 0.128.2216 198a7ea
(libswscale 2.1.101)
(libavformat 54.25.105)
(ffmpegsource 2.17.2.1)
built by Komisar on Sep 6 2012, gcc: 4.7.1 (multilib.generic.Komisar)
configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

Result when encoding and muxing a small test NTSC movie: 29.97 fps

The .nl version:

x264 0.130.2273 b3065e6
(libswscale 2.1.1)
(libavformat 54.21.2)
(ffmpegsource 2.17.3.0)
built on Feb 27 2013, gcc: 4.7.2
configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: LGPL version 2.1 or later

Result when encoding and muxing the same NTSC movie: 25 fps

Of course, I've used the same encoding and muxing parametres in both cases.

As long as you output the stream as MKV file, there should be FPS information included.
I agree. But it seems that mkvmerge can find the correct frame rate in one case, and it defaults to 25fps in the other case. Why? I'm puzzled.

[LoRd_MuldeR]

Well, you are comparing x264 r2216 to x264 r2273. You should compare the same revisions to be sure. Also I have updated "my" package to x264 r2273 (again Komisar build) too.

(Furthermore, adding "--force-cfr" might help, but I'm not sure)

[r0lZ]

--force-cfr is in my settings.

I'll do other tests later, but it seems that it's not related to the version number. (Or should I consider that the newer version did a regression?) I'll post here if I can understand the problem.

Anyway, thanks for your help.

[LoRd_MuldeR]

--force-cfr is in my settings.

I'll do other tests later, but it seems that it's not related to the version number. (Or should I consider that the newer version did a regression?) I'll post here if I can understand the problem.

Anyway, thanks for your help.

As long as you are comparing two different versions, we cannot know whether this has something to do with changes in x264 or with the different builds, but I'd say the former is more likely...

[r0lZ]

OK, I did comparisons with the latest versions. Still same problem.

Komisar version (distributed with your launcher):

x264 0.130.2273 b3065e6
(libswscale 2.2.100)
(libavformat 54.63.100)
(ffmpegsource 2.17.3.0)
built by Komisar on Feb 27 2013, gcc: 4.7.2 (multilib.generic.Komisar)
configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

Command: "x264_8bit_x64.exe" --force-cfr --no-interlaced --sar 32/27 --crf 23 --preset medium --threads 3 --qpfile qpfile.txt --index VideoFile.ffindex --output VideoFile.264 VideoFile.m2v

ffms [info]: indexing input file...
ffms [info]: 720x480p 32:27 @ 3434/143 fps (cfr)
x264 [info]: using SAR=32/27
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
x264 [info]: profile High, level 3.0
x264 [info]: encoding...
x264 [info]: frame I:101 Avg QP:22.06 size: 23023
x264 [info]: frame P:2344 Avg QP:24.75 size: 6615
x264 [info]: frame B:2291 Avg QP:27.08 size: 1654
x264 [info]: consecutive B-frames: 16.3% 51.1% 19.5% 13.1%
x264 [info]: mb I I16..4: 13.5% 68.8% 17.6%
x264 [info]: mb P I16..4: 2.1% 7.7% 0.9% P16..4: 42.6% 17.6% 9.2% 0.0% 0.0% skip:19.9%
x264 [info]: mb B I16..4: 0.1% 0.6% 0.1% B16..8: 36.2% 3.7% 0.8% direct: 2.2% skip:56.4% L0:36.1% L1:56.8% BI: 7.1%
x264 [info]: 8x8 transform intra:71.0% inter:70.7%
x264 [info]: coded y,uvDC,uvAC intra: 69.9% 72.4% 39.2% inter: 22.2% 23.3% 2.0%
x264 [info]: i16 v,h,dc,p: 42% 26% 5% 27%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 12% 16% 7% 9% 11% 8% 10% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 21% 12% 6% 9% 9% 8% 7% 6%
x264 [info]: i8c dc,h,v,p: 55% 18% 19% 8%
x264 [info]: Weighted P-Frames: Y:19.4% UV:8.2%
x264 [info]: ref P L0: 60.1% 18.8% 14.4% 5.7% 1.0%
x264 [info]: ref B L0: 84.4% 14.5% 1.1%
x264 [info]: ref B L1: 96.6% 3.4%
x264 [info]: kb/s:877.10
encoded 4736 frames, 57.14 fps, 877.10 kb/s

The frame rate 3434/143 (24.014 fps) is strange, but apparently correct. At least, there is no perceptible A/V sync problem.

The version downloaded from x264.nl:

x264 0.130.2273 b3065e6
(libswscale 2.1.1)
(libavformat 54.21.2)
(ffmpegsource 2.17.3.0)
built on Feb 27 2013, gcc: 4.7.2
configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: LGPL version 2.1 or later

Command: "x264(NL).exe" --force-cfr --no-interlaced --sar 32/27 --crf 23 --preset medium --threads 3 --qpfile qpfile.txt --index VideoFile.ffindex --output VideoFile.264 VideoFile.m2v

ffms [info]: indexing input file...
ffms [info]: 720x480p 32:27 @ 25/1 fps (cfr)
x264 [info]: using SAR=32/27
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
x264 [info]: profile High, level 3.0
x264 [info]: encoding...
x264 [info]: frame I:101 Avg QP:22.20 size: 22586
x264 [info]: frame P:2344 Avg QP:24.91 size: 6446
x264 [info]: frame B:2291 Avg QP:27.23 size: 1605
x264 [info]: consecutive B-frames: 16.3% 51.1% 19.5% 13.1%
x264 [info]: mb I I16..4: 13.9% 68.6% 17.5%
x264 [info]: mb P I16..4: 2.2% 7.6% 0.9% P16..4: 42.7% 17.2% 9.1% 0.0% 0.0% skip:20.4%
x264 [info]: mb B I16..4: 0.1% 0.6% 0.1% B16..8: 36.0% 3.7% 0.7% direct: 2.1% skip:56.8% L0:36.1% L1:57.0% BI: 6.9%
x264 [info]: 8x8 transform intra:70.7% inter:71.0%
x264 [info]: coded y,uvDC,uvAC intra: 69.3% 71.6% 38.2% inter: 21.7% 22.7% 1.9%
x264 [info]: i16 v,h,dc,p: 42% 26% 5% 27%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 12% 16% 7% 9% 11% 8% 10% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 21% 12% 6% 9% 9% 8% 7% 6%
x264 [info]: i8c dc,h,v,p: 55% 18% 19% 8%
x264 [info]: Weighted P-Frames: Y:19.4% UV:8.2%
x264 [info]: ref P L0: 60.2% 18.9% 14.3% 5.7% 1.0%
x264 [info]: ref B L0: 84.6% 14.3% 1.1%
x264 [info]: ref B L1: 96.6% 3.4%
x264 [info]: kb/s:889.68
encoded 4736 frames, 56.00 fps, 889.68 kb/s

Obviously, the ffms info is not correct. With that version, the frame rate is ALWAYS 25fps, regardless of the source (at least when the source is a MPEG stream extracted from a DVD).
I suppose the bug is caused by libavformat v54.21.2, as the version of ffmpegsource is identical in both builds.

I haven't tested the 32-bit exes, and the 10-bit depth exes, but I suppose they have the same bug.

Anyway, the Komisar version is the one to keep. (It gives also a slightly better compression with identical parameters, and it is slightly faster.) Keep that version for your launcher!

Can you confirm that your versions are the KMod builds from this page (http://komisar.gin.by/)? [EDIT] I don't need a reply for that question. They are the "clear" builds.

[r0lZ]

OK, I've downloaded and tested all versions from Komisar's page, and none of them have the frame rate bug.

I've also noticed that the KMod builds have a different output for the progress lines, and I guess they are not compatible with your launcher, for that reason. (I had to modify my PgcEdit plugin to support them.)

I'll stick with the Komisar clear builds for now, as I know that they work well.

Thanks again for your inputs.

[EDIT] Tested also all versions from http://x264.nl/, and all of them have the frame rate bug. So, it seems that it's not a problem with the x32/x64 or 8/10-bit depth versions, but a problem with the libraries used by the author of that builds. (I don't know who he is and how to contact him.)

[LoRd_MuldeR]

Okay, so from your go log we can see that it's actually the FFMS2 (FFmpegSource2) detecting different frame rates for your original input to x264!

That's probably the result of different versions of the FFMS2/Libav libraries being used in those builds.

Looks like they both use the same FFMS version (2.17.3.0), but the Komisar build was made using as lightly never Libav version (54.63.100 -vs- 54.21.2).

[r0lZ]

Yes, that was my conclusion too. The x264 code itself is not the culprit. But it is a fact that it's a very big difference, although both versions have the same build number.
Anyway, you can't help. Sorry for having polluted your thread!

[LoRd_MuldeR]

Yes, that was my conclusion too. The x264 code itself is not the culprit. But it is a fact that it's a very big difference, although both versions have the same build number.
Anyway, you can't help. Sorry for having polluted your thread!

While these builds were mode form the very same version (revision number) of x264, they include different versions of the (optional) third-party extra libraries...

[JEEB]

Looks like they both use the same FFMS version (2.17.3.0), but the Komisar build was made using as lightly never Libav version (54.63.100 -vs- 54.21.2).
Other than the fact that the ffms2 version actually tells rather little (as it gets so rarely updated at times), there is one rather big difference here. And both library versions were most probably built from the HEAD of their repositories at the point of compilation.

Basically, the .100 at the end of the version is a sign that the project this library came from is ffmpeg, while a version number that doesn't have that is from libav. So one is not older than the other, but those two projects have completely different versioning schemes.

[r0lZ]

Thanks for the precision. Anyway, I have learned one important thing. You cannot trust the frame rate when the h264 stream has been encoded with some x264 builds. Detecting what builds or library versions can be trusted seems not easy, but I don't need that. I have added a test to be sure that the version used with my plugin uses the correct frame rate, and that should be sufficient to avoid the problem with MkvMerge. The test consists in encoding a very small black NTSC video and detecting if ffms2 reports the wrong 25fps frame rate. If it is sufficient to check the .100 to be sure that it's a "good" version, I'll remove that test later, as it's easier and quicker to test. But I have to verify that too. Thanks JEEB for the pointer.

I have also tried to contact the author of the x264.nl builds, but he seems to have disappeared! Someone knows who he is, and how to contact him?

[LoRd_MuldeR]

I have also tried to contact the author of the x264.nl builds, but he seems to have disappeared! Someone knows who he is, and how to contact him?

Should be bob0r (http://forum.doom9.org/member.php?u=14812). And, as far as I know, the builds hosted there are those made by JEEB...

[r0lZ]

Thanks. Yes, it's probably bob0r, but I see on his profile: Last Activity: 6th February 2011 14:01
I've sent him a PM anyway, but I doubt he will reply.

[MonoS]

Yesterday i installed Windows 7 Ultimate 64bit
When i try to launch Simple x264 Launcher the application freeze at startup
Windows give me this information about the problem

Nome evento problema: AppHangB1
Nome applicazione: x264_launcher.exe
Versione applicazione: 2.0.9.408
Timestamp applicazione: 5137c307
Firma di blocco: d0b7
Tipo interruzione: 0
Versione SO: 6.1.7601.2.1.0.256.1
ID impostazioni locali: 1040
Firma blocco aggiuntiva 1: d0b73af4b3ad63005339879e458276fa
Firma blocco aggiuntiva 2: c490
Firma blocco aggiuntiva 3: c49016d5f73eec146d68c2682233ee1c
Firma blocco aggiuntiva 4: d0b7
Firma blocco aggiuntiva 5: d0b73af4b3ad63005339879e458276fa
Firma blocco aggiuntiva 6: c490
Firma blocco aggiuntiva 7: c49016d5f73eec146d68c2682233ee1c


It's mine first time using x64 OS, so i hope it's not mine configuration's fault to cause this error

What could be the problem??

[LoRd_MuldeR]

All my software is developed on Windows 7 (64-Bit), so the OS is not the problem.

Please try running the application with "--console" parameter to get more verbose output and then see at which point it hangs!

My bet would be that it's an Avisynth issue, so maybe you try "--skip-avisynth-check" as well...

[MonoS]

It blocks here

avs_create_script_enviroment_ptr(AVS_INTERFACE_25)


I imagined that was a avisynth problem so i tried to reinstall it [avisynth 2.5.8 x86 ST official build], but even not worked

Using --skip-avisynth-check the program start, but when i try to start a job but it blocks creating avisynth process

I'm sorry for have posted such a question here, but I thought that wasn't an avisynth problem

I'll try to find a solution, thanks for help LoRd_MulderR

[LoRd_MuldeR]

First thing to try: Uninstall whatever Avisynth you have installed and then install the latest stable release of Avisynth (v2.5.8):
http://sourceforge.net/projects/avisynth2/files/AviSynth%202.5/AviSynth%202.5.8/

(Please do not use the "x64" or the "MT" forks of Avisynth for now, as they are known to be anything but stable)

Second thing to try: Remove everything from your Avisynth plug-in's directory. Load individual plug-in's explicitly from your script, if you need to.

[MonoS]

Uninstalled and renamed plugins directory, now it works

Thanks again for the help LoRd

[LoRd_MuldeR]

I have moved the Avisynth initialization code into separate thread, so if Avisynth should deadlock for whatever reason it now won't hang the whole app ;)

[superhil]

it's very awesome and simple tools
dear LoRd_MuldeR, any plan to add batch support?

i mean, if i had 100 files in a folder, i can simply open folder
and then the launcher will process it automatically with same configuration
rather than open file one by one

it's the same feature as "open folder" in MeGUI one click interface

thank you :-)

[LoRd_MuldeR]

Hello.

Well, there already is batch support. It's just not yet possible to add a large number files at once with the same settings.

I will look into that...

[LoRd_MuldeR]

I have uploaded a new build.

(Please note the remarks about OpenCL support in the Readme file!)

[superhil]

Hello.

Well, there already is batch support. It's just not yet possible to add a large number files at once with the same settings.

I will look into that...

I'm sorry,,so the correct name is "add folder" feature ;)
BTW, thank you for new update

[VideoFanatic]

If I don't have a deblocker Avisynth script, will Simple x264 Launcher do any deblocking if my source is MPEG2 or h264?

[LoRd_MuldeR]

Nope, it doesn't apply any "post processing" filters. Especially not out of its own violation ;)

Remember that Simple x264 Launcher is just a GUI for x264, so anything that doesn't happen either in your input script (if using Avisynth input) or in x264 itself, doesn't happen at all. Therse is no secret "magic" going on behind the screnes.

I would suggest you use DGIndex/DGDecode in your Avisynth script to load the MPEG-2 source. It provides various deblock options:
http://neuron2.net/dgmpgdec/DGDecodeManual.html#MPEG2Source

(Also note that the "In-Loop Deblocking" feature of H.264 does NOT deblock your input, it only tries to prevent blocking artifacts introduced by the H.264 encoding. Thus, the "--filter" option of x264 will not help with blocks in the source)

[bjoker]

Thank you Mulder for your great tools and all the help being provided by you.

I just wanted to try your "Simple X264" as an alternative to handbrake. But am not able to open DVD folder/VOB file directly.

My requirements:

1. ability to create an MP4 (x264) from a DVD folder (I have decrypted DVD folders on my HDD)

2. ability to set custom bitrates of both audio and video. (I tried ripbot but it doesn't offer custom bit-rate)

3. 2-pass encoding a must.

4. Option to add thrid-party encoders like NeroAAC (So I don't need use it separately and remux it with video file again)

5. Ability to preserve same resolution of source (DVDFab fails here)

6. ability to see output MP4 file size (optional)

Could you please suggest me if I should go with your "Simple x264" (if yes, please guide me towards some kind of documentation to start with) OR any other?

TIA

[superhil]

Thank you Mulder for your great tools and all the help being provided by you.

I just wanted to try your "Simple X264" as an alternative to handbrake. But am not able to open DVD folder/VOB file directly.

My requirements:

1. ability to create an MP4 (x264) from a DVD folder (I have decrypted DVD folders on my HDD)

2. ability to set custom bitrates of both audio and video. (I tried ripbot but it doesn't offer custom bit-rate)

3. 2-pass encoding a must.

4. Option to add thrid-party encoders like NeroAAC (So I don't need use it separately and remux it with video file again)

5. Ability to preserve same resolution of source (DVDFab fails here)

6. ability to see output MP4 file size (optional)

Could you please suggest me if I should go with your "Simple x264" (if yes, please guide me towards some kind of documentation to start with) OR any other?

TIA

Then MeGUI will work for you :D

[LoRd_MuldeR]

Could you please suggest me if I should go with your "Simple x264" (if yes, please guide me towards some kind of documentation to start with) OR any other?

Nope. This program is a rather simple GUI for x264, but nothing more. It only does the video encoding and that's it.

It's not an "egg-laying wool-milk-sow" like, e.g. MeGUI, that does pre-processing, video encoding, audio encoding, muxing, etc., all in one. My goal never was to create yet another MeGUI clone.

Doesn't mean all this can not be done with Simple x264 Launcher, but it will definitely require some extra work...

[LoRd_MuldeR]

Here is a small experimental update which improves support for adding multiple jobs/file at once.

[superhil]

thank you for the update :-D
btw, any plan to add resize and crop options as part of GUI?

[LoRd_MuldeR]

any plan to add resize and crop options as part of GUI?

Not currently.

That's mainly because pre-processing filters don't fit well into the existing "configuration" and "template" system (although the filters currently end up there, if you write them into the "custom parameters" box).

It's more a separate thing that should be kept in a separate data structure, I think. But I currently don't have the time to do that properly.

[superhil]

That's mainly because pre-processing filters don't fit well into the existing "configuration" and "template" system (although the filters currently end up there, if you write them into the "custom parameters" box).

I agree with this, it should be separated from template.
How about simply add this (crop and resize) as part of "custom parameters"?
I mean, for example, if resize option is checked, then it will add some parameter into "custom parameter" :D

----
btw, is it possible to make this software automatically delete "file.stats" and "file.stats.mbtree" after the process finished when we use 2-pass mode?
i don't know much about programming, but i think it's not that difficult to add this command. :D

thank you

[LoRd_MuldeR]

I agree with this, it should be separated from template.
How about simply add this (crop and resize) as part of "custom parameters"?
I mean, for example, if resize option is checked, then it will add some parameter into "custom parameter" :D

The "custom parameter" belong to the encoder settings. Something like pre-processing filters, logically, don't fit in there very well.

btw, is it possible to make this software automatically delete "file.stats" and "file.stats.mbtree" after the process finished when we use 2-pass mode?
i don't know much about programming, but i think it's not that difficult to add this command. :D

Sure, this is straight forward to do. But surly most users don't want that, so I would have to make it an option.

Adding that new option to the GUI as well as to the internal data structures and saving/loading it from the INI file is the bigger work...

[VideoFanatic]

I encode several videos each day in Simple x264 Launcher. I get around 13-14 FPS. However I've noticed that if an encoding in the queue starts while I'm doing something CPU intensive like muxing a video (which only takes a couple of minutes) then the encoding may encode at between 6-10 FPS. The problem is that after I finish muxing a video and all the cores are free, the encoding speed does not recover to 13-14 FPS, it just stays at 6-10 FPS. Is there any way you can fix that please?

[detmek]

Using latest stabe build and experimental too gives me an error when I click on Show Help screen for x264 and Avs2YUV.
https://dl.dropboxusercontent.com/u/19804113/Forumi/Slike/Doom9/ScreenShot00180.png
Encoding works fine for normal files. I didn't try AVS script yet.

[LoRd_MuldeR]

I encode several videos each day in Simple x264 Launcher. I get around 13-14 FPS. However I've noticed that if an encoding in the queue starts while I'm doing something CPU intensive like muxing a video (which only takes a couple of minutes) then the encoding may encode at between 6-10 FPS. The problem is that after I finish muxing a video and all the cores are free, the encoding speed does not recover to 13-14 FPS, it just stays at 6-10 FPS. Is there any way you can fix that please?

Not related to Simple x264 Launcher. It's scheduler (http://en.wikipedia.org/wiki/Scheduling_%28computing%29) of the operating system which decides how much CPU time a specific process gets at given moment in time. Should be clear that if you create more processes at the same time, like running a Muxer while you already are running a video encoder, things will become slower, because your CPU doesn't magically duplicate, so all process need to share the available CPU resources.

Finally, if you "slow down" a running encoder process for a certain time, e.g. by running other CPU intensive processes in parallel, of course this will have a permanent effect on its overall (average) throughput. That's because, even if the other processes terminate, the encoder process cannot use more than 100% of the CPU time, so it can never catch up the time it already lost! - as compared to running with 100% CPU time all the way.

(Car analogy: If your car can drive at most 100 km/h, then the maximum average speed you can ever reach would be 100 km/h, i.e. driving 100 km/h all the time. Consequently, if at any point you get slowed down by a traffic jam and thus are forced to drive slower than 100 km/h, this will permanently reduce your average speed, i.e. you will arrive later - regardless of what happens after the traffic jam)

[LoRd_MuldeR]

Using latest stabe build and experimental too gives me an error when I click on Show Help screen for x264 and Avs2YUV.
https://dl.dropboxusercontent.com/u/19804113/Forumi/Slike/Doom9/ScreenShot00180.png
Encoding works fine for normal files. I didn't try AVS script yet.

I see what the problem is. Will be fixed shortly!

[VideoFanatic]

Finally, if you "slow down" a running encoder process for a certain time, e.g. by running other CPU intensive processes in parallel, of course this will have a permanent effect on its overall (average) throughput. That's because, even if the other processes terminate, the encoder process cannot use more than 100% of the CPU time, so it can never catch up the time it already lost! - as compared to running with 100% CPU time all the way.

I know that, what I'm saying is that if an encoding starts at the same time while I'm muxing a video then the FPS encoding speed will drop by up to half from 13FPS to 6.5 FPS. That's normal due to 2 programs using the CPU at the same time. What I'm saying is, is that when the muxing has completed after a couple of minutes and Simple x264 Launcher is the only program using the CPU again, the encoding speed does not go back up to 13 FPS.

[LoRd_MuldeR]

I know that, what I'm saying is that if an encoding starts at the same time while I'm muxing a video then the FPS encoding speed will drop by up to half from 13FPS to 6.5 FPS. That's normal due to 2 programs using the CPU at the same time. What I'm saying is, is that when the muxing has completed after a couple of minutes and Simple x264 Launcher is the only program using the CPU again, the encoding speed does not go back up to 13 FPS.

And I already explained to you why that is ;)

Back to the car analogy: If you start at 12:00 at your home and you know that you would arrive at your destination at 18:00, given that you drive at maximum speed of 100 km/h all the time, but then you get into a traffic jam and need to drive only 50 km/h for a period of 2 hours, can you still arrive at 18:00? No you can't! Even if you drive 100 km/h again for the rest of the way.

Here the car's current speed corresponds to the percentage of CPU time the encoder process gets assigned. And the time of arrival corresponds to the overall encoding time, and thus to the (average) encoder throughput, i.e. the number of frames processed per second. That's because the number of frames is fixed, but the encoding time may vary.

[VideoFanatic]

The car analogy seems to say that if you're due to arrive at 6PM but you get caught in a traffic jam then of course your journey will take longer. I understand that. Obviously the encoding will take longer if I mux a video at the same time as doing the encoding because the CPU power will be shared between them. What I'm saying is that I got 13FPS before I started muxing a video then when I started muxing a video, the encoding speed halved. After the muxing was complete, the encoding speed did not go back to 13FPS even though nothing else was using the CPU. Of course the encoding will take longer due to the time lost, the problem is that the FPS speed stays at half even after the muxing was complete.

If I was to do the same thing with HC Encoder for example, the FPS speed goes back to normal after I've finished muxing a video. Why does that not happen with your program? Could you fix it please.

[LoRd_MuldeR]

You seem to make the assumption that the "FPS" value displayed by x264 is something like an average over the last few seconds only. But it's not! It's simply the number of frames processed so far, divided by the number of seconds that have passed since the encode started. In other words, it's x264's current estimate of the overall average throughput. Thus, it should go up, slightly and slowly, after your other processes have terminated. But it clearly cannot reach the maximum of 13 fps again - just like you said yourself: the journey will take longer... (or in other words: in the end, the FPS will be lower)

1701 int64_t i_time = x264_mdate();
1702 if( i_previous && i_time - i_previous < UPDATE_INTERVAL )
1703 return i_previous;
1704 int64_t i_elapsed = i_time - i_start;
1705 double fps = i_elapsed > 0 ? i_frame * 1000000. / i_elapsed : 0;

You can make the experiment: Suspend the x264 process with Process Explorer (http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx) for a longer time, near the start of the encode. Then resume it. You will then see an FPS value near zero ;)

[LoRd_MuldeR]

Using latest stabe build and experimental too gives me an error when I click on Show Help screen for x264 and Avs2YUV.
https://dl.dropboxusercontent.com/u/19804113/Forumi/Slike/Doom9/ScreenShot00180.png
Encoding works fine for normal files. I didn't try AVS script yet.I see what the problem is. Will be fixed shortly!

Fixed version is available now :)

[detmek]

Thanks. Works just fine.

[LoRd_MuldeR]

Uploaded a new build. OpenCL workaround has been removed, as it is not needed anymore.

[Dion]

Would you be willing to add a priority option for the CPU usage.

High
Above Normal
Normal
Below Normal <--- This is what it currently defaults too.
Low

I would like to run it in low. Without having to manually do it everytime.

[LoRd_MuldeR]

I can add that, if there really is a use-case for this.

[CarlPig]

I will vote for the option.

[LoRd_MuldeR]

Okay, I have added the option to the preferences.

[Chumbo]

Okay, I have added the option to the preferences.
I was about to +1, but I see you caved. ;) Good call. :D

[Dion]

Okay, I have added the option to the preferences.

Thank You.. Great option.. Can confirm its working in low now.

[VideoFanatic]

Is there any way you could please add a sound alert functionality so that when a new item in the queue starts encoding it will play a sound or a popup message?

This would be useful because at the moment I do restoration with Avisynth. I find that if an encoding starts at the same time I try to mux a file or do something else CPU intensive then the encoding speed will drop to up to half the normal speed and when CPU intensive task has finished the encoding speed does not go back to normal. An encoding could be half way finished before I realise it was encoding at half speed.

If I got an audio alert, I could check that the video was encoding at the correct speed. If it wasn't then I could abort it and start it again after I've finished doing my CPU intensive task.

[LoRd_MuldeR]

Is there any way you could please add a sound alert functionality so that when a new item in the queue starts encoding it will play a sound or a popup message?

This would be useful because at the moment I do restoration with Avisynth. I find that if an encoding starts at the same time I try to mux a file or do something else CPU intensive then the encoding speed will drop to up to half the normal speed and when CPU intensive task has finished the encoding speed does not go back to normal. An encoding could be half way finished before I realise it was encoding at half speed.

If I got an audio alert, I could check that the video was encoding at the correct speed. If it wasn't then I could abort it and start it again after I've finished doing my CPU intensive task.

Indeed, I could add that as yet another option, disabled by default - so people don't go mad about those sound effects ;)

[VideoFanatic]

That would be much appreciated, thanks.

[LoRd_MuldeR]

That would be much appreciated, thanks.

(BTW: It seems you are still interpreting the FPS indicator in the wrong way, although we had discussed that before)

[Dion]

This version seems to require the use of the new x264 build. Is there a reason for that?

Simple x264 Launcher v2.17 (2013-07-05)

[LoRd_MuldeR]

The minimum supported version is forced to the latest revision from the "stable" branch. Currently that is:
http://git.videolan.org/?p=x264.git;a=commit;h=585324fee380109acd9986388f857f413a60b896

This is done in order to prevent people from using old/outdated revisions with known bugs. Also the GUI is developed and tested with up-to-date x264. Using some very old build may not work well.

But if you insist in using some outdated build, this requires exactly one line of code to change ;)

[Dion]

Was just more of a general wondering. I use custom x264 builds with your launcher. And they wouldn't work. So I had to grab the latest custom. But yes it would be nice to not have this restriction.

It was only one rev down from the latest too. So it wasn't that out of date.

[LoRd_MuldeR]

Was just more of a general wondering. I use custom x264 builds with your launcher. And they wouldn't work. So I had to grab the latest custom. But yes it would be nice to not have this restriction.

It was only one rev down from the latest too. So it wasn't that out of date.

I have added a CLI option to skip the version check. Use at your own risk :p

[Atombossler]

I have added a CLI option to skip the version check. Use at your own risk :p
Hi Lord Moulder.
I would also like to make some feature requests. :D
1. editable profiles in some kind of mask would be comfortable.
2. adjustable delay after encode finish to proper unload heavy gpu tasks (1-10 sec.), causes possible hickups now time by time.
3. Some sort of network render feature :devil:
But however, nice work till now! :thanks:

[LoRd_MuldeR]

1. editable profiles in some kind of mask would be comfortable.

Profiles are defined by the H.264 standard, so we cannot edit them.

But if you are talking about templates, you can simply load a template by selecting from the "template" combobox, then edit everything as desired and finally save your changes via "Save As" button.

Not sure what else you may need...

2. adjustable delay after encode finish to proper unload heavy gpu tasks (1-10 sec.), causes possible hickups now time by time.

Once the x264 process terminates there is nothing left that would need to time to "unload".

Don't know what you mean with "hickups", but it seems there is something wrong either with your system or your input chain...

3. Some sort of network render feature :devil:

Not supported by x264. Feature that is not supported cannot be exposed in the GUI ;)

(In theory it would be possible to run multiple encoder instances on different machines and finally stitch together the individual pieces. But besides the fact that this is totally not compatible with 2-Pass RC, it's far out of the scope of this application)

[AGKnotUser]

I'm using an AVS script which takes a long time to start up due to it's indexing a large vc1 file. x264 Launcher times out during this indexing. Could you add an option to either defeat or lengthen the timeout period?

Thanks.

[Atombossler]

@AGKnotUser
Just index this file before you use it.

@LoRd_MuldeR
Yes, Templates Is what I meant.
For example how do I change the order of the templates?

The Graphics Card Ram needs time to unload because the before transfered data has to be removed after processing finished.

I know x264 doesn't support a network render feature.
However you can split the job into little chunks via Avisynth and stich it together as you said.
I never made 2-pass RC, so not neccessary.
But I guessed it's out of reach for the little gui. :cool:

[AGKnotUser]

@AGKnotUser
Just index this file before you use it.



Yes I know that. It's what I've been doing. It just would be a little easier if I could let Simple x264 Launcher do it instead.

[LoRd_MuldeR]

Yes, Templates Is what I meant.
For example how do I change the order of the templates?

You can't change the order. The templates appear in alphabetic order.

The Graphics Card Ram needs time to unload because the before transfered data has to be removed after processing finished.

As soon as a process terminates, all of its memory gets released automatically and immediately. That's a core principle of all modern OS.

[Atombossler]

That's true.
And in 95% of times it works well.
But sometimes not and it's recognizable that the RAM still is unloading.
I don't know how reliable those tools are (hwinfo, gpu observer), but it takes 1 or 2 seconds to finish (RAM usage falling).
Well, it should'nt behave like this but it does. :scared:

[LoRd_MuldeR]

Well, as soon as the x264 process terminates, that RAM is "free" by definition. Even if some kind of lazy/delayed clean-up is going on, that RAM still has to be treated as free memory. So if another process tries to allocate that memory, right after the previous process has terminated, it may encounter some delay in the memory allocation, yes. But it must not encounter any "out of memory" issues. If it does, this would indicate some serious flaw in the driver code!

Adding an "artificial" delay doesn't make much sense to me. Whether you encounter the delay during the memory allocation or you encounter an additional delay before process creating doesn't make much of a difference. Except that the "artificial" delay will be encountered always, even when it isn't required at all. For most users adding an artificial delay will only be pointless and annoying. Also we have no idea how long the delay has to be...

[Atombossler]

Annoying if it can't be disabled and unknown delay could be adjustable from 0-5 sec in preferences.
In general this setting is disabled by default so nobody have to be annoyed.
I know that people ask for that feature in other encoding app as well so it's not only me who need that kind of feature.
But feel free to ignore it. :cool:

[LoRd_MuldeR]

Annoying if it can't be disabled and unknown delay could be adjustable from 0-5 sec in preferences.
In general this setting is disabled by default so nobody have to be annoyed.
I know that people ask for that feature in other encoding app as well so it's not only me who need that kind of feature.

Adding new features, even optional ones, adds more complexity to the application. I won't do this, unless there is a compelling reason. Especially when it comes to such "ugly" workarounds.

As explained before, there is no advantage in adding an "artificial" delay before the next process is created. Whether you experience the delay, because the process takes a little longer to allocate the memory or because the process creation is delayed artificially be the GUI, makes no difference. Except that in the latter case we need extra complexity in the GUI code. That plus we might be waiting longer than necessary (or we even might be waiting for nothing).

[LoRd_MuldeR]

Here is a new experimental version with VapourSynth input support:

Note: Requires VapourSynth r19 or later to be installed. Download it here (http://www.vapoursynth.com/).

[aegisofrime]

Hi Lord Mulder! Thanks for what is perhaps the first GUI to support VS :)

I would just like to report that I have this problem where after encoding a certain amount of frames, the launcher reports that x264 is not responding and is in a possible deadlock. My VS script is just a QTGMC of a DVD, nothing too complex. The same QTGMC settings and x264 settings complete successfully when I use x264 directly.

Any ideas on how to resolve this issue? :thanks:

[LoRd_MuldeR]

The timeout interval is already set to 5 minutes. I think if x264 doesn't update the progress at least once within 5 minutes, something is seriously wrong.

Anyway, I don't know how "optimized" QTGMC is in VapourSynth, compared to the Avisynth original. Maybe it's really that slow and thus triggers the timeout. So did you do some benchmarking?

Also, at which phase does it time out? Can you please post your log...

Finally, how can you use x264 "directly" with QTGMC? If you open the source directly in x264 (not via Avisynth or VapourSynth), there will be no QTGMC processing and things will be a lot faster, obviously.

[aegisofrime]

The timeout interval is already set to 5 minutes. I think if x264 doesn't update the progress at least once within 5 minutes, something is seriously wrong.

Anyway, I don't know how "optimized" QTGMC is in VapourSynth, compared to the Avisynth original. Maybe it's really that slow and thus triggers the timeout. So did you do some benchmarking?

Also, at which phase does it time out? Can you please post your log...

Finally, how can you use x264 "directly" with QTGMC? If you open the source directly in x264 (not via Avisynth or VapourSynth), there will be no QTGMC processing and things will be a lot faster, obviously.

Woops. I guess I left some important information out, or my phrasing isn't that good. :(

When I said that I used x264 directly with QTGMC, I meant that I was piping the output of the Vapoursynth script to x264 like so:

vspipe.exe Meh.vpy - -y4m | x264.exe --crf 21 --preset "slower" --tune "film" --demuxer y4m --output Meh.mkv -

The same script, Meh.vpy is also what I load into Simple Launcher. So, I kept everything is the same in both cases as best as I can; The script settings, and x264 settings. I also made sure to copy the x264 file that I usually use into the launcher's toolsets directory, to keep everything the same.

As for a log... I'm not sure where to find one. I don't see any option in the launcher to save or view a log, nor is there a log file in the installation directory or the folder of my script...

Meanwhile the best I can provide is this:

http://i.imgur.com/9knSLrN.png

Thanks for your time!

[LoRd_MuldeR]

You can right-click in the lower pane and select "Copy to Clipboard" in order to copy the log.

Also: If you use a different x264 binary than what ships with the Simple x264 Launcher, are you sure your x264 binary works with Simple x264 Launcher properly at all?

If, e.g., your binary contains patches that alters the progress output, then Simple x264 Launcher won't be able to recognize the progress updates...

(Anyway, I could send you a build with more diagnostic output later)

[aegisofrime]

You can right-click in the lower pane and select "Copy to Clipboard" in order to copy the log.

Also: If you use a different x264 binary than what ships with the Simple x264 Launcher, are you sure your x264 binary works with Simple x264 Launcher properly at all?

If, e.g., your binary contains patches that alters the progress output, then Simple x264 Launcher won't be able to recognize the progress updates...

(Anyway, I could send you a build with more diagnostic output later)

Well, anyway I compared the hashes of the default binary in the toolset, and the one I use, and they are the same. There shouldn't be an issue there I guess :p

Alright, will wait for the diagnostic version. :D

[LoRd_MuldeR]

Here is a new experimental version with VapourSynth input support:

Note: Requires VapourSynth r19 or later to be installed. Download it here (http://www.vapoursynth.com/).

Here is a small update (install on top of the above download!) that adds a new option to disable the deadlock detection:

Please see the README file for details...

[Evil_Burrito]

That's true.
And in 95% of times it works well.
But sometimes not and it's recognizable that the RAM still is unloading.
I don't know how reliable those tools are (hwinfo, gpu observer), but it takes 1 or 2 seconds to finish (RAM usage falling).
Well, it should'nt behave like this but it does. :scared:

Maybe your monitoring program just isn't configured to update the interface hundreds of times a second, so the read out it isn't actually "real-time" (unnecessary use of resources).

Also, it is possible your system and or gpu is using power adaption. So, for example, it finishes a process and lowers the performance before going back to maximum state of the next job. Although, this would only slow you down a couple to a few milliseconds (depending on the speed and cycles of the memory).

Thanks Mulder for keeping Simple x264 and this thread up to date! :thanks:

[LoRd_MuldeR]

I have released a new version with support for VapourSynth input.

[Dion]

This release always says I don't have VapourSynth. So I click ignore.

It always ask me everytime I start the program :/

[Chumbo]

I have released a new version with support for VapourSynth input.
Thank you. BTW, title shows 2013-07-07.

[LoRd_MuldeR]

This release always says I don't have VapourSynth. So I click ignore.

It always ask me everytime I start the program :/

Not sure what you want to say :confused:

1) You don't have VapourSynth installed -> install VapourSynth (download (http://www.vapoursynth.com/))

2) You don't want to use/install VapourSynth at all -> simply ignore the warning (or see the README on how to disable it permanently)

3) You have VapourSynth (R19+) installed but still get the warning -> you probably found a bug

[Dion]

Not sure what you want to say :confused:

1) You don't have VapourSynth installed -> install VapourSynth (download (http://www.vapoursynth.com/))

2) You don't want to use/install VapourSynth at all -> simply ignore the warning (or see the README on how to disable it permanently)

3) You have VapourSynth (R19+) installed but still get the warning -> you probably found a bug

I did click Ignore warning. It comes back everytime I restart the app.

I run in portable mode from USB drive.

[LoRd_MuldeR]

I did click Ignore warning. It comes back everytime I restart the app.

I understood that. But what exactly is your problem?

As long as VapourSynth is not installed on your system, the warning is legitimate and it will re-appear for obvious reasons.

If, however, it appears despite VapourSynth is installed, this would indicate a bug. So please clarify...

[Chumbo]

Would you consider adding a "Don't show this warning again" check box so those of us not planning on using Vaporsynth, at least not any time soon, wouldn't have to continually click on Ignore every time the UI is loaded? Thanks for considering it.

[Dion]

I understood that. But what exactly is your problem?

The problem is.. It always ask.

I too would like an option to disable it permanently ( I thought Ignore would do this ). At least for portable mode.

edit: imo vapoursynth is too new. There should be no option to check for it. And an option in the options to enable it. For people experimenting with it.

[LoRd_MuldeR]

The problem is.. It always ask.

I too would like an option to disable it permanently ( I thought Ignore would do this ). At least for portable mode.

edit: imo vapoursynth is too new. There should be no option to check for it. And an option in the options to enable it. For people experimenting with it.

As I told you above, that there is and option to disable the Avisynth and/or VapourSynth check. It is described in the README file!

Anyway, since it seems that most people just ignore the documentation, I have added a new option to the preferences dialog now.

Would you consider adding a "Don't show this warning again" check box so those of us not planning on using Vaporsynth, at least not any time soon, wouldn't have to continually click on Ignore every time the UI is loaded? Thanks for considering it.

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).

[Dion]

As I told you above, that there is and option to disable the Avisynth and/or VapourSynth check. It is described in the README file!

Anyway, since it seems that most people just ignore the documentation, I have added a new option to the preferences dialog now:
http://www.mediafire.com/download/l0fanzrkyptfc76/x264_x64.2013-08-09.zip

No I saw it. But having to run a special command while using the app in "Portable Mode" is kind of a hassle. Defeats the whole point of being portable imo. Thanks for adding the option.. appreciate it.

[LoRd_MuldeR]

No I saw it. But having to run a special command while using the app in "Portable Mode" is kind of a hassle

It's not related to portable mode at all. And if you want to always pass a specific command-line option, you can just create a shortcut or a batch file.

Anyway, with the new version you can simply disable the warning directly inside the program...

[docholliday]

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

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

[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.

[LoRd_MuldeR]

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"

AFAIK, Windows doesn't reveal this info with "standard" tools, but you can use CPU-Z:
http://www.cpuid.com/softwares/cpu-z.html

Or, if you need it even more detailed, you might want to have a look a TMonitor:
http://www.cpuid.com/softwares/tmonitor.html

Finally, Intel offers a (rather clunky) tool here:
https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&ProdId=3052&DwnldID=19105&lang=eng

[VideoFanatic]

Thanks guys. I already using CPUs-Z and CoreTemp. Darksoul - I'm using scripts to do restoration on my videos. The scripts are slow so I can only encode six 1 hour 30 minute videos per day. Using a faster preset makes no difference to the encoding speed in this situation. The problem is that for some reason each video is taking 45 minutes longer to encode than normal and I don't know why. I'm using the same scripts as always.

I'm looking forward to the 8 core (16 thread) Intel CPUs coming out next year then the encodings will be so fast that losing a couple of FPS won't make a difference. Anybody know when they're coming out?

[Darksoul71]

Ah...there we come closer....honestly with a complex filter chain in AVISynth I guess that x264 is most likely not the bottleneck :)

Is your CPU maxed out ? If not you could consider using AVISynth-MT for your scripts. Hopefully you do not do dual-pass with your videos and the complex filter chain ?

@LoRd_MuldeR: Thanks...I was not aware of this. My main OS of choice is Linux and I rarely touch my Windows 7 box beside some gaming or BD ripping.

[Leinad4Mind]

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 JEEB r2334 build, and I dunno how to patch, but I like to use some features as fgo and fade-compensate.

And I don't see why just to support the lattest version...

It would be better to let the user choose the x264 version he wants.

Best regards

[LoRd_MuldeR]

I use JEEB r2334 build, and I dunno how to patch, but I like to use some features as fgo and fade-compensate.

If those patches are still relevant (AFAIK, FGO was superseded by Psy-RDO/Psy-Trellis, and the "fade compensation" patch is just a hack that moves more bits into "fades" ... no matter what ... causing problems of its own), somebody should make an up-to-date build of x264 with those. You don't want to stick with an outdated x264, just because somebody once made a build with some obscure patch, do you? Again, if the patch is still relevant, somebody ought to actively maintain it.

And if you prefer using patches nobody else seems to care about anymore, you better familiarize yourself with building x264 from the sources...

And I don't see why just to support the lattest version...

Well, I think I have made that clear above (http://forum.doom9.org/showthread.php?p=1642055#post1642055).

It would be better to let the user choose the x264 version he wants.

I don't think so. I think a "user friendly" software is supposed to guide the average user into the "right" direction ;)

At the same time, the advanced user can always adapt the program to his/her needs. Those are the blessings of OpenSource software...

[Leinad4Mind]

Thanks, I will test out psy-RDO, with komisar builds (with fade compensation). ;)

And try to learn how to use vapoursynth, to check the possible speed compensation.

Best regards!

[sneaker_ger]

Taro (http://astrataro.wordpress.com/category/encode/x264/x264-bin/) builds recent versions with a lot of patches, including fgo and fade compensation.

[Leinad4Mind]

It's the first time I tried to encode using this GUI, and I've tried with a simple .avs:

DGSource("D:\Blu-Rays\GLOBAL_EDITION\5stars.dgi")

But the GUI takes too long to starting up. More than 2h...

MeGUI can use dgi file and encode right away, so why it takes so much time? Is Simplex264 creating a new index file?


EDIT: Maybe is he already encoding, but the info keep saying "starting up" lol (I think that it could tell the remaining time)


PS: Thanks sneaker_ger about that info. Glad to know too.

[LoRd_MuldeR]

Startup times are not related to the GUI. But you can try opening your AVS file in VirtualDub, just to be sure it opens correctly.

Anyway, if the progress indicator in the x264 GUI doesn't seem to update, then please try to run the exactly same AVS file with an unmodified x264 binary.

Quite possible the "Taro" build (or whatever you are using now) breaks compatibility, so the GUI cannot parse the progress message...

[Leinad4Mind]

In virtualDub, it opens correctly. AVSPMod too.

I've just change the 10bit version to an modified one. So I change the preference to 8bit (x264 is the original one), and tried, but the message still doesnt update.

Kinda strange...

[LoRd_MuldeR]

Please make a clean re-install of Simple x264 Launcher and try again. I cannot help you with modified versions.

If you still encounter problems, then please:
:logfile:

[Leinad4Mind]

You are right, with a unmodified version, it update.;)

With an modified one, the message appears too, but on the log. And we can see the same information too.

Thanks to explain. :)

[LoRd_MuldeR]

Please post a link to the exact modified x264 binary you are using and I might be able to implement a workaround...

[LoRd_MuldeR]

Well, here is a test version that adds support for the heavily modified progress output in Komisar's "kMod" build:
http://www.mediafire.com/download/n8tk1kmb0fbj6b8/x264_x64.2013-10-13.exe

Please note that this will probably remain an exception, as I certainly won't try to support any modified build out there ;)

(It's generally a very bad idea to modify the progress output, as this is likely to break x264 GUI's)

[Leinad4Mind]

Thanks, I'll try out later. :)

[kypec]

:thanks: a million for "Apply to all selected files" option when adding new jobs. Until now I had to click dozens of times on "Add job" with chosen template which was not that bad either when encoding series with more than 20 episodes at once but this option is simply amazing!
Thumbs up once again, Lord M! :D

[AGKnotUser]

Just tried to use version 2.24 with Windows 8.1 64 bit. When started a (paraphrasing) "...Launcher.exe cannot run in Windows Compatibility mode" message appears and asks to quit. If I go back to 2013-8-28 or 2013-10-13 it runs without incident. I'm not running in compatibility mode. Could you please have a look?

[LoRd_MuldeR]

Just tried to use version 2.24 with Windows 8.1 64 bit. When started a (paraphrasing) "...Launcher.exe cannot run in Windows Compatibility mode" message appears and asks to quit. If I go back to 2013-8-28 or 2013-10-13 it runs without incident. I'm not running in compatibility mode. Could you please have a look?

I think I have an idea. Will upload a fixed version when I'm back from work this evening...

[AGKnotUser]

I think I have an idea. Will upload a fixed version when I'm back from work this evening...

Thanks for the quick response.

[LoRd_MuldeR]

I think I have an idea. Will upload a fixed version when I'm back from work this evening...

New version is now available.

[AGKnotUser]

Thanks, that fixed the problem.

[AGKnotUser]

I see it does an avs script check now. It tells me my script doesn't look like an avs script when it is and the path and script name are displayed in 8.3 format not long file names. I have uploaded the script used.

[LoRd_MuldeR]

First of all, Simple x264 Launcher is passing short (8+3) file names to Avs2YUV because Avisynth (latest stable release) does not support Unicode file names :rolleyes:

Using short (8+3) file names is an unreliable hack, I know, but it's all we can do until they add proper Unicode support. x264 does support Unicode file names now, but until recently it had the same issue.

Secondly, the error message you are getting is not generated by Simple x264 Launcher, but by Avs2YUV. It probably means that your script has some kind of error and did not actually return a clip :eek:

When I try to run your script I get this:
infile 'C:\Temp\AVS_72~1.AVS' doesn't look like an avisynth script
error: Script error: there is no function named "SetMTmode"
(C:\Temp\AVS_72~1.AVS, line 2)

It's obviously because I don't use the "MT" branch of Avisynth and thus SetMTmode() doesn't exist. You will need Avisynth-MT to run this kind of script. Do you use Avisynth-MT ???

(There also are a bunch of plug-in's used in that script. Do you have all of the required plug-ins in your Avisynth "plugins" folder too?)

[AGKnotUser]

Thank you for the explanation. I'll check my script but it did run properly with a cmd file using avs2yuv. And yes, I am using the MT version AVISynth 2.6.

Edit: Ok, I guess I was just not used to seeing those messages as they did not appear in earlier versions of the launcher. The script seems to run though so no problem.

[LoRd_MuldeR]

Thank you for the explanation. I'll check my script but it did run properly with a cmd file using avs2yuv. And yes, I am using the MT version AVISynth 2.6.

Edit: Ok, I guess I was just not used to seeing those messages as they did not appear in earlier versions of the launcher. The script seems to run though so no problem.

After some more investigation, it seems the "doesn't look like an avisynth script" warning is not related to the error message I got at all.

Avs2YUV simply checks the input file name for an ".avs" extension and it will show a warning if no such extension is present. However that check is case-sensitive!

And since we are passing a "short" (8+3) file name - which happens to be all upper-case - Avs2YUV doesn't recognize the ".avs" extension ;)

[AGKnotUser]

And since we are passing a "short" (8+3) file name - which happens to be all upper-case - Avs2YUV doesn't recognize the ".avs" extension ;)

So now you have a choice to make. Unicode compatibility or a permanent avs script warning.

[LoRd_MuldeR]

The warning can be ignored safely, so it's just a "cosmetic" problem ;)

I could either filter out that message so user never gets it to see or I could convert the "shot" name to lower case before passing it to Avs2YUV.

Or I could simply fix the check inside Avs2YUV...

[szabi]

Hi

This error message pop up when I want to start the application:
http://abload.de/img/s264l_errutqvm.png

Of course aplication does not start.
What can be the solution?

bye
szabi

[LoRd_MuldeR]

What version are you using? If you are not using v2.25 (Build #610) yet, please install the latest update.

[szabi]

This one: x264_x64.2013-11-03.exe

bye
szabi

[LoRd_MuldeR]

This is not the latest (http://forum.doom9.org/showthread.php?p=1234822#post1234822) version. As I said before, please update to the latest version.

[szabi]

Ok, I installed this one x264_x64.2013-11-06.exe (http://code.google.com/p/mulder/downloads/detail?name=x264_x64.2013-11-06.exe&can=2&q=&sort=-uploaded).
But now this problem occured: PROCESS EXITED WITH ERROR CODE: -1073741819 for my script.
Script is attached.

[LoRd_MuldeR]

Lookls like Avisynth/Avs2YUV has crashed, so this is not related to Simple x264 Launcher at all.

So first make sure that your script is working correctly. But by having a look at your script, it seems you are using Avisynth-MT, which is known to be an unstable mess. You might want to start by throwing out the MT-related stuff installing a stable Avisysnth 2.5...

In any case, you can use the following to check if your script working correctly:
avs2yuv.exe "c:\path to script\foobar.avs" -raw -o NUL

[szabi]

Ok, thanks.
You are right avisynth MT is used.
What can be tested with this code?

[AGKnotUser]

The warning can be ignored safely, so it's just a "cosmetic" problem ;)

I could either filter out that message so user never gets it to see or I could convert the "shot" name to lower case before passing it to Avs2YUV.

Or I could simply fix the check inside Avs2YUV...

I vote for the Avs2YUV check.

[LoRd_MuldeR]

FWIW, I have implemented a workaround for the Avs2YUV warning message:
http://www.mediafire.com/download/4ndl2hd1au4j706/x264_x64.2013-11-08.exe

[AGKnotUser]

FWIW, I have implemented a workaround for the Avs2YUV warning message:
http://www.mediafire.com/download/4ndl2hd1au4j706/x264_x64.2013-11-08.exe

Ah, you pass AVS in lowercase. Works for me!

[lansing]

I had installed both 32bit and 64bit vapoursynth, and simple x264 launcher is giving me the message "vapoursynth missing" on start up.

[LoRd_MuldeR]

I had installed both 32bit and 64bit vapoursynth, and simple x264 launcher is giving me the message "vapoursynth missing" on start up.

Currently only 32-Bit version is required/used.

Anyway, do you have the latest Simple x264 Launcher installed? And with what version of VapourSynth? :confused:

Furthermore: What does the log say? (try to run the app with "--console" if you haven't yet)

[lansing]

I'm using both the last vapoursynth R22 test3 and simple x264 laucher 2.27.638.

And how can I run it with --console?

[LoRd_MuldeR]

I'm using both the last vapoursynth R22 test3 and simple x264 laucher 2.27.638.

AFAIK, VapourSynth R22 has not even been released yet, so I don't know if anything relevant for Simple x264 Launcher is going to change. Haven't tried those test builds :confused:

Please try with current R21 (http://www.vapoursynth.com/downloads/vapoursynth-r21.exe) release. I will have a look at R22 as soon as it's done.


And how can I run it with --console?

Type this:
x264_launcher.exe --console

...then hit Enter.

[lansing]

I ran the console the saw the problem.

The newer Vapoursynth version changed the structure of the installation folder. Now they have four folders for filters: core32, core64, plugins32, plugins64

[LoRd_MuldeR]

I ran the console the saw the problem.

The newer Vapoursynth version changed the structure of the installation folder. Now they have four folders for filters: core32, core64, plugins32, plugins64

Okay, I will adjust the detection code and release a new version, as soon as R22 is officially out.

(Can send you test version via PM)

[LoRd_MuldeR]

Okay, I will adjust the detection code and release a new version, as soon as R22 is officially out.

(Can send you test version via PM)

The new version is out now!

[Sm3n]

Hi,
Any chance to see soon a Simple x265 Launcher beta?

[LoRd_MuldeR]

Hi,
Any chance to see soon a Simple x265 Launcher beta?

I did not yet have a chance to play around with x265. But if their interface isn't too different, support can be added in a future version, hopefully.

[Sm3n]

That would be great.
Thx Lord

[szabi]

I receive an alert notification for the exe file:
http://abload.de/img/simp_x264_lau05sw0.gif
Do yu have any idea for reason?

bye
szabi

[szabi]

I ignore the alert, and launch the program, what drives new questions.
This is the log file:
Resolution: 704x528
Frame Rate: 25
No. Frames: 333381

--- PASS 1 ---

Creating Avisynth process:
"C:/Program Files (x86)/MuldeR/Simple x264 Launcher v2/toolset/x86/avs2yuv_x86.exe" D:\movie\movie.avs -

Creating x264 process:
"C:/Program Files (x86)/MuldeR/Simple x264 Launcher v2/toolset/x64/x264_8bit_x64.exe" --bitrate 2540 --pass 1 --stats C:\Users\szabi\Videos\movie.stats --preset veryslow --tune film --profile high --level 3.1 --bframes 6 --ref 9 --no-fast-pskip --output C:\Users\szabi\Videos\movie.mkv --frames 333381 --demuxer y4m --stdin y4m -

y4m [info]: 704x528p 0:0 @ 25/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
x264 [info]: profile Main, level 3.1

Why not save the output to the same directory?
My "C" drive is ssd, which has not enough space for huge files.
Saving to same directory more logical.

Why the given profile is not used?
It is set to High but using Main.

Bye
szabi

[r0lZ]

The warning is due to the fact that the program is not digitally signed. (That cost money, and you cannot hope that a free program will be signed.)
Why not save the output to the same directory?
My "C" drive is ssd, which has not enough space for huge files.
Saving to same directory more logical.There is an option in the Preferences to save by default to the source directory.

I prefer to leave more knowledgeable persons reply to the question about the main profile. I guess it's because you have used an option incompatible with the high profile.

[szabi]

I use several free program, but only this one got alert notification by anti-virus program.
Yes, I found this option in preferences, my suggestion it to make it default settings.

So you think Level3.1 is not available for high profile? Only main one?

[r0lZ]

Oh, I haven't noticed that the warning was issued by AVG. It's probably a false positive. Scan the exe files with VirusTotal.

I don't know if Level 3.1 is incompatible with the high profile. That may be caused by another option. I don't know the h264 specs enough to be sure.

[szabi]

Propable, yes.
I am going to see, as you wrote if "more knowledgeable persons" can answer.
Thanks.

bye
szabi

[kypec]

Propable, yes.
I am going to see, as you wrote if "more knowledgeable persons" can answer.
Thanks.

bye
szabi
Are you using 2-pass encoding mode? If so then please wait until 2nd pass is started and you'll see that your chosen profile "High" will be truly selected. x264 is very clever and ignores H.264 Profile for the 1st pass encoding...

[LoRd_MuldeR]

Oh, I haven't noticed that the warning was issued by AVG. It's probably a false positive. Scan the exe files with VirusTotal.
I use several free program, but only this one got alert notification by anti-virus program.

Please read this:
http://lamexp.sourceforge.net/doc/FAQ.html#96205e91

I originally wrote that for LameXP, but it applies to Simple x264 Launcher in the same way, of course.


Why not save the output to the same directory?
My "C" drive is ssd, which has not enough space for huge files.
Saving to same directory more logical.

The output file is saved to where you have chosen. You can select the output file when adding a new job...


Why the given profile is not used?
It is set to High but using Main.

Because the Profile is defined by which H.264 features you use. x264 sets the lowest possible Profile that supports all features you are using - setting an even higher one would be pointless.

So, if you are using only "Main" (and "Baseline") Profile features, i.e. no "High" Profile features, then x264 will set the "Main" Profile, since a "Main" Profile capable decoder suffices to playback that stream!

The "--profile" option can be used to force a specific Profile. But this only works to enforce a lower Profile! It won't pretend a higher Profile, when that isn't needed at all...

You almost always want to leave the "Profile" option on the default "Auto" setting. As soon as you use any "High" Profile features, you will see that x264 is going to set the proper Profile automatically ;)

Details:
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles

[szabi]

Thanks for the answer, now the profile question is clear.
Unfortunately when the 1st pass finished and 2nd started i got an error message:
x264 [error]: 2nd pass has more frames than 1st pass (333381 vs 323980)
x264 [error]: x264_encoder_open failed
av2y [info]: D:\movie\movie.avs: 704x528, 25 fps, 333381 frames
av2y [info]: error: wrote only 556620 of 557568 bytes

WARNING: Input process exited with error (code: 1), your encode might be *incomplete* !!!
I do not understand how it is possible?
Source is the same.

[LoRd_MuldeR]

Looks like something weird is going on with your input script :confused:

(Or maybe, in the first pass, Avisynth simply crashed shortly before the end of the encode?)

What happens if you run this multiple times? Does it always show the same info?
avs2yuv.exe -frames 1 "your_script.avs" NUL

Also, if you open the very same script in, e.g. VirtualDub, does it play fine, all the way to the end?

[szabi]

Hi

I do not want to try running it again, because the first pass was running almost 6 hours.
I guess you can imagine my happiness when this error occured, on the last frame.
In other topic (http://forum.doom9.org/showthread.php?p=1658392#post1658392) dissgussion was about to load script to virtuadub, set fast recompress, select ffdshow video codec ffv1 and save the script to uncompressed avi.
And give it to x264 for encoding.
This way there is no quality loss just more steps and lots of disc space needed.
Tomorrow I will check it.

[LoRd_MuldeR]

I do not want to try running it again, because the first pass was running almost 6 hours.
I guess you can imagine my happiness when this error occured, on the last frame.

Happy or not, you won't get around debugging your Avisynth script, if you want to fix the issue.

In other topic (http://forum.doom9.org/showthread.php?p=1658392#post1658392) dissgussion was about to load script to virtuadub, set fast recompress, select ffdshow video codec ffv1 and save the script to uncompressed avi.
And give it to x264 for encoding.
This way there is no quality loss just more steps and lots of disc space needed.
Tomorrow I will check it.

Creating a lossless intermediate file from your Avisynth script might make sens for a 2-Pass encode, if you use very slow filters. Either that or simply use CRF mode ;)

[szabi]

Thanks, I started saving it by huffyuv in virtualdub, colorspace yv12, predictor: plane.
Estimated time 6hours, and predicted file size is 87GB.
I hope that will be successfull.

[VideoFanatic]

Could you please tell me what is the correct SAR for 4:3 720p?

I have upscaled the Standard Definition video to 960 x 720 and I've added 160 pixels each to the left and right border to make a total of 1280 x 720.

For 720 x 480 4:3 I have a SAR of 8:9 and the video displays correctly but when I do the same thing for the 720p upscaled video, the picture doesn't appear wide enough - it's squashed.

I'm using the "ARS Calculator" program to give me the correct SAR. It works fine for standard definition but it doesn't seem to give the correct values for 4:3 720p.

[LoRd_MuldeR]

If with 720p you mean 1280x720 - the resolution commonly associated with "720p" - then the DAR almost certainly is 16:9, which corresponds to a SAR of 1:1.

But if we are talking about 720x480 footage (aka "480p", aka "NTSC"), then the DAR most likely is either "classic" 4:3 or "anamorphic" 16:9, which corresponds to a SAR of 8:9 or 32:27, respectively.

It should very easy to spot whether a DAR of 4:3 or a DAR of 16:9 look correct - because picking the wrong one will result in eggheads ;)

[VideoFanatic]

Thanks 1:1 works great. Also when viewing a 720 x 480 video there's an option on my media player to play in 16:10 which makes the picture slightly wider on each side by about an inch but to my eyes it still looks in proportion (although I know it's not). What SAR should I use to get that effect in 720 x 480 and in 4:3 720p?

And would that SAR be Bluray compatible or does it not matter what SAR is used?

[LoRd_MuldeR]

As said before, with 480p (720x480), you can get a DAR of 4:3 or 16:9 by applying a SAR of 8:9 or 32:27, respectively.

Furthermore, AFAIK, BluRay doesn't use anamorphic video for the "HD" resolutions (720p and above) at all, so those should all use a SAR of 1:1. Anamorphic video is still used for NTSC (480p) and PAL (576p) - for historical reasons.

For details, please have a look here:
http://www.x264bluray.com/

[VideoFanatic]

Thanks. I'm also getting a problem where my encodings keep failing within a couple of minutes of the encoding starting. My script is pretty simple, I'm downscaling 1080i 25fps to 720p 50fps. I'm using the following customer parameters: --sar 1:1. Here's my script:

setmtmode(5,12)
DGSource("X:\Video.dgi")
setmtmode(2)

AssumeTFF()
QTGMC(Preset="Super Fast")

Lanczos4Resize(1280,720)

That makes a 720p 50fps video. The error message says: WARNING: Input process exited with error code: -1073741819.

Is there another program I could use to give a more detailed error message so I could see what's causing the problem?

I use QTGMC all the time when re-encoding 720 x 480i MPEG2 to h264 and the encodings never fail so I don't understand why they're failing for HD? I'm using the latest version of DGIndexNV to index the file which is read by your program. I use DGIndex for MPEG2s.

[LoRd_MuldeR]

int x = -1073741819;
printf("%d = 0x%08X\n", x, x);

-1073741819 = 0xC0000005

It means that Avisynth, or more likely one of the plug-in's you are using, has crashed - with STATUS_ACCESS_VIOLATION (http://www.tenox.net/links/ntstatus.html) (0xC0000005) error.

In case of a "hard" crash, you won't get any useful error message, as the program just dies. You may be able to locate in which module and function it crashed using a debugger though.

Anyway, this problem obviously is not related to x264 or Simple x264 Launcher. All you can do at this point is stripping down your Avisynth script and find out which plug-in is responsible.

And, most important, get rid of the unstable mess called Avisynth-MT for now and try again with a stable Avisynth ;)

[johnchoi]

I would like to request 2 features be added to Simple x264 Launcher:


The ability to fully add jobs to Simple using the command line with no other input/dialogs necessary. While the --add function currently exists all it does is add the file you specify to the Add New Job dialog box. What I would like is the ability to add the complete job with no GUI input necessary. For example a command like this: "x264_launcher.exe --input Video.avs --output Video.mkv --template 720pHD". This would require a template to already exist. The end goal of these commands would be to allow people to add jobs to Simple x264 Launcher using batch files or scripts.


The ability to re-order jobs currently in queue in Simple x264 Launcher. Currently if I have 3 jobs in queue and I add a 4th that I want to run ahead of those 3 I have to delete the 3 existing jobs and then re-add then. A simple Up/Down ability for the queue or a Low, Normal, High priority setting for queue management would be great.

[LoRd_MuldeR]

The ability to fully add jobs to Simple using the command line with no other input/dialogs necessary. While the --add function currently exists all it does is add the file you specify to the Add New Job dialog box. What I would like is the ability to add the complete job with no GUI input necessary. For example a command like this: "x264_launcher.exe --input Video.avs --output Video.mkv --template 720pHD". This would require a template to already exist. The end goal of these commands would be to allow people to add jobs to Simple x264 Launcher using batch files or scripts.

You are not the first one to ask for this. It's one of the things I'm planning for future versions. No ETA though ;)

The ability to re-order jobs currently in queue in Simple x264 Launcher. Currently if I have 3 jobs in queue and I add a 4th that I want to run ahead of those 3 I have to delete the 3 existing jobs and then re-add then. A simple Up/Down ability for the queue or a Low, Normal, High priority setting for queue management would be great.

Adding job priorities seems reasonable. I will consider this feature for a future version...

[LoRd_MuldeR]

Here is a new test version with improved command-line support:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_x64.2014-01-29.exe/download

You can now add new jobs directly (no dialog) by using:
x264_launcher.exe --add-job <source_file> <destination_file> <template>

Note that the template can be specified as "-" to encode with x264 default settings.

[LoRd_MuldeR]

Yet another test version with improved command-line support:

New jobs will now be started immediately or added to the queue - depending on the user's preferences.

Also there are two new CLI options that can be used to enforce that a new job will be started immediately or to enforce that a new job will added to the queue.

[johnchoi]

Yet another test version with improved command-line support:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_x64.2014-02-03.exe/download

New jobs will now be started immediately or added to the queue - depending on the user's preferences.

Also there are two new CLI options that can be used to enforce that a new job will be started immediately or to enforce that a new job will added to the queue.
For those wondering, the options are listed in the ReadMe.txt file and are:

--[no-]force-start .............. Next job will [not] be started immediately
--[no-]force-enqueue ............ Next job will [not] be appended to queue

[LoRd_MuldeR]

Simple x264 Launcher v2.31 has been released.

[Chumbo]

Simple x264 Launcher v2.31 has been released.
Thanks. BTW, it looks like the download link, for the installer, is still for the 2013-12-14 release.

[LoRd_MuldeR]

Thanks. BTW, it looks like the download link, for the installer, is still for the 2013-12-14 release.

No, the download link was okay. Just the wrong name for the correct file. Should be fixed now ;)

[Chumbo]

No, the download link was okay. Just the wrong file name. Should be fixed now ;)
Man that was quick! :) Thanks.

[lansing]

Hi, today when I was trying to encode a dvd, the process ended with an error after three hours. Here the error message from the log.


av2y [info]: xyz.avs: 720x550, 60000/1001 fps, 523236 frames
av2y [info]: error: Unknown ResampleHQ internal error. occurred while reading frame 139815

WARNING: Input process exited with error (code: 1), your encode might be *incomplete* !!!


I'm not sure where should I look for help with this problem.

[LoRd_MuldeR]

Seems pretty obvious where the problem occurred:

av2y [info]: error: Unknown ResampleHQ internal error. occurred while reading frame 139815

Try to kick out the ResampleHQ plug-in and then try again. If it runs through fine then, you probably need to bother the ResampleHQ author ;)

BTW: You are using "stable" Avisynth or Avisynth-MT or Avisynth+ ???

[lansing]

BTW: You are using "stable" Avisynth or Avisynth-MT or Avisynth+ ???

Avisynth+.

I'll try to run a quick encode with only ResampleHQ and without to see how it goes.

[LoRd_MuldeR]

Avisynth+.

I'll try to run a quick encode with only ResampleHQ and without to see how it goes.

Try stable Avisynth 2.5 with one of the built-in resize filters. You can still try the "fancy" stuff once you have a working baseline.

[lansing]

Try stable Avisynth 2.5 with one of the built-in resize filters. You can still try the "fancy" stuff once you have a working baseline.

I broken my script into parts and encoded them each, but still couldn't reproduce the problem. Guess I'll have to settle for another resizer.


And for this program, can you add a confirm pop up if the user click abort job, just in case any misclick. Also, can you add a button or context menu option to open the output folder for the selected job?

[LoRd_MuldeR]

And for this program, can you add a confirm pop up if the user click abort job, just in case any misclick.

Adding that is not a big deal. The question is more whether I like to have yet another popup window.

Also, can you add a button or context menu option to open the output folder for the selected job?

Right-click -> "Explore job" should do exactly this ;)

[lansing]

Adding that is not a big deal. The question is more whether I like to have yet another popup window.

I believe that it should be a necessary safe guard to have that, just like having a confirm pop up when the program is about to overwrite an existing file.


Right-click -> "Explore job" should do exactly this ;)

Good to know that ;), didn't understand what it meant before.

[LoRd_MuldeR]

Here is a new experimental build with rudimentary x265 encoding support:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_x64.2014-02-26.exe/download

http://i.imgur.com/nQwrBCDs.png (http://i.imgur.com/nQwrBCD.png)

[DeeSeven]

I've been using simple x264 for a while now with no troubles, I updated to the latest and greatest and I get this error

your revision of x264 is too old.

I've tried updating to the latest x264 and I get the same error. I've been replacing the x264 .exes in here C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset

is that right? I'm running a 64 bi win 8 machine

[LoRd_MuldeR]

I've been using simple x264 for a while now with no troubles, I updated to the latest and greatest and I get this error

your revision of x264 is too old.

I've tried updating to the latest x264 and I get the same error. I've been replacing the x264 .exes in here C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset

is that right? I'm running a 64 bi win 8 machine

I generally set the minimum required revision to the latest stable (http://git.videolan.org/?p=x264.git;a=shortlog;h=refs/heads/stable) x264 revision.

Of course the x264 binaries that ship with Simple x264 Launcher will be at least that revision, to make sure that everything works out-of-the-box. Why not simply stick with the provided binaries?

[Atak_Snajpera]

Detection of AVS properties does not work for my simple script.

Simple x264 Launcher (Build #808), built 2014-02-26

Job started at 2014-02-28, 19:23:10.

Source file : C:\temp\RipBot264temp\job1\job1.avs
Output file : C:\Users\Dave\Desktop\job1.mkv

--- SYSTEMINFO ---

Binary Path : C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2
Avisynth : Yes
VapourSynth : N/A

--- SETTINGS ---

Encoder : x265 (H.265/HEVC), x64, 8-Bit
Source : Avisynth (avs)
RC Mode : CRF
Preset : Medium
Tuning : None
Profile : Auto
Custom : (None)

--- CHECK VERSION ---

Detect video encoder version:

Creating process:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x64\x265_8bit_x64.exe" --version

x265 [info]: HEVC encoder version 0.7+232-fec3cab870437c10
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast SSSE3 SSE4.2 AVX

Detect video source version:

Creating process:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x86\avs2yuv_x86.exe"

Avs2YUV 0.24bm2

> x265 version: 0.7+232
> Avs2YUV version: 0.24.2

--- GET SOURCE INFO ---

Creating process:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x86\avs2yuv_x86.exe" -frames 1 C:\temp\RIPBOT~1\job1\job1.avs NUL


FAILED TO DETERMINE AVS PROPERTIES !!!

Job1.avs
DirectShowSource("C:\Users\Dave\Desktop\112.MTS",audio=false)

[LoRd_MuldeR]

Detection of AVS properties does not work for my simple script.

If you run this from the console manually, what output do you get? :confused:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x64\x265_8bit_x64.exe" -frames 1 C:\temp\RIPBOT~1\job1\job1.avs NUL

From you log it looks like it didn't generate any text output at all...

[Atak_Snajpera]

It works in console but not in gui
http://i.cubeupload.com/KeRyxP.png

[LoRd_MuldeR]

That doesn't make much sense to me. Does it only happen with DirectShowSource() or with other scripts too?

[Atak_Snajpera]

That doesn't make much sense to me. Does it only happen with DirectShowSource() or with other scripts too?

It works with this script
LoadPlugin("..\RawSource.dll")
video1=RawSource("E:\_Video_Samples\y4m\crowd_run_1080p50.y4m")
video2=RawSource("E:\_Video_Samples\y4m\park_joy_1080p50.y4m")
video3=RawSource("E:\_Video_Samples\y4m\ducks_take_off_1080p50.y4m")
video4=RawSource("E:\_Video_Samples\y4m\in_to_tree_1080p50.y4m")
video5=RawSource("E:\_Video_Samples\y4m\old_town_cross_1080p50.y4m")

return video1+video2+video3+video4+video5

This also works

LoadPlugin("\DGDecode.dll")
video=MPEG2Source("C:\Temp\RipBot264temp\job3\job3.d2v")


but it does not work with DirectShowSource

Check this video https://mega.co.nz/#!pE0E2QyQ!vn7Gqyl97u1ca8rPNb--IrgroYHV-ZkOekzORgbj7XA

[LoRd_MuldeR]

So, obviously, the detection code is working fine. Must be some oddity with DirectShowSource() or the particular DirectShow decoder filter.

[EDIT]

Works fine for me with your clip, using FFVideoSource:
Simple x264 Launcher (Build #808), built 2014-02-26

Job started at 2014-02-28, 21:19:25.

Source file : C:\Temp\Dwm 2014-02-28 20-14-23-60.avs
Output file : C:\Temp\Dwm 2014-02-28 20-14-23-60.hevc

--- SYSTEMINFO ---

Binary Path : E:\DeLpHi\x264_x64_launcher\bin\Release
Avisynth : Yes
VapourSynth : D:\VapourSynth\core32

--- SETTINGS ---

Encoder : x265 (H.265/HEVC), x64, 8-Bit
Source : Avisynth (avs)
RC Mode : CRF
Preset : Superfast
Tuning : None
Profile : Auto
Custom : (None)

--- CHECK VERSION ---

Detect video encoder version:

Creating process:
E:\DeLpHi\x264_x64_launcher\bin\Release\toolset\x64\x265_8bit_x64.exe --version

x265 [info]: HEVC encoder version 0.7+232-fec3cab870437c10
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast SSSE3 Cache64 SlowShuffle

Detect video source version:

Creating process:
E:\DeLpHi\x264_x64_launcher\bin\Release\toolset\x86\avs2yuv_x86.exe

Avs2YUV 0.24bm2

> x265 version: 0.7+232
> Avs2YUV version: 0.24.2

--- GET SOURCE INFO ---

Creating process:
E:\DeLpHi\x264_x64_launcher\bin\Release\toolset\x86\avs2yuv_x86.exe -frames 1 C:\Temp\dwm201~1.avs NUL

C:\Temp\dwm201~1.avs: 2048x1152, 30030/1001 fps, 1362 frames

Resolution: 2048x1152
Frame Rate: 30030/1001
No. Frames: 1362

--- ENCODING VIDEO ---

Creating input process:
E:\DeLpHi\x264_x64_launcher\bin\Release\toolset\x86\avs2yuv_x86.exe C:\Temp\dwm201~1.avs -

Creating encoder process:
E:\DeLpHi\x264_x64_launcher\bin\Release\toolset\x64\x265_8bit_x64.exe --crf 22.0 --preset superfast --output "C:\Temp\Dwm 2014-02-28 20-14-23-60.hevc" --frames 1362 --y4m -

y4m [info]: 2048x1152 30030/1001 fps i420, frames 0 - 1361 of 0
x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast SSSE3 Cache64 SlowShuffle
x265 [info]: HEVC encoder version 0.7+232-fec3cab870437c10
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: Main profile, Level-5 (Main tier)
x265 [info]: WPP streams / pool / frames : 36 / 4 / 2
x265 [info]: CU size : 32
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 44 / 1 / 2
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 10 / 4 / 0
x265 [info]: b-pyramid / weightp / refs : 1 / 0 / 1
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-22.0 / 0.0 / 0
x265 [info]: tools: cfm esd rd=3 lft sao-lcu sign-hide

[Atak_Snajpera]

My chain looks like this Haali + ffdshow (libavcodec for avc)

[Atak_Snajpera]

Problem was solved after re-boot. Weird...
Sorry Lord_Mulder for raising false alarm ;)

[Bozotheclown]

Welcome everyone,

Very nice and useful app for x264 stuff.

few questions:

1. It's possible to add new button labeled as "SAVE" for saving modified parameters in existing template?

2. Add option for edit existing "Job".

3. If m2ts container officially supported as input? There is no such ext on "all supported files" in "Open Source File" window. But program accepted this kind of file.

[LoRd_MuldeR]

1. It's possible to add new button labeled as "SAVE" for saving modified parameters in existing template?

Possible? Yes. Will it be added? Maybe ;)

2. Add option for edit existing "Job".

Well, at least when the job is not started yet, this should be possible. But requires extra work.

3. If m2ts container officially supported as input? There is no such ext on "all supported files" in "Open Source File" window. But program accepted this kind of file.

Simple x264 Launcher is just a front-end to x264/x265. So what works (or does not work) solely depends on the encoder! If you use a x264 build with FFM2-support enabled (as is the case with the included builds), it can read almost everything thanks to FFMS2/libav. However, as far as I remember, TS/M2TS is known to be a particular problematic format for FFMS2. As for x265, all it can read is "raw" YUV4MPEG at the moment, nothing else.

Of course you can always load your M2TS file via Avisynth or VapurSynth, for both x264 and x265. I recommend DGDecodeNV.

[VideoFanatic]

I was using an old version of Simple x264 Launcher that I was quite happy with. I got fed up with the "this version is more than 6 months old" message every time I started the program so I downloaded the latest version.

I thought the program was supposed to be portable, it just extracts the files to a folder? However there's an entry in the Programs and Features section in Windows which suggests it installed the program.

Also, when installing the program there was a popup saying it was out of date so I clicked the button to update it, it appears to be updating mplayer. The top of the window says "download complete, verifying signature".

The progress window says "Failed to verify signature" at the bottom and the install has paused. The only button available to click is the cancel button.

Not very happy. What's going on?

[LoRd_MuldeR]

I thought the program was supposed to be portable, it just extracts the files to a folder? However there's an entry in the Programs and Features section in Windows which suggests it installed the program.

Correct, the program is 100% portable - in the sense that it does not require any additional "runtime libraries", "frameworks" or "codecs" to be installed on the system. It's 100% self-contained.

You can even rename the program file to x264_launcher_portable.exe in order to enable a "real" portable mode, in which case the program will keep all it's INI files directly in the program directory.

Though using the "real" portable mode is only recommended if you want to carry around the program on your USB stick. Otherwise, I highly recommend to keep the INI files at %LOCALAPPDATA%.


As far as the installer is concerned, it doesn't do anything but extracting the program files to the selected directory (just like an SFX archive) and create the shortcuts to the program.

In newer versions we also have a proper uninstaller now, because a lot of people asked for it. They don't believe that deleting the installation directory plus the (now defunct) shortcuts can be sufficient.

But that's pretty much what the uninstaller does. So it's just a convenience feature. And of course the uninstaller will show up under "Programs and Features", so people can find it ;)

(Note: The paranoid user, who believes that the installer program does some evil things - which of course it doesn't - may still extract the program files with 7-Zip and bypass the installer altogether)

Also, when installing the program there was a popup saying it was out of date so I clicked the button to update it, it appears to be updating mplayer.

What makes you believe the Simple x264 Launcher Auto-Updater was downloading "mplayer" updates?

Well, one of our update servers is located at "mplayer.savedonthe.net" and maybe you got confused by that. But let me assure you that not only MPlayer updates are hosted there :p

The top of the window says "download complete, verifying signature".

The progress window says "Failed to verify signature" at the bottom and the install has paused. The only button available to click is the cancel button.

Of course all updates I distribute have a PGP signature attached, so potential attackers cannot slip in "malicious" files. And my Auto-Update utilities won't install any updates, unless they have verified the signature :cool:

If you get "Failed to verify signature", it means the signature verification has failed for some reason. Probably it's just a failed/corrupted download. Though, this could also mean that you have just been protected from an attack!

In any case, it should be obvious that the update installer won't go on after the signature check has failed, so simply try again! And if the update fails multiple times, I will need to have a closer look...

[VideoFanatic]

OK thanks. Why after uninstalling does it say I need to reboot if it's merely just deleted the files since the program is portable?

What's the point of the signature thing? If it didn't need a signature then it would have downloaded fine?

I have now renamed the installation file to: x264_launcher_portable.exe but when I open the file it's still asking me to install it?

[LoRd_MuldeR]

OK thanks. Why after uninstalling does it say I need to reboot if it's merely just deleted the files since the program is portable?

NSIS decides by itself when it needs to reboot.

If it requests a reboot, that probably means one of the files that were supposed to be deleted was locked at the time the uninstaller was run.

What's the point of the signature thing?

Digital signatures make sure that the files you are downloading are genuine, i.e. they have been created by me and have not been modified since then.

Thus it prevents that:

The download can be modified while it's traveling trough the Internet from the update server to your computer - which otherwise would easily be possible.
If somebody manages to break into one of my update mirrors, he can modify the files unnoticed, e.g. replace the original files with "malicious" ones.
If one of my update mirrors is no longer under my control, e.g. because the domain name now belongs to somebody else, the new owner can start distributing "malicious" files.
I will still be able to distribute any updates, if I ever loose my private signing key :p


Recommended reading:
http://en.wikipedia.org/wiki/Digital_signature
http://en.wikipedia.org/wiki/GNU_Privacy_Guard


If it didn't need a signature then it would have downloaded fine?

Nope. Without the signature, the Auto-Updater simply would have no way to know whether the file it just downloaded is genuine or malicious.

In other words: Without the signatures, the Auto-Update process would be inherently insecure! :eek:

I have now renamed the installation file to: x264_launcher_portable.exe but when I open the file it's still asking me to install it?

Did you rename the installer or the program? Renaming the installer has no effect at all! :confused:

Renaming the program itself has exactly one effect: The program will now keep all of it's INI files in the same directory where the EXE file is located. And this is usually not recommended.

(As said before: The "real" portable mode is only recommended if you want to carry around the program on your USB stick, but not for normal "local" usage)

[r0lZ]

The program will now keep all of it's INI files in the same directory where the EXE file is located. And this is usually not recommended.May I ask why it's not recommended? I install many programs in portable mode whenever possible on my D: HDD, because that way I don't need to re-install them if I need to format my system disc and re-install Windows. I find that technique very convenient, or at least much more convenient than installing the programs in the default location "C:\Program Files". So, if for any reason, that technique could have a drawback or be insecure, please let me know.

[LoRd_MuldeR]

May I ask why it's not recommended? I install many programs in portable mode whenever possible on my D: HDD, because that way I don't need to re-install them if I need to format my system disc and re-install Windows. I find that technique very convenient, or at least much more convenient than installing the programs in the default location "C:\Program Files". So, if for any reason, that technique could have a drawback or be insecure, please let me know.

Because on modern multi-user operating systems the proper place to store user-specific configuration files is %APPDATA% or %LOCALAPPDATA% (equivalent to "/home/user_name" on POSIX systems). This way each user can have its own configuration without interfering with other user's configuration. But most important, any user is guaranteed to have write-access to these user-specific directories, which is not the case for %PROGRAMFILES% (equivalent to "/usr/bin" on POSIX systems). And that is for a good reason! Now you could of course install the program to some directory where all users have write access to workaround the issue. But that obviously undermines the operating system's security mechanisms.

BTW: In practice it may actually work to store configuration files in %PROGRAMFILES%, even if the program is not run with "elevated" (root) privileges. That's because Windows provides backward-compatibility mechanisms for legacy applications. It will automatically redirect any attempt to create files in "%PROGRAMFILES%" to "%LOCALAPPDATA%\VirtualStore". But of course new software should not depend on such backward-compatibility mechanisms. This is 2014, not 1994 ;)

[r0lZ]

OK, I did know that. My PC us used only by me, and I store my portable apps on D:\, because I have no access right limitation. So, everything is fine in my case, but I agree that your multi-users argument is important. Thanks for the clarification.

[VideoFanatic]

I tried unzipping the exe installation file but all I got was a folder called: $PLUGINSDIR and another identical folder inside that. Then inside that folder were these files:
StdUtils.dll
x264_x64-SETUP-r754.exe

[LoRd_MuldeR]

I tried unzipping the exe installation file but all I got was a folder called: $PLUGINSDIR and another identical folder inside that. Then inside that folder were these files:
StdUtils.dll
x264_x64-SETUP-r754.exe

Keep the file "x264_x64-SETUP-r754.exe" and try unzipping that one the same way you did before ;)

[VideoFanatic]

Then I get these files but no .exe file to launch the program - checked all the folders:


$_OUTDIR
$COMMONFILES
$PLUGINSDIR
imageformats
$R0
Copying.txt
History.txt
History-x264.txt
License.txt
License-Qt4.txt
msvcp120.dll
msvcr120.dll
QtCore4.dll
QtGui4.dll
QtSvg4.dll
QtXml4.dll
ReadMe.txt

[LoRd_MuldeR]

Then I get these files but no .exe file to launch the program - checked all the folders:


$_OUTDIR
$COMMONFILES
$PLUGINSDIR
imageformats
$R0
Copying.txt
History.txt
History-x264.txt
License.txt
License-Qt4.txt
msvcp120.dll
msvcr120.dll
QtCore4.dll
QtGui4.dll
QtSvg4.dll
QtXml4.dll
ReadMe.txt


Looks like 7-Zip - or whatever tool you used to extract the installer - didn't get all the file names right.

Try renaming the file "$R0" to "x264_launcher.exe". And the "$_OUTDIR" probably is supposed to be "toolset". Not sure what $COMMONFILES refers to.

Of course there is a much easier solution: Just run the darn installer ;)

[VideoFanatic]

I was wondering what profile should I use to give the highest compression without lowering the picture quality? I'm converting 1080i 25fps TV recordings to 720p 59.94fps. The source was Main @ L4.0. At the moment Simple x264 Launcher automatically uses High @ L3.2.

[szabi]

Few month ago, I had a problem with multithread avisynth by qtgmc.
But now, I tried it again and I can say this issue is gone.
It run for 6 hours without problem.
Thanks for your job.

bye
szabi

[LoRd_MuldeR]

I was wondering what profile should I use to give the highest compression without lowering the picture quality? I'm converting 1080i 25fps TV recordings to 720p 59.94fps. The source was Main @ L4.0. At the moment Simple x264 Launcher automatically uses High @ L3.2.

Simple x264 Launcher does not set the Profile nor the Level, unless you explicitly request a specific Profile or Level.

The default behavior of x264 is to set the proper Profile and Level automatically for you, i.e. the lowest possible Profile/Level that your stream conforms to. And almost always there is no need to set the Profile or Level manually.

To make it clear again: The Profile and Level are just labels that indicate the minimum decoder capabilities that are required to play your stream. For example, a "High" Profile stream will require a decoder with support for "High" Profile.

(Enforcing an even lower Profile or Level than x264 would set by default can make sense, e.g. in case you need to hit a lower Profile/Level for compatibility reasons. Enforcing a higher Profile/Level makes no sense to me)

Few month ago, I had a problem with multithread avisynth by qtgmc.
But now, I tried it again and I can say this issue is gone.
It run for 6 hours without problem.
Thanks for your job.

Thanks, but I'm pretty sure neither the problem nor the solution was caused by Simple x264 Launcher ;)

[VideoFanatic]

Seems to be a bug. I selected High444 profile then after the encoding was finished I muxed the file and mediainfo says the profile is High@L3.2.

[LoRd_MuldeR]

As I told you before, x264 will set the proper Profile automatically. The "--profile" option is used to limit your stream to (at most) the specified Profile. In other words, if you specify "--profile X", then x264 will turn off any feature that would violate Profile X, in order to make sure you get an X Profile compliant stream. But it will not randomly turn on features to get into a higher Profile. I don't know if it is technically possible (with x264) to enforce a higher Profile than what is actually required for your stream - but it certainly wouldn't make sense to do that! It would limit the possible playback devices for absolutely no benefit! Obviously, your stream complies to the "High" Profile, so why should it be labeld as "High444" Profile? :confused:

In particular, the only relevant feature that the "High444" Profile allows, but the "High" Profile doesn't, is 4:4:4 chroma subsampling. Well, that plus predictive lossless coding. So is your input video YUV 4:4:4 at all ???

(If your input is standard YUV 4:2:0 footage and if you aren't using "lossless" mode, then it is perfectly clear why you won't get "High444" Profile)

--profile (Default: not set)

Limit the profile of the output stream. If you specify a profile, it overrides all other settings, so if you use it, you will be guaranteed a compatible stream.

If you set this option, you cannot use lossless encoding.

You should set this if you know your playback device only supports a certain profile. Most decoders support High profile, so there's no need to set this.

[SeeMoreDigital]

It's been a while since I've used 'Simple x264 Launcher'...

Can somebody please remind me where the custom 'Templates' are stored? I've made three (I think) but I can't find them!

[LoRd_MuldeR]

Can somebody please remind me where the custom 'Templates' are stored? I've made three (I think) but I can't find them!

%LOCALAPPDATA%\LoRd_MuldeR\Simple x264 Launcher\templates.ini

[Sm3n]

thx for this major update and for adding HEVC encoder.
Is that normal as soon as I select a template, the custom parameters doesn't load. (before the update it loaded always)

Also, everytime I customize my parameters and I clic outside the program, I have to navigate to the begining of the line to change the first parameter (if it's a long line), and this everytime. It's boring.

[LoRd_MuldeR]

Is that normal as soon as I select a template, the custom parameters doesn't load. (before the update it loaded always)

What exactly do you mean with "the custom parameters doesn't load"?

If you save a template, the current custom parameters should be saved in the template. Later, if you load (select) that template, the custom parameters should be restored accordingly.

Anything else would indicate a regression :eek:

Also, everytime I customize my parameters and I clic outside the program, I have to navigate to the begining of the line to change the first parameter (if it's a long line), and this everytime. It's boring.

Note quite sure what you mean. But for editing long custom parameters lines, you can right-click into the edit box and select "open the text editor". This isn't new ;)

[Sm3n]

Note quite sure what you mean. But for editing long custom parameters lines, you can right-click into the edit box and select "open the text editor". This isn't new ;)
Ah ok, I didn't know. Shame. :o
Thx for the tip.

If you save a template, the current custom parameters should be saved in the template. Later, if you load (select) that template, the custom parameters should be restored accordingly.
That's exactly what it's supposed to do, but not at all. They don't show up.
So I made a fresh install, did an encode to test but still nothing. Look at my screen:

http://i.imgur.com/36s5aH5.png

I'm running win 8.1 + new april update.

[cptthumb]

^I noticed this as well.

To reproduce do this:
Job -> Create Job
Load input, configure the template you want to save.
Hit 'Save As...' enter template name, hit OK.
All is good here.

Hit Add Job or Cancel.
Job -> Create Job
Select previously saved template.
Custom parameters are blank. Only <Recently Used> has the latest parameters.

The .ini file looks okay though. It has all the parameters stored, but will they be used? I'd feel safer that the parameters I've put in the box would be shown in it again after I load the template.

Another question:
I just encoded a video (2Pass). I wanted it to have a certain filesize. I used a bitrate which should make the video 5,6 GB.
After the first pass, in the Job Details window, it shows:
"Final file size is 5.07 GB bytes."

When the process was in its second pass, in the small box below the Job Details window, it showed that its currently encoding with 10149kb/s and est. final size is 6.45 GB..

In the end the output video was as I wanted it to be. However this is kinda confusing as I thought my encode will surely be f***** up.

http://i.imgur.com/vZ8OmTs.png

[LoRd_MuldeR]

That's exactly what it's supposed to do, but not at all. They don't show up.
So I made a fresh install, did an encode to test but still nothing.Hit Add Job or Cancel.
Job -> Create Job
Select previously saved template.
Custom parameters are blank.

Okay, I can reproduce it. Sorry, I had screwed up the template loading code. Expect a new build (http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_x64.2014-04-11.update-1.exe/download) soon.

[LoRd_MuldeR]

I just encoded a video (2Pass). I wanted it to have a certain filesize. I used a bitrate which should make the video 5,6 GB.
After the first pass, in the Job Details window, it shows:
"Final file size is 5.07 GB bytes."

The first pass runs in ABR RC mode, so it won't hit the target size as accurately as it will in the second pass, which uses 2-Pass RC mode. There's no reason to worry about this. It is perfectly normal.

When the process was in its second pass, in the small box below the Job Details window, it showed that its currently encoding with 10149kb/s and est. final size is 6.45 GB..

In the end the output video was as I wanted it to be. However this is kinda confusing as I thought my encode will surely be f***** up.

As the name implies, the "estimated" file size is... an estimate! It simply extrapolates the final size from what has been encoded so far. For example, if 10% of the encode are complete so far, we simply take the size of the file that has been written so far and multiply it by ten. If 50% of the encode are complete so far, we multiply the current file size by two. And so on. It should be obvious that the closer we get to 100%, the more accurate the estimate will become. At the beginning of the encode, the estimate unavoidably will be rather inaccurate (but still better than nothing, right?). Also you need to be aware that 2-Pass mode can result in strong bitrate fluctuations! If the movie starts with a very complex opening scene, the bitrate in the first scene will be much higher than in average. Consequently the final size will be overestimated at first. If, instead, you were to encode "2001: A Space Odyssey", then the bitrate would certainly be underestimated at first ;)

[Dion]

Okay, I can reproduce it. Sorry, I had screwed up the template loading code. Expect a new build (http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_x64.2014-04-11.update-1.exe/download) soon.

Tried the new build. Still seems to be a problem. Custom commands are never loaded.

edit: nevermind working.

[LoRd_MuldeR]

1. It's possible to add new button labeled as "SAVE" for saving modified parameters in existing template?

The new version will now offer an (editable) combobox, containing a list of all existing template names, when saving a template. So it should be more convenient to save to an existing template.

[GZZ]

Will a Load Queue / Save Queue be possible. It could save it to a ini file style output. Then it would be possible to create a queue file and quickly load 20 Episode for encoding ?

[LoRd_MuldeR]

Will a Load Queue / Save Queue be possible. It could save it to a ini file style output.

Not yet. Maybe in a future version. It's not something I could do in 5 minutes, so I cannot promise an ETA.

Then it would be possible to create a queue file and quickly load 20 Episode for encoding ?

Possible already: You can simply add a bunch of files at once via Drag&Drop.

And if you want to encode all files with the same settings, just check "Apply To All Files" and then hit "Add Job" once.

That's it ;)

[GZZ]

Possible already: You can simply add a bunch of files at once via Drag&Drop.

And if you want to encode all files with the same settings, just check "Apply To All Files" and then hit "Add Job" once.

That's it ;)

Great, I will try that. :)

[GZZ]

Maybe its out of scope for you simple encoder. But here it goes:
Is it possible that your program could tell the auto crop value for a stream. At the moment I use Handbrake to open my MKV file and see what its Top, Bottom, Left, Right Crop value is and then use it for my custom crop parameter for x264 (--vf crop:0,140,0,140)

[LoRd_MuldeR]

I don't even know what an "auto crop" value is supposed to mean...

[GZZ]

I don't even know what an "auto crop" value is supposed to mean...

I guess its out of scope then. Never mind.

[Guest]

@LoRd_MuldeR

It means an automatic crop of black borders.

[LoRd_MuldeR]

It means an automatic crop of black borders.

Well, this is a GUI front-end for x264/x265, so only features present in x264 or x265 can be exposed. x264 contains a few simple video filters. But, as far as I know, there's no "auto crop" filter. It also would be difficult to realize such filter in x264, because you probably can't (and don't want) to change the resolution during the encode. So an additional "analyze" pass would be required before the actual encoding starts. Furthermore, x265 does not support any video filters at all. After all, you will either need to setup x264's "crop" filter manually (the GUI cannot do this for you, it doesn't know anything about the video's content!) or use an Avisynth/VapourSynth based solution...

[LoRd_MuldeR]

I would like to request 2 features be added to Simple x264 Launcher:

[...]

The ability to re-order jobs currently in queue in Simple x264 Launcher. Currently if I have 3 jobs in queue and I add a 4th that I want to run ahead of those 3 I have to delete the 3 existing jobs and then re-add then. A simple Up/Down ability for the queue or a Low, Normal, High priority setting for queue management would be great.

Here is a new test version with the ability to move jobs up/down in the queue:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_x64.2014-04-20.exe/download

(Note: As a shortcut, you can use the up/down cursor keys while holding down the CTRL key)

[r0lZ]

I've just checked that version, and I've noticed a problem. The program insists to use the 64-bit version of x264 even when the "Use 64-bit Avisynth/Avs2YUV" option is off in Preferences. As a consequence, I cannot encode a script that requires a 32-bit plugin.
I don't know if the previous versions have the same problem, as usually I encode in 64-bit anyway.

[LoRd_MuldeR]

I've just checked that version, and I've noticed a problem. The program insists to use the 64-bit version of x264 even when the "Use 64-bit Avisynth/Avs2YUV" option is off in Preferences.

...because those are two completely separate things ;)

Which encoder you which to use (x264 or x265, 32-bit or 64-bit, "high bitdepth" or not) you can select in the "Add Job" dialog, indivually for each job. The option in the preferences is about Avisynth/Avs2YUV. By default, always 32-Bit Avisynth/Avs2YUV is used, regardless of what encoder you select! That can be changed to 64-Bit Avisynth/Avs2YUV in the preferences, if desired.

As a consequence, I cannot encode a script that requires a 32-bit plugin.

You can! Simple x264 Launcher was created to use 32-Bit Avisyth with 64-Bit x264. That's why we use Avs2YUV, rather then loading the AVS script into x264 directly. Just be sure you do not request 64-Bit Avisynth/Avs2YUV in the preferences, if you which to use 32-Bit plug-in's. Also be aware that changing the preferneces only effects jobs that you create subsequently.

[r0lZ]

Hum, yes, the option in the Add Job dialog is set to x264 64-bit (8 bit depth). But I suppose that when it's the case, the program uses Avs2YUV 32-bit to read the AVS script, and therefore that it should accept a script that works perfectly when launched with the 32-bit version of x264 (and without Avs2YUV). So, there is still a problem: why is it refusing to work?
Here is the log, if that can help:

Simple x264 Launcher (Build #844), built 2014-04-20

Job started at 2014-04-24, 15:44:40.

Source file : E:\video\Har.avs
Output file : E:\video\Har.264

--- SYSTEMINFO ---

Binary Path : D:\Tools\Simple x264 Launcher
Avisynth : Yes
VapourSynth : N/A

--- SETTINGS ---

Encoder : x264 (H.264/AVC), x64, 8-Bit
Source : Avisynth (avs)
RC Mode : CRF
Preset : Ultrafast
Tuning : <None>
Profile : High
Custom : --level 4.1 --keyint 96 --frame-packing 3

--- CHECK VERSION ---

Detect video encoder version:

Creating process:
"D:\Tools\Simple x264 Launcher\toolset\x64\x264_8bit_x64.exe" --version

x264 0.142.2409 d6b4e63
(libswscale 2.5.101)
(libavformat 55.34.101)
(ffmpegsource 2.17.4.0)
built by Komisar on Mar 14 2014, gcc: 4.8.2 (multilib.generic.Komisar)
configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

Detect video source version:

Creating process:
"D:\Tools\Simple x264 Launcher\toolset\x86\avs2yuv_x86.exe"

Avs2YUV 0.24bm2

> x264 revision: 2409 (core #142)
> Avs2YUV version: 0.24.2

--- GET SOURCE INFO ---

Creating process:
"D:\Tools\Simple x264 Launcher\toolset\x86\avs2yuv_x86.exe" -frames 1 E:\SPACEP~1.DTS\spacep~1.avs NUL

Find sync word: 7ffe8001
Find sync extension: 3f
Frame #1: Core: 1004 words unpacked
Decoded audio will be stored in the following files:
file_L_R.wav for front left channel and front right channel
file_C_LFE1.wav for center channel and LFE channel
file_Ls_Rs.wav for srrd left channel and srrd right channel
Frame #2: Core: 1004 words unpacked
E:\SPACEP~1.DTS\spacep~1.avs: 1920x1080, 5000000/208541 fps, 165830 frames
converting input clip to YV12

Resolution: 1920x1080
Frame Rate: 5000000/208541
No. Frames: 165830

--- ENCODING VIDEO ---

Creating input process:
"D:\Tools\Simple x264 Launcher\toolset\x86\avs2yuv_x86.exe" E:\SPACEP~1.DTS\spacep~1.avs -

Creating encoder process:
"D:\Tools\Simple x264 Launcher\toolset\x64\x264_8bit_x64.exe" --crf 22.0 --preset ultrafast --profile high --level 4.1 --keyint 96 --frame-packing 3 --output "E:\video\Har.264" --frames 165830 --demuxer y4m --stdin y4m -

x264 [error]: could not open input file `-'
av2y [info]: E:\video\Har.avs: 1920x1080, 5000000/208541 fps, 165830 frames
av2y [info]: converting input clip to YV12
av2y [info]: error: wrote only 3085668 of 3110400 bytes

WARNING: Input process exited with error (code: 1), your encode might be *incomplete* !!!

FATAL ERROR: The encoder process has *crashed* -> your encode probably is *incomplete* !!!
Note that this indicates a bug in the current encoder, *not* in Simple x264/x265 Launcher.

PROCESS EXITED WITH ERROR CODE: -1

I have encoded the same file directly with x264 (32-bit) from the command line without problem. (The only plugin I use in that script is VSFilter 32-bit, and it has never failed.)
IMO, when the option to use the 64-bit Avisynth is not ticked, there should be no problem, regardless of the version of x264 selected in the New Job window (since x264 does not "see" the AVS script directly).
Obviously, avs2yuv_x86.exe has some kind of bug and crashes when x254_x86 works without problem.

[LoRd_MuldeR]

Obvisouly, x264 was not able to process the output of Avs2YUV:
x264 [error]: could not open input file `-'

That is kind of strange, because Avs2YUV seems to have opened the input AVS script correctly.

So what happens if you try this from the console:
"D:\Tools\Simple x264 Launcher\toolset\x86\avs2yuv_x86.exe" E:\SPACEP~1.DTS\spacep~1.avs - > "C:\Temp\test.y4m"
:confused:

Also, what happens if you put a simple ChangeFPS(24.0) at then of your script?

[r0lZ]

I have interrupted the process, because I don't have much disc space to waste, but it seems to work.

spacep~1.avs: 1920x1080, 5000000/208541 fps, 165830 frames
converting input clip to YV12
^C

[LoRd_MuldeR]

I have interrupted the process, because I don't have much disc space to waste, but it seems to work.

Add "-frames 100" to limit file size. Once it is done, open the resulting Y4M file in your favority HEX editor and check whether it is valid.

See here:
http://wiki.multimedia.cx/index.php?title=YUV4MPEG2


Then, if the file seems valid, try this from the console:
"D:\Tools\Simple x264 Launcher\toolset\x64\x264_8bit_x64.exe" --crf 22.0 --preset ultrafast --profile high --level 4.1 --keyint 96 --frame-packing 3 --output "E:\video\Har.264" --frames 100 --demuxer y4m --stdin y4m - < C:\temp\test.y4m

[r0lZ]

Hum, the header of the y4m file seems strange to me, but according to the file format description, it is probably legal.
ASCII dump of the first bytes:

Find sync word: 7ffe8001
Find sync extension: 3f
Frame #1: Core: 1004 words unpacked
YUV4MPEG2 W1920 H1080 F5000000:208541 Ip A0:0 C420mpeg2
FRAME
[followed by binary data...]

When launching the x264 command using that file, I still get the x264 [error]: could not open input file `-'

May be a problem with my PC right now. I will try again after a reboot, but currently, I'm still encoding and I can't shut the machine down...

[LoRd_MuldeR]

Looks valid too me. No idea, why x264 wouldn't eat that file :confused:

Does it play properly in VLC or MPlayer? If so, I'd suspect a bug in x264 or some x264 build issue...

[LoRd_MuldeR]

Wait a moment!

Are those additional lines like "Find sync extension: 3f" also stored in the Y4M file ??? :eek:

[r0lZ]

Yes! It's why that file looks strange. But according to to the file format, that may be legal:

A Y4M file begins with a plaintext, quasi-freeform header.

But immediately after, I see:

The first 10 bytes are a file signature of 'YUV4MPEG2 '
I'm not sure how to interpret that sentence. Is the file supposed to BEGIN with YUV4MPEG2, ir is it an ID that must FOLLOW the freeform header?

[LoRd_MuldeR]

So the case is clear:

You have some horrible broken Avisynth plug-in in your chain, which writes Debug outputs to the STDOUT stream. And, of course, that will corrupt the image data that Avs2YUV itself writes to the STDOUT stream (for passing it on to x264). x264 is perferctly right to reject that. Yet another proof that all diagnostic output always should go to the STDERR stream, not STDOUT! And that it should be optional.

http://www.smiliesuche.de/smileys/kopf-gegen-wand/kopf-gegen-wand-smilies-0002.gif


(BTW: While Y4M starts with a "plain text" header, this header still needs to contain to correct information, not some unrelated garbage. In particular, "YUV4MEPG2" must be the very first data in the file!)

[r0lZ]

OK, I understand. It's strange as I have used that VSFilter plugin several times previously without problem. But I don't remember if I have encoded that script with your GUI, or from the command line with x264 alone. And I may have used another version of the plugin.

Anyway, thanks for your diagnostic, and sorry for having squatted your thread with a problem that is not related to your (excellent) work.

[LoRd_MuldeR]

OK, I understand. It's strange as I have used that VSFilter plugin several times previously without problem. But I don't remember if I have encoded that script with your GUI, or from the command line with x264 alone. And I may have used another version of the plugin.

The problem is, that the Debug outputs will be "mixed" into the image data in an arbitary way. If you are lucky, those Debug outputs will corrupt the Y4M header and the encoder will abort right away. If you are not so lucky, it won't corrupt the header. Then you will get random image corruptions in your encode, because the encoder has no way to destinguish the Debug outputs from "legitimate" image data...

[r0lZ]

Yes, that's right. I've never noticed any problem, but you're right. The error messages must always be written to stderr (or a log file). Since with the current example, I have no problem to see if the plugin writes to stdout, I will try to find a better version of the VSFilter plugin.
Thanks again.

[r0lZ]

Damn! I have commented out the LoadPlugin and the VobSub commands, just to verify if everything is OK, and I still have exactly the same problem!
I suppose that the debug message are sent to stdout by some DirectShow filter necessary to open my MKV file. It's much more complex to locate, but I will try.
For your information, here is my AVS script:

#LoadPlugin("D:\Tools\Avisynth_plugins\VSFilterMOD.dll")
DirectShowSource("Space.mkv")
Crop(0, 60, -0, -0)
AddBorders(0,0,0,60)
#VobSub("French.idx")
intro=BlankClip(last, 120)
return(intro+last+intro)

As you can see, it doesn't use fancy plugins any more. But it is difficult to control what's happening behind DirectShowSource().

[EDIT] New test with the DirectShowSource() command ONLY. Same problem. That confirms that DirectShow is a mess! ;-)

[LoRd_MuldeR]

Try FFVideoSource() instead of DirectShowSource().

[r0lZ]

FFVideoSource() works fine. Thanks. :-)

[LoRd_MuldeR]

Updated x264 and x265 binaries to the latest revisions.

[AYColumbia]

Hey, just FYI, it looks like the Python link is no longer valid, i.e., https://www.python.org/getit/. This is the link that is on the dialog that comes up after installation. The general download page for Python looks like is this: https://www.python.org/downloads/

[LoRd_MuldeR]

Hey, just FYI, it looks like the Python link is no longer valid, i.e., https://www.python.org/getit/. This is the link that is on the dialog that comes up after installation. The general download page for Python looks like is this: https://www.python.org/downloads/

Thanks for pointing that out!

Fixed now:
https://www.assembla.com/code/simple-x264-x265-launcher/git/commit/061009a171cb765626f918fcf5b349edef4169e5

[RTW47]

Hello, I still have detection problem with 64-bit VapourSynth r23 installation.
looks like GUI first checks /core32 directory for vspipe.exe and vapoursynth.dll, after that, however, looks inside /core directory. (which does not exist anyway) ..instead of /core64?
#edit:. log (http://pastebin.com/YKwVic0y)

[LoRd_MuldeR]

Currently only 32-Bit VapourSynth is supported.

So the program will first look into "core32" folder and then, if not found yet, revert to the "core" folder (for backwards compatibility with older VapourSynth).

[RTW47]

Got it. Thank you Lord, for such quick response (:

[LoRd_MuldeR]

I still have detection problem with 64-bit VapourSynth r23 installation.
Got it. Thank you Lord, for such quick response (:

You can try with this TEST version:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2014-05-04.exe/download

[VincAlastor]

i've tried to exchange the x265_64_8bit.exe to a more actually build (1.0+5). but the version check fails. how can i skip the version determining in simple x265 launcher to use nightly builds?

[RTW47]

#edit:. as expected v2.38.860 now additionally checks for /core64 directory for required files, yet after that fails to load/detect vsscript library from system32;

[Check for VapourSynth support]
VapourSynth thread has been created, please wait...
VapourSynth Dir: C:/Program Files (x86)/VapourSynth
VapourSynth EXE: C:/Program Files (x86)/VapourSynth/core32/vspipe.exe
VapourSynth DLL: C:/Program Files (x86)/VapourSynth/core32/vapoursynth.dll
VapourSynth EXE: C:/Program Files (x86)/VapourSynth/core64/vspipe.exe
VapourSynth DLL: C:/Program Files (x86)/VapourSynth/core64/vapoursynth.dll
Failed to load VSSCRIPT.DLL !!!
VapourSynth thread finished.
VapourSynth thread failed to detect installation!

[LoRd_MuldeR]

i've tried to exchange the x265_64_8bit.exe to a more actually build (1.0+5). but the version check fails. how can i skip the version determining in simple x265 launcher to use nightly builds?

Please :logfile:

#edit:. as expected v2.38.860 now additionally checks for /core64 directory for required files, yet after that fails to load/detect vsscript library from system32;

[Check for VapourSynth support]
VapourSynth thread has been created, please wait...
VapourSynth Dir: C:/Program Files (x86)/VapourSynth
VapourSynth EXE: C:/Program Files (x86)/VapourSynth/core32/vspipe.exe
VapourSynth DLL: C:/Program Files (x86)/VapourSynth/core32/vapoursynth.dll
VapourSynth EXE: C:/Program Files (x86)/VapourSynth/core64/vspipe.exe
VapourSynth DLL: C:/Program Files (x86)/VapourSynth/core64/vapoursynth.dll
Failed to load VSSCRIPT.DLL !!!
VapourSynth thread finished.
VapourSynth thread failed to detect installation!

Yeah, that's not very surprising. If you only have a 64-Bit binary of VSSCRIPT.DLL installed, the application cannot load it.

That's because loading 64-Bit libraries into 32-Bit processes, or vice versa, is not possible. I guess we'll need a completely different solution then.

And that probably means we just run the "vspipe.exe" and see if it works correctly...

[LoRd_MuldeR]

Here is a new TEST version with improved VapourSynth detection could that now should be able to deal with the 64-Bit version too:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2014-05-05.exe/download

[LoRd_MuldeR]

i've tried to exchange the x265_64_8bit.exe to a more actually build (1.0+5). but the version check fails. how can i skip the version determining in simple x265 launcher to use nightly builds?

Okay, I have now been able to reproduce the issue. This HOTFIX should fix the detection of x265 v1.0 and later:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2014-05-05.Hotfix-3.zip/download

[VincAlastor]

Please :logfile:

sorry, here is the log file:

Simple x264 Launcher (Build #856), built 2014-05-01

Job started at 2014-05-05, 19:04:55.

Source file : G:\hd_other_fox_blu_ray_trailer_the_future_is_blu_1\hd_other_fox_blu_ray_trailer_the_future_is_blu_1.avs
Output file : G:\hd_other_fox_blu_ray_trailer_the_future_is_blu_1\hd_other_fox_blu_ray_trailer_the_future_is_blu_1 (4).hevc

--- SYSTEMINFO ---

Binary Path : C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2
Avisynth : Yes
VapourSynth : N/A

--- SETTINGS ---

Encoder : x265 (H.265/HEVC), x64, 8-Bit
Source : Avisynth (avs)
RC Mode : ABR
Preset : Fast
Tuning : <None>
Profile : <Unrestricted>
Custom : (None)

--- CHECK VERSION ---

Detect video encoder version:

Creating process:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x64\x265_8bit_x64.exe" --version

x265 [info]: HEVC encoder version 1.0+5-dcf74ea39e31
x265 [info]: build info [Windows][GCC 4.6.3][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX

FAILED TO DETERMINE VERSION INFO !!!

[VincAlastor]

Okay, I have now been able to reproduce the issue. This HOTFIX should fix the detection of x265 v1.0 and later:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2014-05-05.Hotfix-3.zip/download

ahhh ok, thank you very much. finally im at home, i can't post you the log file earlier... anyway thanks a lot!

[RTW47]

Here is a new TEST version with improved VapourSynth detection could that now should be able to deal with the 64-Bit version too:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2014-05-05.exe/download Grateful for the support; I will proceed using test [Build#864] for now.
as I can't work with vspipe efficiently.

[LoRd_MuldeR]

can't work with vspipe efficiently

Not sure what you mean :confused:

[EncodedMango]

Just informing that I noticed a typo in one of the buttons. Says "Ingnore" instead of "Ignore"
http://i.minus.com/ibhTSyGQXfj64S.PNG

[LoRd_MuldeR]

Thanks for reporting. Fixed:
http://repo.or.cz/w/simple-x264-launcher.git/commitdiff/0c4c96da502ae9c6af288850e2544481eeb9ad1c?hp=834905abf9c70bd51f4a53c8c11cdcc702feb515

[LoRd_MuldeR]

v2.39 updates x265 to the latest revision and contains some bugfixes.

[r0lZ]

Currently, I re-encode some MPEG files with Simple x264 Launcher. I use an Avisynth script that uses the FFMpegSource2 command to read the original MPEG file. The first time it is called, FFMpegSource2 needs to create an index file. This is a very long process, and unless I manage to create the index in advance, Simple x264 Launcher fails with this message:

Warning: Input process did not respond for 60 seconds, potential deadlock...
PROCESS TIMEOUT !!!
Input process has encountered a deadlock or your script takes EXTREMELY long to initialize!

I understand that that message can be useful, but in my case, it comes too early, and is not useful at all, since I know why the script takes a long time to start. And, of course, the fact that the encoding is aborted is very annoying.

So, I suggest, if it's possible, to add a dialog box asking if the encoding should be aborted, or if the program should wait some time again. The problem is that the dialog box should assume "abort" if the user has not replied after some time, because otherwise it may stop a long batch list of encodings to do during the night. So, if that "auto-closing" dialog cannot be made easily, I suggest to add an option to turn off the timeout check, or to select a much longer timeout.

Anyway, currently, the program doesn't work with perfectly good scripts, and a solution is necessary. Thanks in advance for considering it.

[LoRd_MuldeR]

Currently, I re-encode some MPEG files with Simple x264 Launcher. I use an Avisynth script that uses the FFMpegSource2 command to read the original MPEG file. The first time it is called, FFMpegSource2 needs to create an index file. This is a very long process, and unless I manage to create the index in advance, Simple x264 Launcher fails with this message:

I understand that that message can be useful, but in my case, it comes too early, and is not useful at all, since I know why the script takes a long time to start. And, of course, the fact that the encoding is aborted is very annoying.

So, I suggest, if it's possible, to add a dialog box asking if the encoding should be aborted, or if the program should wait some time again. The problem is that the dialog box should assume "abort" if the user has not replied after some time, because otherwise it may stop a long batch list of encodings to do during the night. So, if that "auto-closing" dialog cannot be made easily, I suggest to add an option to turn off the timeout check, or to select a much longer timeout.

Anyway, currently, the program doesn't work with perfectly good scripts, and a solution is necessary. Thanks in advance for considering it.

The "deadlock detection" timeout currently is 5 minutes. I think if your Avisynth script takes longer than 5 minutes to initialize, you really should consider using ffmsindex to index your file beforehand.

Anyway, there already is an option to turn off the "deadlock detection" completely, for when you cannot "fix" your input script. See the README file for details please!

Using "popup" dialog boxes is not really a feasible option here, because Simple x264 Launcher is designed to run multiple jobs in parallel, so the dialog boxes could interfere with each other...

[r0lZ]

OK, I've found the --no-deadlock-detection CLI option. Thanks.

[kypec]

Is there any way to support old templates that were created with earlier versions (pre-x265 enabled builds) and lack the following parameters?
encoder_type=0
encoder_arch=1
encoder_variant=0

The above parameters x264, x64, 8-Bit could be made as "assumed defaults" in case they're missing from template definition. As it is now, new builds ignore such templates completely thus not listing them in drop-down box at all.

Just a thought to make user's life easier, thanks.

[LoRd_MuldeR]

The above parameters x264, x64, 8-Bit could be made as "assumed defaults" in case they're missing from template definition.

Okay, I will consider adding backwards-compatibility for old templates.

[LoRd_MuldeR]

Version 2.40 is available. Includes updated x265 v1.1 binaries (details (https://forum.doom9.org/showpost.php?p=1682837&postcount=868)).

[zallen]

Version 2.40.878. H265-encoder not usable. With input any sourse such as raw: h264_1920x1080_50fps.yuv error falls:

http://savepic.ru/5138155.jpg (http://savepic.ru/5137131.jpg)

[LoRd_MuldeR]

raw: h264_1920x1080_50fps.yuv error falls:

http://savepic.ru/5155563.jpg (http://savepic.ru/5166827.jpg)

That's because it's impossible to know (or detect) the width, height and FPS of "raw" YUV data!

As the error message says, when using "raw" YUV, you need to specify the required info manually (using "--input-res" and "--fps"). Either that or just use YUV4MPEG (.y4m) instead.

And of course it has always been that way ;)

[zallen]

It's clear. But in standard containers mp4 and mkv does not accept:

http://savepic.ru/5138150.jpg (http://savepic.ru/5137126.jpg) http://savepic.ru/5144294.jpg (http://savepic.ru/5143270.jpg)

Note that Simple launcher for AVС1 / H.264 fulfills perfectly.

[LoRd_MuldeR]

It's clear. But in standard containers mp4 and mkv does not accept:

http://savepic.ru/5138150.jpg (http://savepic.ru/5137126.jpg) http://savepic.ru/5144294.jpg (http://savepic.ru/5143270.jpg)

x265 does not support MP4 or MKV input yet. Who said it does? I think the error message is quite clear on this :rolleyes:

Actually, at this point, x265 accepts nothing but uncompressed YUV data as input. Either as "raw" data (.yuv) or, preferably, as MPEG4YUV file (.y4m).

If you want to feed x265 with a compressed MKV or MP4 or AVI (or whatever) file, simply use Avisynth (http://avisynth.nl/index.php/Main_Page#New_to_AviSynth_-_start_here) or Vapoursynth (http://www.vapoursynth.com/doc/gettingstarted.html) input!

Note that Simple launcher for AVС1 / H.264 fulfills perfectly.

...because x264 and x265 are two different applications ;)

Yes, x265 has adopted some code and algorithms from x264. Also the (basic) command-line options of x265 are consistent with x264. But still, they are two completely separate applications.

Most important, the x264 command-line encoder has a "built-in" FFmpegSource/Libavformat decoder for quite some time now. x265 has nothing like that at the moment!

(You may wish to file a feature request (https://bitbucket.org/multicoreware/x265/issues) and send it to x265 developers)

[zallen]

Thanks. Now it is a little understood.

[Anacletus]

Hi LoRd_MuldeR,

maybe i'm missing something or just doing something wrong myself, but when i check the option "Automatically save output to log file when a job is finished" i expect to find a log file somewhere.

Fact is i cannot find any. Would you like to explain me what am i doing wrong?

[GZZ]

Try look here: c:\Users\<User Name>\AppData\Local\LoRd_MuldeR\Simple x264 Launcher\
A possibility to save it in the same folder as the output would be great.

[Anacletus]

Try look here: c:\Users\<User Name>\AppData\Local\LoRd_MuldeR\Simple x264 Launcher\
GZZ, found the log right there! :thanks:
A possibility to save it in the same folder as the output would be great.
I second this request, that would be handy :cool:

[docholliday]

Hi,

It would be better to add finally file size in 2pass.When we add bitrate we don't know how much size will get finally.

[VideoFanatic]

Hi, I was wondering if it's possible to use x264 to deblock and what setting would I use to do that? For example could I use x264 to deblock a source that has minor blocking? Or if the blocking only happened after using x264 to encode to a lower bitrate then would the x264 deblocker still work?

[LoRd_MuldeR]

Hi, I was wondering if it's possible to use x264 to deblock and what setting would I use to do that? For example could I use x264 to deblock a source that has minor blocking? Or if the blocking only happened after using x264 to encode to a lower bitrate then would the x264 deblocker still work?

Nope, you can't. The H.264 In-Loop Deblocking filter is for "suppressing" block artifacts introduced by the H.264 compression, not for removing block artifacts already present in the source.

Keep in mind that, for the encoder, it's not possible to know what is a "desirable detail" or what is an "unwanted artifact". The encoder simply tries to resemble the source image as closely as possible. So, if the source contains block artifacts, the encoder actually considers those to be part of the original image and will try to retain them. I think any "deblocking" effect would be purely coincidentally.

Well, I guess a combination of high quantizer (low quality) plus strong In-Loop Deblocking plus disabling the Psy optimizations will tend to smooth out block artifacts. But only because it will smooth out pretty much any detail in the image ;)

Instead you should apply a proper deblocking filter on your source prior to encoding...

[VideoFanatic]

OK thanks. I normally use the CPU=6 of DGIndex to deblock MPEG2 standard definition VHS-to-DVD conversions. However DGDecodeNV must be used to index HD videos and that doesn't have a deblocker function as the author said there was no need for it in HD footage! I have HDTV videos copied directly from my satellite box. I've noticed that some soaps have minor pixellation on the background walls in indoor scenes on gradients. The bitrate of the source is 9 Mbps which gives a good picture quality on soaps apart from the occasional pixellation issue I mentioned. Should I be using a deblocker to fix that as the blocking only happens in gradients?

I looked into using an Avisynth deblocker such as DeBlock or DeBlock QED with 1080i TV footage but I couldn't get them working correctly. I actually tested them on a standard definition MPEG2 VHS-to-DVD overly compressed video - same video I used to test CPU=6. CPU=6 deblocked perfectly. However DeBlock and DeBlock QED could not handle camera flashes very well from the audience in the wrestling match and I got weird artifacts.

I've asked repeatedly on VideoHelp.com and I've had some answers but I still can't get the deblockers working correctly. I ask on Doom9 but nobody ever answers me - I find that on Doom9 nobody wants to help with basic issues like that but if you've got a technical question then you get loads of help!

Any idea what the correct code is to get a deblocker to work correctly with interlaced standard definition/HD footage?

[LoRd_MuldeR]

OK thanks. I normally use the CPU=6 of DGIndex to deblock MPEG2 standard definition VHS-to-DVD conversions. However DGDecodeNV must be used to index HD videos and that doesn't have a deblocker function as the author said there was no need for it in HD footage! I have HDTV videos copied directly from my satellite box. I've noticed that some soaps have minor pixellation on the background walls in indoor scenes on gradients. The bitrate of the source is 9 Mbps which gives a good picture quality on soaps apart from the occasional pixellation issue I mentioned. Should I be using a deblocker to fix that as the blocking only happens in gradients?

While DGDecodeNV doesn't have a separate "deblock" post-processing filter, good old DGDecode has BlindPP() and Deblock() as stand-alone filters that you can apply on any source.

Also, if you see "banding" artifacts in gradients, you should probably try a "debanding" filter instead of a "deblocking" filter, such as GradFun2DB() or GradFun2DBmod(). Preferably in combination with the 10-Bit variant of x264 ;)

[Guest]

I normally use the CPU=6 of DGIndex to deblock MPEG2 standard definition VHS-to-DVD conversions. However DGDecodeNV must be used to index HD videos and that doesn't have a deblocker function as the author said there was no need for it in HD footage! I never said that. The reason there is no similar deblocker is because when using CUVID there is no access to the quants. Also, DGIndex can open HD MPEG2 video.

I've asked repeatedly on VideoHelp.com and I've had some answers but I still can't get the deblockers working correctly. I ask on Doom9 but nobody ever answers me - I find that on Doom9 nobody wants to help with basic issues like that but if you've got a technical question then you get loads of help!

Any idea what the correct code is to get a deblocker to work correctly with interlaced standard definition/HD footage? Provide a specific source sample for us to work with, and then you may find people will help you. It's best to start a new thread in Avisynth Usage as it's getting OT for this one.

EDIT: LoRd_MuldeR is spot on in suggesting you have banding rather than blocking, which would explain why deblockers aren't working for you. This is why you should always provide a source sample.

[VideoFanatic]

I was wondering if you would ever consider adding automated DGIndex file creation and automated muxing to .ts after the encoding has completed (the audio would be muxed instead of re-encoded). So basically I can drag a TS file into Simple x264 Launcher and enter an Avisynth script to use then the program will give me back a TS encoded file. Basically like what MeGUI does but without all the other features that MeGUI has.

I love Simple x264 Launcher but it's quite time consuming to have to create an index file, Avisynth avs file then mux everything back together again when I've got several files to encode every day. By having the program do everything, I can save a couple of hours, I just get up in the morning and my files are already muxed back to TS!

[LoRd_MuldeR]

I was wondering if you would ever consider adding automated DGIndex file creation and automated muxing to .ts after the encoding has completed

Sorry, I currently have no such plans.

[VideoFanatic]

Is there a way to have the profiles kept in the portable location of the program instead of here?: C:\Users\Dave\AppData\Local\LoRd_MuldeR\Simple x264 Launcher

[LoRd_MuldeR]

Is there a way to have the profiles kept in the portable location of the program instead of here?: C:\Users\Dave\AppData\Local\LoRd_MuldeR\Simple x264 Launcher

Did you note there's that file README in the program directory? :devil:

[Emulgator]

Many thanks again, oh Lord ;-)

A hint to those who may want to re-use their beloved x264 templates within the extended Launcher

(assumption: x264 x86 8bpc):
After title insert

encoder_type=0
encoder_arch=0
encoder_variant=0

P.S. Never mind, I was late, kypec mentioned something related one page before...

BTW, Lord Mulder, may I talk you into adding x262 as well ?
A small step for a man, a huge leap for mankind...

[detmek]

Hi LM. Any chance we get 2-pass support for x265 encoder in Simple x264 Launcher? Current x265 builds have, I think, working 2-pass encoding mode.

[LoRd_MuldeR]

A hint to those who may want to re-use their beloved x264 templates within the extended Launcher

(assumption: x264 x86 8bpc):
After title insert

encoder_type=0
encoder_arch=0
encoder_variant=0

Yeah, I'm going to add some compatibility code for "old" presets in the next version.

BTW, Lord Mulder, may I talk you into adding x262 as well ?
A small step for a man, a huge leap for mankind...

I currently have no plans for that.

Correct me if I'm wrong: x262 is "working", but still far from being on par with state-of-the-art MPEG-2 encoders. Also development seems to go very slow, if at all.

If anybody really uses x262 for MPEG-2 encodes on a regular basis (not just for a few tests now and then!), I may consider adding it...

Hi LM. Any chance we get 2-pass support for x265 encoder in Simple x264 Launcher? Current x265 builds have, I think, working 2-pass encoding mode.

It's on my TODO list. But before that, I need to get latest x265 to work at all ;)

The latest "milestone" release (v1.2) compiles fine, but is lacking any sign of 2-Pass support. And the latest version from "main" branch doesn't currently compile.

See here:
https://forum.doom9.org/showpost.php?p=1689849&postcount=1152

[LoRd_MuldeR]

Okay, here is a new experimental version of Simple x264 Launcher for you to test:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/

Some noteworthy changes:
Updated x264 and x265 to the latest versions (x265 is a few revisions behind HEAD, because the very latest revision won't compile!)
Added 2-Pass encoding support for x265
Added support for VapourSynth r24 (minimum required version is now also r24, because r24 changed the interface in a non-backward-compatible way)
Templates saved in an "old" program version should now work in the "new" program version without manual modifications

[detmek]

Thanks LM. I just tried it on short clip and it seams to work. I will do more test later.

[LoRd_MuldeR]

Simple x264/x265 Launcher v2.41

Release Highlights:
Updated x264 and x265 encoders to the latest versions
Enabled 2-Pass encoding support for x265 encoder
Added support for VapourSynth r24 (minimum required version is r24 now!)
Better support for templates saved in program "old" versions

[wiak]

hey just a quick and dirty question, can you add libopenshot support in the mix when its more mature in the future??
https://launchpad.net/libopenshot

its basicly alot like avisynth but newer, its part of the openshot 2.0 project over at
http://www.openshotvideo.com
https://www.kickstarter.com/projects/421164014/openshot-video-editor-for-windows-mac-and-linux

[LoRd_MuldeR]

hey just a quick and dirty question, can you add libopenshot support in the mix when its more mature in the future??
https://launchpad.net/libopenshot

its basicly alot like avisynth but newer, its part of the openshot 2.0 project over at
http://www.openshotvideo.com
https://www.kickstarter.com/projects/421164014/openshot-video-editor-for-windows-mac-and-linux

Haven't heard about libopenshot :confused:

Anyway, does "libopenshot" offer a command-line tool that, similar to Avs2YUV and VSPipe, takes a script file as input and writes the video data, preferably as YUV4MPEG, to the stdout?

If so, I may consider adding it in a future versions. Otherwise, no chance. Your request would have to go to the x264/x265 developers...

[wiak]

Haven't heard about libopenshot :confused:

Anyway, does "libopenshot" offer a command-line tool that, similar to Avs2YUV and VSPipe, takes a script file as input and writes the video data, as YUV4MPEG, to the stdout?

If so, I may consider adding it in a future versions. Otherwise, no chance. Your request would have to go to the x264/x265 developers...
i have to check with the dev
as far as i know it uses ffmpeg to read files and encode files. it is in heavy development at this moment so i might get him to implement a av2you and/or vspipe-ish solution :)

FYI libopenshot is a commandline tool lol, its the backend for openshot 2.0 :P

[LoRd_MuldeR]

Without having looked further into this topic, the project's own description clearly says that it's a library, just like the name suggests:
libopenshot is an open-source, cross-platform C++ library dedicated to delivering high quality video editing, animation, and playback solutions to the world. This is the same library which powers OpenShot Video Editor (version 2.0+) and it could power your next video editing application! C++, Python, and Ruby are fully supported, and other languages can be added if requested.

So it seems this library can be incorporated into video editing application. Maybe it could be incorporated into a video encoder like x264 or x265 too, but that's not my job ;)

(Note: At this point x265 doesn't even support Avisynth input natively!)

[LoRd_MuldeR]

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

Release Highlights:
Various installer fixes and improvements

[SeeMoreDigital]

Hi LoRd_MuldeR,

I've just tried upgrading via the applications 'Check for new updates' link and got this: -

http://i60.tinypic.com/2s7te1v.png


Cheers

[LoRd_MuldeR]

Hi LoRd_MuldeR,

I've just tried upgrading via the applications 'Check for new updates' link and got this: -

Cheers

Sorry, somehow the upload got stuck, leading to an incomplete file on the update mirror.

And of course the digital signature didn't match on that incomplete file! I have resumed the upload, so this should be fixed now.

Please try again...

[davidtuning]

Hi I have a problem with the program, I Update to the latest versión and i get this error
http://puu.sh/aVbNb/e14d007c15.jpg

but I have both programs installed it's latest versión: VapourSynth R24, Python 3.4.1 help.

[RTW47]

Chances vs was not installed correctly, you can try running x264_launcher.exe via --console switch and then inspect/post log section responsible for vapoursynth support.
personally don't have any vs detection problems using v2.4.1 and after updating to v2.4.2 with everything 64-bit.
---
by the way, pressing ?\x264 Online Documentation link leads to 'This page can’t be displayed' message inside IE. (and also ?\About...\x264 Encoder\user's manual)
seems like http://mewiki.project357.com/wiki/X264_Settings - no longer available?..

[LoRd_MuldeR]

Hi I have a problem with the program, I Update to the latest versión and i get this error
http://puu.sh/aVbNb/e14d007c15.jpg

but I have both programs installed it's latest versión: VapourSynth R24, Python 3.4.1 help.

According to your screenshot, you are obvisouly using an old version of Simple x264 Launcher!

Support for VapourSynth r24 requires Simple x264 Launcher v2.41 or newer, because VapourSynth r24 has changed the interface in way that is not compatible to previous VapourSynth versions.

If you still have problems with VapourSynth r24 using the latest Simple x264 Launcher version, do what RTW47 has suggested...


by the way, pressing ?\x264 Online Documentation link leads to 'This page can’t be displayed' message inside IE. (and also ?\About...\x264 Encoder\user's manual)
seems like http://mewiki.project357.com/wiki/X264_Settings - no longer available?..

Indeed, the site appears to be down at the moment. If it turns out that the site is gone prermanently, I will change the link...

[r0lZ]

The "X264 Settings" site is working for me.

[hackjack]

i am always getting error on simple x264 when trying to encode x265 video. the file not supported or job failed.please see the image below.

[LoRd_MuldeR]

The "X264 Settings" site is working for me.

It still appears down for me this morning :confused:

(have you tried clearing your browser cache?)

i am always getting error on simple x264 when trying to encode x265 video. the file not supported or job failed.please see the image below.

No double posting please!
https://forum.doom9.org/showthread.php?p=1690176#post1690176

:readrule:

[r0lZ]

Yes, I've just tried again, after having double-checked that the cache was empty, and I can still open the site. However, this (http://www.downforeveryoneorjustme.com/http://mewiki.project357.com/wiki/X264_Settings) indicates that you are not alone having the problem. I suspect a DNS problem, so I've tried to enter the IP directly (69.164.203.52 according to this site (https://www.site24x7.com/find-ip-address-of-web-site.html)) and this time, I can't connect. I don't understand, but anyway the site is down or something else is broken.

[SeeMoreDigital]

Sorry, somehow the upload got stuck, leading to an incomplete file on the update mirror.

And of course the digital signature didn't match on that incomplete file! I have resumed the upload, so this should be fixed now.

Please try again...Thanks... The download update is working fine now ;)

[LoRd_MuldeR]

Yes, I've just tried again, after having double-checked that the cache was empty, and I can still open the site. However, this (http://www.downforeveryoneorjustme.com/http://mewiki.project357.com/wiki/X264_Settings) indicates that you are not alone having the problem. I suspect a DNS problem, so I've tried to enter the IP directly (69.164.203.52 according to this site (https://www.site24x7.com/find-ip-address-of-web-site.html)) and this time, I can't connect. I don't understand, but anyway the site is down or something else is broken.

For me, mewiki.project357.com also resolves to 69.164.203.52. That server responds to ping, but currently won't accept HTTP connections:
>ping mewiki.project357.com

Pinging bravo.bluebottle.net.au [69.164.203.52] with 32 bytes of data:
Reply from 69.164.203.52: bytes=32 time=170ms TTL=51
Reply from 69.164.203.52: bytes=32 time=170ms TTL=51
Reply from 69.164.203.52: bytes=32 time=168ms TTL=51
Reply from 69.164.203.52: bytes=32 time=178ms TTL=51

Ping statistics for 69.164.203.52:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 168ms, Maximum = 178ms, Average = 171ms


>wget http://mewiki.project357.com/
--2014-08-17 16:14:00-- http://mewiki.project357.com/
Resolving mewiki.project357.com... 69.164.203.52
Connecting to mewiki.project357.com|69.164.203.52|:80... failed: Bad file descriptor.

>wget http://69.164.203.52/
--2014-08-17 16:14:30-- http://69.164.203.52/
Connecting to 69.164.203.52:80... failed: Bad file descriptor.

Could be a DNS issue, indeed. Let's wait a few days and probably the problem will be resolved. Otherwise I'll change to a different site for x264 help ;)

In the meantime, the Internet Archive has a recent backup of that site available:
https://web.archive.org/web/20140627075103/http://mewiki.project357.com/wiki/X264_Settings

[Evil_Burrito]

Thank you LoRd_MuldeR for the regular updates. I use Simple x264 or LameXP almost every day.

There are two small things that have always annoyed me (they aren't "bugs" exactly). 1. Auto open installation directory window after install has completed and 2. Automatically pinning shortcuts to the taskbar after install/update.

[LoRd_MuldeR]

1. Auto open installation directory window after install has completed

Well, shouldn't be a big deal to just close the Explorer window, if you don't need it ;)

(Honestly, how often do you re-install or update the Simple x264 Launcher? Not more often then once in a few weeks/months, I suppose)

2. Automatically pinning shortcuts to the taskbar after install/update.

Pretty much the same applies here. Still I may consider making this one optional, if it helps...

[Evil_Burrito]

Honestly? Every time there is an update :p.

:thanks:

[VideoFanatic]

Hi, I would like to be able to do the following with Simple x264 Launcher:

Select a folder of files to encode and select an Avisynth script to use on all the videos.
Simple x264 Launcher would then create an index file for each video with DGDecodeNV. Then the files would be encoded using the Avisynth script.
Once encoding is finished Simple x264 Launcher should mux the audio back with the video output with TSmuxer to m2ts.

I've tried MeGUI but it's very buggy and unreliable. I know you said you won't be doing anything like the above but I was wondering if it would be OK to hire someone to mod Simple x264 Launcher and develop it for me.

Any idea how much that might cost to develop?

[LoRd_MuldeR]

Select a folder of files to encode and select an Avisynth script to use on all the videos. Simple x264 Launcher would then create an index file for each video with DGDecodeNV. Then the files would be encoded using the Avisynth script.

The problem with your idea is that an Avisynth (or VapourSynth) script is not "used" on a video file. The script simply returns video data to the host application, but the host has no means of determining where that video came from. The script may have read the video data from a file using whatever source plug-in, it may have created the video data by combining several input files or it even may have generated that video data all by itself!

Surely, what could be implemented is a "script generator" that outputs a simple Avisynth script to load a single input file trough a pre-defined source plug-in without any fancy extra processing. But what certainly can not be done is writing a program that takes an arbitrary Avisynth script as input and "applies" that script on your specific video file(s). There are far too many possibilities how the script may look and how exactly it would have to be modified to "load" exactly the desired file...

Once encoding is finished Simple x264 Launcher should mux the audio back with the video output with TSmuxer to m2ts.

Audio processing is not currently supported.

Any idea how much that might cost to develop?

I would assume a professional freelancer programmer costs about $100 per hour and that such a project could take quite a few days (á 8 hours) to understand the existing code, implement the required extensions (which may require a significant redesign of the code) and do all the testing.

[VideoFanatic]

Thanks. I know it doesn't support audio. I was referring to DGDecodeNV demuxes the audio and video then after Simple x264 Launcher encodes the video only, TS Muxer would mux the files back together.

So is it OK if I hire someone to mod Simple x264 Launcher? Once the program was finished it would be made available to download for free. Obviously I'd have to call the program "Simple x264 Launcher Batch Mod" or if there's a name you don't want me to use then that's fine.

[Atak_Snajpera]

Why don't you just use TX264 if you need audio as well?

[LoRd_MuldeR]

So is it OK if I hire someone to mod Simple x264 Launcher? Once the program was finished it would be made available to download for free. Obviously I'd have to call the program "Simple x264 Launcher Batch Mod" or if there's a name you don't want me to use then that's fine.

This software is released under the GNU General Public License (GPL). So everybody is granted the right to use the software for free, to redistribute the software, to modify the software according to their needs and even to re-use parts of the software in their own software. No further approval by the author is required. However, be aware that the GPL also requires that any derivative work will be released under the GPL too! Even if you re-use only a small part of the original software in your software, you still must release your software under the GPL too. Just offering your software for free download is not sufficient! You are required to grant your users the same rights that the developer of the original software granted you.

See also:
http://www.gnu.org/licenses/gpl-2.0.html
http://en.wikipedia.org/wiki/Copyleft

[VideoFanatic]

I would like to encode a wrestling show. All HD episodes are approximately the same length at about 2 hours 17 minutes each but when I use CRF 17 I get file sizes of between 7-8.5GB. That's quite a big difference. How does that happen as I looked at the episodes and they each have approximately the same length of talking segmets and action segments (matches).

Anyway is there a way to tell x264 to encode to a target file size? All I can see is 2 pass but it only allows you to enter the bitrate not the filesize.

Is there a quality loss from doing 2 pass versus CRF?

Both episode sources were 13.4GB but after encoding to CRF 17.5 the file size was 6.79GB for one episode and 8.67GB for another. Both sources were copied directly from my satellite box onto my PC without re-encoding then I re-encoded them.

[LoRd_MuldeR]

I would like to encode a wrestling show. All HD episodes are approximately the same length at about 2 hours 17 minutes each but when I use CRF 17 I get file sizes of between 7-8.5GB. That's quite a big difference. How does that happen as I looked at the episodes and they each have approximately the same length of talking segmets and action segments (matches).

CRF mode gives the same quality (roughly!) for different sources, given that you use the same CRF value and given that you do not change other encoder settings. Of course the size can vary greatly between different sources, because source 'A' could be much more "compressible" than source 'B', or vice versa. Consequently, it's not surprising at all that different sources come out at different size, even if the duration is identical. Of course sources with "similar" content are expected to come out at more "similar" sizes. And indeed, despite you have been encoding 2 hours 17 minutes of completely different material (though of similar nature), the difference is file size is only ~20%.

Anyway is there a way to tell x264 to encode to a target file size?

2-Pass mode !?!?!?!? :sly:

All I can see is 2 pass but it only allows you to enter the bitrate not the filesize.

Size = Duration × Bitarte

Inserting the Duration of your movie plus the desired Size and then solving that equation for Bitarte should be pretty doable.

Tough, if you are as lazy as I am, enter "bitrate calculater" into Google ;)

Is there a quality loss from doing 2 pass versus CRF?

CRF and 2-Pass are using the exactly some rate-control algorithm.

So, nope, two files encoded with CRF and 2-Pass will have the exactly same quality, given that they come out at the same bitrate (file size).

[Atak_Snajpera]

Size = bitrate / 8 x duration

[LoRd_MuldeR]

Size = bitrate / 8 x duration

If bitrate is supposed to be in "bits per second", but size is supposed to be in "bytes", then yes.

(I gave the general formular that makes no such presumptions)

[r0lZ]

IMO, 2-pass is slightly less good than CRF, because the encoder is constrained by the given bitrate. The first pass helps greatly to distribute the bitrate according to the "difficulty" to compress the different parts of the movie, but it's still not perfect. (It's why some users prefer to encode in 3-pass, or even more.) In the other hand, CRF has no constraints at all, and can therefore obtain the best quality immediately. Anyway, that considerations are very theoretical, because there is no practical way to encode in CRF and 2-pass modes with exactly the same overall bitrate. But IMO, unless the final file size is really important, CRF is always preferable.

[LoRd_MuldeR]

IMO, 2-pass is slightly less good than CRF, because the encoder is constrained by the given bitrate. The first pass helps greatly to distribute the bitrate according to the "difficulty" to compress the different parts of the movie, but it's still not perfect. (It's why some users prefer to encode in 3-pass, or even more.) In the other hand, CRF has no constraints at all, and can therefore obtain the best quality immediately. Anyway, that considerations are very theoretical, because there is no practical way to encode in CRF and 2-pass modes with exactly the same overall bitrate. But IMO, unless the final file size is really important, CRF is always preferable.

As explained before, 2-Pass and CRF use the exactly same rate-control algorithm :)

So if you make two encodes of the same source, one with 2-Pass and one with CRF, the two encodes will come out at the same quality - given that they come out at the same file size (bitrate). Really the only difference between 2-Pass and CRF is that 2-Pass mode can hit a predefined average bitrate. 2-Pass does that by adjusting the "rate factor" automatically so that the desired bitrate is hit, while CRF uses a fixed rate-factor (as the name implies). Otherwise they are pretty much the same. So any quality difference between 2-Pass and CRF you may have observed is because the files came out at different bitrate (size) - in which case the comparison was biased/unfair, of course - or because other settings were different.

BTW: The first pass of a 2-Pass encode is simply run in ABR mode. The only info that the second pass will reuse from the first pass is a rough approximation of the "complexity" of each frame. That's also why you can use "very fast" settings during the first pass, even when the second pass will use "slow" settings: The approximation of the frame "complexities" will still be reasonably accurate and all the rest doesn't matter at all.

BTW 2.0: Using three or even more passes with x264 is nonsense, except for the extremely rare case when the second pass didn't hit the target bitrate (happens almost never for "real world" footage).


CRF and 2-pass use the exact same bit distribution algorithm. If you do a CRF encode and a 2-pass encode at the same bitrate, the results will be nearly identical.

Hypothetically, there could be a bug in the 2-pass code that didn't show up in CRF, but outside of a hypothetical bug workaround, this is probably not a good suggestion.What do you think about using more than two passes?

Useless waste of time. 99% of any benefit you'll get from it can be gotten by running the first pass with --slow-firstpass instead running a third pass, and even that benefit is tiny.


See also:
http://git.videolan.org/?p=x264.git;a=blob;f=doc/ratecontrol.txt;h=e93ced2aa374a4a36fa1f34121358d943a28f6bc;hb=dd79a61e0e354a432907f2d1f7137b27a12dfce7

[r0lZ]

OK, thanks for the clarification. (I'm also sure that doing more than 2 passes is overkill, but some peoples are strange and do it anyway.)

Anyway, I think that my conclusion is still valid: Unless you need a specific file size, it is better to use CRF, because CRF gives you the quality you want anyway, regardless of the complexity of the movie. If you encode in 2-pass, with a target quality in mind, you have to figure out the bitrate to obtain that quality. It's something virtually impossible to do for an human being. CRF does it automatically for you. And there is obviously another good reason to prefer CRF: the speed of the overall encoding process.

[VideoFanatic]

OK I tried 2 pass and entered a bitrate of 7500 but MediaInfo says the bitrate is 7908 variable bitrate. I want the max variable bitrate to not go above 7500. How can I do that?

I was wondering, is there no way for you to add a feature to the program where you can enter a target file size and the program does a 2 pass to get to that file size?

[LoRd_MuldeR]

OK I tried 2 pass and entered a bitrate of 7500 but MediaInfo says the bitrate is 7908 variable bitrate. I want the max variable bitrate to not go above 7500. How can I do that?

I wouldn't blindly trust what MediaInfo says here, because determining a "bitrate" for a variable bitrate file is kind of tricky ;)

x264 will print out the actual average bitrate at the end of the encode. That's the number of total bits written divided trough the duration of your input. And that's what you can rely on!

Also keep in mind, the bitrate that you enter for x264 is the VIDEO bitrate only. If you are going to add AUDIO too, this will be added to the file size afterwards.

I was wondering, is there no way for you to add a feature to the program where you can enter a target file size and the program does a 2 pass to get to that file size?

The problem is that you'd need to know the duration of the file beforehand in order to compute the target bitrate, based on a desired file size.

Determining the duration of an Avisynth script source is straight forward, because we can query the total number of frames and the number of frames per second.

But for other types of input it's not so easy, especially if we use x264's built-in decoders ;)

[VideoFanatic]

OK but I always use Avisynth and you say when using Avisynth it's easy to determine the duration with that. So is there any chance you could add that feature please? Perhaps you could add a warning that "target file size" only works when using Avisynth?

[VideoFanatic]

I was wondering, you said CRF and 2 pass gives the same quality. Is there any reason not to use ABR mode in the same bitrate as I would in a 2 pass?

[Asmodian]

Yes, the quality would be significantly worse. ABR is not the same as CRF. To hit a specific size with optimal quality two passes are needed.

[LoRd_MuldeR]

I was wondering, you said CRF and 2 pass gives the same quality. Is there any reason not to use ABR mode in the same bitrate as I would in a 2 pass?

2-Pass mode can predict the size of future frames, since it has information from the first pass. ABR mode, on the other hand, can only extrapolate from what has been encoded thus far, because it has no info on future frames.

If, for example, there happens to be a very complex section near the end of the movie, then 2-Pass mode "knows" about this beforehand. So it can reduce the bitrate, to some degree, at the beginning of the movie, in order to "save" enough bits for the end of the movie, where those bits will be more than helpful. ABR mode obviously can not do this. When it reaches the complex section at the end of the movie, it has to get along with the number of bits that are still left at this point.

CRF mode also has no info on future frames. But it doesn't need to. Since CRF doesn't need to hit a specific file size (average bitrate), it can simply use as many bits as it deems appropriate...

[hello_hello]

OK I tried 2 pass and entered a bitrate of 7500 but MediaInfo says the bitrate is 7908 variable bitrate. I want the max variable bitrate to not go above 7500. How can I do that?

Try checking with Bitrate Viewer (http://www.winhoros.de/docs/bitrate-viewer/). As far as I'm aware it's accurate.

[szabi]

Hi

I use latest build (884), which came x264v2453.
I see newer x264v2479 is out.
Can x264 be replaced in toolset directory? Without any issue?

bye
szabi

[LoRd_MuldeR]

Can x264 be replaced in toolset directory?

Yes.

Without any issue?

Usually there should be no problem, if you replace it with a newer version.

There can be problems if you apply non-standard patches...

[VideoFanatic]

Can I request a small feature please. At the moment when you modify a profile it gives you the option to select a profile to overwrite. But I can't always remember the name of the profile I was editing and want to overwrite because it has a long name.

Could you instead do this: https://docs.google.com/document/d/1OlFuehIssbrsiP3LltOs9JkehR5I7o43LyHAMulxGhc/edit

When you change a setting of a saved profile it will add "<Modified>" to the Template Name. Could you add a Save button so it will overwrite the profile name (the "<Modified>" text will not be a part of the save name) without asking what profile to save as.

[VideoFanatic]

What do I expect? I expect that, if I neither use "--profile" nor "--level", then x264 will set the "correct" Profile and Level for me. That is: the lowest possible Profile that my stream complies to as well as the lowest possible Level that my stream complies - given the current input file and the current encoder settings. Consequently, manually enforcing an even higher Profile or an even higher Level would make no sense. Enforcing a lower Profile can make sense, e.g. if I need to stick within "Main" Profile, because my playback device can only do "Main" Profile but not "High" Profile. Enforcing a lower Level, on the other hand, is almost always a very bad idea, as explained and demonstrated in the previous post (https://forum.doom9.org/showpost.php?p=1696566&postcount=1395).



You can't modify Profiles, because they are predefined by the H.264 standard. All H.264 Profiles that x264 recognizes should be selectable from the "Profile" combobox.

Sorry I was referring to Templates. Would it be possible to add what I asked please?

[LoRd_MuldeR]

Sorry I was referring to Templates. Would it be possible to add what I asked please?

What about this: When you click the "Save as..." button, it the initial name will be that of the last profile you have loaded?

[VideoFanatic]

What about this: When you click the "Save as..." button, it the initial name will be that of the last profile you have loaded?

That would be fine. Thanks

[szabi]

Yes.

Usually there should be no problem, if you replace it with a newer version.

There can be problems if you apply non-standard patches...
Thnx, it worked. :)

[LoRd_MuldeR]

That would be fine. Thanks

Try with this version please:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2014-10-11.exe/download

[VideoFanatic]

I don't want to install it, do you have a portable version please like what's on VideoHelp.com?

[LoRd_MuldeR]

I don't want to install it, do you have a portable version please like what's on VideoHelp.com?

The installer contains the exactly same files as the ZIP package does. And it doesn't do much more than extracting those files to the target directory. There is no such thing as a separate "portable" version.

I don't have time to upload a ZIP package now. If you don't "trust" my installer for whatever reason, use 7-Zip/UniversalExtract to unzip the files. Or simply use a tool like Sandboxie ;)

[VideoFanatic]

The installer contains the exactly same files as the ZIP package does. And it doesn't do much more than extracting those files to the target directory. There is no such thing as a separate "portable" version.

I don't have time to upload a ZIP package now. If you don't "trust" my installer for whatever reason, use 7-Zip/UniversalExtract to unzip the files. Or simply use a tool like Sandboxie ;)

Thanks, I used the installer and the saving feature works.

There's a portable version here: http://www.videohelp.com/tools/Simple-x264-Launcher

I unzip it and it works, it's got all the template and preferences file in the same directory. Can I make a suggestion please. Why not only provide the portable version since it's less hassle. I don't see the point in using an installer when I can just unzip the portable version and it's ready to use.

I think you've told me before that the installer just extracts files but every time a see an installer I always think it installs something! It's not that I don't trust your installer, it's just that I don't want registry entries, etc written to windows when I can just use a portable version.

[LoRd_MuldeR]

There's a portable version here: http://www.videohelp.com/tools/Simple-x264-Launcher

As said before, there is no such thing as a separate "portable" version.

Apparently, Videohelp.com is just mirroring my files. Still, the files contained in the installer and in the ZIP package are one and the same! Calling the ZIP package a "portable version" is misleading here :rolleyes:

If you would have a look at the REAMDE file, it explains very well how to enable "portable" mode. And that's completely regardless of how you obtained the files...


Why not only provide the portable version since it's less hassle.

All binaries that I provide (installer and ZIP package) support the "portable" mode. There's no separate "portable" version. Again I advise you to have a look at the README file ;)


I don't see the point in using an installer when I can just unzip the portable version and it's ready to use.

Actually, a lot of people want the software to be "installed" locally - with shortcuts, a proper uninstaller and everything. So if only a ZIP package was provided, these people would not be happy and ask "Why only a ZIP file that I have to extract manually, when the installer is much more convenient?" Furthermore, the installer is much less error prone than the ZIP package! The installer makes sure that all files are extracted and that the correct directory structure will be preserved. It will also clean-up leftovers from a previous install. If the ZIP package is extracted manually, we can only hope that the user will extract all files. And we can only hope that whatever "unzip" tool he is using was setup to retain the directory structure...


I think you've told me before that the installer just extracts files but every time a see an installer I always think it installs something!

Well, I hope the installer does install something. Would be a rather nonsensical installer, if it didn't install anything :D

Though, in the case of Simple x264 Launcher, the installation process pretty much consists of extracting the program files, creating the shortcuts and registering the uninstaller.

(Yes, creating registry entries to make the system "recognize" the uninstaller is unavoidable. Those entries will be removed by the uninstaller)


It's not that I don't trust your installer, it's just that I don't want registry entries, etc written to windows when I can just use a portable version.

I think you should be using a tool like Sandboxie (http://www.sandboxie.com/) then. It probably makes your day ;)

[THEAST]

I started using Simple x264 Launcher instead of MeGUI since it offers the options to "pause" the encode. Yesterday I started an encode that was supposed to take nearly 6 hours to finish, paused the encode at 30% and hibernated my machine and today I started my machine and resumed the encode without issues but currently, the average fps and the eta are incorrect because it seems the time since the start of the encode is taken into account when calculating the average fps, instead of the time the encode has been active and hence, the eta is also incorrect. If possible, I'd really appreciate it if this issue is addressed in the upcoming versions.
Also I was wondering if there are any known issues with pausing the encode and hibernating the machine while it is paused.

Edit: I just noticed that Simple x264 Launcher's report is based on what x264 itself is reporting and the issue happens because x264 doesn't know it is being paused; is there a way to get around this?

[LoRd_MuldeR]

I started using Simple x264 Launcher instead of MeGUI since it offers the options to "pause" the encode. Yesterday I started an encode that was supposed to take nearly 6 hours to finish, paused the encode at 30% and hibernated my machine and today I started my machine and resumed the encode without issues but currently, the average fps and the eta are incorrect because it seems the time since the start of the encode is taken into account when calculating the average fps, instead of the time the encode has been active and hence, the eta is also incorrect. If possible, I'd really appreciate it if this issue is addressed in the upcoming versions.
Also I was wondering if there are any known issues with pausing the encode and hibernating the machine while it is paused.

This has been discussed several times before: The "FPS" value displayed by x264 is simply the total number of frames that have been encoded thus far divided through the total time that has elapsed since the encoding process was
started. Consequently, if you suspend the encoding process, time continues to go by, but no frames are encoded. Thus you will see the "FPS" value go down ;)

Edit: I just noticed that Simple x264 Launcher's report is based on what x264 itself is reporting and the issue happens because x264 doesn't know it is being paused; is there a way to get around this?

Yes, change the x264 code to compute the "FPS" in a different way. For example, on each progress update, they could take the number of frames that have been encoded since the last progress update and divide that through the time that has elapsed since the last progress update. Of course that would result in much more "unsteady" FPS. Maye some gradual update function like "FPS[i+1] = (α × FPS[i]) + ((1-α) × FPS_current)" could be used to compensate.

[THEAST]

Well, modifying x264 code isn't really something I'm capable of; I thought correcting the issue would be easier on Simple x264 Launcher since it is aware of when the process is paused and when it is working but it's most probably not on your list of priorities. I can live with it though, it's not really that big of an issue. :)

[LoRd_MuldeR]

Well, modifying x264 code isn't really something I'm capable of; I thought correcting the issue would be easier on Simple x264 Launcher since it is aware of when the process is paused and when it is working but it's most probably not on your list of priorities. I can live with it though, it's not really that big of an issue. :)

Nope. FPS is computed by x264 itself and the GUI simply displays that value. I theory, the GUI could implement its own FPS computation, but I hate to implement redundant functions ;)

I'd rather suggest you bother the x264 guys with your request...

[VideoFanatic]

Hi, from this post http://forum.doom9.org/showthread.php?p=1696590#post1696590 we discussed having a portable version of Simple x264 Launcher. I had it working fine but today I opened the program and I get a popup saying VapouSynth is not installed despite me disabling that warning before (I also checked the options and "Never show warning about missing Avisynth or Vapoursynth is still ticked"). Also when I go to add a new job none of my templates show up, the only thing that shows is Default. This has happened before in previous versions. My templates file is still where it should be but none of the templates show up in the program.

[LoRd_MuldeR]

Hi, from this post http://forum.doom9.org/showthread.php?p=1696590#post1696590 we discussed having a portable version of Simple x264 Launcher. I had it working fine but today I opened the program and I get a popup saying VapouSynth is not installed despite me disabling that warning before (I also checked the options and "Never show warning about missing Avisynth or Vapoursynth is still ticked"). Also when I go to add a new job none of my templates show up, the only thing that shows is Default. This has happened before in previous versions. My templates file is still where it should be but none of the templates show up in the program.

So, do you currently run Simple x264 Launcher in "portable mode" or not? :confused:

If you do so, it will store all INI files in the very same folder where the program file resides. Otherwise, it will store the INI files at "%LOCALAPPDATA%\LoRd_MuldeR\Simple x264 Launcher". Of course, in "portable mode", you must make sure the directory where the program file resides is actually writable! If it is not writable, e.g. because you put the program to "C:\Program Files\Something", your settings cannot be saved, obviously! Conversely, %LOCALAPPDATA% is always writable.

Also, if you switch from "portable mode" back to "standard" mode (or vice versa), your settings will be lost. That's because the program will now look for the INI files in a different place than where they have been saved before. Of course you can simply move the INI files to the new location and everything will be fine again. Anyway, moving your INI files around is only needed if you switch between "portable mode" and "standard" mode. It is not required as long as you stick to one mode.

Having said that, if you think that your settings are not saved correctly, I would suggest to inspect the INI files! Also, you can run the program with "--console" option to get more diagnostic output...

[VideoFanatic]

As far as I know I was running it in portable mode and the files are not in the C Drive so it should be writeable. The INI files are still in the folder where the program is. However when no templates showed up in the program I saved another one and it showed up in AppData\Local\LoRd_MuldeR\Simple x264 Launcher so it looks like the program changed to non-portable mode somehow.

How do you actually switch between modes?

[LoRd_MuldeR]

The INI files are still in the folder where the program is. However when no templates showed up in the program I saved another one and it showed up in AppData\Local\LoRd_MuldeR\Simple x264 Launcher so it looks like the program changed to non-portable mode somehow.

So, apparently, you have been using "portable mode" at some point in the past, but you are using the "standard" mode now. That's exactly the case that I described in my previous post...

How do you actually switch between modes?

C'mon! At least have a look at the README (http://muldersoft.com/docs/x264_launcher_readme.html) file before asking this :rolleyes:

[yangshao]

Use the simple x264 default parameters encoded video in iphone4s/5S inside can only play the start of 7mn31s, and then the picture stagnant not fast forward rewind, dance music playback, voice only! What is the reason? Should I fill in which parameters in the "custom encoder options"? The red line is shown as below:
http://image16.poco.cn/mypoco/myphoto/20141128/19/6253250320141128191919047.png?570x602_130
Code out of the MP4: Guardians of the Galaxy.2014.1280x720_23.976fps_121mins_2500KB,bit （The video using the computer to play is normal, but in iphone4s in error, unable to drag around playing!!）
Please tell me what I should do, thank you!

[LoRd_MuldeR]

1. There is are no "simple x264 default parameters", because Simple x264 Launcher defaults to whatever x264 defaults to (i.e. Simple x264 Launcher, by default, doesn't overwrite any x264 default settings).

2. Nobody ever claimed that a stream created with x264 default settings will play correctly on device XYZ.

3. Settings a specific H.264 Level via "--level" switch does not guarantee that the resulting H.264 stream will actually conform to that Level! There are many properties of the input file (frame rate, frame size, etc) that may violate the desired H.264 Level. And, if your input file violates the desired Level already, then there is nothing x264 could do about that. So be aware for any warnings that x264 may spit out!

4. You may need to setup the required VBV parameters for your playback device in order to ensure proper playback. But please don't ask me what the correct VBV parameters for your device are. Use Google ;)

[yangshao]

1. There is are no "simple x264 default parameters", because Simple x264 Launcher defaults to whatever x264 defaults to (i.e. Simple x264 Launcher, by default, doesn't overwrite any x264 default settings).

2. Nobody ever claimed that a stream created with x264 default settings will play correctly on device XYZ.

3. Settings a specific H.264 Level via "--level" switch does not guarantee that the resulting H.264 stream will actually conform to that Level! There are many properties of the input file (frame rate, frame size, etc) that may violate the desired H.264 Level. And, if your input file violates the desired Level already, then there is nothing x264 could do about that. So be aware for any warnings that x264 may spit out!

4. You may need to setup the required VBV parameters for your playback device in order to ensure proper playback. But please don't ask me what the correct VBV parameters for your device are. Use Google ;)

MP4-INFO:
http://image16.poco.cn/mypoco/myphoto/20141129/13/62532503201411291312043046902787195_001.jpg?541x629_130
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 1h 33mn
Source duration : 7mn 31s
Bit rate : 2 600 Kbps
Maximum bit rate : 17.0 Mbps
Width : 1 920 pixels
Height : 1 040 pixels
Display aspect ratio : 1.85:1
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.054
Stream size : 1.70 GiB (100%)
Source stream size : 1.70 GiB (100%)

Player iphone4s：
http://image16.poco.cn/mypoco/myphoto/20141129/13/62532503201411291312043046902787195_000.jpg?960x640_130
Play 7min31s and picture suspension, the only sound...

[kypec]

yangshao you have to correct the input parameter first because according to your screenshot you made an obvious typo:
-- level 3.1 is wrong
--level 3.1 is the correct setting

[LoRd_MuldeR]

Good observation, kypec. Actually I think the GUI shouldn't allow to enter "--" without an option name. Will be fixed for next version.

[Dion]

Can you please add an option to disable x264 version check.

[LoRd_MuldeR]

Please try with this TEST version:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2014-12-10.exe/download

This adds the "--skip-version-checks" command-line switch, or better, makes that switch work again ;)

[Dion]

Please try with this TEST version:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2014-12-10.exe/download

This adds the "--skip-version-checks" command-line switch, or better, makes that switch work again ;)

That works but not exactly ideal for the portable version.

x264_launcher_portable.exe

Was thinking an option in the options menu.

[LoRd_MuldeR]

That works but not exactly ideal for the portable version.

Where's the problem? You could write a Batch script that runs the program with the desired extra arguments and put it into the same folder as the EXE file - portable or not.


Was thinking an option in the options menu.

I don't want to encourage people to use outdated versions too much ;)

[Dion]

I don't want to encourage people to use outdated versions too much ;)

You already include the skip option via command.. Don't see how an option in the options would encourage people to use patched x264 builds. Alot easier then dealing with batch files. :/

[LoRd_MuldeR]

Alot easier then dealing with batch files. :/

That's the point. This is something you should use only in "special" situations (e.g. for testing something), but not for your every-day work.

Why exactly do you want to use an old/outdated encoder version anyway, except for testing? The only reason I can think of is that the latest version has some kind of regression(s).

But in that case, you should better get the developers to fix the regression, instead of reverting to on older version...

[Dion]

That's the point. This is something you should use only in "special" situations (e.g. for testing something), but not for your every-day work.

Why exactly do you want to use an old/outdated encoder version anyway, except for testing? The only reason I can think of is that the latest version has some kind of regression(s).

But in that case, you should better get the developers to fix the regression, instead of reverting to on older version...

Newer x264 have LSMASH issues. So they arent updated. ( modded x264 ).

So newer isn't always better.

[chinobino]

Hi all, I have been having trouble with x264 Launcher (2014-11-02) and the test build (2014-12-10) on Windows 8.1 x64.

I am loading avs scripts in to re-encode some decrypted MPEG-2 videos from DVD to 10-bit x264 or 10-bit x265.

The problem is that if I abort a job (to analyse the output) and then restart it (or recreate it), the job will always fail unless I rename the output file to something different.

If I don't rename the output file x264 Launcher asks me if I want to overwrite the existing file, I say 'Yes' and then the encoding process starts and errors out with this;

http://members.iinet.net.au/~michaeldd/x264_Launcher_Runtime_Error.png

And the log reads;

Simple x264 Launcher (Build #898), built 2014-12-10

Job started at 2014-12-15, 16:11:08.

Source file : G:\01 More Than Meets The Eye (Part 1).avs
Output file : G:\\01 More Than Meets The Eye (Part 1).hevc

--- SYSTEMINFO ---

Binary Path : C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2
Avisynth : Yes
VapourSynth : C:\Program Files (x86)\VapourSynth\core32

--- SETTINGS ---

Encoder : x265 (H.265/HEVC), x64, 16-Bit
Source : Avisynth (avs)
RC Mode : CRF
Preset : Veryfast
Tuning : <None>
Profile : <Unrestricted>
Custom : --ref 10

--- CHECK VERSION ---

Detect video encoder version:

Creating process:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x64\x265_16bit_x64.exe" --version

x265 [info]: HEVC encoder version 1.4
x265 [info]: build info [Windows][MSVC 1800][64 bit] 16bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX

Detect video source version:

Creating process:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x86\avs2yuv_x86.exe"

Avs2YUV 0.24bm2

> x265 version: 1.4+0
> Avs2YUV version: 0.24.2

--- GET SOURCE INFO ---

Creating process:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x86\avs2yuv_x86.exe" -frames 1 "G:\\01 more than meets the eye (part 1).avs" NUL

G:\\01 more than meets the eye (part 1).avs: 960x720, 24000/1001 fps, 32949 frames

Resolution: 960x720
Frame Rate: 24000/1001
No. Frames: 32949

--- ENCODING VIDEO ---

Creating input process:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x86\avs2yuv_x86.exe" "G:\\01 more than meets the eye (part 1).avs" -

Creating encoder process:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x64\x265_16bit_x64.exe" --crf 22.0 --preset veryfast --ref 10 --output "G:\\01 More Than Meets The Eye (Part 1).hevc" --frames 32949 --y4m -

y4m [info]: 960x720 fps 24000/1001 i420p8 unknown frame count
x265 [info]: HEVC encoder version 1.4
x265 [info]: build info [Windows][MSVC 1800][64 bit] 16bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [warning]: level 4 detected, but NumPocTotalCurr (total references) is non-compliant
x265 [info]: NONE profile, Level-NONE (Main tier)
x265 [info]: WPP streams / frame threads / pool : 23 / 3 / 8
x265 [info]: Internal bit depth : 10
x265 [info]: CTU size / RQT depth inter / intra : 32 / 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 57 / 1 / 2
x265 [info]: Keyframe min / max / scenecut : 23 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 15 / 4 / 0
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 10
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-22.0 / 1.0 / 0
x265 [info]: tools: rd=2 esd lft sao signhide fast-intra tmvp
encoded 81 frames in 33.53s (2.42 fps), 2539.74 kb/s
x265 [info]: frame I: 9, Avg QP:10.57 kb/s: 8887.56
x265 [info]: frame P: 19, Avg QP:14.89 kb/s: 2303.27
x265 [info]: frame B: 53, Avg QP:16.88 kb/s: 1546.57
x265 [info]: global : 81, Avg QP:15.72 kb/s: 2539.74
x265 [info]: Weighted P-Frames: Y:5.3% UV:0.0%
x265 [info]: consecutive B-frames: 46.4% 3.6% 3.6% 7.1% 39.3%
av2y [info]: G:\\01 more than meets the eye (part 1).avs: 960x720, 24000/1001 fps, 32949 frames

WARNING: Input process exited with error (code: 3), your encode might be *incomplete* !!!
Final file size is 1.02 MB bytes.

--- COMPLETED ---

Job finished at 2014-12-15, 16:11:52. Process took 0 minutes, 44 seconds.

This happens regardless of which codec and parameters are used.

It also occurs if I delete the partially created file from the job that I aborted.

My avs script's process fine in VirtualDub but I would prefer to use x264 Launcher.

I searched for other instances of this problem but didn't find anything.

[LoRd_MuldeR]

Newer x264 have LSMASH issues. So they arent updated. ( modded x264 ).

So newer isn't always better.

What issues?

Anyway, recent x264 has support for L-SMASH MP4 Muxer built-in (http://git.videolan.org/?p=x264.git;a=blob;f=output/mp4_lsmash.c;), so there's no need for any "modded x264" to get L-SMASH support.

And if you encounter any problems with the built-in L-SMASH muxer in up-to-date (vanilla) x264, better report to the developers!


http://members.iinet.net.au/~michaeldd/x264_Launcher_Runtime_Error.png

It means Avisynth (or, more likely, one of the Avisynth plug-in's you are using) has just crashed. It's not a Simple x264 Launcher problem. Don't shoot the messenger!

Time to load up your debugger ;)

My avs script's process fine in VirtualDub but I would prefer to use x264 Launcher.

The joys of undefined behavior (http://en.wikipedia.org/wiki/Undefined_behavior) :rolleyes:

In the best case, the buggy program will crash right away, so at least you know that something is wrong and you can track down the cause (easily).

In the worst case, it will not crash at all - but produce corrupted outputs silently...

[chinobino]

It means Avisynth (or, more likely, one of the Avisynth plug-in's you are using) has just crashed. It's not a Simple x264 Launcher problem. Don't shoot the messenger!

Time to load up your debugger ;)

The joys of undefined behavior (http://en.wikipedia.org/wiki/Undefined_behavior) :rolleyes:

In the best case, the buggy program will crash right away, so at least you know that something is wrong and you can track down the cause (easily).

In the worst case, it will not crash at all - but produce corrupted outputs silently...

Ok, thankyou for clarifying - do you happen to know of a good source for debugging avs scripts and plug-ins?

At the moment I am trying to wrap my head around this (http://avisynth.nl/index.php/Filter_SDK/Debugging_instructions) one.

[kypec]

Could it be that the problem is caused by two backslashes in path after drive letter for output file?
Source file : G:\01 More Than Meets The Eye (Part 1).avs
Output file : G:\\01 More Than Meets The Eye (Part 1).hevc

[LoRd_MuldeR]

Could it be that the problem is caused by two backslashes in path after drive letter for output file?
Source file : G:\01 More Than Meets The Eye (Part 1).avs
Output file : G:\\01 More Than Meets The Eye (Part 1).hevc

Shouldn't be a problem. There is an infinite number of possible ways to write a path that refers to the same file. And there generally is no requirement to pass a path in canonical (http://msdn.microsoft.com/en-us/library/windows/desktop/bb773569%28v=vs.85%29.aspx) form.

[Dion]

What issues?

Anyway, recent x264 has support for L-SMASH MP4 Muxer built-in (http://git.videolan.org/?p=x264.git;a=blob;f=output/mp4_lsmash.c;), so there's no need for any "modded x264" to get L-SMASH support.

And if you encounter any problems with the built-in L-SMASH muxer in up-to-date (vanilla) x264, better report to the developers!

Apparently it has been updated and was buried in the comments.

However your launcher detects it out of date when its running on the latest x264.

https://github.com/jpsdr/x264/releases/tag/r2525

[LoRd_MuldeR]

However your launcher detects it out of date when its running on the latest x264.

https://github.com/jpsdr/x264/releases/tag/r2525

This modified build of x264 changes the x264 outputs in a way which breaks compatibility to "vanilla" x264. Thus the version number cannot be read correctly by the GUI :rolleyes:

Or, more precisely, the GUI does read the version number correctly, but at the position where the build number is supposed to be, the "modified" build prints a zero.

And, of course, you cannot expect that a GUI, such as Simple x264 Launcher, will support any non-standard variant of x264 that might be floating around somewhere on the Internet...

Instead, find the person who thought that it would be a good idea to totally mess up the x264 version string. And then ask him or her to get rid of this pointless quirk! ;)



Standard x264, i.e. how the output is supposed to look:
x264_8bit_x86.exe --version
x264 0.144.2525 40bb568

...and what the so-called "t_mod" build produces:
x264_x86.exe --version
x264 0.144.0+2574 9abcd72 t_mod_Custom [8-bit@all X86]

:scared:

[Remicade]

I get this error with avi, mkv, mov. Why ?

[LoRd_MuldeR]

I get this error with avi, mkv, mov. Why ?

Did you actually read the error message? :confused:

(It should be rather clear. If something remains unclear, please specify your question more precisely.)

[Remicade]

I read but vidcoder and internet friendly media encoder works with this file and x265.exe. Simple x264 Launcher has another version of x265.exe ? What I have to do for x265.exe to work in Simple x264 Launcher ? I don't know much about x265.exe, I make many conversions with x264.exe (megui, staxrip and ripbot) and It's works very well.
Maybe this is the problem ?

[LoRd_MuldeR]

x265 does not support anything but uncompressed input yet. So, unless this has changed very recently, x265 can not read AVI files (directly).

If you want this to be changed, ask the x265 developers, not me. And, until then, simply use Avisynth or VapurSynth input in order to feed your AVI file into x265 ;)

Simple x264 Launcher has another version of x265.exe ?

No. Simple x264 Launcher uses a "vanilla" build of x265, i.e. it has been built from the official x265 sources with no modifications whatsoever.

Maybe this is the problem?

Yes, trying to open an AVI file with a program that is known to not support AVI as input, is a problem. It means you are trying to do something that is not currently possible.

[LoRd_MuldeR]

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

Simple x264/x265 Launcher v2.46 [2015-01-31]
* Updated x265 to version 1.4+424
* Updated x264 to revision 2525
* Updated Avs2YUV to version 0.24 (BugMaster's mod 3)
* Proper detection of Windows 10
* Added new Tuning options for x265 encoder

[VideoFanatic]

Got the following crash (http://pastebin.com/bPp8qBt0) on MT Avisynth 2.6 running in Non-MT mode with Simple x264 Launcher:

WARNING: Input process exited with error (code: 1), your encode might be *incomplete* !!!

Bit annoying as I was encoding the 24 hours of Le Mans and it was 3/4s of the way finished then it crashed. I thought you don't get crashes when running in single threaded mode? Here's my script - the plugins I'm using are pretty stable:

DGSource("D:\Le Mans 24 Hour 2014 Race.dgi")

AssumeTFF()
DeGrainMedian(limitY=2, limitUV=3, mode=1, interlaced=true)

Yadif(mode=1, order=1)
Vinverse()
Spline36Resize(1280,720)

Crop(2,2,-2,-8)
AddBorders(2,6,2,4, $000000)

[LoRd_MuldeR]

Got the following crash (http://pastebin.com/bPp8qBt0) on MT Avisynth 2.6 running in Non-MT mode with Simple x264 Launcher:

WARNING: Input process exited with error (code: 1), your encode might be *incomplete* !!!

Bit annoying as I was encoding the 24 hours of Le Mans and it was 3/4s of the way finished then it crashed. I thought you don't get crashes when running in single threaded mode? Here's my script - the plugins I'm using are pretty stable:

DGSource("D:\Le Mans 24 Hour 2014 Race.dgi")

AssumeTFF()
DeGrainMedian(limitY=2, limitUV=3, mode=1, interlaced=true)

Yadif(mode=1, order=1)
Vinverse()
Spline36Resize(1280,720)

Crop(2,2,-2,-8)
AddBorders(2,6,2,4, $000000)

Since this is almost certainly not a GUI-related problem, please discuss in the proper Avisynth forum.

Anyway, I highly recommend to use latest stable Avisynth (http://forum.doom9.org/showthread.php?t=171668), if you encounter any strange issues with Avisynth MT. If it does work with stable Avisynth, you know that it's either an Avisynth-MT issue or one of your plug-in's is not MT-safe.

The MT branch has always been a game of luck ;)

[LoRd_MuldeR]

New Test Build:

This is the first build that is based on the MUtilities library. Please report any regressions you may notice ;)

[LoRd_MuldeR]

New Test Build:

This version offers much improved VapourSynth detection code. 32-Bit and 64-Bit editions of VapourSynth are now detected separately. And, if both are available, you can choose which one you want to use.

Note that, in order to get both, 32-Bit and 64-Bit, editions VapourSynth, you must install both, 32-Bit and 64-Bit, Python before installing VapourSynth. Make sure you install them to different directories!

[LoRd_MuldeR]

New Test Build:

This version includes: Improved Avisynth detection code + updated included x265 binaries.

[r0lZ]

The link to the x264 Online Doc (http://mewiki.project357.com/wiki/X264_Settings) in your "?" menu is dead, and it seems that it's for ever. Do you know another site with the explanation of the x264 command line options? I've googled and found several sites, but all of them are completely outdated. If you know a good up to date site, can you change the link in the next version of Simple x264 Launcher, and, in the meantime, post it here too? Thanks.

I'm using the latest non-beta release, v2.46.902. I haven't checked the last test build.

[LoRd_MuldeR]

The link to the x264 Online Doc (http://mewiki.project357.com/wiki/X264_Settings) in your "?" menu is dead, and it seems that it's for ever. Do you know another site with the explanation of the x264 command line options? I've googled and found several sites, but all of them are completely outdated. If you know a good up to date site, can you change the link in the next version of Simple x264 Launcher, and, in the meantime, post it here too? Thanks.

I could change the link to point to the Archive.org mirror, if the site is permanently down:
https://web.archive.org/web/20150203203142/http://mewiki.project357.com/wiki/X264_Settings

Alternatively, there would be this article on the Wikibooks.org web-site:
http://en.wikibooks.org/wiki/MeGUI/x264_Settings

[r0lZ]

I have checked the old link several times since two weeks or so, and it was always down. So, yes, it seems that the site is abandoned.

IMO, the wikibook article looks better. Wayback is a great tool, but linking to a page that is not maintained officially any more is not a very good alternative imo.
Anyway, thanks for the links!

[LoRd_MuldeR]

New Test Build:

Update x264 to r2538 and x265 to v1.5+200. Also fixed the link to x264 documentation, since the "mewiki" site seems to be gone for good.

[THEAST]

I had a small request: is there a chance a horizontal slider could be added to the job details windows? Depending on screen resolution, sometimes lines (usually commands with too many switches) will not fit on the screen no matter how much the GUI windows is stretched horizontally.

[LoRd_MuldeR]

I had a small request: is there a chance a horizontal slider could be added to the job details windows? Depending on screen resolution, sometimes lines (usually commands with too many switches) will not fit on the screen no matter how much the GUI windows is stretched horizontally.

Try this version please:

Note the changes in the context menu of the log view, where you can enable line-wrapping now!

[THEAST]

Try this version please:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2015-03-23.exe/download

Note the changes in the context menu of the log view, where you can enable line-wrapping now!
Thank you.

[LoRd_MuldeR]

New test build:

x265 binaries updated to v1.5+370.

[LoRd_MuldeR]

Simple x264 Launcher v2.50

Simple x264/x265 Launcher v2.50 [2015-04-17]
* Simple x264/x265 Launcher is based on the MUtilities (https://github.com/lordmulder/MUtilities) library
* Updated Qt runtime libraries to v4.8.7 snapshot-5 (2015-03-25)
* Overhauled startup code + show spinner while initializing
* Much improved Avisynth and VapourSynth detection code
* Added option to prefer 64-Bit VapourSynth, when available
* Updated x264 to revision 2538
* Updated x265 to version 1.6+174

[StinDaWg]

Something happened during the update and I lost all my prefs/templates. It's like it did a clean install. I still have the LoRd_MuldeR folder under AppData/Local with the old saved settings/templates, but none of the settings are being used. Also, no new log files are going to this folder (or anywhere else that I can see).

How do I get it working properly again?

It also keeps saying I need to check for an update because it's been longer than 14 days, even though I just updated it.

[LoRd_MuldeR]

Something happened during the update and I lost all my prefs/templates. It's like it did a clean install. I still have the LoRd_MuldeR folder under AppData/Local with the old saved settings/templates, but none of the settings are being used. Also, no new log files are going to this folder (or anywhere else that I can see).

For what version did you update to which one? Can you share (http://pastie.org/) your "templates.ini" files?

It also keeps saying I need to check for an update because it's been longer than 14 days, even though I just updated it.

Just let it check. The date when you last checked for updates with the current version has nothing to do with what you did (or did not do) with some previous version.

[StinDaWg]

You must have changed the default directory of installs recently. I now have two folders in program files (x86). MuldeR and LoRd_MuldeR.

I tried to copy the files from the old LoRd_MuldeR appdata folder into MuldeR, but it still won't take the old settings, and no new log files are created.

As for the version, it updated from whatever the previous one was to 2.50.948.

[LoRd_MuldeR]

Nope, nothing has changed regrading the paths! The default installation path is, and has always been:
%PROGRAMFILES%\MuldeR\Simple x264 Launcher v2

But of course the user decides the actual installation path during setup, so this can be whatever destination path you have selected during setup!


Furthermore, and totally independent from the chosen installation path, your settings will be stored to and loaded from:
%LOCALAPPDATA%\LoRd_MuldeR\Simple x264 Launcher

...unless you are running in "portable" mode, of course. In the latter case, settings are stored to and loaded from the application directory, i.e. where the EXE file is located.

(Note: In "portable" mode you have to ensure the application directory is actually writable, or your settings cannot be saved!)


As for the version, it updated from whatever the previous one was to 2.50.948.

I need the exact version from which you were upgrading (or at least your "templates.ini file). Otherwise I cannot try to reproduce your problem...

[StinDaWg]

Yes, I'm aware of that. But I'm very sure I did not not tell it to install to \LoRd_MuldeR when I first installed it months ago.

I'm going to uninstall everything, reboot, re-install, then try to copy over the template pref files.

Edit: So this is bizarre. Uninstalled, reboot, installed. It created %LOCALAPPDATA%\LoRd_MuldeR\LameXP - Audio Encoder Front-End.

The settings are located in this folder. There is no %LOCALAPPDATA%\LoRd_MuldeR\Simple x264 Launcher

I copied the old settings and template into the LameXP - Audio Encoder Front-End folder and now everything is back to normal.

Why did it create a folder named LameXP - Audio Encoder Front-End instead of Simple Launcher? I've never heard of this program and didn't install it. Is this an installer glitch on your end?

[LoRd_MuldeR]

So this is bizarre. Uninstalled, reboot, installed. It created %LOCALAPPDATA%\LoRd_MuldeR\LameXP - Audio Encoder Front-End.

The settings are located in this folder. There is no %LOCALAPPDATA%\LoRd_MuldeR\Simple x264 Launcher

I copied the old settings and template into the LameXP - Audio Encoder Front-End folder and now everything is back to normal.

Why did it create a folder named LameXP - Audio Encoder Front-End instead of Simple Launcher? I've never heard of this program and didn't install it. Is this an installer glitch on your end?

It's actually not that "bizarre", if you take into account that Simple x264 Launcher and LameXP now share a huge portion of their code-base, aka MUtilities (https://github.com/lordmulder/MUtilities) library ;)

But, of course, this is certainly not supposed to happen and I will have to investigate... :o

EDIT: This was a stupid Copy&Paste error, which has been fixed now. Fixed version will be available shortly, please stay tuned...

[LoRd_MuldeR]

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

Simple x264/x265 Launcher v2.51 [2015-04-26]
* Fixed regression: Config files were stored in a wrong directory
* Updated x265 to version 1.6+239

[r0lZ]

Just installed the newest version and now I have these dialogs, and the main window doesn't open:
---------------------------
MUtils
---------------------------
FATAL ERROR: MUtils library version mismatch detected!
---------------------------
OK
---------------------------

---------------------------
MUtils
---------------------------
Please re-build the complete solution in order to fix this issue!
---------------------------
OK
---------------------------

[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.

[LoRd_MuldeR]

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?

I'm probably not going to move that option to the main window. However, there already is a countdown (including sound notification) before the system shuts down, so the shutdown shouldn't come at a surprise, even if you forgot the option. You can cancel the shutdown easily. Do you think the countdown needs to be longer? Also, would adding a second button to the countdown dialog be helpful? That button would abort the countdown and disable the shutdown option.


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

Probably not a good idea. Someone will complain he has to re-enable the option every time now ;)

[almosely]

If I am sitting at my pc, this is no problem at all, of course. The cancel-button is pressed easily in that case. But sometimes I start an encode, go eating, to sleep, shopping (...), start a long download too and other jobs, come back and the pc is shut down while the other jobs could not be finished and have to be started all over again. Or I start an encode, go to the living room and want to use my pc as a media server and at sometime suddenly the connection is lost. So, every time I start your launcher, at first I go to preferences and check, if the shutdown-option is checked or not - just to be safe. Sometimes the shut down is welcome, sometimes not. I change that setting regularly.

[kypec]

...I change that setting regularly.
If you keep changing that setting regularly then no one else but you must pay attention when is it ON or OFF and ensure that no other tasks are running when encoding job finishes.
Personally, I never used that option because there are far better ways to save power in Windows. Just check your power settings and setup idle times as needed. That way, your PC will run at full power when needed (encoding video) and can switch off automatically as well once no active tasks are running.

[almosely]

My energy saving settings are perfectly set. There is no way to save more power for hours then pull the plug. My CPU is running idle almost every time, my GPU too, my monitor switches of after 5 minutes inactivity, my harddrive is permanently on, because I do not shorten its lifetime with unnecessary spin-ups. And if I do not use the system at all, its shut down completely. No hibernation. And I do not want to let my system automatically shut down when no task is running. Sometimes the system has to be running, so I can use it, when I want to, without to change to floor, wait till bootup finishes ...

Yes, I have to pay attention. This is why I check the prefs on every startup. Because I switch so often, I do not know, if I had it set or not. You must not understand that. But you have to accept, that other people think, plan and work different than you.

Other tools, like JDownloader, have that function too and it is - for this reason - solved by a permanently viewable button on top of the main window. Further tools, like Comodo Internet Security, solved the deactivation of some protections by options like "disable for 10 minutes", "disable for one hour" or "disable until next system boot" but not permanently. The last one equals the shutdown-switch with an automated reset to off, after the one shut down. There are many other programs solving the shut-down like a one-time-option, because a shut-down is a big deal.

I thought, my suggestion would be easy to integrate and also be welcome.

[rus929]

Gud day Lord!

I am very grateful that you've made this application. And I am using this ever since. As of this writing, I am still using v2.46.902. I am trying to install the latest version but it has issues with my system ( win 7 - 64 bit ). It stops my Catalyst Control System. Another issue also that I am experiencing now (with v2.46.902) is that, even if the I disable the "Auto update notification on start up", it still notifies me to check for update everytime I open the application.
I hope you can address this problems and once again thank you very much and more power.

[LoRd_MuldeR]

I am trying to install the latest version but it has issues with my system ( win 7 - 64 bit ). It stops my Catalyst Control System.
Not quite sure what you mean. Simple x264 Launcher or its installer don't "stop" anything. And they don't interfere with "Catalyst Control System" in any way.

Yes, it's possible that the installer (LockedList (http://nsis.sourceforge.net/LockedList_plug-in) plug-in) will ask you to close certain applications, if and only if those applictions block files that need to be overwritten by the installer. But it certainly won't stop those applications by itself.

So this sounds more like there's an unrelated problem with your display driver ("Catalyst" is the AMD display driver), which happened to hit while you were trying to install/use Simple x264 Launcher.


Another issue also that I am experiencing now (with v2.46.902) is that, even if the I disable the "Auto update notification on start up", it still notifies me to check for update everytime I open the application.

That's a pretty old version. Update notifications become more emphatic after a while. And that is intentional ;)

[LoRd_MuldeR]

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

Version 2.62 [2015-11-18]
* Make 'custom' Avs2YUV parameters work again
* Changed mode for the Status/Progress columns to "ResizeToContents"
* Updated x265 to version 1.8+106

[Minister]

I only found this application recently & want to say how terrific it is. I've been a long time user of MeGUI til now, but have made the switch to Simple x264 Launcher for most projects.

I have a feature request I hope you'll consider.

Currently I use batch files utilizing your CLI switches to load many jobs, which works a treat. However there is no quick way to delete multiple jobs in the queue, instead having to delete them one at a time.
A workaround is closing the program, telling it to discard the jobs at close, then confirming that choice, and after that I can reopen Simple to start over, but that is a bit cumbersome, and not an option if you have jobs currently running that you don't want to abort.

I am hoping you can the add the option to select multiple jobs from the list for deletion. It'd be very helpful for those who run 20-30+ jobs at a time.

[LoRd_MuldeR]

Hi,

selecting multiple jobs is "problematic". For example, for which job do we show the details in the lower pane, if multiple jobs can be selected in the upper pane? :confused:

Maybe I will just add an "Remove all (completed) jobs" entry to the "File" menu...

[ben_franklin]

Hey Mulder,

I guess this is more of a x264/x265 complaint and likely not your problem. I have a 26 second 4k file I am trying to encode and when reducing the resolution to 1080p it encodes fine, but when keeping the native resolution it is always corrupt when producing an x264 encode.

Also when trying to encode to x265 it tells me the input source is not valid. The source file is:

AVI
24 bit RGB (RV24)
24 FPS
4096x1706

Any ideas? Thanks!

[LoRd_MuldeR]

Hey Mulder,

I guess this is more of a x264/x265 complaint and likely not your problem. I have a 26 second 4k file I am trying to encode and when reducing the resolution to 1080p it encodes fine, but when keeping the native resolution it is always corrupt when producing an x264 encode.

Also when trying to encode to x265 it tells me the input source is not valid. The source file is:

AVI
24 bit RGB (RV24)
24 FPS
4096x1706

Any ideas? Thanks!

Well, what is the type of source? Avisynth? VaporSynth? Trying to load that AVI file directly?

The latter clearly can not work with x265. And with x264 you'd be using the "built-in" FFMS2 source filter, which may (or may not) be able to decode your source. Might very well be the problem you are describing.

If you are using Avisynth or VaporSynth, do other programs (e.g. VirtualDub) open your script correctly?

[ben_franklin]

Well, what is the type of source? Avisynth? VaporSynth? Trying to load that AVI file directly?

The latter clearly can not work with x265. And with x264 you'd be using the "built-in" FFMS2 source filter, which may (or may not) be able to decode your source.

If you are using Avisynth or VaporSynth, do other programs (e.g. VirtualDub) open your script correctly?

Allow me to rephrase and elaborate. When encoding and resizing to 1080p in x264 with "--video-filter", it works fine HOWEVER when trying to encode with x264 and NOT reducing the resolution the output always looks corrupt.

The source file is an uncompressed AVI generated in Adobe After effects. Is there some technical reason x265 wont accept that as a source input?

[LoRd_MuldeR]

Allow me to rephrase and elaborate. When encoding and resizing to 1080p in x264 with "--video-filter", it works fine HOWEVER when trying to encode with x264 and NOT reducing the resolution the output always looks corrupt.

In this case you should create an example, containing your full x264 command-line plus the shortest possible source, that can be used to reproduce the problem.

(Source should be provided in YUV4MPEG format, to exclude decoding issues)


The source file is an uncompressed AVI generated in Adobe After effects. Is there some technical reason x265 wont accept that as a source input?

I don't think x265 CLI can read anything as input, except for "raw" YUV data and YUV4MPEG. Has that ever changed?

[ben_franklin]

In this case you should create an example, containing your full x264 command-line plus the shortest possible source, that can be used to reproduce the problem.

(Source should be provided in YUV4MPEG format, to exclude decoding issues)

I'm pretty limited in the uncompressed output that After Effects provides. I don't really see an option for YUV4MPEG.




I don't think x265 CLI can read anything as input, except for "raw" YUV data and YUV4MPEG. Has that ever changed?
How are people supposed to take advantage of x265 if it is so limited in what uncompressed formats that it accepts? For example, if I had uncompressed TIFF frames or PNG frames, how would I convert those to a "raw" YUV file?

I am cognizant that you are helping me with "my" problem and I hope I am not being a pest.

[LoRd_MuldeR]

I'm pretty limited in the uncompressed output that After Effects provides. I don't really see an option for YUV4MPEG.

Use FFmpeg to generate Y4M file:
ffmpeg.exe -i input.avi -pix_fmt yuv420p -f yuv4mpeg output.y4m

How are people supposed to take advantage of x265 if it is so limited in what uncompressed formats that it accepts? For example, if I had uncompressed TIFF frames or PNG frames, how would I convert those to a "raw" YUV file?

I am cognizant that you are helping me with "my" problem and I hope I am not being a pest.

Just pipe (https://en.wikipedia.org/wiki/Pipeline_%28Unix%29) the input from Avisynth or VapourSynth, which gives you access to pretty much any source that exists ;)

And that is, of course, exactly what the Simple x264/x265 Launcher is going to do, if you select an AVS or VPS script file as your input...

(You can also pipe from FFmpeg, which is essentially the same outcome as using x264's "built-in" FFMS2 source)

[ben_franklin]

Use FFmpeg to generate Y4M file:
ffmpeg.exe -i input.avi -pix_fmt yuv420p -f yuv4mpeg output.y4m



Just pipe (https://en.wikipedia.org/wiki/Pipeline_%28Unix%29) the input from Avisynth or VapourSynth, which gives you access to pretty much any source that exists ;)

And that is, of course, exactly what the Simple x264/x265 Launcher is going to do, if you select an AVS or VPS script file as your input...

(You can also pipe from FFmpeg, which is essentially the same as using x264's "built-in" FFMS2 source)

Well crap, I was hoping my workflow would be export from After Effects > x264 launcher... :(

And this brings up another question. If I am "downgrading" the chroma to 420, what if I want 422 or 444? And if x265 is supposed to support enhanced chroma ranges and HDR, why does it need to be reduced to 420?

Again, sorry, I know this is not specifically a Launcher problem....

Oh wait, can I also import yuv422p and yuv444p?

[LoRd_MuldeR]

Well crap, I was hoping my workflow would be export from After Effects > x264 launcher... :(
Who said you can't?

Just use Avisnyth (or VapurSynth) to load your AVI file and drop it into Simple x264/x265 Launcher. The the most simple case, the AVS script you need is a one-liner :)

FFVideoSource("C:\Path to my file\Input.avi")

And this brings up another question. If I am "downgrading" the chroma to 420, what if I want 422 or 444? And if x265 is supposed to support enhanced chroma ranges and HDR, why does it need to be reduced to 420?

Someone correct me if I'm wrong, but I think at this point there are only the "Main" and "Main 10" profiles of H.265/HEVC finished, which provide 4:2:0 chroma sub-sampling with 8-Bit and 10-Bit per pixel, respectively.

[ben_franklin]

Someone correct me if I'm wrong, but I think at this point there are only the "Main" and "Main 10" profiles of H.265/HEVC finished, which provide 4:2:0 chroma sub-sampling with 8-Bit and 10-Bit per pixel, respectively.

It is here in the Wiki (https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding) under "range extensions" and yea, you are right those are not finished....

[ben_franklin]

Use FFmpeg to generate Y4M file:
ffmpeg.exe -i input.avi -pix_fmt yuv420p -f yuv4mpeg output.y4m


It is actually ffmpeg.exe -i input.avi -pix_fmt yuv420p -f yuv4mpegpipe output.y4m

I did this and the resultant file was half the size. It also completely murdered the colors, and the result was visually indistinguishable from the 1080p version. The spacial resolution advantage was visually undetectable.

How do the studios do it when remastering down to blu ray?

[LoRd_MuldeR]

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

Version 2.64 [2015-12-20]
* Fixed a dependency issue with Visual Studio runtime libraries

Version 2.63 [2015-12-19]
* Updated build environment to Visual Studio 2015 with Update-1
* Updated x265 to version 1.8+167

[LoRd_MuldeR]

Currently I use batch files utilizing your CLI switches to load many jobs, which works a treat. However there is no quick way to delete multiple jobs in the queue, instead having to delete them one at a time.
A workaround is closing the program, telling it to discard the jobs at close, then confirming that choice, and after that I can reopen Simple to start over, but that is a bit cumbersome, and not an option if you have jobs currently running that you don't want to abort.

I am hoping you can the add the option to select multiple jobs from the list for deletion. It'd be very helpful for those who run 20-30+ jobs at a time.

Try with this test version:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2015-12-20.TEST-2.exe/download

I did this and the resultant file was half the size.

Getting 1/2 the file size when going from uncompressed 4:4:4 data to uncompressed 4:2:0 data is expected.

The amount of data for the two chroma channels is reduced to 1/4 each (because 4 pixels in a 2x2 block share one chroma value), while the amount of data for the luma channels remains unchanged. Results in a 1/2 reduction overall.

1/3 + ((1/3) / 4) + ((1/3) / 4) = 4/12 + 1/12 + 1/12 = 6/12 = 1/2

It also completely murdered the colors, and the result was visually indistinguishable from the 1080p version. The spacial resolution advantage was visually undetectable.

Not quite sure what you mean with "completely murdered the colors", but generally the difference between 4:4:4 and 4:2:0 is hardly visible for "normal" film footage, while it can be more apparent with screen captures (text) and the like.

How do the studios do it when remastering down to blu ray?

I'd assume they re-scan from the original film master, they do all the processing at the scanner's "native" resolution (probably in RGB or YUV 4:4:4 format) and they downscale to 1080p (YUV 4:2:0) just before the final encode.

Also I'd assume the whole processing is done at 10-Bit or 12-Bit and they go down to 8-Bit (using proper dithering!) just before the final encode.

[r0lZ]

Not sure it's normal, but I've noticed the presence of 40 "api-ms-win-*-l1-1-0.dll" files in the latest official ZIP distribution x264_launcher.2015-12-20.zip (v2.64.1000). It seems that these files can safely be deleted. Can you confirm?

[LoRd_MuldeR]

Not sure it's normal, but I've noticed the presence of 40 "api-ms-win-*-l1-1-0.dll" files in the latest official ZIP distribution x264_launcher.2015-12-20.zip (v2.64.1000). It seems that these files can safely be deleted. Can you confirm?

Yes, it's "normal". And nope, you generally should not delete this files!

This is the new Universal CRT (UCRT), introduced with Windows 10 (adopted by Visual Studio 2015), and how Microsoft thinks we should do "app-local deployment" from now on :rolleyes:
http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx

Updated September 11, 2015: App-local deployment of the Universal CRT is supported. To obtain the binaries for app-local deployment, install the Windows Software Development Kit (SDK) for Windows 10. The binaries will be installed to C:\Program Files (x86)\Windows Kits\10\Redist\ucrt. You will need to copy all of the DLLs with your app (note that the set of DLLs are necessary is different on different versions of Windows, so you must include all of the DLLs in order for your program to run on all supported versions of Windows).

The alternative, of course, would be to require everybody to separately install the Visual Studio 2015 redistributable package on their system - which also contains the UCRT for pre-Windows 10 systems - before they can use the program.

(If you actually do delete the UCRT files from the application directory, because you want to use the system-provided UCRT, be sure you delete "api-ms-win-*.dll" and "ucrtbase.dll")

[ben_franklin]

MuldeR, this is what I did:

ffmpeg.exe -i input.avi -pix_fmt yuv444p -f yuv4mpegpipe output.y4m

The resulting YUV file was then the same size as the .avi

HOWEVER, the resulting output.y4m file had something weird done to the colors. Please see attached pic. Note, I cant attach a nice full size png because it is too big, but the jpg at imgur is at least 90% accurate in its representation of what I am trying to show.

Is it me, or is it weird that going uncompressed to 444 is doing strange things with the colors? How does one compensate for this?


http://i.imgur.com/JGLNfBW.jpg

[LoRd_MuldeR]

Looks like a typical "PC Levels" vs. "TV Levels" problem ;)

Movies stored in YUV color format typically (though not necessarily) use the 16-235 range, which is also known as "TV Levels". However, your PC screen probably uses the full 0-255 range, which is also known as "PC Levels".

So, at playback time, when the video renderer performs the required YUV to RGB conversion (video is always sent to the screen as RGB), the "correct" Levels need to be assumed. Otherwise, the result may look too bright ("washed out") or too dark.

This means what you are seeing is probably a playback problem. I don't know what playback software you are using to check the Y4M file, but be sure the video renderer is assuming "TV Levels" for the input and uses "PC Levles" as output!

http://i.imgur.com/z9YAivl.png

See here for details:
* http://avisynth.nl/index.php/Luminance_levels
* http://forum.doom9.org/showthread.php?t=143689

[ben_franklin]

Looks like a typical "PC Levels" vs. "TV Levels" problem ;)

Movies stored in YUV color format typically (though not necessarily) use the 16-235 range, which is also known as "TV Levels". However, your PC screen probably uses the full 0-255 range, which is also known as "PC Levels".

So, at playback time, when the video renderer performs the required YUV to RGB conversion (video is always sent to the screen as RGB), the "correct" Levels need to be assumed. Otherwise, the result may look too bright ("washed out") or too dark.

This means what you are seeing is probably a playback problem. I don't know what playback software you are using to check the Y4M file, but be sure the video renderer is assuming "TV Levels" for the input and uses "PC Levels" as output!

See here for details:
http://avisynth.nl/index.php/Luminance_levels

I am playing both of the files with VLC player. I guess I need to go dig through the ffmpeg settings and see if there is one that is butchering the luma. FYI, when I output with mainconcept encoder from Adobe premier it does the same thing.

UPDATE: Finally solved this. For future reference, The custom encoder parameter for X264 launcher is --range pc
I REALLY wish this was not even an option, because it defaults to the wrong setting in an age where we all have HDTV's with a full color range, and is more likely to just make life irritating for people trying to do an encode. MuldeR, I REALLY wish you would set the default to "PC" instead of "Auto"....

[LoRd_MuldeR]

UPDATE: Finally solved this. For future reference, The custom encoder parameter for X264 launcher is --range pc
I REALLY wish this was not even an option, because it defaults to the wrong setting in an age where we all have HDTV's with a full color range, and is more likely to just make life irritating for people trying to do an encode.

Using the --range option does nothing but indicating the "intended" luma-range via VUI (Video Usability Info). So it's a meta-info added to the stream.

This will have an effect if and only if, the decoder actually looks at the VUI and performs the YUV to RGB conversion accordingly. Many "real world" decoder do not do this and just assume "TV Levels". And, of course, this can work only, if the decoder actually outputs RGB. In practice, however, the decoder will usually output YUV and leave the required YUV to RGB conversion to the video renderer - which generally has no access to the VUI and thus will probably just assume "TV Levels".

tl;dr: Encoding YUV with "PC Levels" is pretty unusual - and even with the proper VUI it's not going to produce the desired screen output in many playback scenarios. Just use "TV Levels", as the rest of the world does ;)

MuldeR, I REALLY wish you would set the default to "PC" instead of "Auto"....

This could only be achieved by patching x264. Or by convincing the x264 devs to change their default. But I don't think it's a good idea, for the reasons outlined above.

[ben_franklin]

tl;dr: Encoding YUV with "PC Levels" is pretty unusual - and even with the proper VUI it's not going to produce the desired screen output in many playback scenarios. Just use "TV Levels", as the rest of the world does ;)


But every modern bluray is encoded with full range levels and not "TV levels".

I sure would like to know what their exact workflow is for this.

[ben_franklin]

And now HEVC encoding is giving me grief....

I created an avi file from tif's using FFMPEG
4:2:2 YUV (Y42B)
4096x1706
24 FPS

And then when I try and encode with HEVC I get:

Simple x264 Launcher (Build #994), built 2015-11-18

Job started at 2015-12-22, 10:12:33.

Source file : \ffmpeg\bin\movie.avi
Output file : \Videos\movie.hevc

--- SYSTEMINFO ---

Binary Path : C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2
Avisynth : No
VapourSynth : No

--- SETTINGS ---

Encoder : x265 (H.265/HEVC), x64, 8-Bit
Source : Native
RC Mode : CRF
Preset : veryslow
Tuning : <None>
Profile : <Unrestricted>
Custom : <None>

--- CHECK VERSION ---

Detect video encoder version:

Creating process:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x64\x265_8bit_x64.exe" --version

x265 [info]: HEVC encoder version 1.8+106-e8f9a60d4cd9
x265 [info]: build info [Windows][GCC 5.2.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX

> x265 version: 1.8+106

--- ENCODING VIDEO ---

Creating encoder process:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x64\x265_8bit_x64.exe" --crf 2.0 --preset veryslow --output \Videos\movie.hevc \ffmpeg\bin\movie.avi

x265 [error]: yuv: width, height, and FPS must be specified
x265 [error]: unable to open input file <\ffmpeg\bin\movie.avi>

PROCESS EXITED WITH ERROR CODE: 1

[LoRd_MuldeR]

But every modern bluray is encoded with full range levels and not "TV levels".

Nope, definitely "TV range" in my experience ;)

It's just that your playback chain knows about this and therefore performs the required "range extension" before the video reaches your screen. So, usually, this happens without you worrying about it.

But you can check this yourself easily: Just be sure that your H.264 decoder gives you to "untouched" YUV data and then explicitly perform the YUV to RGB conversion yourself, e.g. using Avisynth' ConvertToRGB32() (http://avisynth.nl/index.php/Convert) function.

You'll see that using "Rec709" matrix (i.e. assuming TV/Limited range) gives the proper output, while using "PC.709" matrix (i.e. assuming PC/Full range) results in "washed out" colors.

Example:
DGSource("heat.dgi")
a = Last.ConvertToRGB32("Rec709").Subtitle("TV Range")
b = Last.ConvertToRGB32("PC.709").Subtitle("PC Range")
Interleave(a,b)

Result:
* http://i.imgbox.com/cq6NhoFJ.png
* http://i.imgbox.com/grL9SvCF.png


--- ENCODING VIDEO ---

Creating encoder process:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x64\x265_8bit_x64.exe" --crf 2.0 --preset veryslow --output \Videos\movie.hevc \ffmpeg\bin\movie.avi

x265 [error]: yuv: width, height, and FPS must be specified
x265 [error]: unable to open input file <\ffmpeg\bin\movie.avi>

PROCESS EXITED WITH ERROR CODE: 1

As explained before, x265 CLI does not read anything, except "raw" YUV or YUV4MPEG.

If you try to feed it with an AVI nonetheless, it will treat the AVI as "raw" YUV (as it has no idea about AVI) - which of course requires that the width, height, and FPS are specified explicitly.

The advantage of YUV4MPEG is that it has a small header indicating the resolution and frame-rate, so this does not need to be specified separately...

[ben_franklin]

Nope, definitely "TV range" ;)
You'll see that using "Rec709" matrix (i.e. assuming TV/Limited range) gives the proper output, while using "PC.709" matrix (i.e. assuming PC/Full range) results in "washed out" colors.


When I take HD footage with a GH4 I don't use Rec709, as it looks terrible. I guess Rec709's importance comes into play at the last stages of output. More research needed.





As explained before, x265 CLI does not read anything, except "raw" YUV or YUV4MPEG.

If you try to feed it with an AVI nonetheless, it will treat the AVI as "raw" YUV (as it has no idea about AVI) - which of course requires that the width, height, and FPS are specified explicitly.

The advantage of YUV4MPEG is that it has a small header indicating the resolution and frame-rate, so this does not need to be specified separately...

I cant find anything that will let me specify "width, height" of the AVI to x265 CLI. Alternatively I cannot figure out which codecs/formats/pix formats from looking at the FFMPEG documentation would give me the right "raw" YUV file when converting that group of TIF files. I got it to work with the x264, but alas no dice on x265. Help?

[LoRd_MuldeR]

When I take HD footage with a GH4 I don't use Rec709, as it looks terrible. I guess Rec709's importance comes into play at the last stages of output. More research needed.

Rec.709 with limited range (TV Levels) is the standard for consumer HD video. I'm not sure the BD spec explicitely requires this (quite possible though), but it certainly is the de facto standard.

I cant find anything that will let me specify "width, height" of the AVI to x265 CLI. Alternatively I cannot figure out which codecs/formats/pix formats from looking at the FFMPEG documentation would give me the right "raw" YUV file when converting that group of TIF files. I got it to work with the x264, but alas no dice on x265. Help?

Even if you could, it wouldn't help!

x265 CLI would still read your AVI file as if it was "raw" YUV (because it has no idea about AVI files), while in fact it is not "raw" YUV, but some kind of video (maybe compressed, maybe not) wrapped in an AVI container.

As explained before, if you want to feed x265 with uncompressed YUV data, just use the YUV4MPEG (Y4M) format.

And, if you want to feed x265 with anything else (e.g. AVI file), but you don't want to create a (potentially huge) intermediate Y4M file, then just frame-serve the video from Avisynth or VapourSynth ;)

Avisynth is not rocket science, a one-liner suffices:
FFVideoSource("C:\path to your source\input.avi")

[ben_franklin]

Rec.709 with limited range (TV Levels) is the standard for consumer HD video. I'm not sure the BD spec explicitely requires this (quite possible though), but it's the de facto standard.



Even if you could, it wouldn't help!

x265 CLI would still read your AVI file as if it was "raw" YUV (because it has no idea about AVI files), while in fact it is not "raw" YUV, but some kind of video (maybe compressed, maybe not) wrapped in an AVI container.

As explained before, if you want to feed x265 with YUV data, use the YUV4MPEG (Y4M) format.

If you want to feed x265 with anything else (e.g. AVI file), and if you don't want to create a (potentially huge) intermediate Y4M file, then just frame-serve the video from Avisynth or VapourSynth ;)

Avisynth is not rocket science, a one-liner suffices:
FFVideoSource("C:\path to your source\input.avi")

I'm completely Avisynth and VapourSynth ignorant. I don't care what the file type is, I just really want to feed x265 an uncompressed file. Is the Avisynth/VapourSynth route the only way to do this?

[LoRd_MuldeR]

Is the Avisynth/VapourSynth route the only way to do this?

Nope. But it's certainly the recommended way. And it allows for advanced video processing. Most of the sophisticated video filters you find on the net are either written as Avisynth scripts or as Avisynth plug-ins (or as a combination thereof).

Anyway, I explained an alternative way to get your video into x265 before. Note, however, that there is no direct support for that alternative way in the Simple x264/x265 Launcher, while Avisynth/VapourSynth works smoothly.

[r0lZ]

OT, sorry:
Since you have just discussed the interesting topic ot TV/RGB levels, I would like to know what does ConvertToRGB32() without specifying the matrix. Is it smart enough to figure out what matrix to use?

And what should be used if you have to convert YV12 from a BD to RGB, to use some filters working only in RGB, and then back to YV12 ? Is it ConvertToRGB32("Rec709").WhateverRGBfilter().ConvertToYV12(matrix="PC.709") or the opposite? (I would like to let the RGB filter work on the full PC range of course.)
In other words, is it correct to say that the matrix specified for ConvertTo* must match the input video range ? Or does it have to specify the desired output range?

[EDIT] I've found this excellent explanation (http://forum.doom9.org/showthread.php?p=1425891#post1425891) that clarifies already many things. Also, the avisynth doc tells that the default matrix is Rec601, so forget my first question. (Rec601 is not really a good choice for HD, but avisynth is becoming old!) However, I'm still wondering how to convert to RGB and back to YV12 with the minimal loss of quality.

[LoRd_MuldeR]

And what should be used if you have to convert YV12 from a BD to RGB, to use some filters working only in RGB, and then back to YV12 ? Is it ConvertToRGB32("Rec709").WhateverRGBfilter().ConvertToYV12(matrix="PC.709") or the opposite? (I would like to let the RGB filter work on the full PC range of course.)

I think for the ConvertToRGB32() call you should use whatever "matches" your source, so that you get proper "full range" RGB. This would probably be "Rec709" in most cases nowadays (HD footage), but it really depends on the source.

For the ConvertToYV12() call you should use whatever you need for the final encode. In most cases this probably is "Rec709" again... as said before, "full range" YUV is unusual for consumer footage and thus more likely to cause playback issues.

[r0lZ]

OK, thanks. That makes sense.

[LoRd_MuldeR]

New test build available now:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2016-01-02.TEST.exe/download

(Updated x265 binaries to latest revision)

[tona69]

Hi, I have this error

Simple x264 Launcher (Build #1004), built 2016-01-02

Job started at 2016-01-02, 15:26:38.

Source file : C:\Downloads\La Vision de Escaflowne\Escaflowne - 013.vpy
Output file : C:\Users\#####\Videos\Escaflowne - 013.mp4

--- SYSTEMINFO ---

Binary Path : C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2
Avisynth : Yes
VapourSynth : Yes

--- SETTINGS ---

Encoder : x264 (H.264/AVC), x64, 8-Bit
Source : VapourSynth (vpy)
RC Mode : 2-Pass
Preset : slow
Tuning : Animation
Profile : High

--- CHECK VERSION ---

Detect video encoder version:

Creating process:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x64\x264_8bit_x64.exe" --version

x264 0.148.2638 7599210
(libswscale 4.0.100)
(libavformat 57.4.100)
(ffmpegsource 2.22.0.0)
built by Komisar on Oct 16 2015, gcc: 4.8.4 (multilib.generic.Komisar)
x264 configuration: --bit-depth=8 --chroma-format=all
libx264 configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

Detect video source version:


VPY INPUT REQUIRES VAPOURSYNTH, BUT IT IS *NOT* AVAILABLE !!!

[LoRd_MuldeR]

Hi, I have this errorVPY INPUT REQUIRES VAPOURSYNTH, BUT IT IS *NOT* AVAILABLE !!!

Well, you are trying to use a .vpy file as your input, but apparently VapourSynth is not installed. This clearly can't work ;)

If, however, you are trying to say that Simple x264 Launcher did not detected VapourSynth although it is installed (what version?) on your system, then please run the application with --console and post your log...

[tona69]

Well, you are trying to use a .vpy file as your input, but apparently VapourSynth is not installed. This clearly can't work ;)

If, however, you are trying to say that Simple x264 Launcher did not detected VapourSynth although it is installed (what version?) on your system, then please run the application with --console and post your log...

Here is:

Simple x264 Launcher v2.65.1004 - use 64-Bit x264 with 32-Bit Avisynth
Copyright (c) 2004-2016 LoRd_MuldeR <mulder2@gmx.de>. Some rights reserved.
Built on 2016-01-02 at 00:13:59 with MSVC 2015.1 for Win-x86.

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License <http://www.gnu.org/>.
Note that this program is distributed with ABSOLUTELY NO WARRANTY.

This application is powerd by MUtils library v1.06 (2016-01-02, 00:13:35).

Command-Line Arguments:
--console

CPU vendor id : GenuineIntel (Intel=1)
CPU brand string : Intel(R) Core(TM) i5-3330S CPU @ 2.70GHz
CPU signature : Family=6 Model=58 Stepping=9
CPU capabilities : MMX=1 SSE=1 SSE2=1 SSE3=1 SSSE3=1 SSE4=1 SSE4.2=1 x64=1
Number of CPU's : 4

Using Qt v4.8.7 [2015-08-05], DLL, Windows msvc release full-config
Compiled with Qt v4.8.7 [2015-05-07], Windows msvc release full-config

Running on Windows 10 or Windows Server 2014 (Preview) (NT v10.0).

Failed to resolve function: ntdll::wine_get_version
Library Path:
C:/Program Files (x86)/MuldeR/Simple x264 Launcher v2

Process token elevation type: Limited -> not elevated.

libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: cHRM chunk does not match sRGB
[Validating binaries]
Binaries checker thread has been created, please wait...
C:/Program Files (x86)/MuldeR/Simple x264 Launcher v2/toolset/x86/x264_8bit_x86.exe
C:/Program Files (x86)/MuldeR/Simple x264 Launcher v2/toolset/x86/x264_10bit_x86.exe
C:/Program Files (x86)/MuldeR/Simple x264 Launcher v2/toolset/x64/x264_8bit_x64.exe
C:/Program Files (x86)/MuldeR/Simple x264 Launcher v2/toolset/x64/x264_10bit_x64.exe
C:/Program Files (x86)/MuldeR/Simple x264 Launcher v2/toolset/x86/x265_8bit_x86.exe
C:/Program Files (x86)/MuldeR/Simple x264 Launcher v2/toolset/x86/x265_10bit_x86.exe
C:/Program Files (x86)/MuldeR/Simple x264 Launcher v2/toolset/x86/x265_12bit_x86.exe
C:/Program Files (x86)/MuldeR/Simple x264 Launcher v2/toolset/x64/x265_8bit_x64.exe
C:/Program Files (x86)/MuldeR/Simple x264 Launcher v2/toolset/x64/x265_10bit_x64.exe
C:/Program Files (x86)/MuldeR/Simple x264 Launcher v2/toolset/x64/x265_12bit_x64.exe
C:/Program Files (x86)/MuldeR/Simple x264 Launcher v2/toolset/x86/avs2yuv_x86.exe
C:/Program Files (x86)/MuldeR/Simple x264 Launcher v2/toolset/x86/avs_check_x86.exe
C:/Program Files (x86)/MuldeR/Simple x264 Launcher v2/toolset/x64/avs2yuv_x64.exe
C:/Program Files (x86)/MuldeR/Simple x264 Launcher v2/toolset/x64/avs_check_x64.exe
C:/Program Files (x86)/MuldeR/Simple x264 Launcher v2/toolset/common/wget.exe
C:/Program Files (x86)/MuldeR/Simple x264 Launcher v2/toolset/common/gpgv.exe
C:/Program Files (x86)/MuldeR/Simple x264 Launcher v2/toolset/common/wupd.exe
Binaries checker thread finished.

[Check for Avisynth support]
Avisynth thread has been created, please wait...
Avisynth 32-Bit support is being tested.
Avisynth was detected successfully (current version: 2.60).
Avisynth DLL path: C:\Windows\SysWOW64\avisynth.dll
Avisynth 32-Bit edition found!
Avisynth 64-Bit support is being tested.
Avisynth was detected successfully (current version: 2.60).
Avisynth DLL path: C:\Windows\System32\AviSynth.dll
Avisynth 64-Bit edition found!
Avisynth thread finished.
Avisynth support is officially enabled now! [x86=1, x64=1]

[Check for VapourSynth support]
VapourSynth thread has been created, please wait...
VapourSynth Dir: C:/Program Files (x86)/VapourSynth
VapourSynth EXE: C:/Program Files (x86)/VapourSynth/core32/vspipe.exe
VapourSynth DLL: C:/Program Files (x86)/VapourSynth/core32/vapoursynth.dll
VapourSynth 32-Bit edition *not* found!
VapourSynth EXE: C:/Program Files (x86)/VapourSynth/core64/vspipe.exe
VapourSynth DLL: C:/Program Files (x86)/VapourSynth/core64/vapoursynth.dll
VapourSynth version was detected successfully.
VapourSynth 64-Bit edition found!
VapourSynth thread finished.
VapourSynth support is officially enabled now! [x86=0, x64=1]


And Vapoursynth:

C:\Program Files (x86)\VapourSynth\core64>vspipe.exe -v
VapourSynth Video Processing Library
Copyright (c) 2012-2015 Fredrik Mellbin
Core R29
API R3.2
Options: -

C:\Program Files (x86)\VapourSynth\core64>

[LoRd_MuldeR]

Hm, looks like VapourSynth was detected successfully:
[Check for VapourSynth support]
VapourSynth thread has been created, please wait...
VapourSynth Dir: C:/Program Files (x86)/VapourSynth
VapourSynth EXE: C:/Program Files (x86)/VapourSynth/core32/vspipe.exe
VapourSynth DLL: C:/Program Files (x86)/VapourSynth/core32/vapoursynth.dll
VapourSynth 32-Bit edition *not* found!
VapourSynth EXE: C:/Program Files (x86)/VapourSynth/core64/vspipe.exe
VapourSynth DLL: C:/Program Files (x86)/VapourSynth/core64/vapoursynth.dll
VapourSynth version was detected successfully.
VapourSynth 64-Bit edition found!
VapourSynth thread finished.
VapourSynth support is officially enabled now! [x86=0, x64=1]

Are you 100% sure this log is from the same run where you got the VapourSynth error when trying to encode from VPY file? :confused:

[tona69]

Hm, looks like VapourSynth was detected successfully:


Are you 100% sure this log is from the same run where you got the VapourSynth error when trying to encode from VPY file? :confused:

Yes, is the first time that show me that error, I alway use your program to encode since 2010 but with avs files and then Vapoursynth

[tona69]

Hm, looks like VapourSynth was detected successfully:


Are you 100% sure this log is from the same run where you got the VapourSynth error when trying to encode from VPY file? :confused:

http://prntscr.com/9lop58
http://prntscr.com/9lop58

[LoRd_MuldeR]

Yes, is the first time that show me that error, I alway use your program to encode since 2010 but with avs files and then Vapoursynth

So what did you change right before it started failing?

Update to a newer program version? If so, what is the last version that was still working okay? Otherwise, maybe you updated to a newer VapourSynth version?

[LoRd_MuldeR]

It's working for me with VapourSynth R26:
C:\Program Files (x86)\VapourSynth\core32>vspipe.exe -v
VapourSynth Video Processing Library
Copyright (c) 2012-2014 Fredrik Mellbin
Core R26
API R3.1Simple x264 Launcher (Build #1004), built 2016-01-02

Job started at 2016-01-03, 20:26:10.

Source file : C:\Program Files (x86)\VapourSynth\Test.vpy
Output file : C:\Users\MuldeR\Videos\Test.hevc

--- SYSTEMINFO ---

Binary Path : E:\DeLpHi\x264_x64_launcher\bin\Win32\Release
Avisynth : Yes
VapourSynth : Yes

--- SETTINGS ---

Encoder : x265 (H.265/HEVC), x64, 8-Bit
Source : VapourSynth (vpy)
RC Mode : CRF
Preset : veryslow
Tuning : <None>
Profile : <Unrestricted>
Custom : --psy-rd 2.0

--- CHECK VERSION ---

Detect video encoder version:

Creating process:
E:\DeLpHi\x264_x64_launcher\bin\Win32\Release\toolset\x64\x265_8bit_x64.exe --version

x265 [info]: HEVC encoder version 1.8+187-da48f2690076
x265 [info]: build info [Windows][GCC 5.2.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle

Detect video source version:

Creating process:
"C:\Program Files (x86)\VapourSynth\core32\vspipe.exe" --version

VapourSynth Video Processing Library
Copyright (c) 2012-2014 Fredrik Mellbin
Core R26
API R3.1

> x265 version: 1.8+187
>
VapourSynth version: r26 (API r3)

--- GET SOURCE INFO ---

Creating process:
"C:\Program Files (x86)\VapourSynth\core32\vspipe.exe" --info C:\PROGRA~2\VAPOUR~1\test.vpy -

Width: 920
Height: 712
Frames: 6220
FPS: 50000/1000 (50.000 fps)
Format Name: YUV420P8
Color Family: YUV
Bits: 8
SubSampling W: 1
SubSampling H: 1

Resolution: 920x712
Frame Rate: 50000/1000
No. Frames: 6220

--- ENCODING VIDEO ---

Creating input process:
"C:\Program Files (x86)\VapourSynth\core32\vspipe.exe" --y4m C:\PROGRA~2\VAPOUR~1\test.vpy -

Creating encoder process:
E:\DeLpHi\x264_x64_launcher\bin\Win32\Release\toolset\x64\x265_8bit_x64.exe --crf 20.0 --preset veryslow --psy-rd 2.0 --output C:\Users\MuldeR\Videos\Test.hevc --frames 6220 --y4m -

y4m [info]: 920x712 fps 50000/1000 i420p8 unknown frame count
raw [info]: output file: C:\Users\MuldeR\Videos\Test.hevc
x265 [info]: HEVC encoder version 1.8+187-da48f2690076
x265 [info]: build info [Windows][GCC 5.2.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
x265 [info]: Main profile, Level-3.1 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: frame threads / pool features : 2 / wpp(12 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / 0 / 1
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-20.0 / 0.60
x265 [info]: tools: rect amp limit-modes rd=6 psy-rd=2.00 rdoq=2 psy-rdoq=1.00
x265 [info]: tools: signhide tmvp b-intra strong-intra-smoothing deblock sao

[tona69]

So what did you change right before it started failing?

Update to a newer program version? If so, what is the last version that was still working okay? Otherwise, maybe you updated to a newer VapourSynth version?

My computer is x64, previously it used the 32-bit version of Vapoursynth, Avisynthand Python, but uninstalled to use 64-bit was when the error occurred

I run the same script in in StaxRip_x64 and is fine.

[LoRd_MuldeR]

Just tried VapourSynth R29, but everything is working perfectly fine:
http://i.imgur.com/iGZ9xDK.jpg

[tona69]

Just tried VapourSynth R29, but everything is working perfectly fine:
http://i.imgur.com/iGZ9xDK.jpg

Simple x264/x265 Launcher (http://prntscr.com/9lozrv)

StaxRip x64 (http://prntscr.com/9lp19p)

I reinstalled all again and woks fine all : )

Works again (http://prntscr.com/9lpb9j)

[LoRd_MuldeR]

Simple x264/x265 Launcher (http://prntscr.com/9lozrv)

StaxRip x64 (http://prntscr.com/9lp19p)

I reinstalled all again and woks fine all : )

Works again (http://prntscr.com/9lpb9j)

Okay, after thinking about it a bit more, I probably know what your problem was:

If you have only the 32-Bit version VapourSynth installed, but you have selected "prefer 64-Bit" in the preferences, it was going to fail at the start of the encode.

Similarly, if you have only the 64-Bit version VapourSynth installed, but you have not selected "prefer 64-Bit" in the preferences, encode was going to fail as well.

This Test build should improve the "32-Bit vs. 64-Bit" selection logic for the Avisynth/VapourSynth source filters:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2016-01-04.TEST.exe/download

[tona69]

Okay, after thinking about it a bit more, I probably know what your problem was:

If you have only the 32-Bit version VapourSynth installed, but you have selected "prefer 64-Bit" in the preferences, it was going to fail at the start of the encode.

Similarly, if you have only the 64-Bit version VapourSynth installed, but you have not selected "prefer 64-Bit" in the preferences, encode was going to fail as well.

This Test build should improve the "32-Bit vs. 64-Bit" selection logic for the Avisynth/VapourSynth source filters:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2016-01-04.TEST.exe/download

Testing (http://prntscr.com/9noye8)

[movmasty]

To make it simple, if one doesnt have Xsinth installed, what input can give?

Why it is not accepting my Huffy avi?

You need FFmpeg for this?

Why you could even have a patch for audio but not for intermediate uncompressed avi?

Why doesnt let me to delete the 64 binaries in a 32 bit environment?

So, my input was illegal and it stopped, but i put the following string like command

--ctu 32 --cutree --keyint 150 --min-keyint 10 --ipratio 1.9 --nr-inter 390 --sar 16:15 --no-strong-intra-smoothing

Is it legal?

[LoRd_MuldeR]

To make it simple, if one doesnt have Xsinth installed, what input can give?

x264: Pretty much anything that can be decoded with libavcodec/libavformat (FFmpeg libraries). Which is pretty much everything.

x265: "Raw" YUV data in YUV4MPEG2 (http://wiki.multimedia.cx/index.php?title=YUV4MPEG2) format.


Why it is not accepting my Huffy avi?

What is "it"?

If you refer to x265 here: At this time, x265 doesn't support reading (compressed) AVI files. Or anything else, except for YUV4MPEG2.

Just frame-serve the input from Avisynth/VaourSynth. Or pipe from FFmpeg. That's it.


You need FFmpeg for this?

If you want to pipe the input from FFmpeg, then, obviously, you are going to need FFmepg.

Avisynth/VaourSynth doesn't need FFmpeg (as a standalone application), but you probably want to use FFMS2 (https://github.com/FFMS/ffms2/releases/latest) (FFmpegSource).


Why you could even have a patch for audio but not for intermediate uncompressed avi?

Don't know what you mean. Neither x264 nor x265 handles audio.

AFAIK, there is an unofficial "audio support" patch for x264, but that has never been committed (and probably never will).


Why doesnt let me to delete the 64 binaries in a 32 bit environment?

Again, what is "it" ???

So, my input was illegal and it stopped, but i put the following string like command


--ctu 32 --cutree --keyint 150 --min-keyint 10 --ipratio 1.9 --nr-inter 390 --sar 16:15 --no-strong-intra-smoothing

Is it legal?

"legal" in what regard?

[movmasty]

I was a bit imprecise sorry,

I refer to x265, it doesnt accet avi in huffy, as i said i dont have avisinth,
could you put any prog able to feed x265 in the pack?

Since im on win32, i tryed to delete the binaries in 64 bits, it is not possible.

is
--ctu 32 --cutree --keyint 150 --min-keyint 10 --ipratio 1.9 --nr-inter 390 --sar 16:15 --no-strong-intra-smoothing
ok for x265?

[LoRd_MuldeR]

I was a bit imprecise sorry,

I refer to x265, it doesnt accet avi in huffy, as i said i dont have avisinth

That's easy to fix:
http://sourceforge.net/projects/avisynth2/

could you put any prog able to feed x265 in the pack?

In theory support for piping input from FFmpeg could be implemented. But it's currently not on my TODO list.

Just use FFMS2 ;)


Since im on win32, i tryed to delete the binaries in 64 bits, it is not possible.

Just ignore the 64-Bit binaries. They will not be used on your system, but they won't hurt either.

is
--ctu 32 --cutree --keyint 150 --min-keyint 10 --ipratio 1.9 --nr-inter 390 --sar 16:15 --no-strong-intra-smoothing
ok for x265?

I don't see anything "wrong" with this command. But is it a "good" idea to use?

Totally depends on what you are trying to achieve...

[movmasty]

OK thanks

[Minister]

Try with this test version:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2015-12-20.TEST-2.exe/download


Sorry to reply so late to this.

What you did is terrific! Solves the issue I was having exactly. Thank you very much for that.

Using the newer test build now.

:)

[LoRd_MuldeR]

Simple x264 Launcher v2.65

Version 2.65 [2016-01-24]
* Added menu entry to remove all completed or enqueued jobs at once
* Improved 32-Bit vs. 64-Bit selection for Avisynth/VapourSynth
* Updated x264 to revision 2665
* Updated x265 to version 1.8+212

[LoRd_MuldeR]

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

Version 2.66 [2016-02-06]
* Updated x265 to version 1.9+3

[2-perf]

Hi,

I'm a total newbie to video encoding. A friend at work heard me saying that I was using Handbrake to encode some Quicktime files to Blu-ray and told me I should be using a frame server... WTF? I replied to him!

Anyway he came to my place, set me up with:

- python-3.5.1-amd64.exe
- ffms2-2.22-msvc (I'm using the x64 flavor)
- vapoursynth-r29.exe (x64 flavor I guess)
- x264_launcher.2016-02-06.exe

He wrote me a VapourSynth script whish looks like this:

import vapoursynth as vs

# get the core instance
core = vs.get_core()

# load a native vapoursynth plugin, you can also use the auto-loading
# you should use absolute paths as the working directory may not be what you think it is
core.std.LoadPlugin(r'S:\Dropbox\softwares\portableapps\codec_encoder\ffms2-2.22-msvc\x64\ffms2.dll')

# open a video file; ret is now a clip object

path = r'D:\restauration\projet\tropico\deliveries\master\tropico.mov'

ret = core.ffms2.Source( source = path )

# flip the video a bit
#ret = core.std.Transpose( ret )

# set the clip to be output
ret.set_output()

The things is it fails 9 times out of 10 when trying to start the second pass.

Here's the .log (Well, I hope). Sorry I'm a digital colorist not a computer geek. :p

Simple x264 Launcher (Build #1012), built 2016-02-06

Job started at 2016-02-18, 22:19:28.

Source file : D:\encodage\projet\tropico\script.vpy
Output file : D:\encodage\projet\tropico\output\script.264

--- SYSTEMINFO ---

Binary Path : C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2
Avisynth : No
VapourSynth : Yes

--- SETTINGS ---

Encoder : x264 (H.264/AVC), x64, 8-Bit
Source : VapourSynth (vpy)
RC Mode : 2-Pass
Preset : slower
Tuning : Film
Profile : High
Custom : --level 4.1 --ref 4 --subme 10 --psy-rd 1.00:0.15 --merange 24 --deadzone-inter 21 --deadzone-intra 11 --no-fast-pskip --cqm flat --chroma-qp-offset 3 --threads 12 --lookahead-threads 1 --slices 4 --no-dct-decimate --bluray-compat --vbv-maxrate 38000 --vbv-bufsize 30000 --bframes 3 --b-pyramid 1 --weightb --open-gop --weightp 1 --keyint 24 --min-keyint 1 --rc-lookahead 24 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --qcomp 0.00 --qpmin 0

--- CHECK VERSION ---

Detect video encoder version:

Creating process:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x64\x264_8bit_x64.exe" --version

x264 0.148.2665 a01e339
(libswscale 4.0.100)
(libavformat 57.21.101)
(ffmpegsource 2.22.0.1)
built by Komisar on Jan 18 2016, gcc: 4.8.4 (multilib.generic.Komisar)
x264 configuration: --bit-depth=8 --chroma-format=all
libx264 configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

Detect video source version:

Creating process:
"C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" --version

VapourSynth Video Processing Library
Copyright (c) 2012-2015 Fredrik Mellbin
Core R29
API R3.2
Options: -

> x264 revision: 2665 (core #148)
>
VapourSynth version: r29 (API r3)

--- GET SOURCE INFO ---

Creating process:
"C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" --info D:\encodage\projet\tropico\script.vpy -

Width: 1920
Height: 1080
Frames: 7491
FPS: 24000/1001 (23.976 fps)
Format Name: YUV422P10
Color Family: YUV
Bits: 10
SubSampling W: 1
SubSampling H: 0

Resolution: 1920x1080
Frame Rate: 24000/1001
No. Frames: 7491

--- ENCODING PASS #1 ---

Creating input process:
"C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" --y4m D:\encodage\projet\tropico\script.vpy -

Creating encoder process:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x64\x264_8bit_x64.exe" --bitrate 35000 --pass 1 --stats D:\encodage\projet\tropico\output\script.stats --preset slower --tune film --profile high --level 4.1 --ref 4 --subme 10 --psy-rd 1.00:0.15 --merange 24 --deadzone-inter 21 --deadzone-intra 11 --no-fast-pskip --cqm flat --chroma-qp-offset 3 --threads 12 --lookahead-threads 1 --slices 4 --no-dct-decimate --bluray-compat --vbv-maxrate 38000 --vbv-bufsize 30000 --bframes 3 --b-pyramid 1 --weightb --open-gop --weightp 1 --keyint 24 --min-keyint 1 --rc-lookahead 24 --colorprim bt709 --transfer bt709 --colormatrix bt709 --qcomp 0.00 --qpmin 0 --output D:\encodage\projet\tropico\output\script.264 --frames 7491 --demuxer y4m --stdin y4m -

y4m [info]: 1920x1080p 0:0 @ 24000/1001 fps (cfr)
resize [warning]: converting from yuv422p16le to yuv420p16le
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [info]: profile Main, level 4.1
x264 [info]: frame I:339 Avg QP:10.89 size:467818
x264 [info]: frame P:2145 Avg QP:13.96 size:277862
x264 [info]: frame B:5007 Avg QP:18.17 size:120544
x264 [info]: consecutive B-frames: 5.1% 5.4% 35.4% 54.0%
x264 [info]: mb I I16..4: 41.5% 0.0% 58.5%
x264 [info]: mb P I16..4: 43.0% 0.0% 0.0% P16..4: 35.5% 0.0% 0.0% 0.0% 0.0% skip:21.5%
x264 [info]: mb B I16..4: 12.5% 0.0% 0.0% B16..8: 26.5% 0.0% 0.0% direct:26.8% skip:34.2% L0:10.4% L1:14.9% BI:74.8%
x264 [info]: direct mvs spatial:99.7% temporal:0.3%
x264 [info]: coded y,uvDC,uvAC intra: 94.9% 39.3% 19.9% inter: 47.8% 11.9% 5.6%
x264 [info]: i16 v,h,dc,p: 14% 9% 65% 12%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 9% 20% 10% 11% 11% 9% 10% 10%
x264 [info]: i8c dc,h,v,p: 65% 16% 16% 4%
x264 [info]: Weighted P-Frames: Y:3.0% UV:0.8%
x264 [info]: kb/s:34776.07
encoded 7491 frames, 25.61 fps, 34776.07 kb/s
vpyp [info]: Output 7491 frames in 292.32 seconds (25.63 fps)
Final file size is 1.26 GB bytes.

--- ENCODING PASS #2 ---

Creating input process:
"C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" --y4m D:\encodage\projet\tropico\script.vpy -

Creating encoder process:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x64\x264_8bit_x64.exe" --bitrate 35000 --pass 2 --stats D:\encodage\projet\tropico\output\script.stats --preset slower --tune film --profile high --level 4.1 --ref 4 --subme 10 --psy-rd 1.00:0.15 --merange 24 --deadzone-inter 21 --deadzone-intra 11 --no-fast-pskip --cqm flat --chroma-qp-offset 3 --threads 12 --lookahead-threads 1 --slices 4 --no-dct-decimate --bluray-compat --vbv-maxrate 38000 --vbv-bufsize 30000 --bframes 3 --b-pyramid 1 --weightb --open-gop --weightp 1 --keyint 24 --min-keyint 1 --rc-lookahead 24 --colorprim bt709 --transfer bt709 --colormatrix bt709 --qcomp 0.00 --qpmin 0 --output D:\encodage\projet\tropico\output\script.264 --frames 7491 --demuxer y4m --stdin y4m -

y4m [error]: bad sequence header magic
x264 [error]: could not open input file `-'

WARNING: Input process exited with error (code: -1073741819), your encode might be *incomplete* !!!

IMPORTANT: The Vapoursynth process terminated abnormally. This means Vapoursynth or one of your Vapoursynth-Plugin's just crashed.

PROCESS EXITED WITH ERROR CODE: -1

Thanks for your patience.

[LoRd_MuldeR]

As the error message says:
The Vapoursynth process terminated abnormally. This means Vapoursynth or one of your Vapoursynth-Plugin's just crashed.

-1073741819 = 0xC0000005 = STATUS_ACCESS_VIOLATION

So this is a problem with Vapoursynth or, more likely, one of the Vapoursynth plug-in's involved. Might as well be a hardware issue though...

[2-perf]

As the error message says:


It's a problem with Vapoursynth or, more likely, one of the Vapoursynth plug-in's involved. Might also be a hardware issue though...

Thanks LoRd_MuldeR. I'll post in the VapourSynth forum.

[djesteban]

As the error message says:


-1073741819 = 0xC0000005 = STATUS_ACCESS_VIOLATION

So this is a problem with Vapoursynth or, more likely, one of the Vapoursynth plug-in's involved. Might as well be a hardware issue though...

I tested this on my side out of curiosity. Tested with two .mov file, one encoded in DNxHD and the other one in ProRes.

I have the same issue than 2-perf where it will crash sometimes on 1-pass startup but mostly on 2nd pass, I would say and easy 8-9 times out of 10.

Seems definitively related to vapoursynth mishandling either .mov containers or the two codecs above... or both. Anyways, there's also ffms2 in the equation here so it could also be part of the issue, but I doubt it.
Encoding a h264 file causes no issue/crash at all.

[SuLyMaN]

Thank you Lord Mulder for this software :)

[LoRd_MuldeR]

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

Version 2.67 [2016-03-17]
* Updated x265 to version 1.9+96
* Fixed detection of 64-Bit VapourSynth in certain cases

[LoRd_MuldeR]

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

Version 2.68 [2016-04-09]
* Updated build environment to Visual Studio 2015 with Update-2
* Updated x265 to version 1.9+106

[RTW47]

vapoursynth input - still gives me troubles with x64 Python 3.5.1 and x64 vapoursynth R31 installed, on Windows 7 SP1;
v2.68.1018 --console as expected shows that 64-bit vapoursynth was successfully detected, unfortunately after selecting add job: I still get "VapourSynth is not/available!" message.
- additionally prefering 64-Bit source in the preferences - not helping;
edit:. trying update to 1024 build via web updater returns SendRequest Error;
edit1:. now noticed that if I just "Ignore&Continue", - everything works without actual problem;

[LoRd_MuldeR]

vapoursynth input - still gives me troubles with x64 Python 3.5.1 and x64 vapoursynth R31 installed, on Windows 7 SP1;
v2.68.1018 --console as expected shows that 64-bit vapoursynth was successfully detected, unfortunately after selecting add job: I still get "VapourSynth is not/available!" message.

Argh, there was a stupid mistake in one of the checks, so it was testing for Avisynth flag where it actually should be testing for VapourSynth flag :mad:

Should be fixed by now:
https://github.com/lordmulder/Simple-x264-Launcher/commit/f6e8d2e113fa26819e6e567482fef73df172f0e2#diff-914a5ac5409e8ddb42c98e1f76e206ff

Please try new TEST version:
https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher-TEST.2016-04-28.exe/download

edit:. trying update to 1024 build via web updater returns SendRequest Error;
edit1:. now noticed that if I just "Ignore&Continue", - everything works without actual problem;

Works for me :confused:

(Probably a short server outage on SF.net)

[RTW47]

Should be fixed by now:
https://github.com/lordmulder/Simple-x264-Launcher/commit/f6e8d2e113fa26819e6e567482fef73df172f0e2#diff-914a5ac5409e8ddb42c98e1f76e206ff

Please try new TEST version:
https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher-TEST.2016-04-28.exe/download

I can confirm that test build works properly.

[szabi]

Hi

Since update to version 2.69 this error occurs:
error: LoadPlugin: unable to load "C:\My Program Files\MeGUI\tools\lsmash\LSMASHSource.dll", Module not found. Install missing library?
I tried it and this avs script works correctly with megui and virtualdub.
What reason makes launcher to fail pluginload?

bye

[LoRd_MuldeR]

Hi

Since update to version 2.69 this error occurs:
error: LoadPlugin: unable to load "C:\My Program Files\MeGUI\tools\lsmash\LSMASHSource.dll", Module not found. Install missing library?

This is an Avisynth error, not Simple x264 Launcher error ;)

Note that Simple x264 Launcher is pretty much just a GUI that launches x264/x265 + Avs2YUV/VSPipe for you. So probably just coincidence that the issue happened to start after the v2.69 update. The real problem must be in Avisynth!


Anyway, one possible reason that comes to my mind:

Maybe your plug-in (LSMASHSource.dll) is 32-Bit and with VirualDub you are using 32-Bit Avisynth, so all is fine, but with Simple x264 Launcher you are trying to use 64-Bit Avisynth? Or the other way around.


[EDIT]

Another possible reason:

Maybe LSMASHSource.dll has a dependency on another DLL. And, when working with VirualDub, that DLL is picked up from VirualDub directory, or from whatever happens to be the "current" directory when you launch VirualDub. But when working with Simple x264 Launcher that other DLL can no longer be loaded, because it's neither in the avs2yuv.exe directory nor in whatever happens to be the "current" directory when you launch Simple x264 Launcher.

It's a very common pitfall with Avisynth plug-in's that have dependencies on other DLL's. Putting those other DLL's into the Avisynth plug-in directory, alongside the plug-in DLL, is not going to work! They must be in one of the directories where the host application (e.g. VirualDub or avs2yuv.exe) will be able to pick them up! One solution is to put the required DLL into "System32" directory. Then it can always be found. But, when doing so, be aware of DLL Hell problem...

[LoRd_MuldeR]

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

Version 2.70 [2016-04-29]
* Fixed potential VapourSynth error, when Avisynth is not installed
* Some installer improvements


I can confirm that test build works properly.

Thanks for confirming.

[szabi]

This is an Avisynth error, not Simple x264 Launcher error ;)

Note that Simple x264 Launcher is pretty much just a GUI that launches x264/x265 + Avs2YUV/VSPipe for you. So probably just coincidence that the issue happened to start after the v2.69 update. The real problem must be in Avisynth!


Anyway, one possible reason that comes to my mind:

Maybe your plug-in (LSMASHSource.dll) is 32-Bit and with VirualDub you are using 32-Bit Avisynth, so all is fine, but with Simple x264 Launcher you are trying to use 64-Bit Avisynth? Or the other way around.


[EDIT]

Another possible reason:

Maybe LSMASHSource.dll has a dependency on another DLL. And, when working with VirualDub, that DLL is picked up from VirualDub directory, or from whatever happens to be the "current" directory when you launch VirualDub. But when working with Simple x264 Launcher that other DLL can no longer be loaded, because it's neither in the avs2yuv.exe directory nor in whatever happens to be the "current" directory when you launch Simple x264 Launcher.

It's a very common pitfall with Avisynth plug-in's that have dependencies on other DLL's. Putting those other DLL's into the Avisynth plug-in directory, alongside the plug-in DLL, is not going to work! They must be in one of the directories where the host application (e.g. VirualDub or avs2yuv.exe) will be able to pick them up! One solution is to put the required DLL into "System32" directory. Then it can always be found. But, when doing so, be aware of DLL Hell problem...

Hi

I try to figure out what cause it, until that megui going to be used instead of your program which i prefer more.
However before update this issue did not exist.
Thanks.

bye

[LoRd_MuldeR]

However before update this issue did not exist.

Please confirm again that the issue still exists with latest version. If so, downgrade to the "old" version (v2.68), but do not touch anything else. Does that resolve the issue?

[szabi]

Hi

You were right the problem comes not from simple launcher.
It comes from megui. It was used to create script.
Megui does something what I do not see.
I reinstall it. Since that script works only with megui nothing else.
Until that I use ffms for indexing which works with simple.
Sorry for that I made a false conclusion.

bye

[LoRd_MuldeR]

It comes from megui. It was used to create script.
Megui does something what I do not see.
I reinstall it. Since that script works only with megui nothing else.
Until that I use ffms for indexing which works with simple.
Sorry for that I made a false conclusion.

Again, I suggest you do this:
Figure out if the plugin DLL that won't load is 32-Bit or 64-Bit. You can use this (https://mzrst.com/) tool, to check the "bitness" (see example here (http://i.imgur.com/C0E7Kqc.png)). If it is 32-Bit, can only work with 32-Bit Avisynth and thus only with 32-Bit programs; if it's 64-Bit, can only work with 64-Bit Avisynth and thus only with 64-Bit programs. The Simple x264 Launcher supports both "variants" of Avisynth – provided they are installed on your system – by using either 32-Bit or 64-Bit version of Avs2YUV. If both "variants" of Avisynth are installed, you can choose the preferred one in the preferences (this clearly has no effect, of only one "variant" is installed). Make sure it uses the version that matches the "bitness" of your plugin-in DLL!
Use this (http://www.dependencywalker.com/) tool to figure out if your plug-in DLL has some additional dependencies. You need the 32-Bit version of the tool for 32-Bit plug-in DLL, and the 64-Bit version for 64-Bit DLL. If it shows any dependencies other than standard Windows DLL's, then these additional DLL's will need to be in a path where they can be found when the plug-in DLL's get loaded into the Avs2YUV process – otherwise loading of the plug-in DLL is going to fail due to missing dependency!

[szabi]

Hi

Many thanks for your help and I apologize for my awkward situation.
Something happened with Microsoft Visual C++ 2015 Redistributable x86 (https://go.microsoft.com/fwlink/?LinkId=615459) which needed by L-SMASH.
It had to be reinstalled.
Somehow megui worked without it but simple did not.
I must say again thanks and sorry for it.

bye

[LoRd_MuldeR]

Here is a new TEST version with experimental NVEncC (http://forum.videohelp.com/threads/370223-NVEncC-by-rigaya-NVIDIA-GPU-encoding) (NVidia GPU encoding) support:
https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher-TEST.2016-05-08.exe/download

This requires a NVIDIA Kepler/Maxwell based GPU with driver 358.xx or higher!

[Zetti]

Why is there no option to select x86 or x64 when i choose to use NVEncC??

[LoRd_MuldeR]

Why is there no option to select x86 or x64 when i choose to use NVEncC??

There is. Isn't it? :confused:
http://i.imgur.com/Atx33Gu.png

[Zetti]

Sorry i mean 8-Bit and 10-Bit option for AVC and HEVC when i choose to use NVEncC.

[LoRd_MuldeR]

Sorry i mean 8-Bit and 10-Bit option for AVC and HEVC when i choose to use NVEncC.

I don't think NVEncC currently offers such an option, or am I missing something?

[Zetti]

I do not know because I am a beginner with NVEnc, so that's why I ask.

[LoRd_MuldeR]

Here is a new TEST version:
https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher-TEST.2016-05-13.exe/download

x265 updated to latest build.

[r0lZ]

I would like to know where you download the x265 binaries distributed with your GUI. There are 3 links in the help menu, but I can't find the 10 and 12-bit x86 versions:
builds.x265.eu (https://builds.x265.eu/) has no x86 versions any more.
x265.ru (http://x265.ru/en/builds/) has only the 8bit color depth in x86.
chromashift.org (http://chromashift.org) is dead.

Also, maybe you should remove or change the chromashift dead link.

[LoRd_MuldeR]

I would like to know where you download the x265 binaries distributed with your GUI.

https://www.mediafire.com/?6lfp2jlygogwa --- by LigH

[r0lZ]

Thanks. (And sorry for replying only now. For whatever reason, I haven't been notified of your reply.)

[tormento]

Big thanks for your neat software. I am moving to complete x64 encoding system and MeGUI was only x86 and full of too much bells and whistles.

I have find yours and it's really useful, giving me full control of everything ;)

[LoRd_MuldeR]

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

Version 2.71 [2016-06-12]
* Updated x265 to version 1.9+200
* Added experimental NVEncC (NVIDIA GPU encoding) support
* Code refactoring
* Fixed various included web-links

[easyfab]

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

What is current NVEnc quality compared to x264 or x265, I didn't find recent review and does newer GTX 1070/1080 have something new ( b-frames, SAO ...) vs GTX 960

[gamebox]

First of all, Mulder, THANK YOU for this wonderful software that is one of the rare tools to encode videos to x265 in Windows XP with all the necessary functionality and very low memory requirements! :)

Just two questions this time - is 64-bit version of x265 encoder compatible with Windows XP 64-bit? I got runtime errors related to kernel32.dll while trying to start encoding task. 32-bit version in 32-bit Windows XP works fine.

Secondly - is there a way to "trick" your software so that existing first pass stats file created by x265 can be reused to start encoding directly from second pass? I had an electricity issue at the beginning of the second pass but stats file is intact.

Thanks in advance :)

[LoRd_MuldeR]

Just two questions this time - is 64-bit version of x265 encoder compatible with Windows XP 64-bit? I got runtime errors related to kernel32.dll while trying to start encoding task. 32-bit version in 32-bit Windows XP works fine.

Not sure. I include plain MinGW builds of x265, as provided by LigH.

It's quite possible though that either the 64-Bit MinGW Runtime or the 64-Bit version x265 itself uses some Win32 API functions there were not available in Windows XP yet.

Note that the first "official" 64-Bit Windows was Vista, so that's probably what most developers regard as a minimum baseline for 64-Bit environments.


JSecondly - is there a way to "trick" your software so that existing first pass stats file created by x265 can be reused to start encoding directly from second pass? I had an electricity issue at the beginning of the second pass but stats file is intact.

No, there is no such function right now, sorry.

[LoRd_MuldeR]

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

Version 2.72 [2016-06-17]
* Now actually contains the "x64" version of NVEncC

[jones1913]

Thanks for this launcher, I like uncomplicated software that does one thing right.

Feature request:
It would be nice if there were an indicator on main window that shows the currently active frameserver mode (32/64 bit).
Because everytime I start the launcher I must open the settings and check whether mode is active.
Ultimately clicking on this indicator instantly could change the mode.

Or alternatively make this setting configurable per job.

Maybe you could consider this, Thanks.

[ProVision]

Hi firstly thanks for the amazing software have been using it since forever. Only one issue. When I put in my custom commands for x265, the program puts in a "-" at the end and ruins the encode. Here's the log:

Simple x264 Launcher (Build #1035), built 2016-06-17

Job started at 2016-06-28, 17:43:48.

Source file : C:\Users\Ali Tawfiq\Desktop\Desktop\Ritual Poster\1.avs
Output file : E:\Temporary\1 (3).hevc

--- SYSTEMINFO ---

Binary Path : E:\Video stuff\x264_launcher.2014-11-02
Avisynth : Yes
VapourSynth : No

--- SETTINGS ---

Encoder : x265 (HEVC/H.265), 64-Bit (x64), 12-Bit
Source : Avisynth (avs)
RC Mode : CRF
Preset : medium
Tuning : <None>
Profile : <Unrestricted>
Custom : --log-level 4 --wpp --ref 6 --rd 6 --cu 64 --min-cu-size 8 --limit-refs 3 --rect --amp --limit-modes --b-intra --cu-lossless --rd-refine --rdoq-level 2 --tu-intra-depth 4 --tu-inter-depth 4 --tskip --rdpenalty 2 --max-tu-size 32 --max-merge 5 --me 3 --subme 7 --merange 200 --temporal-mvp --weightp --weightb --strong-intra-smoothing --psy-rd 3.0 --psy-rdoq 1.0 --open-gop --scenecut 35 --rc-lookahead 225 --lookahead-slices 0 --b-adapt 2 --bframes 7 --bframe-bias 40 --b-pyramid --crf-max 24 --crf-min 16 --aq-mode 3 --aq-strength 2 --qg-size 64 --cutree --qcomp 0.84 --qblur 0.9 --cplxblur 60 --sao --deblock=-1:-3 --info

--- CHECK VERSION ---

Detect video encoder version:

Creating process:
"E:\Video stuff\x264_launcher.2014-11-02\toolset\x64\x265_12bit_x64.exe" --version

x265 [info]: HEVC encoder version 1.9+200-6098ba3e0cf16b11
x265 [info]: build info [Windows][GCC 5.3.0][64 bit] 12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX

Detect video source version:

Creating process:
"E:\Video stuff\x264_launcher.2014-11-02\toolset\x86\avs2yuv_x86.exe"

Avs2YUV 0.24bm3

> x265 version: 1.9+200
> Avs2YUV version: 0.24.3

--- GET SOURCE INFO ---

Creating process:
"E:\Video stuff\x264_launcher.2014-11-02\toolset\x86\avs2yuv_x86.exe" -frames 1 C:\Users\ALITAW~1\Desktop\Desktop\RITUAL~1\1.avs NUL

C:\Users\ALITAW~1\Desktop\Desktop\RITUAL~1\1.avs: 1920x1072, 24000/1001 fps, 35661 frames

Resolution: 1920 x 1072
Frame Rate: 24000/1001
No. Frames: 35661

--- ENCODING VIDEO ---

Creating input process:
"E:\Video stuff\x264_launcher.2014-11-02\toolset\x86\avs2yuv_x86.exe" C:\Users\ALITAW~1\Desktop\Desktop\RITUAL~1\1.avs -

Creating encoder process:
"E:\Video stuff\x264_launcher.2014-11-02\toolset\x64\x265_12bit_x64.exe" --crf 22.7 --preset medium --log-level 4 --wpp --ref 6 --rd 6 --cu 64 --min-cu-size 8 --limit-refs 3 --rect --amp --limit-modes --b-intra --cu-lossless --rd-refine --rdoq-level 2 --tu-intra-depth 4 --tu-inter-depth 4 --tskip --rdpenalty 2 --max-tu-size 32 --max-merge 5 --me 3 --subme 7 --merange 200 --temporal-mvp --weightp --weightb --strong-intra-smoothing --psy-rd 3.0 --psy-rdoq 1.0 --open-gop --scenecut 35 --rc-lookahead 225 --lookahead-slices 0 --b-adapt 2 --bframes 7 --bframe-bias 40 --b-pyramid --crf-max 24 --crf-min 16 --aq-mode 3 --aq-strength 2 --qg-size 64 --cutree --qcomp 0.84 --qblur 0.9 --cplxblur 60 --sao --deblock=-1:-3 --info --output "E:\Temporary\1 (3).hevc" --frames 35661 --y4m -

x265 [warning]: extra unused command arguments given <->
av2y [info]: C:\Users\ALITAW~1\Desktop\Desktop\RITUAL~1\1.avs: 1920x1072, 24000/1001 fps, 35661 frames
av2y [info]: error: wrote only 3062628 of 3087360 bytes

WARNING: Input process exited with error (code: 1), your encode might be *incomplete* !!!

PROCESS EXITED WITH ERROR CODE: 1



Any help? Thanks.

When just using the medium preset with no custom options for x265 the encode works fine.

[Ma]

Custom : --log-level 4 --wpp --ref 6 --rd 6 --cu 64 [...]

It could be a problem with '--cu' options that not exists. Try '--ctu' instead.

[LoRd_MuldeR]

@ProVision:
The "-" at the end of the command-line is the input file. And here the special name "-" means "read input from STDIN, rather than regular file". Since the input is pipe'd from the Avs2YUV process, this is absoloutely required!
But, as Ma said, there is no "--cu" option (see here (http://x265.readthedocs.io/en/default/cli.html) for details!). Seems like this is confusing x265's command-line parser, ultimaterly leading to the error that you are seeing. So please ty using "--ctu" instead.

[LoRd_MuldeR]

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

Version 2.73 [2016-07-03]
* Updated x264 to revision 2705
* Updated x265 to version 1.9+227

[kypec]

Hi Mulder, today I was starting your launcher and warning dialog below appeared. Please note that x264_lancher.exe is referred to as *LameXP* which I had never installed. Probably just a copy+paste typo from your other application? :confused:
http://i67.tinypic.com/10huk55.jpg

[LoRd_MuldeR]

Hi Kypec, actually that warning messages is created by the MUtilities (https://github.com/lordmulder/MUtilities) library, which forms the basis of most of my applications nowadays.

Much of that code originates from the LameXP project and has been generalized for library usage. But it's an ongoing job to generalize all the code. That's why you may still find "LameXP" hardcoded in a few places.

I have now fixed (generalized) the message you are referring to. Thanks for pointing me at that! The fix is not included in v2.74 yet though.

[LoRd_MuldeR]

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

Version 2.74 [2016-07-18]
* Updated x265 to version 2.0+2

[almosely]

Hi there,

a few minutes ago I updated Simple x264 Launcher and started a .avs-x264-encoding. Something is working wrong. The first issue is: I chose CRF 18.4 but in the joblist is stated "CRF@18". The job details is displaying the correct value, "--crf 18.4". The second issue is: I got insane quantizers listed in the logfile (I-frames Avg-QP=26.55, P-frames Avg-QP=30.35, B-frames Avg-QP=31.93). Both worked fine with the non-updated version before (I don't remember, which version that was, maybe something from april 2016). When I analyze the encoded file with AVInaptic, I get different, more realistic quantizers (I-slices avg DRF=13.91, P-sclices avg DRF=17.61, B-slices avg DRF=19.06). I know that AVInaptic normally differs from the Simple x264 Launchers logfile, but it has never been that much.

- edit -

the version before the update was: Simple x264 Launcher (Build #1026), built 2016-04-29

now it is: Simple x264 Launcher (Build #1038), built 2016-07-18

- edit -

now I downloaded the older version (2016-04-29) and just installed it over the newer one. Do I need to completely uninstall Simple x264 Launcher before or is this working okay?

- edit -

okay, I re-encoded the same test-vid with the downgraded launcher and got the following values:

- "CRF@18.4" (in the joblist)
- I-frames avg QP=14.83
- P-frames avg QP=18.54
- B-frames avg QP=20.04

AVInaptic tells me:

- I-slices avg DRF= 14.03
- P-slices avg DRF=17.71
- B-slices avg DRF=19.07

That sounds more familiar to me.

[Minister]

L_M - There doesn't seem a means to do a manual 2nd pass with previously created stats with Simple x264. I wonder if you'd consider adding the option?

In my current case I'm working with 30 videos, each of which took about 30 minutes to create the first pass stats, and I need to recode them a 2nd time. For the moment I'll just use the CLI to x264 directly (rather than spend another 15 hours recreating the first passes just so I can work with Simple x264 again), but if you thought you could add those manual pass options in rate control, that would be very helpful.

[LoRd_MuldeR]

Hi there,

a few minutes ago I updated Simple x264 Launcher and started a .avs-x264-encoding. Something is working wrong. The first issue is: I chose CRF 18.4 but in the joblist is stated "CRF@18". The job details is displaying the correct value, "--crf 18.4". The second issue is: I got insane quantizers listed in the logfile (I-frames Avg-QP=26.55, P-frames Avg-QP=30.35, B-frames Avg-QP=31.93). Both worked fine with the non-updated version before (I don't remember, which version that was, maybe something from april 2016). When I analyze the encoded file with AVInaptic, I get different, more realistic quantizers (I-slices avg DRF=13.91, P-sclices avg DRF=17.61, B-slices avg DRF=19.06). I know that AVInaptic normally differs from the Simple x264 Launchers logfile, but it has never been that much.

The CRF value displayed in the job name is a rounded value - for the sake of simplicity. So this is not necessarily the exact CRF value that you specified and that will be passed to x264.

I'm pretty sure that, if you look at the actual x264 command-line (in your log), you will realize that the "correct" CRF value has been passed to x264.

Also note: In CRF mode, the QP values are allowed to fluctuate as needed. The x264 developers decided to make the CRF value live on the same scale as the QP values, but that was a completely arbitrary decision! Internally, x264 will multiply the value that you passed via --crf parameter with some "magic" number in order to compute the actual constant "rate factor" which will be used for encoding. That "magic" number has been tuned so that using --crf x roughly results in an average QP of x. Again, this was an arbitrary decision. And the tuning was done with a specific set of source clips. Consequentiality, you can not expect that --crf x will result in an average QP of exactly x. It may depend a lot on your particular source video!

In a quick test with "--crf 18.4" and "medium" preset, I got this result:
x264 [info]: frame I:401 Avg QP:14.87 size: 35850
x264 [info]: frame P:7835 Avg QP:17.73 size: 13307
x264 [info]: frame B:19384 Avg QP:19.72 size: 5328

[LoRd_MuldeR]

L_M - There doesn't seem a means to do a manual 2nd pass with previously created stats with Simple x264. I wonder if you'd consider adding the option?

Yes, re-using an existing stats file is not currently possible. Simple x264 Launcher automates the whole 2-Pass process for you. Currently I have no plans to change that, sorry.

[Minister]

Yes, re-using an existing stats file is not currently possible. Simple x264 Launcher automates the whole 2-Pass process for you. Currently I have no plans to change that, sorry.

That's ok. I appreciate your responding, and for all the great work you've done with this application. Thanks.

[LoRd_MuldeR]

Here is a new TEST version:
https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher-TEST.2016-08-29.exe/download

x265 and NVEncC updated to latest versions.

[almosely]

Thanks for your reply, Lord_Mulder,

I did know all that before ... And I showed you the difference between your latest version (working wrong) and the older version of your launcher (working right) - but I think, you did not read that. And I told you, that I see the correct crf-value in the logfile, but not in the joblist ... And I showed you too, that I know, that a p-frames Quantizer of 17.xx is completely normal for a crf 18.4 encoding, the same as a p-frame Quantizer with a value of 19.xx would be too - but a value about 30.xx is not right at all (with the actual version of your launcher), especially when the value is about 17.xx, when I encode the same video with the same crf-value with the older version of your launcher.

Either your launcher is working wrong or the used x264-version, in case of the listed, insane quantizers (they are avg quantizers, not peaks).

And, I liked it more, as the crf-value was not rounded. I often encode the same video (5% compression-test) a few times, to find out the crf value I want. A quick look into the joblist, with the correct crf value instead of a rounded one, was a lot more convenient for me.

So, I am still using the "outdated" april-version of your launcher and will not update again, till this is fixed.

[LoRd_MuldeR]

There is nothing to be fixed ;)

As long as Simple x264 Launcher is passing the "correct" CRF value to x264.exe on the command-line – and your confirmed yourself that it does – there is no problem on the Simple x264 Launcher side. The CRF value in the job list is irrelevant.

Furthermore: As far as I can tell, there is no problem on the x264 side either. As explained before, CRF mode does not guarantee that a CRF value of x will result in an average QP of x. CRF mode does not even guarantee that a CRF value of x will result in an average QP close to x. This may be the case for a specific set of "reference" source clips, but it is not guaranteed for all source clips. For your specific source clip it may not be the case at all!

It was a completely arbitrary decision of the x264 developers to make CRF values live on the same scale as QP values! This is just for convenience. They could have decided to make the CRF value live on a 0.0 to 1.0 scale just as well...

(If you still think x264 is doing anything wrong here, you have to bother the x264 developers. But you will probably get the same answer)

[almosely]

Of course I still think theres a problem, but it seems to be within x264. As I said, I encoded the same video with the same parameters, once with your april-version, another time with the newest one. And I got almost twice as high quantizers with your newest one. So, there has to be a problem, but inside x264, as you guessed.

The rounded crf-value in your joblist is not irrelevant TO ME. It would help me, if it would still be the full parameter. As it would help me, if I could see, whether the automatic shutdown is active or not, without going into the prefs before - as I mentioned a few months ago. But, of course, both is YOUR decision and I have to live with that.

Thanks again, anyway, for this nice tool.

[LoRd_MuldeR]

Of course I still think theres a problem, but it seems to be within x264. As I said, I encoded the same video with the same parameters, once with your april-version, another time with the newest one. And I got almost twice as high quantizers with your newest one. So, there has to be a problem, but inside x264, as you guessed.

The meaning of the CRF values has changed many times in the history of x264. Therefore you cannot expect that a specific CRF value still has the same meaning in the "new" that it had in the "old" version.

Also, how do you know the "new" version is performing worse than the "old" version? Did you actually compare the resulting files visually? Or how did you come to the conclusion that the "new" version has a problem?

(Of course you can only compare file of the same file size, otherwise you are comparing apples and oranges. Thus, if necessary, adjust the CRF value so that both versions produce a file of the same size)

[almosely]

I noticed a little variance in resulting quantizers for crf-encondings (listed in the logfiles of x264) over the years and different x264-versions, but never that much (from 18.xx to 30.xx). Mostly I try to get a value of around 19.0 for the average p-frames of my encodings. I did a lot of testing on my smartphone, pc, stand-alone and lcd-tv and found, that this is a very good quality-filesize-relation for me. Sometimes I need a 16.xx CRF-value to achieve that, sometimes CRF 22.xx is enough. If x264 has changed that behaviour that much, for what p-frame-quantizers should I aim now - 30, 34, 27 ... or should I use a CRF-value around 8 or something? I am used to rely on that values. Furthermore, every enconding-guide (Brother Johns ...) I ever read relies on the resulting quantizers (with CRF too) as a quality-scale and proposes something between 18-20 for good encodings. Therefore I downgraded to the older version of your launcher with the old x264-version, to still know what I am doing.

I knew that the "new" version is working wrong (or at least very different), because I updated to the newest version, did run a 5%-compression-test and got 30.xx values for the avg p-frame-quantizers in the logfile of x264 (with a CRF-value of 18.4). Then I downgraded your launcher (without deinstalling before), did the same compression-test again and got 18.xx values for the p-frames (of the same file with the same enconding-parameters). I did not compare visually neither on other ways than looking into the x264-logfiles.

-edit-

I just compared the two logfiles of these compression-tests and found, that the "new" one (with the 30.xx p-frame-quantizers) started a 10-bit-depth-encoding and the "old" one a 8-bit-depth-encoding. Perhaps that explaines the difference? But I just updated to your newest launcher, did run the test, downgraded and did run the test and never adjusted the value for the bit-depth, so maybe the standard-values of your old and new launcher-version have changed?

[LoRd_MuldeR]

I just compared the two logfiles of these compression-tests and found, that the "new" one (with the 30.xx p-frame-quantizers) started a 10-bit-depth-encoding and the "old" one a 8-bit-depth-encoding. Perhaps that explaines the difference? But I just updated to your newest launcher, did run the test, downgraded and did run the test and never adjusted the value for the bit-depth, so maybe the standard-values of your old and new launcher-version have changed?

Of course, 8-Bit vs. 10-Bit makes a significant difference. They don't even use the same QP scale, which means you can't really compare those QP values.

When creating the job, did you select "8-Bit" or "10-Bit" encoder variant? I just did a quick test and Simple x264 Launcher seems to run the "correct" encoder, as selected by the user in job creating dialog.

[almosely]

That is the question. I think, I did not select/adjust anything else than the crf-value. I just updated, draged the .avs-file in and started the encoding. I assumed, that every parameter would be the same as before the update. I think, thats what happened. I did not even think about changing the bit-depth. But I will update again and watch out for the bit-depth-parameter (the standard-value in the gui after the update) and try some encodings with the new launcher version. Sadly I do not have the former test-video to repeat everything exactly, but I will test with another video.

[almosely]

So, I just updated your launcher, made a screenshot before and after that and figured out, that the standard-value for the bit-depth has changed after the update, from 8 bit to 10 bit. That's it. And I tested a little bit more. If I change "encoder", "architecture", "variant", "mode", "quantizer/crf", "preset", "tuning" and "profile" and load a saved template after that, everything is reconfigered like I saved it in the template, but not the bit-depth - this parameter is back on 10-bit. I never use 10-bit to encode. I always encode in 8-bit.

-edit-

I tested a little bit more. It seems that the bit-depth was not been saved in the templates before the update, because now I changed the bit-depth, saved a template, loaded an old template (bit-depth changed to 10 - your new standard value for this parameter), loaded the new template (bit-depth changed to 8). Okay, I will update my templates, then it should be okay.

And ... is there any possibility that your updater will not stress my firewall and fingers next time with around 10-15 clicks to allow your updater to work and complete? I have to click that much every time, because you use random and temporary names for every step in this job.

[LoRd_MuldeR]

I tested a little bit more. It seems that the bit-depth was not been saved in the templates before the update, because now I changed the bit-depth, saved a template, loaded an old template (bit-depth changed to 10 - your new standard value for this parameter), loaded the new template (bit-depth changed to 8). Okay, I will update my templates, then it should be okay.

And ... is there any possibility that your updater will not stress my firewall and fingers next time with around 10-15 clicks to allow your updater to work and complete? I have to click that much every time, because you use random and temporary names for every step in this job.

In the current version, just as in all previous versions, the "8-Bit" encoder variant is the default, not "10-Bit". You can easily confirm that by removing or renaming your "templates.ini", which will reset everything to the defaults.

If you look in "templates.ini" more closely, you will see that the "8-Bit" and "10-Bit" encoder variants are now saved correctly as "encoder_variant=0" and "encoder_variant=1", respectively. Also these values are loaded correctly from the INI file.

However, there has been an "issue" in some older versions, which caused the "encoder_variant" index to not be zero-based (but one-based). So, "8-Bit" had actually been saved as "encoder_variant=1". And "10-Bit" as "encoder_variant=2".

(This is a bit unfortunate, if you still have some "old" templates, yes. But it can not be fixed retrospectively. And, fixing up your "old" templates once, should be fairly trivial to do)

[LoRd_MuldeR]

Here is a new TEST version:
https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher-TEST.2016-09-15.exe/download

x265 updated to latest version.

[LoRd_MuldeR]

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

Version 2.75 [2016-09-25]
* Updated build environment to Visual Studio 2015 with Update-3
* Updated x264 to revision 2721
* Updated x265 to version 2.0+54
* Updated NVEncC to version 2.11

[LoRd_MuldeR]

Here is a new TEST version:
https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher-TEST.2016-10-13.exe/download

WHAT'S NEW:
* Updated x265 to version 2.1+20
* Detection of "portable" VapourSynth (see README for details!)
* Detection of "portable" Avisynth (see README for details!)

[LoRd_MuldeR]

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

Version 2.76 [2016-10-21]
* Updated x265 to version 2.1+25
* Updated NVEncC to version 3.01
* Detection of "portable" VapourSynth (see README for details!)
* Detection of "portable" Avisynth (see README for details!)

[LoRd_MuldeR]

New TEST build with latest x265 encoder:
https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher-TEST.2016-11-06.exe/download

[r0lZ]

Is it possible to use the x264 launcher with VapourSynth installed in portable mode?

I haven't found a way to tell it where VapourSynth and Python are located, and the launcher tells me that VapourSynth is NOT currently installed. I understand that it cannot find it automatically since by definition the portable installation is not tied to the system, but IMO it should be possible to specify the directory somehow, with the preferences dialog or by editing a configuration file. Is it currently possible? If not, can you add that possibility?

[BakaProxy]

LoRd_MuldeR would it be possible to add a feature in which you can set a custom deadlock value or even fully disable it? Because some scripts have long initialization times which exceed the default 60 seconds, which makes batch encoding quite irritating to handle within your GUI.

Thanks in advance.

[LoRd_MuldeR]

LoRd_MuldeR would it be possible to add a feature in which you can set a custom deadlock value or even fully disable it? Because some scripts have long initialization times which exceed the default 60 seconds, which makes batch encoding quite irritating to handle within your GUI.

Thanks in advance.

Please see here:
https://github.com/lordmulder/Simple-x264-Launcher/blob/master/README.md#command-line-syntax

;)

[BakaProxy]

Please see here:
https://github.com/lordmulder/Simple-x264-Launcher/blob/master/README.md#command-line-syntax

;)
Oh it's actually 5 minutes. Then I can rest assured for now, but I would definitely appreciate it if you can set a custom deadlock value. It would save me some time and effort and I'm sure I'm not the only one who could use this, but that's your decision.

Verstuurd vanaf mijn SM-A500FU met Tapatalk

[r0lZ]

Is it possible to use the x264 launcher with VapourSynth installed in portable mode?
Since I haven't received an answer to that question, should I assume that it's impossible?

[LoRd_MuldeR]

Is it possible to use the x264 launcher with VapourSynth installed in portable mode?
Since I haven't received an answer to that question, should I assume that it's impossible?

Sorry, missed that for some reason.

It should be possible now, with the very latest version. But you have to follow instructions exactly:
https://github.com/lordmulder/Simple-x264-Launcher/blob/master/README.md#vapoursynth

[r0lZ]

OK, thanks! I have already "installed" VS Portable elsewhere, but I suppose that I can do an hard or soft link to duplicate it within the extra folder. But IMO, it would be better to have the possibility to specify the path manually, perhaps with a command line argument, or within the preferences.ini file. Just a suggestion.

[EDIT] Using an hard link (called Junction in Windows terminology) works fine, but a soft link doesn't work. So, the directories with the Simple Launcher and with VapourSynth must be on the same physical partition. An additional reason to provide a way to specify the path. ;-)

[LoRd_MuldeR]

New TEST build available:
https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher-TEST.2016-12-09.exe/download

Updated x264 and x265 to the latest versions.

[LoRd_MuldeR]

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

Version 2.77 [2016-12-11]
* Updated x265 to version 2.1+69
* Updated x264 to revision 2744
* Updated NVEncC to version 3.02

[olex99]

I have a weird feature request.

I currently do my encoding on a computer that I only have access to on the weekend. I'm usually doing Home Videos for archiving so I only care about quality, I use QTGMC as my de-interlacer and because of this my encodes average around 0.3fps and can take up for 3 weeks to complete.

I use Simple x264 Launcher as my GUI and it works well, I usually have up to 6 Job running at a time as I only use the Single Threaded Avisynth to do the work.

What I would like is a way to see the status of the encode remotely since I only have access to actually be in front of the encoding computer on the weekend. What I do have access to though is the file system. Is there a chance you can add a feature to allow a log file to be written with the status of the encode while the encode is happening? I could then check this file at any time to see where the encodes are up to. I believe it can be done by piping the output to a text file but I don't have anyway in the software to add that command line from what I can see.

[LoRd_MuldeR]

I have a weird feature request.

I currently do my encoding on a computer that I only have access to on the weekend. I'm usually doing Home Videos for archiving so I only care about quality, I use QTGMC as my de-interlacer and because of this my encodes average around 0.3fps and can take up for 3 weeks to complete.

I use Simple x264 Launcher as my GUI and it works well, I usually have up to 6 Job running at a time as I only use the Single Threaded Avisynth to do the work.

What I would like is a way to see the status of the encode remotely since I only have access to actually be in front of the encoding computer on the weekend. What I do have access to though is the file system. Is there a chance you can add a feature to allow a log file to be written with the status of the encode while the encode is happening? I could then check this file at any time to see where the encodes are up to. I believe it can be done by piping the output to a text file but I don't have anyway in the software to add that command line from what I can see.

Ever heard of VNC (http://www.uvnc.com/downloads/ultravnc.html)? ;)

Really, instead of messing up one tool with too many (unrelated) features, you should use the right tool for each job - and combine them as needed (cf. Unix philosophy (https://en.wikipedia.org/wiki/Unix_philosophy#Origin)).

Having said that, there already is a feature in Simple x264 Launcher to automatically generate a log file for each encoding task.

But this won't be very helpful for you, I guess, because the log file is saved when the encoding task has been completed. The log file is not written (or updated) in "realtime" while the encoding is still running.

And even if the log file was updated in "realtime", it still wouldn't allow you to see the current progress by looking at the file. That's because:

(a) progress lines are not written to the log, because it would completely flood the log. Except for warnings that might pop up throughout the encode, most long lines are either created right at the beginning or at the very end;

(b) even if we wrote all output the the log file in an "unfiltered" way, including progress lines, you still couldn't see progress in "realtime", because the file I/O buffering of the operating system will delay file writes.

[fijam]

I've been using Simple Launcher for over a year now, thanks for that great piece of software.

I have three small pet peeves:
1. it's not possible to edit the paths and filenames in source/output directly (the field is not editable, you need to click [...] and edit it there, then click Save again)

2. there is no way to disable custom parameter validation, e.g. I'd often like to use tmod's --aq2-strength and Simple Launcher will not let me do that ("custom parameters are invalid and will be discarded")

3. my templates quickly grow into a rat's nest, some kind of system with categories for templates (DVD/HDTV/BD, or SD/720p/1080p for example, preferably user-editable) would be nice

[Pulp Catalyst]

what de-interlacing capability does this have?

also, how difficult would it be to add (NNEDI3 + YadifMod) combination? (there are AviSynth and Vapour-synth plugins available for both).

[LoRd_MuldeR]

1. it's not possible to edit the paths and filenames in source/output directly (the field is not editable, you need to click [...] and edit it there, then click Save again)

Yes, that's intentional. If free editing was allowed, the user could enter arbitrary invalid or non-existing paths, so we would have to do (rather complex) validation.

2. there is no way to disable custom parameter validation, e.g. I'd often like to use tmod's --aq2-strength and Simple Launcher will not let me do that ("custom parameters are invalid and will be discarded")

Parameter validation can't be disabled for good reason.

However, there was (yet another) small issue in the parameter validation code. Should be fixed in latest TEST version:
https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher-TEST.2017-01-07.exe/download

3. my templates quickly grow into a rat's nest, some kind of system with categories for templates (DVD/HDTV/BD, or SD/720p/1080p for example, preferably user-editable) would be nice

I will need to think about a solution...

what de-interlacing capability does this have?

also, how difficult would it be to add (NNEDI3 + YadifMod) combination? (there are AviSynth and Vapour-synth plugins available for both).

Yes, those are Avisynth/VapourSynth filters. Using them with Simple x264/x265 Launcher is no different than with any other application that supports Avisynth/VapourSynth input.

If you want to use those deinterlacing filters without frame-serving your source from Avisynth or VapourSynth: Nope, that's not possible ;)

[LoRd_MuldeR]

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

Version 2.78 [2017-01-07]
* Updated x265 to version 2.2+22
* Updated Avs2YUV to version 0.24 (BugMaster's mod 5)
* Added new option to save pending jobs *without* confirmation
* Some fixes to parameter validation code

[masagrator]

I don't know why, but Launcher cannot detect my Avisynth 2.6. Is there a way to write a path to Avisynth? I tried with AviSynth+ and works only with 64-bit plugins... Launcher and avisynth are installed on system partition. I tried reinstalling and nothing. Windows 10 64-bit Education. I checked 2 last versions of Launcher. I tried with "portable version", changing name and copying standalone avisynth to Launcher folder. And still the same.

[LoRd_MuldeR]

I don't know why, but Launcher cannot detect my Avisynth 2.6. Is there a way to write a path to Avisynth? I tried with AviSynth+ and works only with 64-bit plugins... Launcher and avisynth are installed on system partition. I tried reinstalling and nothing. Windows 10 64-bit Education. I checked 2 last versions of Launcher. I tried with "portable version", changing name and copying standalone avisynth to Launcher folder. And still the same.

Simple x264 Launcher will launch encoding tools, e.g. x264, as separate processes. And these tools will then try to load Avisynth.DLL, when needed – usually from the "System32" (or "SysWow64") directory.

The only difference in "portable" mode is that Simple x264 Launcher will add "<InstallPath>\Avisynth\{x86,x64}" to the PATH environment variable before launching the encoder process, so that the encoder process will be able to load Avisynth.DLL from that directory too. Still, programs prefer loading DLL's from the "System32" (or "SysWow64") directory, before they fall back to the directories listed in PATH.

Anyway, you can try running "toolset\x86\avs_check_x86.exe" or "toolset\x64\avs_check_x64.exe" manually and look at the output, in order to check for the availability of 32-Bit or 64-Bit Avisynth, respectively.

[VincAlastor]

Is it possible to add aomenc for testing, please? With your GUI it could be easier to test this new encoder with logs and statistics.

daily nightly builds:
http://forum.doom9.org/showthread.php?p=1778544#post1778544

[LoRd_MuldeR]

Is it possible to add aomenc for testing, please? With your GUI it could be easier to test this new encoder with logs and statistics.

daily nightly builds:
http://forum.doom9.org/showthread.php?p=1778544#post1778544

First of all: I have zero experience with "aomenc".

If it could work a drop-in replacement for x264 or x265 (i.e. it has similar command-line syntax, it has similar input/output capabilities, and it writes similar status messages to the STDOUT), then integration would probably be straight-forward.

Otherwise, I don't know if integration could be done with reasonable efforts. But, in any case, I won't guarantee anything ;)

[LoRd_MuldeR]

For anybody getting this error with latest release, please try the new "hotfix" build below:

https://cloud.githubusercontent.com/assets/470590/21948975/ded54b54-d9ee-11e6-892a-5924b305b920.png

x264_launcher.2017-01-14.exe (https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Hotfix/x264_launcher.2017-01-14.exe/download)

[GMJCZP]

I have a question: Is a good idea for Bluray ripping use makemkv and later use Simplex264 for definitive coding (video only, of course)?
The quality of image is still good?

[kypec]

The quality of image is still good?

Quality of video will depend on the bitrate and settings you setup for x264 encoder. I personally usually encode with preset=veryslow, CRF=20 and appropriate tuning applied (Film, Animation...)

[BakaProxy]

Quality of video will depend on the bitrate and settings you setup for x264 encoder. I personally usually encode with preset=veryslow, CRF=20 and appropriate tuning applied (Film, Animation...)
I personally like to use qp=21,preset=placebo, deblock=9:-9,aq-strength 0.69 for maximum quality, I swear you you won't notice the difference except for some small dots here and there. 👌👌👌

Verstuurd vanaf mijn SM-A500FU met Tapatalk

[GMJCZP]

In short: Is usable makemkv for video input for simplex264?

[LoRd_MuldeR]

Quality-wise, the Simple x264 Launcher is as good (or bad) as any other x264 front-end. But yes, x264 should be able to reduce the bitrate of a BluRay source quite a bit without much quality loss.

As far as MKV input is concerned, x264 can read MKV files directly, thanks to built-in FFmpegSource support. x265 is still lacking a feature like that, but of course you can always frame-serve your MKV files via Avisynth or VapurSynth...

[GMJCZP]

Thanks, I was worried for the quality input of makemkv video, not for the performance of your program. In short Makemkv and Simplex264 are a good combo for ripping!

[kypec]

Thanks, I was worried for the quality input of makemkv video, not for the performance of your program.
Seems like you've been missing one important point to know:
MakeMKV is a ripping tool, not encoder which means that the visual quality of output MKV file is exactly the same as that of original BD stream, the data are just repacked in different container = mkv (Matroska) instead of ts (MPEG transport stream). ;)

[GMJCZP]

Indeed, thanks. Makemkv's output is lossless. Now I know.

[r0lZ]

In toolset/common, netc.exe is detected as a virus by many antivirus programs (VirusTotal score (https://www.virustotal.com/en/file/e8fbec25db4f9d95b5e8f41cca51a4b32be8674a4dea7a45b6f7aeb22dbc38db/analysis/): 10/56). It's probably a false positive, but who know? What is its usage, and can we safely add it to the white list of our antivirus?

[LoRd_MuldeR]

In toolset/common, netc.exe is detected as a virus by many antivirus programs (VirusTotal score (https://www.virustotal.com/en/file/e8fbec25db4f9d95b5e8f41cca51a4b32be8674a4dea7a45b6f7aeb22dbc38db/analysis/): 10/56). It's probably a false positive, but who know? What is its usage, and can we safely add it to the white list of our antivirus?

Netcat (https://en.wikipedia.org/wiki/Netcat) (aka "nc") is a standard networking tool. Pretty much every Unix/Linux-based OS comes with this standard tool included. Windows doesn't, so a Windows port of Netcat is included with my software.

It's used by my auto-update feature, for fast connectivity tests. It only runs when you let auto-updater check for new updates. Don't worry: Netcat is a 100% legitimate. All you have to do is getting rid of buggy "anti-virus" software.

Recommended reading:
http://robert.ocallahan.org/2017/01/disable-your-antivirus-software-except.html

[r0lZ]

OK, thanks. But note that it's not a single antivirus that is "buggy". As I wrote, 10 different antivirus consider the exe as dangerous, and it's too much to suspect a simple false positive. However, most of them flag it simply as suspect (or Potentially Unwanted Application) rather than as a real virus, probably because the exe can be used to communicate private information over the internet. Of course, I don't suspect your program to use it that way, but it remains that the exe might really be potentially dangerous if it is used by a malicious app, and that it will certainly be quarantined by the anti-virus of many users. Some peoples may be scared and refuse to use your program any more. Perhaps you should consider to use another solution, or integrate the version check within the program itself rather than using an external exe?

Anyway, on my side, I'll simply add it to the white list of my antivirus.

[LoRd_MuldeR]

OK, thanks. But note that it's not a single antivirus that is "buggy". As I wrote, 10 different antivirus consider the exe as dangerous, and it's too much to suspect a simple false positive. However, most of them flag it simply as suspect (or Potentially Unwanted Application) rather than as a real virus, probably because the exe can be used to communicate private information over the internet.

There is a very fundamental difference between the following types of "detections":
Known malware, i.e. a specific well-known software that was strictly written to cause harm and that has been identified undoubtedly
Something that looks somewhat similar to a known malware, i.e. heuristic detection
Software that is 100% legitimate and that is used for 100% legitimate purposes most of the time, but may also be used for causing harm

The big problem with so-called "anti-virus" software is that they do not clearly distinguish these cases!

In case (1) the "anti-virus" software should trigger an alert, yes. In case (2) the "anti-virus" software may still show a warning to the user, but it must be made very clear (not hidden somewhere in the details!) that such heuristic detections are only a very vague assumption and, most likely, the file is 100% legitimate. And, in case (3), the "anti-virus" software should not show anything to the user, with default settings. That's because, if you think about it, pretty much any software belongs into that category! Show me one (non-trivial) legitimate software that couldn't be used to cause harm, in one way or another, if you really want to. It doesn't exist. So, what software they call "potentially dangerous", or not, is a completely arbitrary decision... Microsoft Word, for example, is by far more "potentially dangerous" than NC will every be - c.f. macro virus (https://en.wikipedia.org/wiki/Macro_virus). But, of course, they wouldn't dare to block Microsoft Word, because Microsoft has an army of lawyers...

(Tomorrow they'll try to tell you that x264 itself is "dangerous" program that needs to be blocked, because terrorists may use it to encode their propaganda videos!)


Of course, I don't suspect your program to use it that way, but it remains that the exe might really be potentially dangerous if it is used by a malicious app, and that it will certainly be quarantined by the anti-virus of many users. Some peoples may be scared and refuse to use your program any more. Perhaps you should consider to use another solution, or integrate the version check within the program itself rather than using an external exe?

At the point where a 100% legitimate application needs to be changed to workaround the shortcomings of the so-called "anti-virus" software (that is supposed to protect us from malware) things are going seriously wrong! So, nope. It's not going to happen that I change a single line of code in order to workaround "buggy" anti-virus software. It would be a pointless effort anyway, because there's like a zillion of "anti-virus" products out there and you can't hack around all of them.

(BTW: There is an important philosophy in software designed that says: Don't stuff too many features into a single program; write programs that do one thing, and do it properly; write programs that cooperate! So, if there already exists a well-established tool that does exactly what you need - as is the case here - it is always much preferable to just call that tool, rather than trying to re-invent the wheel)

[r0lZ]

I agree, especially on the difficulty to identify clearly if an exe is a real virus or just a PUA. And it's the major problem with VirusTotal, since when an antivirus doesn't give the green light, VirusTotal counts it as positive, even if it's only a PUA. But the fact remains that a score of 10/56 is scaring for many users, and that may have a bad effect on the reputation of your program. It's why I suggested to integrate the version check within the main exe, but of course it's not mandatory. I hope that your program will not be affected.

Anyway, thanks for your long reply.

[AbeSimpson]

Just recently my x264 logs are now showing timestamps when I save them. I haven't had this before and don't remember turning them on. How can I shut them off?

[LoRd_MuldeR]

Just recently my x264 logs are now showing timestamps when I save them. I haven't had this before and don't remember turning them on. How can I shut them off?

Yes, timestamps are now saved in the logfile for each line. This has been implemented a while ago. It is actually very common that entries in an application log are timestamped, so that you can later trace back what happened when.

There currently is no option to turn it off. And I'm not sure I want (yet another) option for this. If you don't care about the timestamps, you can just ignore them, right?

(it seems you are the first person to even notice ^^)

[AbeSimpson]

Yes, timestamps are now saved in the logfile for each line. This has been implemented a while ago. It is actually very common that entries in an application log are timestamped, so that you can later trace back what happened when.

There currently is no option to turn it off. And I'm not sure I want (yet another) option for this. If you don't care about the timestamps, you can just ignore them, right?

(it seems you are the first person to even notice ^^)

I hadn't done any encoding for a while so I guess they must have shown up since my last one. Thanks for clearing that up.

[rus929]

Gud day LoRd_MuldeR:

First of all, I would like to thank you for this wonderful software that you've shared to us.

Today, I am glad to share my experience that I've discovered by using this software in all of my video encodes.

For the past days, I am using Simple x264/x265 Launcher with Avisynth script in resizing my videos (from 1080p to 720p) using Avisynth's spline64 resizer. I am not into lanczos cause for me it creates more banding on my encodes. By the way my encode settings are 2pass @1500kbps and I am using the medium preset with the following changes: level 4.1, deblock -1:-1, ref=4, subme=8, umh, merange=64, rc-lookahead=96, b-adapt=2 and no p-fast skip. The encodes are good (if not best), but I think it is a little smooth because I think of the spline method.

What I've discovered lately is that, when I put directly the video into the job without using Avisynth script and add a --video-filter resize:1280,XXX as additional command, the resulting encode was superb using the same settings as above. The encode is a little crispier but not so much of having banding effects created. Also, I observe that it saves about an hour of time in first-pass and also save more minutes for the second-pass (since only the x264 executable is only running and no Avs2yuv is running).

Now, what I am wondering is that, is there any possibility that x264 can add an "add-border" function in its video filters cause as of this moment I can add only borders to my encodes using Avisynth's add border command. If you are wondering why, re-encoding videos (i.e. cropped movies) into full 1920x1080p in just single or dual-layer dvd discs and mux them as AVCHD format is beautiful to watch since blu-ray players will play the video in full-1080p/24-frames signal unlike the cropped videos which is converted to 60-frames.

More power and thanks once again.

[sneaker_ger]

The vanilla x264 does not have a border adding filter and I haven't seen any other builds with such filter. By default it uses bicubic resizing. Have you tried AviSynth's BicubicResize() filter for comparison?

[rus929]

The vanilla x264 does not have a border adding filter and I haven't seen any other builds with such filter. By default it uses bicubic resizing. Have you tried AviSynth's BicubicResize() filter for comparison?

Have not tried Avisynth's bicubic. I will try, but my concern now is the time factor.

About the add-border, of my knowledge, there is one application - uncropmkv, but this is an old tool, and i think it uses avisynths too. If x264 can do this internally I think we can save time to encode videos.

I am wondering if LorR_MuldeR can channel this concern to the developers of x264 since he has authority in using their binaries.

Anyway, thanks for the reply.

[LoRd_MuldeR]

Have not tried Avisynth's bicubic. I will try, but my concern now is the time factor.

Piping the input from Avisynth into x264 certainly has some overhead. But, compared to the CPU time spent for the actual encoding, this should usually be negligible. It can have more effect in the (fast) first pass, though.

Anyway, it is quite possible that the Spline64 or Lanczos resizer you have been using in Avisynth produces "sharper" image than the Bicubic resizer used by x264 by default, which, in turn, could effect x264 encoding speed.



I am wondering if LorR_MuldeR can channel this concern to the developers of x264 since he has authority in using their binaries.

:confused:

No, nothing like that. If you want to get in touch with x264 developers, your best bet is the mailing list, I suppose:
https://mailman.videolan.org/listinfo/x264-devel

[rus929]

[QUOTE=LoRd_MuldeR;1798618]Piping the input from Avisynth into x264 certainly has some overhead. But, compared to the CPU time spent for the actual encoding, this should usually be negligible. It can have more effect in the (fast) first pass, though.

Right, since upon examining the running executable on the first pass, x264 and avs2yuv share almost 50-50 on the CPU, unlike without piping it from the Avisynth which x264 has it all. On the final encoding though, still piping it through Avisynth, avs2yuv get about 10-20% of CPU.

I tried, BicubicResize of Avisynth, to my eye, launching the mkv file directly to Simple x264/x265 Launcher has sharper image than that of Avisynth (not that it has great difference though, but on the time it finish to encode, more than an hour).

Btw, I am wondering why using the 64bit version of x264, when launching the file through Avisynth it uses the 32bit version of avs2yuv, but it has a 64bit version on the same folder?

Anyway, thanks for the info of reaching x264 developer.

Gud day, and more power.

[LoRd_MuldeR]

Right, since upon examining the running executable on the first pass, x264 and avs2yuv share almost 50-50 on the CPU, unlike without piping it from the Avisynth which x264 has it all. On the final encoding though, still piping it through Avisynth, avs2yuv get about 10-20% of CPU.

This is not really surprising. The "faster" your encoding settings are (and "fast first-pass" uses very fast settings!) the more CPU time is spent for I/O processing - relative to the time spent for the actual encoding.

You have the same effect - more or less - when decoding the input directly with x264. But, in that case, you don't have two separate processes, so you can't "see" the effect easily.

(Still I would assume that I/O overhead with Avs2YUV is a bit higher)


Btw, I am wondering why using the 64bit version of x264, when launching the file through Avisynth it uses the 32bit version of avs2yuv, but it has a 64bit version on the same folder?

...because "official" Avisynth does not have a 64-Bit version yet. And 64-Bit x264 can not load a 32-Bit Avisynth DLL. So we use 32-Bit Avs2YUV (with 32-Bit Avisynth) and then pipe the input into 64-Bit x264.

There is an "unofficial" 64-Bit fork of Avisynth, but it is considered deprecated now. Avisynth+, which is yet another "unofficial" fork of Avisyth, also does have a 64-Bit version available. But not everybody is using Avisynth+.

And even if you use a "native" 64-Bit Avisyth, you would still need to have all of your plug-ins as "native" 64-Bit versions too. Many "legacy" plug-ins are 32-Bit only, though.

(BTW: There is an option in the preferences to use 64-Bit Avisynth input, provided that a 64-Bit Avisynth is installed)

[aegisofrime]

Hey Lord Mulder!

Been using this nifty little tool without too much trouble for a while now, all of a sudden this starts happening:

http://i.imgur.com/vmWBS3O.png

I'm on Windows 10. I have tried downloading your installer and reinstalling, but the same thing happens. :confused:

[LoRd_MuldeR]

Hey Lord Mulder!

Been using this nifty little tool without too much trouble for a while now, all of a sudden this starts happening:

http://i.imgur.com/vmWBS3O.png

I'm on Windows 10. I have tried downloading your installer and reinstalling, but the same thing happens. :confused:

That's weird. This error would indicate that "imageformats\qsvg4.dll" is missing, or could not be loaded. But after a re-install this would have (or at least: should have) been fixed :confused:

Make sure that there is a "qsvg4.dll" in the sub-folder "imageformats" immediately below the directory where your "x264_launcher.exe" resides.

Also make sure that "QtSvg4.dll" and "QtXml4.dll" are in the same directory where your "x264_launcher.exe" resides. If either of those is missing from application directory, the "qsvg4.dll" plug-in cannot be loaded.

Finally, make sure you don't have any files mixed from older program versions or, more critically, older compiler versions. Actually, I suggest to completely delete the install directory, then make a "clean" re-install.

If you launch "x264_launcher.exe" with extra option "--console", anything noteworthy in the log?

[CrosstownTraffic]

Starting with version v2.69 the file "netc.exe" has been included in the /toolset/common directory. As of this post, this file shows up on 10 of 61 potential scans (https://www.virustotal.com/en/file/e8fbec25db4f9d95b5e8f41cca51a4b32be8674a4dea7a45b6f7aeb22dbc38db/analysis/) via VirusTotal. Symantec correctly and best identifies this as netcat (https://en.wikipedia.org/wiki/Netcat) which is a fairly popular program for managing connections.

The release notes for v2.69 (https://github.com/lordmulder/Simple-x264-Launcher/releases/tag/v2.69) suggest that the addition of netc.exe was related to auto-update functionality.

Note: Occasionally your Antivirus program may mistakenly detect "malware" (virus, trojan, worm, etc.) in some of the files here.
This is called a "false-positive" and the files are actually innocent (clean). It's a failure in your specific Antivirus software.
In case you encounter such problems, go to http://www.virustotal.com/ and check the file again with multiple Antivirus engines!
And take care with results like "suspicious", "generic" or "packed". Those are *not* real hits, they are just wild speculation...

Could this please be updated to include exactly what file(s) show up like this, and some technical explanation for why this is so? I have tons of software that manages to automatically update (including some open source software!) without using something like netcat, so I am wondering why this was chosen. Thank you very much for all of your tireless work on this software over the years.

EDIT: Look at the other executables that create or otherwise interact with this version of netcat on VirusTotal. All of them are trojans, backdoors, and other terrible software. I tried quarantining/deleting netc.exe but x264/x265 Launcher refuses to run without it -- why is this so? Who cares if it can check for recent updates or not on run?

[Rodger]

That's weird. This error would indicate that "imageformats\qsvg4.dll" is missing, or could not be loaded. But after a re-install this would have (or at least: should have) been fixed :confused:

Make sure that there is a "qsvg4.dll" in the sub-folder "imageformats" immediately below the directory where your "x264_launcher.exe" resides.

Also make sure that "QtSvg4.dll" and "QtXml4.dll" are in the same directory where your "x264_launcher.exe" resides. If either of those is missing from application directory, the "qsvg4.dll" plug-in cannot be loaded.

Finally, make sure you don't have any files mixed from older program versions or, more critically, older compiler versions. Actually, I suggest to completely delete the install directory, then make a "clean" re-install.

If you launch "x264_launcher.exe" with extra option "--console", anything noteworthy in the log?

SAME error here....never had any problems...didn´t use it for a while...did absolutely nothing else than just updating it....
BAM....always this error.

tried the sugguested console run se pic attached...


/EDIT: Tried fresh install in a totally different directory....NOPE! Same error...this release does NOT work.
Windows10 pro 64bit?!

[r0lZ]

I confirm that there is a big problem with the latest version (2017-01-07), after a fresh install of the portable version from the ZIP archive. But I have a different error message:
---------------------------
x264_launcher_portable.exe - Application Error
---------------------------
The application was unable to start correctly (0xc0000005). Click OK to close the application.
---------------------------
OK
---------------------------

[LoRd_MuldeR]

Sorry for late replay, just returned from business trip.

Starting with version v2.69 the file "netc.exe" has been included in the /toolset/common directory. As of this post, this file shows up on 10 of 61 potential scans (https://www.virustotal.com/en/file/e8fbec25db4f9d95b5e8f41cca51a4b32be8674a4dea7a45b6f7aeb22dbc38db/analysis/) via VirusTotal. Symantec correctly and best identifies this as netcat (https://en.wikipedia.org/wiki/Netcat) which is a fairly popular program for managing connections.

Yes, NC is a widely-used standard network tool, available on pretty much any Unix/Linux system "out of the box". My software ships with a Win32 port of NC, because Windows doesn't ship with NC included.

I'm well aware that some braindead so-called "anti-virus" software is defames NC as "potentially dangerous" software :rolleyes:

If you want this fixed, then please call your anti-virus vendor and ask them to hire some developers that actually have a clue what they are doing. Be reassured that I don't have any plans to stop using/including NC in my software.

See also:
* https://forum.doom9.org/showpost.php?p=1795630&postcount=1652
* https://forum.doom9.org/showpost.php?p=1795879&postcount=1654

Recommended reading:
http://robert.ocallahan.org/2017/01/disable-your-antivirus-software-except.html

I confirm that there is a big problem with the latest version (2017-01-07), after a fresh install of the portable version from the ZIP archive. But I have a different error message:
---------------------------
x264_launcher_portable.exe - Application Error
---------------------------
The application was unable to start correctly (0xc0000005). Click OK to close the application.
---------------------------
OK
---------------------------

Hmm, have you tried this?
https://forum.doom9.org/showpost.php?p=1793404&postcount=1642

Possible UPX issue. I got this error once on one of my machines, but it was gone after a reboot and I couldn't reproduce it since then...

[Rodger]

Works!
No more "qsvg4.dll" error.
Application starts now just like it used to.

Thx@mulder

[LoRd_MuldeR]

Works!
No more "qsvg4.dll" error.
Application starts now just like it used to.

Thx@mulder

Okay, thanks for confirming. I will probably push a new build on the update servers soon. Not tonight though.

[CrosstownTraffic]

Yes, NC is a widely-used standard network tool, available on pretty much any Unix/Linux system "out of the box". My software ships with a Win32 port of NC, because Windows doesn't ship with NC included.

I'm well aware that some braindead so-called "anti-virus" software is defames NC as "potentially dangerous" software :rolleyes:


Again, thanks for taking the time to write this software & respond to my forum post.
Your post lacks technical explanation for why you need to use netcat.
Your post last technical explanation about why your software can't launch without it.
Again, tons of other software manages to auto-update without using such a vastly large network library for such a simple task.


Your software, your dance. But the author of software that includes something like this telling me "oh they just don't know what they're talking about" without any technical explanation just isn't good enough for me to potentially violate security.

Again, I implore you to list the files that trigger anti-virus scanners regardless of your personal opinions of them and post a technical explanation for why you must use this software.

[CrosstownTraffic]

Yes, NC is a widely-used standard network tool, available on pretty much any Unix/Linux system "out of the box". My software ships with a Win32 port of NC, because Windows doesn't ship with NC included.

Yes, as I indicated I know what netcat is -- what I'm seeking is a technical explanation of why you chose to include it in your software, and why your software is unable to run without it.

I'm well aware that some braindead so-called "anti-virus" software is defames NC as "potentially dangerous" software :rolleyes:

If you want this fixed, then please call your anti-virus vendor and ask them to hire some developers that actually have a clue what they are doing. Be reassured that I don't have any plans to stop using/including NC in my software.


You have no idea how confidence-destroying that reads. "Those quacks at the Food and Drug Administration tell us that drug is unsafe, but what do they know?" It turns out they know a lot, actually, which is why users trust them to protect their machines. They certainly more than 99.9% of users out there, which is why they exist in the first place.

A couple links to other posts involving your rant against anti-virus software because you've chosen to include such an expansive suite of network tools just for auto-update functionality doesn't help here. Not to mention in the one link you say it's for "fast connectivity tests" -- for gods sake, is that really necessary for the daily function of your software?

I implore you to seek another, accepted method of auto-updating your software or at least provide an option to run the software without auto-update functionality on initial run. You mention disabling auto-update but you can't do that unless you run the software, and to do that you must allow netcat to run.

Regardless of your protestations against anti-virus software vendors, I don't understand why you require netcat to run if it truly is just there to provide software updates.

Again, thanks for writing the software and taking the time to reply. I'm sure this will go absolutely nowhere and I'll move on to other software. I do hope you reconsider.

[r0lZ]

Possible UPX issue. I got this error once on one of my machines, but it was gone after a reboot and I couldn't reproduce it since then...
Strange, but true. Just tested again this morning after a fresh boot, and it works fine. I did not need to install the hotfix.
It would be nice to understand the origin of the problem. It is well known that Windows is terribly unstable, but normally it is not necessary to reboot to run a program!

[LoRd_MuldeR]

You have no idea how confidence-destroying that reads. "Those quacks at the Food and Drug Administration tell us that drug is unsafe, but what do they know?" It turns out they know a lot, actually, which is why users trust them to protect their machines. They certainly more than 99.9% of users out there, which is why they exist in the first place.

A couple links to other posts involving your rant against anti-virus software because you've chosen to include such an expansive suite of network tools just for auto-update functionality doesn't help here. Not to mention in the one link you say it's for "fast connectivity tests" -- for gods sake, is that really necessary for the daily function of your software?

I implore you to seek another, accepted method of auto-updating your software or at least provide an option to run the software without auto-update functionality on initial run. You mention disabling auto-update but you can't do that unless you run the software, and to do that you must allow netcat to run.

Regardless of your protestations against anti-virus software vendors, I don't understand why you require netcat to run if it truly is just there to provide software updates.

Again, thanks for writing the software and taking the time to reply. I'm sure this will go absolutely nowhere and I'll move on to other software. I do hope you reconsider.

And you probably have no idea how annoying it is, when you create a perfectly legitimate software (containing only 3rd-party tools each of which is perfectly legitimate too), you donate your work to the OpenSource community, and then some braindead so-called "anti-virus" company comes along and accuses your product of being or containing malware - causing unaware users to send you loads of angry email, asking why you are spreading malware!

If this was one of the projects that I'm doing for a company, I would just forward this case to our legal department. Our lawyers would do the required phone call and tomorrow the "anti-virus" company would have the problem fixed - either that or they could watch how they are sued to death. Anyway, as things are, this is just one of my "private" projects that I'm doing for fun. I don't have an army of lawyers to keep the "anti-virus" companies in their place. So, all I can do is try to educate people and tell them the facts. The day that I change a single line of my code to escape unjustified defamation committed by "anti-virus" companies is not going to happen. It would be a pointless endeavor anyway, because there is a zillion of "anti-virus" products on the market that tend to change their behavior on a daily basis, so you couldn't workaround all of them, even if you would be willing to waste your time on this - their propaganda is working well, it seems.


Strange, but true. Just tested again this morning after a fresh boot, and it works fine. I did not need to install the hotfix.
It would be nice to understand the origin of the problem. It is well known that Windows is terribly unstable, but normally it is not necessary to reboot to run a program!

I think it is related to:
Changes in 3.93 (29 Jan 2017):
* UPX has moved to GitHub - the new home page is https://upx.github.io
* fixed some win32/pe and win64/pe regressions introduced in 3.92

UPX 3.93, which I used in the TEST build, seems to have it fixed. New version will be released soon.

[LoRd_MuldeR]

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

Version 2.79 [2017-03-23]
* Updated x265 to version 2.3+22
* Fixed possible application startup error "0xc0000005"

[CrosstownTraffic]

And you probably have no idea how annoying it is, when you create a perfectly legitimate software (containing only 3rd-party tools each of which is perfectly legitimate too)

I actually do have a very good idea, except instead of anti-virus it was Microsoft and it cost my company hundreds of thousands in contracts.

you donate your work to the OpenSource community

Which I have thanked you at every point for doing, but does not excuse any of this behavior nor the attitude.

and then some braindead so-called "anti-virus" company comes along and accuses your product of being or containing malware - causing unaware users to send you loads of angry email, asking why you are spreading malware!

Did you even look at the VirusTotal report? A number of well-known, actual white hat software firms list netcat as malware! It does way, way more than you need for auto-update. Your blistering anti-anti-virus company rants aside, you've still been unable to produce a technical reason why you chose netcat for auto-update, and unable to produce a technical reason your software cannot run without the auto-update portion turned off.

If this was one of the projects that I'm doing for a company, I would just forward this case to our legal department. Our lawyers would do the required phone call and tomorrow the "anti-virus" company would have the problem fixed - either that or they could watch how they are sued to death.

The very fact that you think this would ever land in court in a "real" project tells me just how little you know about this process, and publishing actual software that isn't a side open source project.

Anyway, as things are, this is just one of my "private" projects that I'm doing for fun. I don't have an army of lawyers to keep the "anti-virus" companies in their place. So, all I can do is try to educate people and tell them the facts.

You've done nothing to "educate" me with "facts" about why you use netcat for auto-update! All you've done is rant against companies labeling netcat as malware.

The day that I change a single line of my code to escape unjustified defamation committed by "anti-virus" companies is not going to happen. It would be a pointless endeavor anyway, because there is a zillion of "anti-virus" products on the market that tend to change their behavior on a daily basis, so you couldn't workaround all of them, even if you would be willing to waste your time on this - their propaganda is working well, it seems.

You are startlingly myopic. I caution against users from using your software, and recommend they look at other applications in this subforum. Your lack of professionalism as a developer and questionable development choices should send red flags.

[LoRd_MuldeR]

Did you even look at the VirusTotal report? A number of well-known, actual white hat software firms list netcat as malware! It does way, way more than you need for auto-update. Your blistering anti-anti-virus company rants aside, you've still been unable to produce a technical reason why you chose netcat for auto-update, and unable to produce a technical reason your software cannot run without the auto-update portion turned off.

First of all, to make one thing clear: I can do whatever I want in my software. As long as I don't distribute actual malware - which of course I never did and never will do! - an anti-virus company is not entitled to judge about my work!

Heck, who do these megalomaniac people think they are? Do they think they are the "programming police", telling other developers how to write their code and how not? That's totally insane! We call such behavior "censorship"! :mad:

Secondly, I'm well aware of the VirusTotal report. Generally VirusTotal is useful, yes. Still, even if 100 out of 100 so-called "anti-virus" engines were reporting a program that every sane person knows is 100% legitimate as "potentially dangerous" (or similar oversimplified nonsense), then this would still be a wrong accusation. And, a wrong accusation doesn't become any more "true", just because it is repeated many times!

Finally, even though I'm not required (not at all!) to justify what I'm doing to any anti-virus company (or to you), the reasons I'm using NC for connectivity check is because it is faster than attempting a "real" HTTP connection via WGet.


The very fact that you think this would ever land in court in a "real" project tells me just how little you know about this process, and publishing actual software that isn't a side open source project.

Just to make it clear: I'm publishing commercial software on a regular basis. Or, more precisely, the company that pays me for developing commercial products for them, publishes the software under their brand.

And, on a regular basis, our software gets blocked by so-called "anti-virus" software - as we learn from people contacting our support. Guess what? I forward the case to the legal department, so they can do the required phone calls. And, once called by the lawyers of a "not so small" company, the anti-virus company will retreat quickly and promise to put our software on their "white-list" as soon as possible. They know why! ;)

If they continued blocking our product for no justified reason, while they are not blocking our competitor's product, this would be an illegal manipulation of the market. It would indicate they have a secret agreement with our competitor to hold our product off the market. If such case ever went to the court, it almost certainly would end up really expensive for them. That's why they always retreat quickly and the case never goes to court. Again: They know why! ;)

(But, as explained before, for the "private" projects I'm doing in my free time, I don't have any lawyers available to keep the "anti-virus" thugs in their place. Otherwise we wouldn't have this discussion)


You are startlingly myopic. I caution against users from using your software, and recommend they look at other applications in this subforum. Your lack of professionalism as a developer and questionable development choices should send red flags.

Why am I not surprised that this discussion ends up in the usual „either you change your software in the way that I want, or I'm going to spread derogative comments about your work“ blackmail attempt?

Be assured that it's not going to work. Been through that :)

[r0lZ]

the reasons I'm using NC for connectivity check is because it is faster than attempting a "real" HTTP connection via WGet.Funny that you use that reason to justify your choice, because I have never seen a program so sloooow to check for new versions. Each time I see the message telling that there is a long time since the last update check, I have to decide to either skip this one and be annoyed the next time, or accept to lose between 15 and 30 seconds and let the check happen. Personally, I use "real HTTP" to check for the updates of my programs, and it takes less than one second to complete (unless, I agree, if the site is down). It is a fact that HTTP is MUCH faster than your method (at least under Windows).

Anyway, as you wrote, there is no reason to justify yourself. But it I were you, I would be much more concerned by the fact that the current situation is scaring for many users, and may (and certainly has) a negative impact on the reputation of your software. The fact that some picky anti-virus may be culprit doesn't change that report. It's why I don't understand your will to leave things as they are. But of course, once again, you are free.

[LoRd_MuldeR]

Funny that you use that reason to justify your choice, because I have never seen a program so sloooow to check for new versions. Each time I see the message telling that there is a long time since the last update check, I have to decide to either skip this one and be annoyed the next time, or accept to lose between 15 and 30 seconds and let the check happen. Personally, I use "real HTTP" to check for the updates of my programs, and it takes less than one second to complete (unless, I agree, if the site is down). It is a fact that HTTP is MUCH faster than your method (at least under Windows).

Sorry, but it is technically impossible that establishing a full HTTP connection (as, e.g., WGet would do) can ever be faster than establishing only a TCP connection (as NC probing does).

That is because HTTP is an "application" layer protocol built-on top of the TCP "transport" layer protocol. Therefore, when establishing a HTTP connection, the first thing that happens is that a TCP connection will be established. Once that TCP connection has been established, HTTP will start sending the actual application-level payload (HTTP request header) over the established TCP connection. So, at the point where HTTP just starts doing its work, NC is already done with its job.

I don't know how you got those numbers (between 15 and 30 seconds), but for me the update check clearly takes less than ~10 seconds – and that's with my slowish DSL "home" connection! (small town, so no VDSL or FTTH)

If "your" way to update works significantly faster than "mine", it is probably because you are checking a single server. And when that server is down, then you give up (I assume). That's how I started too. But I had to learn, the hard way, that relying on a single update server is a bad idea! If the only update server breaks away (permanently) it leaves thousands of existing installations unable to update - forever. Consequently, I'm now using a bunch of update mirrors (currently 16), which greatly improves reliability. But, of course, nothing in life is for free. Providing many mirrors means that the application needs to find a "working" update mirror - which is done by probing. And NC does this way faster than, e.g., WGet.

See here:
http://muldersoft.com/temp/GVbsVBSXhCT3woAD/web_update.zip

[LoRd_MuldeR]

Funny that you use that reason to justify your choice, because I have never seen a program so sloooow to check for new versions. Each time I see the message telling that there is a long time since the last update check, I have to decide to either skip this one and be annoyed the next time, or accept to lose between 15 and 30 seconds and let the check happen. Personally, I use "real HTTP" to check for the updates of my programs, and it takes less than one second to complete (unless, I agree, if the site is down). It is a fact that HTTP is MUCH faster than your method (at least under Windows).
Sorry, but it is technically impossible that establishing a full HTTP connection (as, e.g., WGet would do) can ever be faster than establishing only a TCP connection (as NC probing does).

That is because HTTP is an "application" layer protocol built-on top of the TCP "transport" layer protocol. Therefore, when establishing a HTTP connection, the first thing that happens is that a TCP connection will be established. Once that TCP connection has been established, HTTP will start sending the actual application-level payload (HTTP request header) over the established TCP connection. So, at the point where HTTP just starts doing its work, NC is already done with its job.

I don't know how you got those numbers (between 15 and 30 seconds), but for me the update check clearly takes less than ~10 seconds – and that's with my slowish DSL "home" connection! (small town, so no VDSL or FTTH)

If "your" way to update works significantly faster than "mine", it is probably because you are checking a single server. And when that server is down, then you give up (I assume). That's how I started too. But I had to learn, the hard way, that relying on a single update server is a bad idea! If the only update server breaks away (permanently) it leaves thousands of existing installations unable to update - forever. Consequently, I'm now using a bunch of update mirrors (currently 16), which greatly improves reliability. But, of course, nothing in life is for free. Providing many mirrors means that the application needs to find a "working" update mirror - which is done by probing. And NC does this way faster than, e.g., WGet.

See here:
http://muldersoft.com/temp/GVbsVBSXhCT3woAD/web_update.zip

FWIW, I have tweaked the update checker algorithm a bit, so that it should now complete faster, most of the time:
https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2017-03-30.exe/download

Now never takes longer than ~3 seconds for me. This has been achieved by reducing the initial connection timeouts. So, if the first chosen mirror happens to be "slow", it will now timeout quickly, so that another (hopefully more responsive) mirror can be tested within a narrow time frame. The timeouts will be increased, successively, if mirrors continue to fail. That is required to deal with sluggish Internet connections...

[Atak_Snajpera]

Alternatively You can hide this "slowness" using background thread. When you run app extra thread should also check for updates. If updates are available some baloon notification could pop-up or maybe some flashing icon somewhere.

Regarding automatic updates I'm using different method in RipBot264. Instead of using 16 mirrors I'm relying on just single URL. However If specified address in .ini file is dead then Updater is using DuckDuckGo to find new location. Works well as long as DuckDuckGo is on-line ;)

[LoRd_MuldeR]

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

Version 2.80 [2017-04-01]
* Another attempt to fix application startup error "0xc0000005"
* Some tweaks to speed-up the update checker

[Sparktank]

Thanks a lot!

I'm new to x265, for testing.
So I find this quick and easy to start up.

Much easier than other bloated GUI's that try cater to so many other uses.

[hasenscharte]

@Lord Mulder: Awesome tool! Using the x64 tool versions is now easy as pie :thanks:

Anyway, could there be an option to have the log file saved to the source directory?

[LoRd_MuldeR]

Anyway, could there be an option to have the log file saved to the source directory?

There already is an option, in the "preferences" dialog, to have the log saved automatically, but logs will currently always be saved to:
%LOCALAPPDATA%\LoRd_MuldeR\Simple x264 Launcher\logs

Of course it would not be too difficult to make the logging directory configurable, or even have an option to write the log to the same directory where the output file is located. But I'm not sure I want to have yet another option for this.

(Writing the log to the same directory where the source file is located would be problematic, as there is no guarantee that this directory is "writable")

[hasenscharte]

as there is no guarantee that this directory is "writable"
Maybe then to the destination directory?

[LoRd_MuldeR]

Maybe then to the destination directory?

Yeah, quite possible. We could simply save the log to "<output_path>.log", for example. But I don't want yet another option for this. Maybe I'll change it completely.

[LoRd_MuldeR]

New TEST build:
https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2017-04-15.exe/download

* Updated x265 to version 2.3+32
* Updated NVEncC to version 3.07
* Save log files to the same directory as the output file

[docholliday]

Add option for 2pass method to see output file size.

[LoRd_MuldeR]

Add option for 2pass method to see output file size.

Uh? https://forums.yoworld.com/images/smilies/dizzy.png

[docholliday]

Uh? https://forums.yoworld.com/images/smilies/dizzy.png

2pass methode allows the user to specify a specific target file size but, i can not see this option in simple x264.

[LoRd_MuldeR]

2pass methode allows the user to specify a specific target file size but, i can not see this option in simple x264.

Nope, 2-Pass mode allows for specifying the desired target average bitrate.

2-Pass mode is enabled by setting the "--pass [1|2]" option in conjunction with the "--bitrate" option. See here for details:
https://manpages.debian.org/jessie/x264/x264.1.en.html

Example usage:

Two-pass with a bitrate of 1000kbps:

x264 --pass 1 --bitrate 1000 -o <output> <input>
x264 --pass 2 --bitrate 1000 -o <output> <input>


The target file size is defined by "duration_in_seconds × target_average_bitrate". So, if we knew the exact duration of the clip, we could compute the average bitrate that yields the desired file size.

However, we do not know the duration of the clip by the time that the job is created (i.e. appended to the queue) ;)

[LoRd_MuldeR]

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

Version 2.81 [2017-05-06]
* Updated x265 to version 2.4+6
* Updated NVEncC to version 3.07
* Save log files to the same directory as the output file

[LoRd_MuldeR]

Just because it fits so nicely into the whole "anti-virus" discussion:

Widely used so-called "anti-virus" products (Sophos, Kaspersky, Cisco) have been found to block the "kill-switch" domain that the WannaCry malware (you probably have heard about it in the news) is trying to contact before it kills itself. In other words: While the malware would normally have killed itself already, because the "kill-switch" domain is in existence now, the so-called "anti-virus" software made sure that malware remains active by preventing connections to that domain.

https://blog.fefe.de/?ts=a7e81647

So, not only is the "snake oil" not going to save you, in this case it can make things a whole lot worse, even for other users... (this not the first example, of course, but a particularly striking one)

[LoRd_MuldeR]

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

Version 2.82 [2017-05-26]
* Updated x264 to revision 2829
* Updated x265 to version 2.4+22

[LoRd_MuldeR]

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

Version 2.83 [2017-06-11]
* Updated x264 to revision 2833
* Updated x265 to version 2.4+36

[iSeries]

Is there a way for --output nul for the first of a two pass encode?

[LoRd_MuldeR]

Is there a way for --output nul for the first of a two pass encode?

Not at the moment. What would be the rationale? Do you think writing the first-pass output file to disk has any noteworthy speed effect?

[iSeries]

No speed effect, but surely less writes to the hard drive is better?

Also, more of a general x264 question. Its been a while since I've done any encoding but I remember from some time ago that when using ffms2 having to explicitly state --fps and --force-cfr in the command line as ffms2 fairly often got it wrong. Is this still the case?

[GMJCZP]

When I make a simple update with the setup, in the "About..." option does not show version 2.83, still showing 2.81.

[LoRd_MuldeR]

No speed effect, but surely less writes to the hard drive is better?

I don't think you really need to worry about this.

On the other hand, it's quite easy to just set the output filename to NUL in the first pass, so I will probably add an option for this.

[LoRd_MuldeR]

When I make a simple update with the setup, in the "About..." option does not show version 2.83, still showing 2.81.

Not quite sure what you mean with "update with the setup". But if it shows "v2.81" in the about screen, then you are running v2.81, not v2.83.

The setup program can "overwrite" (upgrade) an existing installation, so you do not need to uninstall to old version first. Anyway, the setup program will install whatever version is contained in the particular setup package that you are installing. Old setup package will install old version. You need to download the latest (https://github.com/lordmulder/Simple-x264-Launcher/releases/latest) setup program from the project site and install that! Or just let the auto-update function upgrade your existing "v2.81" installation to the latest...

(I just tested that v2.81 will upgrade to v2.83 flawlessly and couldn't notice any issues)

[iSeries]

I don't think you really need to worry about this.

On the other hand, it's quite easy to just set the output filename to NUL in the first pass, so I will probably add an option for this.

Thank you! :-)

[GMJCZP]

Fixed issue, I was using an old setup, thank you.

[Shb]

Firstly, thanks for all the work! I'm using this pretty much daily and it's been great.

Recently, I've been having a slight issue with hitting the deadlock timer. I've been using the --no-deadlock-detection switch to avoid the problem for the most part, however I'm somewhat confused as to why both creating the avs2yuv and x264 process take a long time. Before the latest version, these would start almost immediately, but on the current version (I think I updated in-app and it said to build #1114), each of these processes takes well over the 5 minutes before deadlocking kicks in. I've even tried manually indexing the files but the same outcome occurs.

Is there anything I can provide you with to assist?

Edit: Seems it was source-specific. I tried a different source and it had none of the same issues.

[LoRd_MuldeR]

Firstly, thanks for all the work! I'm using this pretty much daily and it's been great.

Recently, I've been having a slight issue with hitting the deadlock timer. I've been using the --no-deadlock-detection switch to avoid the problem for the most part, however I'm somewhat confused as to why both creating the avs2yuv and x264 process take a long time. Before the latest version, these would start almost immediately, but on the current version (I think I updated in-app and it said to build #1114), each of these processes takes well over the 5 minutes before deadlocking kicks in. I've even tried manually indexing the files but the same outcome occurs.

Is there anything I can provide you with to assist?

Edit: Seems it was source-specific. I tried a different source and it had none of the same issues.

Well, the included avs2yuv hasn't changed for ages. x264 has been updated recently, but there should be no change effecting "startup" time.

If avs2yuv or x264 takes a long time to start or even triggers "deadlock" detection, then it almost certainly means that Avisynth (or more precisely: your Avisynth script) takes a very long time to initialize.

A typical cause for this is FFMS2 (or whatever source filter you use) taking a long time to index the source. But there could be other reasons, e.g. your script is just painfully slow overall.

[r0lZ]

Personally, I check my script in AvsPmod (https://avspmod.github.io) before encoding it with Simple X264 Launcher. With AvsPmod, I have a visual feedback, and if something goes wrong, I can see the avisynth error message. And the indexing of the source is already finished when I decide to encode. With that method, I have no startup problem any more.

[Shb]

Personally, I check my script in AvsPmod (https://avspmod.github.io) before encoding it with Simple X264 Launcher. With AvsPmod, I have a visual feedback, and if something goes wrong, I can see the avisynth error message. And the indexing of the source is already finished when I decide to encode. With that method, I have no startup problem any more.

That's what I have been doing, and I didn't have any issues with any source up until the one I posted about. Even after moving on to different sources I am back to normal again, I'm just not sure why it struggled. There was nothing unusual about the script, just resizing and a slight bit of cropping. Along the lines of:


FFVideoSource("..\source.mkv")
Crop(0, 20, 0, -20)
Spline36ResizeMod(1024, 552)

No deinterlacing or anything intensive at all. It seemed as though the file was being reindexed every single time no matter if the index file already existed.

[LoRd_MuldeR]

That's what I have been doing, and I didn't have any issues with any source up until the one I posted about. Even after moving on to different sources I am back to normal again, I'm just not sure why it struggled. There was nothing unusual about the script, just resizing and a slight bit of cropping. Along the lines of:


FFVideoSource("..\source.mkv")
Crop(0, 20, 0, -20)
Spline36ResizeMod(1024, 552)

No deinterlacing or anything intensive at all. It seemed as though the file was being reindexed every single time no matter if the index file already existed.

Try setting the "cachefile" option explicitly in your FFVideoSource() call.

[LoRd_MuldeR]

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

Version 2.84 [2017-07-12]
* Updated x264 to revision 2851
* Updated x265 to version 2.5+2

[tormento]

I read, from website, I can use portable AviSynth:
InstallPath\
├─ x264_launcher_portable.exe
└─ extra\
└─ Avisynth\
├─ x86\
│ ├─ avisynth.dll <32-Bit>
│ ├─ devil.dll <32-Bit>
│ └─ etc…
└─ x64\
├─ avisynth.dll <64-Bit>
├─ devil.dll <64-Bit>
└─ etc…
Imaging I can put there AviSynth+, how can I place there plugins too, with the same structure of AviSynth+, forgetting forever the PITA of installing AviSynth?

[LoRd_MuldeR]

I read, from website, I can use portable AviSynth:
InstallPath\
├─ x264_launcher_portable.exe
└─ extra\
└─ Avisynth\
├─ x86\
│ ├─ avisynth.dll <32-Bit>
│ ├─ devil.dll <32-Bit>
│ └─ etc…
└─ x64\
├─ avisynth.dll <64-Bit>
├─ devil.dll <64-Bit>
└─ etc…
Imaging I can put there AviSynth+, how can I place there plugins too, with the same structure of AviSynth+, forgetting forever the PITA of installing AviSynth?

My experience with Avisynth+ is limited.

When you install "normal" Avisynth, it will offer you the "Standalone, Unpack Files only" install option. That will extract the required files. For "portable" use, those files need to be placed exactly as described in the README file.

You can try doing the same with Avisynth+. If case that there is no "Standalone, Unpack Files only" option in the Avisynth+ installer, you will need to extract the required files in a different way...

[LoRd_MuldeR]

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

Version 2.85 [2017-10-04]
* Updated x265 to version 2.5+22
* Updated build environment to Visual Studio 2017 with Update-3

[LoRd_MuldeR]

Simple x264 Launcher v2.86

Version 2.86 [2018-02-27]
* Updated x264 to revision 2901 (API v155)
* Updated x265 to version 2.7+1
* Updated NVEncC to version 3.30
* x264 encoder now uses combined 8-Bit/10-Bit binaries
* Moved "Shutdown computer" option from preferences to application menu
* Updated build environment to Visual Studio 2017 with Update-5

[Cedvano]

I fall down on this sotfware and it's wonderful

Thank you, it's so simple to convert UHD with this software.

[Atak_Snajpera]

Lord_Mulder
You can reduce archive size from 54.8 MB (zip) to 32.7 MB (7z ULTRA preset). ZIP compression efficiency is a joke in 2018 ;)

You could use ffmpeg to pipe directly from .mkv
http://i.cubeupload.com/dEdlSS.png

[tormento]

@Lord_Mulder

Do you plan to add HDR support?

[LoRd_MuldeR]

Lord_Mulder
You can reduce archive size from 54.8 MB (zip) to 32.7 MB (7z ULTRA preset). ZIP compression efficiency is a joke in 2018 ;)

Yes, I know, LZMA (7z) beats Deflate (ZIP) by far. That's why the EXE installer uses LZMA.

ZIP is used for the "portable" version for max. compatibility. After all, the only archive format Windows supports "out of the box" is ZIP.

(Yes, CAB works too and compresses slightly better, but Explorer fails horribly to extract CAB's with sub-folders)

You could use ffmpeg to pipe directly from .mkv
http://i.cubeupload.com/dEdlSS.png

Maybe in a future version. Currently I have no time for bigger improvements like this, as my "real-life" job is keeping me busy ;)

And, of course, I'd much prefer, if x265 CLI finally adopted the FFMS2 input module from x264 CLI...

[LoRd_MuldeR]

@Lord_Mulder

Do you plan to add HDR support?

I have no idea. What changes in GUI you would be required to "add HDR support" :confused:

(If you are referring to "HDR support" support in x264 or x265, you would have to ping the x264/x265 developers. That's not my business)

[AYColumbia]

Hi,
I just installed the latest NVIDIA driver 397.31 and now avs2yuv_x64.exe crashes. I found the info below in the event viewer. Note that rolling driver back to prior version 391.35 works fine. I confirmed this on my laptop (GeForce GTX 960M) and my media server (Geforce GTX 650).

Faulting application name: avs2yuv_x64.exe, version: 0.0.0.0, time stamp: 0x57b61de5
Faulting module name: nvcuda.dll, version: 24.21.13.9731, time stamp: 0x5adc2e79
Exception code: 0xc0000005
Fault offset: 0x00000000001280ef
Faulting process id: 0x5c4
Faulting application start time: 0x01d3ddb05c0c63d7
Faulting application path: c:\MultiMediaTools\Simple x264 Launcher v2\toolset\x64\avs2yuv_x64.exe
Faulting module path: C:\WINDOWS\SYSTEM32\nvcuda.dll
Report Id: 282ad1ed-1fca-41a4-bc35-68fffdc1550e
Faulting package full name:
Faulting package-relative application ID:


I run the line below to get info I need like # of frames which has been working flawlessly until the new driver.

cmd /c ""c:\MultiMediaTools\Simple x264 Launcher v2\toolset\x64\avs2yuv_x64.exe" -frames 1 "media_p1.avs" NUL 2>&1"

The avs file only has two lines, i.e.,

LoadPlugin("c:\MultiMediaTools\DGDecNV\x64 Binaries\DGDecodeNV.dll")
DGSource("media_p1.dgi")

I was able to load/play the avs file in vdub64 just to be sure. Let me know if you need any other info.

[tormento]

Hi,I just installed the latest NVIDIA driver 397.31 and now avs2yuv_x64.exe crashes.
Same here. Did not try to rollback yet but same symptoms.

MeGUI_x64 gives errors too.

EDIT: rollback to 391.35 and error disappeared. Very strange indeed.

[Jim_Pansen]

Hi Mulder,

thank you very much for this helpful tool.

Could you please add a regular field to locate a chapter index file to can assign it to a job more easy?
Parameter --qpfile QPFILE_NAME
http://www.x264bluray.com/advanced-features/chapters

The parameter would be best controlled in the GUI since the cmd line is not much handy for modifications.
An the file must be changed for each file!

Another feature request is to can define different speed for first pass in 2-pass mode.

Thanks to consider about it
best regards
Jim

[r0lZ]

I just installed the latest NVIDIA driver 397.31 and now avs2yuv_x64.exe crashes.It seems that this version of the driver is full of problems. I have read here (in French) (https://www.tomshardware.fr/articles/geforce-397.31-bug-pilote-carte-graphique,1-67457.html) that if you install it for a GTX 1060, the installer asks to reboot the computer after each reboot! nVidia is currently working on a solution. Perhaps the solution will fix the avs2yuv bug too.
In the meantime, the article suggests to skip this update, or, if it has already been installed, use the Display Driver Uninstaller (https://www.wagnardsoft.com) and then re-install the previous version (v391.35) (http://www.nvidia.com/download/driverResults.aspx/132845/en-us).

[LoRd_MuldeR]

Hi,
I just installed the latest NVIDIA driver 397.31 and now avs2yuv_x64.exe crashes. I found the info below in the event viewer. Note that rolling driver back to prior version 391.35 works fine. I confirmed this on my laptop (GeForce GTX 960M) and my media server (Geforce GTX 650).

Faulting application name: avs2yuv_x64.exe, version: 0.0.0.0, time stamp: 0x57b61de5
Faulting module name: nvcuda.dll, version: 24.21.13.9731, time stamp: 0x5adc2e79
Exception code: 0xc0000005
Fault offset: 0x00000000001280ef
Faulting process id: 0x5c4
Faulting application start time: 0x01d3ddb05c0c63d7
Faulting application path: c:\MultiMediaTools\Simple x264 Launcher v2\toolset\x64\avs2yuv_x64.exe
Faulting module path: C:\WINDOWS\SYSTEM32\nvcuda.dll
Report Id: 282ad1ed-1fca-41a4-bc35-68fffdc1550e
Faulting package full name:
Faulting package-relative application ID:


I run the line below to get info I need like # of frames which has been working flawlessly until the new driver.

cmd /c ""c:\MultiMediaTools\Simple x264 Launcher v2\toolset\x64\avs2yuv_x64.exe" -frames 1 "media_p1.avs" NUL 2>&1"

The avs file only has two lines, i.e.,

LoadPlugin("c:\MultiMediaTools\DGDecNV\x64 Binaries\DGDecodeNV.dll")
DGSource("media_p1.dgi")

I was able to load/play the avs file in vdub64 just to be sure. Let me know if you need any other info.

Well, avs2yuv_x64.exe is just the "wrapper" around Avisynth.DLL. So, if you see crashes in avs2yuv_x64.exe, it is almost certainly not a problem in avs2yuv_x64.exe itself but a crash in Avisynth.

Furthermore, as long as you are using the "official" stable version of Avisyth, crashes in Avisynth are caused by "buggy" plug-ins more often than not.

Here the case seems quite clear: You are using "DGDecodeNV.dll" plug-in (GPU-based decoder DLL) and that seems to not work correctly with latest NVIDIA driver. The crash of avs2yuv_x64.exe is just the symptom of the underlying problem.

I cannot say whether there is a bug in "DGDecodeNV.dll" (which I don't have) that happens to trigger with latest NVIDIA driver, or whether the latest NVIDIA driver is bugged. Comments by others seem to indicate the latter...

[LoRd_MuldeR]

Hi Mulder,

thank you very much for this helpful tool.

Could you please add a regular field to locate a chapter index file to can assign it to a job more easy?
Parameter --qpfile QPFILE_NAME
http://www.x264bluray.com/advanced-features/chapters

The parameter would be best controlled in the GUI since the cmd line is not much handy for modifications.
An the file must be changed for each file!

This seems a bit specific for me to justify another GUI option.

If you need to use a different "--qpfile" for each input file, you can use the variables "$(INPUT)" or "$(OUTPUT)" in your custom parameters...


Another feature request is to can define different speed for first pass in 2-pass mode.

Thanks to consider about it
best regards
Jim

x264 and x265 automatically applies "faster" settings to the first pass of a 2-Pass encode, unless you specify "--slow-first-pass" option.

The idea is that you can use the same settings (Preset) for both passes and still the encoder automatically uses "faster" settings in the first pass for those settings that won't effect the 2nd pass...

[AYColumbia]

@r0lZ,
Thanks for the info. I'll wait for the next driver release.

@LoRd_MuldeR,
I think you're right as what you said makes sense. Hopefully next driver release fixes the current mess.

[Jim_Pansen]

This seems a bit specific for me to justify another GUI option.
Mmmh, it's needed to define precise chapter points for Blu-ray compatible streams.

If you need to use a different "--qpfile" for each input file, you can use the variables "$(INPUT)" or "$(OUTPUT)" in your custom parameters...
Thank you for the hint, but sorry, I don't know exactly what to do.
Sure I know how to drop the parameter into the line of custom parameters. :)
But I must admit, I'm not familar with the syntax, is it propritairy?
I can put it into the custom parameter line and add the job to queue.
But what happens next? Where has the files and folders to be defined?
Will simpleX264 launcher ask me for that?

x264 and x265 automatically applies "faster" settings to the first pass of a 2-Pass encode, unless you specify "--slow-first-pass" option.

The idea is that you can use the same settings (Preset) for both passes and still the encoder automatically uses "faster" settings in the first pass for those settings that won't effect the 2nd pass...
Thanks!

Do you consider about capabilities to can re-edit jobs already in queue?
Do you even consider about to can save and restore queues like a project?

best
Jim

[LoRd_MuldeR]

Thank you for the hint, but sorry, I don't know exactly what to do.
Sure I know how to drop the parameter into the line of custom parameters. :)
But I must admit, I'm not familar with the syntax, is it propritairy?
I can put it into the custom parameter line and add the job to queue.
But what happens next? Where has the files and folders to be defined?
Will simpleX264 launcher ask me for that?

It is explained in the program ;)

https://i.imgur.com/gUCtiJo.png?1

Instead of writing a specific file name, such as --qpfile "c:\foo\bar\baz.qpfile", you can, for example, write --qpfile "$(INPUT).qpfile".

This is going to load the file "<whatever_the_input_file_is>.qpfile" as the qpfile.


Do you consider about to re-edit jobs already in queue?

Just select "Restart Job", which effectively clones the existing into a new one and also allows you to edit the job.


Do you even consider about to can save and restore queues like a project?

Not at this point, sorry.

[sneaker_ger]

x264 and x265 automatically applies "faster" settings to the first pass of a 2-Pass encode, unless you specify "--slow-first-pass" option.
This is not true for x265 anymore.

http://x265.readthedocs.io/en/default/cli.html#cmdoption-slow-firstpass

[LoRd_MuldeR]

This is not true for x265 anymore.

http://x265.readthedocs.io/en/default/cli.html#cmdoption-slow-firstpass

In what way? Seems to do exactly what one would expect:

x265:
--slow-firstpass, --no-slow-firstpass

Enable first pass encode with the exact settings specified. The quality in subsequent multi-pass encodes is better (compared to first pass) when the settings match across each pass. Default enabled.

When slow first pass is disabled, a turbo encode with the following go-fast options is used to improve performance:
[…]

x264:
--slow-firstpass

Don't force these faster settings with --pass 1:
[…]

[sneaker_ger]

Enable first pass encode with the exact settings specified. The quality in subsequent multi-pass encodes is better (compared to first pass) when the settings match across each pass. Default enabled.



Version 2.0
Release date - 13th July, 2016

- multi-pass: First pass now uses slow-firstpass by default, enabling better RC decisions in future passes
http://x265.readthedocs.io/en/default/releasenotes.html#version-2-0

[LoRd_MuldeR]

Okay, so x265 now has "--slow-firstpass" enabled by default, and you actually have to pass "--no-slow-firstpass" in order to get faster settings in the first pass.

Doesn't change the basic idea though: We still can use the same settings for both passes, and simply add "--no-slow-firstpass" in order to speed up the first pass (instead of adding "--slow-firstpass" in order to not peed up the first pass).

[Jim_Pansen]

This is going to load the file "<whatever_the_input_file_is>.qpfile" as the qpfile.
This works really fine!
I did not realize the mouse-over description!
Thank you very much!

Jim

[tormento]

397.55 (http://nvidia.custhelp.com/app/answers/detail/a_id/4661) out

Any hero to try? :)

EDIT: Tried and same error. Back to past.

[AYColumbia]

397.55 (http://nvidia.custhelp.com/app/answers/detail/a_id/4661) out

Any hero to try? :)

EDIT: Tried and same error. Back to past.
I use DGDecNV so I checked the forum there and sure enough someone did report issues that are fixed in the latest DG tools slipstream of 2053. If you're using this, then grab the latest. I did and it does now work fine with 397.31 which didn't prior. I normally don't install hot fix releases but just the official releases but I'm sure it'll work fine with .55 too.

[LoRd_MuldeR]

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

Version 2.87 [2018-05-11]
* Updated x265 to version 2.7+348
* Updated NVEncC to version 4.01
* Updated build environment to Visual Studio 2017 with Update-7

[jorX]

In my XP - SP3 install, any version following the 2.84 doesn't works;
It says: "process exited with error code: -1073741511" without further explanation(s).
Any hints?
Thank you

[lansing]

How do I set bit depth for NVEncC? I tried to put "--output-depth 10" on the custom parameter but it gave me the warning "forbidden parameter".

[StainlessS]

In my XP - SP3 install, any version following the 2.84 doesn't works;
It says: "process exited with error code: -1073741511" without further explanation(s).
Any hints?
Thank you

-1073741511 is hex 0x3ffffec7,

Only found a few mentions of that error code via google,
here is one concerning problem with a Qt4 dll:- http://www.qtcentre.org/threads/26213-exited-with-code-1073741511

[LoRd_MuldeR]

In my XP - SP3 install, any version following the 2.84 doesn't works;
It says: "process exited with error code: -1073741511" without further explanation(s).
Any hints?
Thank you

-1073741511 == 0xC0000139 == STATUS_ENTRYPOINT_NOT_FOUND
The procedure entry point %hs could not be located in the dynamic link library %hs.

I suppose you see that in that log inside of Simple x264 Launcher?

It would indicate that whatever encoder (x264? x265?) you are trying to use is missing a required function from one of its required DLLs.

Probably means that Windows XP is no longer supported by the effected encoder.

(Which wouldn't be much of a surprise, considering that Windows XP has reached "end of life" more than four years ago)

[UPDATE]

Indeed, current "x264.exe" imports various functions from KERNEL32.DLL that have not been available on Windows XP yet:
https://i.imgur.com/LtNswSW.png

(Also imports some functions from BCRYPT.DLL, which is missing entirely on Windows XP)

[LoRd_MuldeR]

-1073741511 is hex 0x3ffffec7

It actually is 0xC0000139, equal to STATUS_ENTRYPOINT_NOT_FOUND, if you interpret it as 32-Bit unsigned integer, which I think is the right thing to do here.

NT_STATUS codes are defined as DWORDs, which are 32-Bit unsigned integer values, but will be typecasted to 32-Bit signed integer values when returned as a process' exit code.

(Hence, if the original unsigned value had its most significant bit set, the signed value will have negative sign)

#include <stdint.h>

int main()
{
const uint32_t code = (uint32_t)(-1073741511);
printf("0x%X\n", code);
return 0;
}
Output:
0xC0000139

[LoRd_MuldeR]

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

Version 2.88 [2018-08-11]
* Updated x264 to revision 2932 (API v157)
* Updated x265 to version 2.8+57

[vehf263]

Hi,

I installed Simple Launcher using .exe setup and extracting from .zip.
In both cases Launcher says it has no Vapoursynth installed.

I tried to do so according your readme.html. No luck.

InstallPath\
├─ x264_launcher_portable.exe
└─ extra\
└─ Avisynth\
├─ x86\
│ ├─ avisynth.dll <32-Bit>
│ ├─ devil.dll <32-Bit>
│ └─ etc…
└─ x64\
├─ avisynth.dll <64-Bit>
├─ devil.dll <64-Bit>
└─ etc…

It's your path to install both Vapoursynth and Avisynth from your readme.html.

The path you provide is not enough clear or is not actual.
Please I need a today's path to install both Vapoursynth and Avisynth.

Thank you.

[LoRd_MuldeR]

Hi,

I installed Simple Launcher using .exe setup and extracting from .zip.
In both cases Launcher says it has no Vapoursynth installed.

I tried to do so according your readme.html. No luck.

InstallPath\
├─ x264_launcher_portable.exe
└─ extra\
└─ Avisynth\
├─ x86\
│ ├─ avisynth.dll <32-Bit>
│ ├─ devil.dll <32-Bit>
│ └─ etc…
└─ x64\
├─ avisynth.dll <64-Bit>
├─ devil.dll <64-Bit>
└─ etc…

It's your path to install both Vapoursynth and Avisynth from your readme.html.

The path you provide is not enough clear or is not actual.
Please I need a today's path to install both Vapoursynth and Avisynth.

Thank you.

If you want to use Avisynth and/or VapourSynth in "portable" mode, you need to follow the install instructions exactly:
http://muldersoft.com/docs/x264_launcher_readme.html#portable-mode

Also note that the files need to be arranged exactly as depicted in the README file. And especially note the remark about "embeddable Python", if you want to use VapourSynth portable!

Last but not least, you can launch "x264_launcher.exe" with option "--console" to get more details about Avisynth/VaopurSynth detection...

[videoh]

Minor cosmetic issue:

http://rationalqm.us/misc/sl.png

Thanks for this great program.

[vehf263]

Hi,

Thank you for your patience.

One more question.
How can I execute some particular Avisynth scripts while using Simple x264 Launcher?

Thank you.

[LoRd_MuldeR]

Minor cosmetic issue:

Should be somewhat better in new version.

One more question.
How can I execute some particular Avisynth scripts while using Simple x264 Launcher?

Uhm? :confused:

You "execute" an Avisynth script simply by selecting as the source file for your encoding job, and then launching that job – if that was the question.

[LoRd_MuldeR]

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

Version 2.89 [2018-10-12]
* Updated x264 to revision 2935 (API v157)
* Updated x265 to version 2.9+1
* Improved initial window size on the "High DPI" screen
* Updated build environment to Visual Studio 2017 with Update-8

[vehf263]

You "execute" an Avisynth script simply by selecting as the source file for your encoding job, and then launching that job – if that was the question.

Hmm :confused:

Will such a script of three actually working string work without any error?

#LoadPlugin("C:\Program Files\MeGUI\tools\ffms\ffms2.dll")
#FFVideoSource("D:\Temp00\StatusQuo.video.mkv", fpsnum=30000, fpsden=1001, threads=1)
#
selectTotal1=framecount()/100
selectTotal2=selectTotal1*2
selectrangeevery(selectTotal2,50)
#

you generate an index file by your internals, so there is no needs to generate it in this tiny script.

[videoh]

Your script must have a source filter, otherwise it does not provide a clip.

[vehf263]

Your script must have a source filter, otherwise it does not provide a clip.

Yup, I got it myself but thank you anyway.

loadplugin("C:\Program Files\MeGUI\tools\AviSynth\plugins\DirectShowSource.dll")
clip=DirectShowSource("D:\Temp00\StatusQuo.video.mkv", convertfps=true)
selectTotal1=framecount(clip)/100
selectTotal2=selectTotal1*2
#selectrangeevery(selectTotal2, 50, 0, false)
selectrangeevery(clip)

[videoh]

Yup, I got it myself but thank you anyway. Trust, but verify.

[tormento]

@LoRd_MuldeR

Would you please add unicode support to log, both window and saved one?

[LoRd_MuldeR]

@LoRd_MuldeR

Would you please add unicode support to log, both window and saved one?

In what sense?

The "main" application is fully Unicode-aware. The output stream produced by the encoder will be interpreted as UTF-8 and will be displayed as proper Unicode.

However, be aware that some of the tools we use may not support Unicode! (Avisynth *cough*)

[tormento]

However, be aware that some of the tools we use may not support Unicode! (Avisynth *cough*)
I had that doubt.

Let's break the balls to Pinterf :devil:

[spoRv]

First, thanks a lot, LoRd_MuldeR, you made a great software!

I usually use it with a lossless file as source, but now that I need to feed it with an avisynth script, I have an error that talks about anaglyph.avsi is missing (sorry, not at my computer now...)

The fact is, the avisynth script contains just avisource commands (to chain various lossless files) and nothing more, for sure not an anaglyph command... and, by the way, that anaglyph.avsi file is in the avisynth plugins directory.

The error came up both with an older version and with the newest one.

May you help me? Thanks a lot in advance!

[LoRd_MuldeR]

I usually use it with a lossless file as source, but now that I need to feed it with an avisynth script, I have an error that talks about anaglyph.avsi is missing (sorry, not at my computer now...)

The fact is, the avisynth script contains just avisource commands (to chain various lossless files) and nothing more, for sure not an anaglyph command... and, by the way, that anaglyph.avsi file is in the avisynth plugins directory.

The error came up both with an older version and with the newest one.

This error message originates from Avisynth, so not actually a Simple x264/x265 Launcher error. What if you open the exactly same .avs file in, e.g., VirtualDub? :confused:

My advice would be to make sure your AVS script really doesn't import/load anything that isn't needed. Also, make sure you remove any .avsi file and any plugin DLL from your Avisynth "plugin" directory that isn't required! Actually I much prefer to keep my Avisynth "plugin" directory to the bare minimum and explicitly load additional plugins (or import additional .avsi files). There's too much that can go wrong, if you bloat your Avisynth "plugins" directory with "legacy" stuff...

BTW: You are using latest "stable" official Avisynth 2.6, or something else?

[spoRv]

This error message originates from Avisynth, so not actually a Simple x264/x265 Launcher error. What if you open the exactly same .avs file in, e.g., VirtualDub? :confused:

My advice would be to make sure your AVS script really doesn't import/load anything that isn't needed. Also, make sure you remove any .avsi file and any plugin DLL from your Avisynth "plugin" directory that isn't required! Actually I much prefer to keep my Avisynth "plugin" directory to the bare minimum and explicitly load additional plugins (or import additional .avsi files). There's too much that can go wrong, if you bloat your Avisynth "plugins" directory with "legacy" stuff...

BTW: You are using latest "stable" official Avisynth 2.6, or something else?

The script works perfectly on VirtualDub (or VirtualDubMod).

About plugins full of stuff: you are right, mine is full of them, but I can't remember anything I need, anytime, to load them for every script I use... the fact is, for some scripts, I could use up to twenty, if not more, plugins and/or .avsi files! :scared:

I use 2.6.0.5 on Windows 10.

Auto-hint: maybe I could just rename the plugin folder temporarily, and see if in the case of a simple script with just avisource commands it works!

[spoRv]

Solved!

Indeed, I just put the (very few) necessary plugins for a very light script, and it works!

Now, I'm curious to know how to get rid of potentially harm plugins - not only for your software, but in general... but this could be material for a new thread (or is there an existing one?)

[legend]

Nice Gui

[Rocinante]

Hi, UI seem clean and wonderful to use.
Wondering if there is any way to add function on GUI to precisely limit the max bit rate of an encoding or the option is just not possible on x264 and we are stuck with unconventional way of limiting vbv maxrate+bufsize?
Thanks in advance.

[LoRd_MuldeR]

Wondering if there is any way to add function on GUI to precisely limit the max bit rate of an encoding or the option is just not possible on x264 and we are stuck with unconventional way of limiting vbv maxrate+bufsize?

x264 does not have a "maximum bitrate" option (other than the VBV options). And the options available in the GUI are, of course, a strict sub-set of the options that x264 offers.

Note: You can not have something like a "maximum bitrate" without a properly defined buffering model. And that's exactly what VBV does. So you actually want VBV here ;)

See also:
https://slhck.info/video/2017/03/01/rate-control.html
→ section "Constrained Encoding (VBV)"

[Rocinante]

x264 does not have a "maximum bitrate" option (other than the VBV options). And the options available in the GUI are, of course, a strict sub-set of the options that x264 offers.

Note: You can not have something like a "maximum bitrate" without a properly defined buffering model. And that's exactly what VBV does. So you actually want VBV here ;)

See also:
https://slhck.info/video/2017/03/01/rate-control.html
→ section "Constrained Encoding (VBV)"

Thanks for explaining on x264 and linking the vbv related articles, I got a better understanding of using vbv now.

Mainly the problem that I'm facing is how to properly define the buffering model for different types of video. Like there is a CBR/2pass encoding to get accurate targeted average bitrate even though the quality will differ in encoding different sources, so I was looking for a similar function that can produce constant result for max bitrate, and perhaps there is something that I did wrong, I can't seem to get that with vbv.

If your encode always “maxes out” your maximum bitrate, your CRF was probably set too low.-[Understanding Rate Control Modes (x264, x265, vpx)-section "Constrained Encoding (VBV)"]
I can cope with the fact that it maxes out the maximum bitrate, but in my case, sometimes it will exceed it depending on sources and that's what troubling me.

Thanks again for your time.

[LoRd_MuldeR]

Thanks for explaining on x264 and linking the vbv related articles, I got a better understanding of using vbv now.

Mainly the problem that I'm facing is how to properly define the buffering model for different types of video. Like there is a CBR/2pass encoding to get accurate targeted average bitrate even though the quality will differ in encoding different sources, so I was looking for a similar function that can produce constant result for max bitrate, and perhaps there is something that I did wrong, I can't seem to get that with vbv.


I can cope with the fact that it maxes out the maximum bitrate, but in my case, sometimes it will exceed it depending on sources and that's what troubling me.

Thanks again for your time.

If you use 2-Pass RC, there normally is no need to set VBV at all. And the same applies to CRF mode.

Just set the target average bitrate as needed (via "--bitrate" option) in order to hit the desired target file size, and let the encoder optimally distribute the available bits. If the encoder creates some bitrate "spikes" or bitrate "drops", then this is the perfectly normal and expected behavior of 2-Pass ABR (or CRF) mode – it happens for a reason! It's because the bits are "moved" to where they are actually needed :)

With VBV enabled, you are effectively forcing the encoder to create a more "uniform" distribution of the available bits. This avoids strong bitrate "spikes" or bitrate "drops", yes. But it also means that the distribution of the available bits is going to deviate from the "optimal" distribution that the encoder would have chosen without the VBV restrictions – sometimes more, sometimes less :scared:

In other words: VBV can only make the resulting video quality worse. In the best case, VBV won't affect video quality in a noticeable way. But, certainly, VBV restrictions do not improve video quality!


VBV is required for two scenarios:
Streaming: Here you necessarily need to avoid bitrate "spikes" that exceed the available network bandwidth in order to ensure "smooth" playback.
Hardware Players: These players read video data from the disc at a certain (maximum) speed, and they have limited buffering capabilities. So, again, strong bitrate "spikes" are to be avoided in order to ensure "smooth" playback.


(In both of these scenarios, we choose VBV as the lesser of two evils. And, in both scenarios, the required VBV parameters are obvious from the use case)

[Rocinante]

If you use 2-Pass RC, there normally is no need to set VBV at all. And the same applies to CRF mode.

Just set the target average bitrate as needed (via "--bitrate" option) in order to hit the desired target file size, and let the encoder optimally distribute the available bits. If the encoder creates some bitrate "spikes" or bitrate "drops", then this is the perfectly normal and expected behavior of 2-Pass ABR (or CRF) mode – it happens for a reason! It's because the bits are "moved" to where they are actually needed :)

With VBV enabled, you are effectively forcing the encoder to create a more "uniform" distribution of the available bits. This avoids strong bitrate "spikes" or bitrate "drops", yes. But it also means that the distribution of the available bits is going to deviate from the "optimal" distribution that the encoder would have chosen without the VBV restrictions – sometimes more, sometimes less :scared:

In other words: VBV can only make the resulting video quality worse. In the best case, VBV won't affect video quality in a noticeable way. But, certainly, VBV restrictions do not improve video quality!


VBV is required for two scenarios:
Streaming: Here you necessarily need to avoid bitrate "spikes" that exceed the available network bandwidth in order to ensure "smooth" playback.
Hardware Players: These players read video data from the disc at a certain (maximum) speed, and they have limited buffering capabilities. So, again, strong bitrate "spikes" are to be avoided in order to ensure "smooth" playback.


(In both of these scenarios, we choose VBV as the lesser of two evils. And, in both scenarios, the required VBV parameters are obvious from the use case)

Yes, I understand vbv is hurting the encoding quality and I can get accurate average bitrate with 2pass RC, but not maximum bitrate.

I'm in a third case scenarios now that due to a website streaming policy, they request a limit for a "maximum bitrate" value (such as all video max bitrate needs to be below 15Mb/s and below 8Mb/s average bitrate) instead of matching buffering capabilities or like a certain fixed vbv value used in bluray.

[LoRd_MuldeR]

I'm in a third case scenarios now that due to a website streaming policy, they request a limit for a "maximum bitrate" value (such as all video max bitrate needs to be below 15Mb/s and below 8Mb/s average bitrate)

That's exactly the "streaming" scenario. So, VBV is what you want/need here.

As said before, there is no such thing as an "instantaneous" bitrate. Instead, a "bitrate" is always an average, computed/measured over a certain time interval.

More precisely: Every picture has a certain size, in bits, in the encoded bitstream. And, whenever the decoder is about to start decoding the next picture, we have to ensure that all bits required to decode that picture already are present in the buffer. That's what VBV is all about! And that's also why "--maxrate" (i.e the network bandwidth, i.e. the max. rate at which the buffer can be filled) is not useful without knowing/setting the "--bufsize" (size of the buffer) as well.

See also:
https://pdfs.semanticscholar.org/8302/27913e017fa6f1ff93ea445779807507dfed.pdf

[cadet51]

Hello,
Since the x265 3.0+ versions, my simple x264 / 265 launcher gives me an error and I can not run an encode. Here is the error that appears.
With versions 2.9, no problem.
cordially
[2019-01-14] [13:20:08] Simple x264 Launcher (Build # 1138), built 2018-10-12
[2019-01-14] [1:20:08 p.m.]
[2019-01-14] [13:20:08] Job started at 2019-01-14, 13:20:08.
[2019-01-14] [1:20:08 p.m.]
[2019-01-14] [13:20:08] Source file: D: \ Encode \ Avs And Graph \ 4K.avs
[2019-01-14] [13:20:08] Output file: D: \ Encode \ Encode in progress \ trans2.hevc
[2019-01-14] [1:20:08 p.m.]
[2019-01-14] [13:20:08] --- SYSTEMINFO ---
[2019-01-14] [1:20:08 p.m.]
[2019-01-14] [13:20:08] Binary Path: C: \ Program Files (x86) \ MuldeR \ Simple x264 Launcher v2
[2019-01-14] [13:20:08] Avisynth: Yes
[2019-01-14] [13:20:08] VaporSynth: No
[2019-01-14] [1:20:08 p.m.]
[2019-01-14] [13:20:08] --- SETTINGS ---
[2019-01-14] [1:20:08 p.m.]
[2019-01-14] [13:20:08] Encoder: x265 (HEVC / H.265), 64-bit (x64), 10-bit
[2019-01-14] [13:20:08] Source: Avisynth (avs)
[2019-01-14] [13:20:08] RC Mode: 2-Pass
[2019-01-14] [13:20:08] Preset: medium
[2019-01-14] [13:20:08] Tuning: <None>
[2019-01-14] [13:20:08] Profile: <Unrestricted>
[2019-01-14] [13:20:08] Custom: --no-slow-firstpass --level-idc = 5.1 --high-tier --block -3: -3 --ctu 64 --min -cu-size 8 --bframes 4 --b-adapter 2 --rc-lookahead 60 --lookahead-slices 1 --scenecut 40 --ref 4 --limit-refs 2 --merange 57 --subm 7 - -rect --amp --max-merge 5 --hevc-aq --qp -adaptation-range = 1.00 --tu-intra 4 --tu-inter 4 --limit yourself 4 --me umh --hdr --hdr-opt --master-display = G (13250,34500) B (7500,3000) R (34,000,16000) WP (15635,16450) L (10,000,000,1) --min-luma 0 - max -luma 1023 --gop-lookahead 54 --weightp --weightb --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --sar 1: 1
[2019-01-14] [1:20:08 p.m.]
[2019-01-14] [13:20:08] --- CHECK VERSION ---
[2019-01-14] [1:20:08 p.m.]
[2019-01-14] [13:20:08] Detect video encoder version:
[2019-01-14] [1:20:08 p.m.]
[2019-01-14] [13:20:08] Creating process:
[2019-01-14] [13:20:08] "C: \ Program Files (x86) \ MuldeR \ Simple x264 Launcher v2 \ toolset \ x64 \ x265_x64.exe" --version
[2019-01-14] [1:20:08 p.m.]
[2019-01-14] [13:20:08] x265 [info]: HEVC encode version 3.0_RC + 10-672ce0547e97
[2019-01-14] [13:20:08] x265 [info]: build info [Windows] [GCC 8.2.1] [64bit] 8bit + 10bit + 12bit
[2019-01-14] [13:20:08] x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
[2019-01-14] [1:20:08 p.m.]
[2019-01-14] [13:20:08] FAILED TO DETERMINE VERSION INFO !!!

[kebulek]

4. Tune: introduce --tune animation option which improves encode quality for animated content

@LoRd_MuldeR: Please add this option to x265 GUI, thank you.

[redbtn]

LoRd_MuldeR thank you for amazing GUI! Cant wait new build with native support x265 3.0+
-------
I'm sorry. I am stupid. Did not read the documentation before the question.

Outdated:
Only one question, is it possible to "Custom Encoder Parameters" input make in two lines, or resizeble?
If I have a lot of parameters, I can't see them all. Unfortunately it is very inconvenient, I have to copy them into a notepad and back to change

[fauxreaper]

With x265 3.0 I'm seeing this error and can't run an encode.

[2019-03-19][16:18:40] x265 [info]: HEVC encoder version 3.0_Au+14-c7e5878bdd31
[2019-03-19][16:18:40] x265 [info]: build info [Windows][MSVC 1920][64 bit] 10bit
[2019-03-19][16:18:40] x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
[2019-03-19][16:18:40]
[2019-03-19][16:18:40] FAILED TO DETERMINE VERSION INFO !!!

[Chouonsoku]

Hello,
Since the x265 3.0+ versions, my simple x264 / 265 launcher gives me an error and I can not run an encode. Here is the error that appears.
With versions 2.9, no problem.
cordially

With x265 3.0 I'm seeing this error and can't run an encode.

[2019-03-19][16:18:40] x265 [info]: HEVC encoder version 3.0_Au+14-c7e5878bdd31
[2019-03-19][16:18:40] x265 [info]: build info [Windows][MSVC 1920][64 bit] 10bit
[2019-03-19][16:18:40] x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
[2019-03-19][16:18:40]
[2019-03-19][16:18:40] FAILED TO DETERMINE VERSION INFO !!!

Launch with --skip-version-checks, no problem with x265 v3.0 builds here.

[r0lZ]

Each times I launch the program, I see now a dialog with "Your version of Simple x264 Launcher is more than 6 months old!" and the Discard button is disabled, so the only choice is to click the Check for updates button. After the long check, the answer is always that I have already the latest version. Frustrating !
Could you please release a new version, just to get rid of that irritation dialog, and with the possibility to click the Discard button in the future ? Thanks !

[LoRd_MuldeR]

Each times I launch the program, I see now a dialog with "Your version of Simple x264 Launcher is more than 6 months old!" and the Discard button is disabled, so the only choice is to click the Check for updates button. After the long check, the answer is always that I have already the latest version. Frustrating !
Could you please release a new version, just to get rid of that irritation dialog, and with the possibility to click the Discard button in the future ? Thanks !

Sorry, I'm panning to release a new version soon.

[StainlessS]

From 1st post.
System Requirements:

* Windows XP with Service Pack 2 or any later Windows system
* 64-Bit Windows is highly recommended (32-Bit Windows works as well)
* The CPU must support at least the MMX and SSE instruction sets
* Avisynth input only available with Avisynth 2.5+ installed
* VapourSynth input only available with VapourSynth R19+ installed
* YV16/YV24 color spaces require Avisynth 2.6 (see section 10)

From current version Readme
2 System Requirements

Simple x264 Launcher is 100% standalone, i.e. it does not require Mircrosoft.NET, Java Runtime Environment or other "external" dependencies.

The required Qt DLLs as well as the encoder binaries are included with the application. Frameservers, like Avisynth or VapourSynth, may need to be installed separately though.

The minimum system requirements to run Simple x264/x265 Launcher are as follows:

Windows Vista with Service Pack 2 or any later Windows system – note that Windows XP is not supported anymore!
64-Bit editions of Windows are highly recommended, though 32-Bit editions will work as well
The CPU must support at least the MMX and SSE instruction sets
Avisynth input only available with Avisynth 2.6 installed – Avisynth 2.5.x is not recommended!
VapourSynth input only available with VapourSynth r24+ installed – Python is a prerequisite for VapourSynth!
YV16/YV24 color spaces require Avisynth 2.6 (see section 10)


Maybe update first post.

[szabi]

Hi

The latest program using x264-2935 which released 25-Sep-2018.
However newer version is available: x264-r2969 released 12-Mar-2019 (https://download.videolan.org/pub/videolan/x264/binaries/win32/).
Can "x264_x86.exe" file be exchanged in "C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x86" directory to a new one with changing name of course?
Also can the "x264_x64.exe" exchanged?
Going to work it properly?

EDIT:
Anyway I did never try it, so are there any encoding speed advance by using 64bit architecture?
https://abload.de/img/simplem7jub.png

bye
szabi

[LoRd_MuldeR]

Can "x264_x86.exe" file be exchanged in "C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x86" directory to a new one with changing name of course?
Also can the "x264_x64.exe" exchanged?
Going to work it properly?

Probably yes. Anyway, a new build of Simple x264/x265 Launcher will probably be soon™.

[szabi]

Probably yes. Anyway, a new build of Simple x264/x265 Launcher will probably be soon™.

Hi

It was a really quick answer during editing my post, thanks. :)

bye
szabi

[LoRd_MuldeR]

Anyway I did never try it, so are there any encoding speed advance by using 64bit architecture?

Yes, quite significant.

[szabi]

Yes, quite significant.

I will switch to use it.
Thanks .

[almosely]

It would be very nice, if you wouldn't force everyone using your launcher to check for updates after six months even the checkbox "never show auto-update notifications on application startup" is enabled. Maybe there's another checkbox necessary for that six-month-message - but I definitively do not want to be forced to check for updates or to wait for a felt eternity before I am allowed to click the discard button.

[rsotome]

It would be very nice, if you wouldn't force everyone using your launcher to check for updates after six months even the checkbox "never show auto-update notifications on application startup" is enabled. Maybe there's another checkbox necessary for that six-month-message - but I definitively do not want to be forced to check for updates or to wait for a felt eternity before I am allowed to click the discard button.

Just gonna ask about that update thing as well, maybe an option to disable checks. Thank you. :)

[jlw_4049]

This program doesn't accept UHD files as an input?

[LoRd_MuldeR]

This program doesn't accept UHD files as an input?

This is just a GUI front-end. It "accepts" whatever Avisynth or VapourSynth script as input that you load ;)

The actual question, IMO, is whether Avisynth or VapourSynth and the particular filters (especially the source filter) that you are using properly support “UHD” material, i.e. 4K resolution + High Dynamic Range (HDR).

I think "classic" Avisynth is out of scope here, as it was 8-Bit only and development is pretty much dead, AFAIK.

But VapourSynth should work fine, as it has supported "high bit-depth" color formats ever since. Maybe Avisynth+ can be made to work too, as it is supposed to add more color formats (including 10, 12, 14 and 16 bits) to Avisynth.

The next big question is, how the encoders, i.e. x264 or x265, deal with “UHD” input. My experience on that field is limited, but you will probably have to use some sort of "tone mapping", if you want to encode as SHD.

[LoRd_MuldeR]

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

Version 2.90 [2019-05-02]
* Updated x265 to version 3.0+18
* Updated x264 to revision 2969 (API v157)
* Updated NVEncC to version 4.36
* Updated build environment to Visual Studio 2017 with Update-9

[jlw_4049]

This is just a GUI front-end. It "accepts" whatever Avisynth or VapourSynth script as input that you load ;)

The actual question, IMO, is whether Avisynth or VapourSynth and the particular filters (especially the source filter) that you are using properly support “UHD” material, i.e. 4K resolution + High Dynamic Range (HDR).

I think "classic" Avisynth is out of scope here, as it was 8-Bit only and development is pretty much dead, AFAIK.

But VapourSynth should work fine, as it has supported "high bit-depth" color formats ever since. Maybe Avisynth+ can be made to work too, as it is supposed to add more color formats (including 10, 12, 14 and 16 bits) to Avisynth.

The next big question is, how the encoders, i.e. x264 or x265, deal with “UHD” input. My experience on that field is limited, but you will probably have to use some sort of "tone mapping", if you want to encode as SHD.Thanks for the info. I've only ever had experience using AviSynth+. Never really looked into vapour synth.

Is it considered better?

Sent from my SM-G965U1 using Tapatalk

[LoRd_MuldeR]

Thanks for the info. I've only ever had experience using AviSynth+. Never really looked into vapour synth.

Is it considered better?

We have a forum rule to not ask "what's best" because this question cannot be answered objectively. The best is what works best for you!

But, according to its author, VapourSynth...

...has been heavily inspired by Avisynth and aims to be a 21st century rewrite, taking advantage of the advancements computers have made since the late 90s. The main features compared to Avisynth are:
Multithreaded – Frame level multithreading
Generalized Colorspaces – New Colorspaces can be specified at runtime
Per Frame Properties – Additional metadata can be attached to frames
Python Based – The scripting part is implemented as a Python module so you don’t have have to learn a special language
Support for video with format changes – Some video just can’t stick to one format or frame size VapourSynth can handle any kind of change

[jlw_4049]

We have a forum rule to not ask "what's best" because this question cannot be answered objectively. The best is what works best for you!

But, according to its author, VapourSynth...Thanks! So, I can use this in GUIs?

Sent from my SM-G965U1 using Tapatalk

[LoRd_MuldeR]

Thanks! So, I can use this in GUIs?

Well, it depends ;)

Simple x264/x265 Launcher, for example, supports VapourSynth scripts as input – provided that VapourSynth is installed. It does not provide any kind of VapourSynth editor though; that is out of scope for this program.

So, if you are looking for a fully-fledged GUI editor for VapourSynth scripts, you should probably have a look at the VapourSynth Editor (https://forum.doom9.org/showthread.php?t=170965).

[Chouonsoku]

I'm having any issue with the latest release where sometimes on running the program and queueing an encode, I get a complaint that VapourSynth is not installed. Closing and reopening the program and queueing the encode again seems to solve the problem. I'm running VS and the launcher in portable mode.

[LoRd_MuldeR]

I'm having any issue with the latest release where sometimes on running the program and queueing an encode, I get a complaint that VapourSynth is not installed. Closing and reopening the program and queueing the encode again seems to solve the problem. I'm running VS and the launcher in portable mode.

Latest release did not change anything regarding VapourSynth detection. Anyway, try running the program with option "--console" and have a look at the log.

[Chouonsoku]

[Check for VapourSynth support]
VapourSynth thread has been created, please wait...
VapourSynth Dir: E:/Tools/Simple x264 Launcher v2/extra/VapourSynth
VapourSynth EXE: E:/Tools/Simple x264 Launcher v2/extra/VapourSynth/core32/vspipe.exe
VapourSynth DLL: E:/Tools/Simple x264 Launcher v2/extra/VapourSynth/core32/vapoursynth.dll
VapourSynth 32-Bit edition *not* found!
VapourSynth EXE: E:/Tools/Simple x264 Launcher v2/extra/VapourSynth/core64/vspipe.exe
VapourSynth DLL: E:/Tools/Simple x264 Launcher v2/extra/VapourSynth/core64/vapoursynth.dll
VSPIPE.EXE process encountered a deadlock -> aborting now!
VSPIPE.EXE process still running, going to kill it!
VSPIPE.EXE failed with code 0x0000F291 -> disable Vapousynth support!
VapourSynth 64-Bit edition was found, but version check has failed!
VapourSynth thread finished.
VapourSynth could not be found -> VapourSynth support disabled!Then I close and relaunch and get this:[Check for VapourSynth support]
VapourSynth thread has been created, please wait...
VapourSynth Dir: E:/Tools/Simple x264 Launcher v2/extra/VapourSynth
VapourSynth EXE: E:/Tools/Simple x264 Launcher v2/extra/VapourSynth/core32/vspipe.exe
VapourSynth DLL: E:/Tools/Simple x264 Launcher v2/extra/VapourSynth/core32/vapoursynth.dll
VapourSynth 32-Bit edition *not* found!
VapourSynth EXE: E:/Tools/Simple x264 Launcher v2/extra/VapourSynth/core64/vspipe.exe
VapourSynth DLL: E:/Tools/Simple x264 Launcher v2/extra/VapourSynth/core64/vapoursynth.dll
VapourSynth version was detected successfully.
VapourSynth 64-Bit edition found!
VapourSynth thread finished.
VapourSynth support is officially enabled now! [x86=0, x64=1]I did update my VS portable install from here recently too so maybe the issue was just not showing because I was using --skip-version-checks until the v2.90.

[LoRd_MuldeR]

Then I close and relaunch and get this:I did update my VS portable install from here recently too so maybe the issue was just not showing because I was using --skip-version-checks until the v2.90.

Well, as can be seen from your log, VSPIPE.EXE encountered a deadlock (i.e. did not terminate normally within the time limit) on the first attempt:

VapourSynth EXE: E:/Tools/Simple x264 Launcher v2/extra/VapourSynth/core64/vspipe.exe
VapourSynth DLL: E:/Tools/Simple x264 Launcher v2/extra/VapourSynth/core64/vapoursynth.dll
VSPIPE.EXE process encountered a deadlock -> aborting now!
VSPIPE.EXE process still running, going to kill it!
VSPIPE.EXE failed with code 0x0000F291 -> disable Vapousynth support!
VapourSynth 64-Bit edition was found, but version check has failed!

The time limit currently is 12 seconds. This choice is kind of arbitrary, yes, but I don't see a reason why the invocation of "vspipe.exe --version" should take longer than about ~1 second – let alone 12 seconds!

If a program takes unusually long to start for no comprehensible reason, then – more often than not – so-called "anti-virus" software was interfering.

Anyhow, coincidentally I did some clean-up and refactoring of the startup code today and also slightly increased the time limit. You can try with the latest TEST build (https://github.com/lordmulder/Simple-x264-Launcher/issues/16#issuecomment-490230555) and see if that makes any difference for you...

[Atak_Snajpera]

Maybe other app is blocking vspipe.exe? I have seen similar problem in my thread
https://forum.doom9.org/showthread.php?p=1862506#post1862506
https://forum.doom9.org/showthread.php?p=1872384#post1872384

[Chouonsoku]

The time limit currently is 12 seconds. This choice is kind of arbitrary, yes, but I don't see a reason why the invocation of "vspipe.exe --version" should take longer than about ~1 second – let alone 12 seconds!

If a program takes unusually long to start for no comprehensible reason, then – more often than not – so-called "anti-virus" software was interfering.
Yeah, seeing it in the log makes it clear that it's not an issue with the program. I've also noticed VSEdit taking a while to open sometimes. Gonna just add the whole folder as an exclusion in Windows Defender. Thanks for helping me troubleshoot a problem completely unrelated to your software! :)

Edit: Excluding it worked, Simple launched on the first try and VSEdit is opening faster. :D

[aldix]

hello.

i've both avisynth and vapoursynth installed and working, yet, when trying a vs script, the simple 264/265 encoder gives the -1 error, saying there's no avisynth installed. :/

what's up?

[LoRd_MuldeR]

hello.

i've both avisynth and vapoursynth installed and working, yet, when trying a vs script, the simple 264/265 encoder gives the -1 error, saying there's no avisynth installed. :/

what's up?

:logfile:

[aldix]

well, it's like i said. which is why i'm confused...


[2019-05-19][02:16:40] avs [error]: failed to load avisynth
[2019-05-19][02:16:40] x264 [error]: could not open input file `C:\Temp\8E5_python.vpy'
[2019-05-19][02:16:40]
[2019-05-19][02:16:40] PROCESS EXITED WITH ERROR CODE: -1


i'll update with the latest version of the x264 gui tho just in case, and report back whether this changes anything.

--
further updates:

um. latest simple x264/x265 gui. using latest this (https://github.com/jpsdr/x264/releases) for my encoding, always have been, swapping it out in the
C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x64 folder. does this mean i cannot use tmod anymore? that would be very unfortunate...


[2019-05-19][02:45:34]
[2019-05-19][02:45:36] vpyp [info]: Error: fwrite() call failed when writing frame: 0, plane: 0, errno: 22
[2019-05-19][02:45:36] vpyp [info]: Output 9 frames in 1.82 seconds (4.95 fps)
[2019-05-19][02:45:36]
[2019-05-19][02:45:36] WARNING: Input process exited with error (code: 1), your encode might be *incomplete* !!!
[2019-05-19][02:45:36]
[2019-05-19][02:45:36] FATAL ERROR: The encoder process has *crashed* -> your encode probably is *incomplete* !!!
[2019-05-19][02:45:36] Note that this indicates a bug in the current encoder, *not* in Simple x264/x265 Launcher.
[2019-05-19][02:45:36]
[2019-05-19][02:45:36] PROCESS EXITED WITH ERROR CODE: -1073741795


--
#update 2:

that sucks. tmod indeed doesn't work at all. whereas regular x264 does. with regular avisynth script it has always worked though. is it something inherent to tmod and there's no hope or what?


thanks!

[LoRd_MuldeR]

um. latest simple x264/x265 gui. using latest this (https://github.com/jpsdr/x264/releases) for my encoding, always have been, swapping it out in the
C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x64 folder. does this mean i cannot use tmod anymore? that would be very unfortunate...


[2019-05-19][02:45:34]
[2019-05-19][02:45:36] vpyp [info]: Error: fwrite() call failed when writing frame: 0, plane: 0, errno: 22
[2019-05-19][02:45:36] vpyp [info]: Output 9 frames in 1.82 seconds (4.95 fps)
[2019-05-19][02:45:36]
[2019-05-19][02:45:36] WARNING: Input process exited with error (code: 1), your encode might be *incomplete* !!!
[2019-05-19][02:45:36]
[2019-05-19][02:45:36] FATAL ERROR: The encoder process has *crashed* -> your encode probably is *incomplete* !!!
[2019-05-19][02:45:36] Note that this indicates a bug in the current encoder, *not* in Simple x264/x265 Launcher.
[2019-05-19][02:45:36]
[2019-05-19][02:45:36] PROCESS EXITED WITH ERROR CODE: -1073741795

that sucks. tmod indeed doesn't work at all. whereas regular x264 does. with regular avisynth script it has always worked though. is it something inherent to tmod and there's no hope or what?

As we can see from your log, the encoder process (i.e. x264.exe) has crashed!

From the exit code -1073741795, which is equivalent to STATUS_ILLEGAL_INSTRUCTION (0xC000001D) (https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55), we can conclude that x264 crashed because it tried to execute an instruction that is not supported by your CPU. If you get that error with "tmod" build, whereas the vanilla build that ships with Simple x264/x265 Launcher is working, then this indicates that the person who compiled "tmod" build used different compiler settings – settings not compatible with your CPU.

Anything else concerning "tmod" build would have to be discussed with the person who provides those builds. I don't provide or use "tmod" build.

BTW: You can ignore the warning about the input process (VapourSynth) in this case, because when the encoder processes crashes and thus breaks the pipe, then the input process won't be able to write to the pipe anymore, obviously.

[aldix]

well, okay, but that doesn't answer the question why basically the exact script and the exact same encoding settings that work with avisynth script + simple x264/265 gui do not work with .vpy script.

[LoRd_MuldeR]

well, okay, but that doesn't answer the question why basically the exact script and the exact same encoding settings that work with avisynth script + simple x264/265 gui do not work with .vpy script.

That's probably a completely different issue.

First of all, try to resolve your obvious x264 crash problem. VapourSynth input can not work, as long as x264 is crashing on you! It would be best to just stick with the vanilla x264.exe that ships with Simple x264/x265 Launcher.

Secondly, encoding from ".vpy" script requires that an up-to-date version VapourSynth is installed on your machine – x264.exe can not read ".vpy" scripts directly, the frames need to be pipe'd via vspipe.exe.

Simple x264/x265 Launcher does that automatically for you. But, if you think that Simple x264/x265 Launcher did not detect VapourSynth even though it is installed, then run x264_launcher.exe with parameter "--console" and…

:logfile:

It is supposed to look like this: https://i.imgur.com/dfyuEwa.png

[aldix]

but the same x264 does not crash with an avisynth script, though. i really don't know how more clearly can i put it lol.

[LoRd_MuldeR]

but the same x264 does not crash with an avisynth script, though. i really don't know how more clearly can i put it lol.

If you refuse to systematically track down your problems, one after the other, or if you don't provide the necessary information, then I can not help.

If the x264.exe process crashes on you – which it did according to the log you posted earlier – you obviously have a problem with x264. As long as you do not fix that problem, anything else will be futile! Whether the source was pipe'd in from avs2yuv.exe (Avisynth) or from vspipe.exe (VapourSynth) does not matter. And, as said before, the exit code STATUS_ILLEGAL_INSTRUCTION indicates that x264 has crashed because it tried to execute an instruction not supported by your CPU. This means whatever x264.exe you are using was compiled with "optimizations" not compatible with your CPU. Does x264 still crash, if you use the x264.exe that ships with Simple x264/x265 Launcher?

If VapourSynth input is not working – which probably is a completely unrelated problem – then the first thing you need to check is whether VapourSynth is installed properly on your system and whether it has been detected correctly. I already told you how to launch x264_launcher.exe with the debug console enabled. So, go check the debug output and see whether VapourSynth has been detected. Or, at the very least, post your debug output!

[aldix]

indeed, my sincere apologies.

was indeed for some brain-fart reason trying to get the boardwell version of the tmod to work until this very moment. the regular, latest build works issue-free just as the vanilla x264 does.

thank you for your software!

[LoRd_MuldeR]

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

Version 2.91 [2019-07-14]
* Updated x265 to version 3.1+2
* Updated build environment to Visual Studio 2019 with Update-1
* Various improvements to Avisynth/VapourSynth detection

[RTW47]

for me Simple x264 Launcher v2.91.1170 (64-bit) is unable to detect 32-bit and 64-bit VapourSynth. (Windows 7 SP1)
At this point only VapourSynth (64-Bit) R46 (non-portable) was installed using this new separate installer for 64-bit. (since R46 (http://www.vapoursynth.com/2019/06/r46-windows-installer-fun/)).

64-bit vapoursynth installation:

C:\Program Files\VapourSynth\
├─ core
├─ docs
├─ pismo
└─ etc…

yet Simple x264 Launcher tried looking for vspipe.exe and vapoursynth.dll inside non-existing core64 folder:

[Check for VapourSynth support]
VapourSynth thread has been created, please wait...
VapourSynth Dir: C:/Program Files/VapourSynth
VapourSynth EXE: C:/Program Files/VapourSynth/core32/vspipe.exe
VapourSynth DLL: C:/Program Files/VapourSynth/core32/vapoursynth.dll
VapourSynth 32-Bit edition *not* found!
VapourSynth EXE: C:/Program Files/VapourSynth/core64/vspipe.exe
VapourSynth DLL: C:/Program Files/VapourSynth/core64/vapoursynth.dll
VapourSynth 64-Bit edition *not* found!
VapourSynth thread finished.
VapourSynth could not be found -> VapourSynth support disabled!

renaming core to core64, would make detection work for 64-bit vapoursynth, however everything else such as vapoursynth editor would fail by default.
---
After instaling Python 3.7.4 (32-bit) and VapourSynth (32-bit) R46, now both 32-bit and 64-bit (non-portable) versions of vapoursynth are installed:

32-bit vapoursynth installation:

C:\Program Files (x86)\VapourSynth-32\
├─ core
├─ docs
├─ pismo
└─ etc…

Simple x264 Launcher now keeps looking elsewhere, but paths are still not correct to detect 32-bit VS and (or) 64-bit VS:

[Check for VapourSynth support]
VapourSynth thread has been created, please wait...
VapourSynth Dir: C:/Program Files (x86)/VapourSynth-32
VapourSynth EXE: C:/Program Files (x86)/VapourSynth-32/core32/vspipe.exe
VapourSynth DLL: C:/Program Files (x86)/VapourSynth-32/core32/vapoursynth.dll
VapourSynth 32-Bit edition *not* found!
VapourSynth EXE: C:/Program Files (x86)/VapourSynth-32/core64/vspipe.exe
VapourSynth DLL: C:/Program Files (x86)/VapourSynth-32/core64/vapoursynth.dll
VapourSynth 64-Bit edition *not* found!
VapourSynth thread finished.
VapourSynth could not be found -> VapourSynth support disabled!that new installer likely changed some folder names etc., since I clearly remember seeing core32 / core64 folders (at least for non-portable vapoursynth).

[LoRd_MuldeR]

for me Simple x264 Launcher v2.91.1170 (64-bit) is unable to detect 32-bit and 64-bit VapourSynth. (Windows 7 SP1)
At this point only VapourSynth (64-Bit) R46 (non-portable) was installed using this new separate installer for 64-bit. (since R46 (http://www.vapoursynth.com/2019/06/r46-windows-installer-fun/)).

It appears there were some significant changes in latest VapourSynth release, which broke "our" detection routines :o

I will have to look into that, as soon as I have some spare time. This is probably not going to happen before next week, because I am very busy right now and I will be on a trip this weekend...

[RTW47]

I will have to look into that, as soon as I have some spare time. This is probably not going to happen before next week, because I am very busy right now and I will be on a trip this weekend...
I'm not in a hurry, take your time and have a safe journey.

[LoRd_MuldeR]

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

Version 2.92 [2019-07-22]
* Updated x264 to revision 2984 (API v158)
* Updated x265 to version 3.1+8
* Fixed detection of VapourSynth R46
* Note: Minimum supported VapourSynth version is R46 now!Hotfix for Simple x264/x265 Launcher v2.92 to remedy an erroneous "critical error" message:
https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2019-07-22.hotfix-1.zip/download

[Dion]

Getting this error with this new version.
https://images2.imgbox.com/da/f1/DxDYncGx_o.png

I don't have Vapoursynth installed or use it. Is there no way to suppress this fully?

[LoRd_MuldeR]

Getting this error with this new version.
https://images2.imgbox.com/da/f1/DxDYncGx_o.png

I don't have Vapoursynth installed or use it. Is there no way to suppress this fully?

https://i.imgur.com/piZl2kZ.png

Sorry, there is a stupid regression in the latest release, when VapourSynth is not found at all. You can safely ignore the "critical error" message.

Anyway, please try with the "hotfix" version from here:
x264_launcher.2019-07-22.hotfix-1.zip (https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2019-07-22.hotfix-1.zip/download)

[RTW47]

Simple x264/x265 Launcher v2.92
https://github.com/lordmulder/Simple-x264-Launcher/releases/tag/v2.92can confirm that new build now successfully detects both (32-bit & 64-bit) non-portable VapourSynth R46. (#1807 (https://forum.doom9.org/showpost.php?p=1879450&postcount=1807))
thanks LM^^

[Chouonsoku]

Edit: Nevermind, user error. :D

[LoRd_MuldeR]

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

Version 2.93 [2019-08-06]
* Fixed a regression in VapourSynth detection code
* Updated NVEncC to version 4.43
* Updated build environment to Visual Studio 2019 with Update-2

[redbtn]

Something strange in log file. Launcher v2.93, x265 v3.1+14


[2019-09-11][07:24:09] x265 [info]: Rate Control / qCompress : CRF-15.0 / 0.65
[2019-09-11][07:24:09] x265 [info]: VBV/HRD buffer / max-rate / init : 160000 / 160000 / 0.900
[2019-09-11][07:24:09] x265 [info]: tools: rect amp limit-modes rd=4 psy-rd=2.00 rdoq=2 psy-rdoq=2.00
[2019-09-11][07:24:09] x265 [info]: tools: rskip limit-tu=4 signhide tmvp b-intra deblock(tC=-3:B=-3)
[2019-09-11][07:46:49] 92 fps, 10111.82 kb/s, eta 17:40:01
[2019-09-11][07:53:16] , 2.84 fps, 11286.77 kb/s, eta 18:03:51
[2019-09-11][09:29:39] [9.7%] 18339/189480 fram
[2019-09-11][09:29:39] es, 2.43 fps, 19276.08 kb/s, eta 19:31:29
[2019-09-11][09:39:19] [10.3%] 19556/189480 fr
[2019-09-11][09:39:19] ames, 2.41 fps, 19775.16 kb/s, eta 19:34:43
[2019-09-11][09:47:19] [10.9%]
[2019-09-11][09:47:19] 20745/189480 frames, 2.41 fps, 19664.61 kb/s, eta 19:24:41
[2019-09-11][10:17:49] 19267.50 kb/s, eta 18:56:01
[2019-09-11][11:19:28] ps, 18573.33 kb/s, eta 17:40:10
[2019-09-11][13:38:17] [29.0%]
[2019-09-11][13:38:17] 54899/189480 frames, 2.45 fps, 18180.11 kb/s, eta 15:17:14
[2019-09-11][13:41:21] 73.79 kb/s, eta 15:14:14
[2019-09-11][14:13:59] 6.31 kb/s, eta 14:50:27
[2019-09-11][14:14:44] 2 kb/s, eta 14:49:52
[2019-09-11][14:19:23] 18461.43 kb/s, eta 14:47:00
[2019-09-11][14:46:51] 3:37
[2019-09-11][15:12:06] [36
[2019-09-11][15:12:06] .1%] 68451/189480 frames, 2.44 fps, 18191.34 kb/s, eta 13:47:26
[2019-09-11][15:43:05] 2.54 kb/s, eta 13:13:47
https://i.imgur.com/dltOCdB.png

[LoRd_MuldeR]

Something strange in log file. Launcher v2.93, x265 v3.1+14

So, I suppose you manually updated the x265 binary to v3.1+14. Does it only happen with x265 v3.1+14, but not with the x265 binary that originally shipped with Simple x264 Launcher? Is the "issue" reproducible?

Also: Which specific x265 build are you using? Are there any "custom" patches included in that build? If you run that binary in the terminal (no GUI), does the output look normal?

[redbtn]

So, I suppose you manually updated the x265 binary to v3.1+14. Does it only happen with x265 v3.1+14, but not with the x265 binary that originally shipped with Simple x264 Launcher? Is the "issue" reproducible?

Also: Which specific x265 build are you using? Are there any "custom" patches included in that build? If you run that binary in the terminal (no GUI), does the output look normal?
Yes, the "issue" is reproducible. I used builds from msystem.waw.pl/x265

I've made few tests:

1) x265 that shipped with Simple x264 Launcher - OK
2) x265 (3.1+14 and 3.1+19) AVX2 VS2019 from msystem.waw.pl/x265 - Have this bug
3) x265 (3.1+19) AVX2 GCC9.2 from from msystem.waw.pl/x265 - OK
4) x265 (3.1+19) build by Barough - OK

So, it seems like a VS2019 compile bug. So, LoRd_MuldeR , i'm sorry for disturbing.

[LoRd_MuldeR]

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

Version 2.94 [2019-10-05]
* Updated x265 to version 3.2+5, incl. AQ mode 4 slowdown fix
* Updated NVEncC to version 4.50 (v2)
* Updated build environment to Visual Studio 2019 with Update-3

[Metal-HTPC]

sadly the simple x264 launcher doesn't work anymore after the latest update.
I'm still using the 2.60 (https://www.videohelp.com/software/Avisynth) version of Avisynth and really didn't chance anything in my configuration.

The problem is the following. I can't re-encode any of my commercial released blu-rays anymore. It only outputs about 21-25 mb and the encodes all come out as this mess:

https://ufile.io/0mptrzot

screenshot of x264 during the encode:

https://s19.directupload.net/images/191027/egtou4k2.png

any help would be appreciated.

[LoRd_MuldeR]

sadly the simple x264 launcher doesn't work anymore after the latest update.
I'm still using the 2.60 (https://www.videohelp.com/software/Avisynth) version of Avisynth and really didn't chance anything in my configuration.

The problem is the following. I can't re-encode any of my commercial released blu-rays anymore. It only outputs about 21-25 mb and the encodes all come out as this mess:

https://ufile.io/0mptrzot

screenshot of x264 during the encode:

any help would be appreciated.

Well, you have to keep in mind that Simple x264 Launcher is just a GUI front-end that invokes x264 with your Avisynth script. No more and no less.

The included x264 binaries were not even changed in the last two releases of my Simple x264 Launcher package. The last time that the x264 binaries were updated was in version 2.92 [2019-07-22].

So, IMO, there is nothing in the last (or second last) release of Simple x264 Launcher that could possibly have changed encoding with x264 and Avisynth input!

You didn't replace the x264 binaries manually, right?

I can only speculate about the cause of your problem. Might be that the Avisynth process crashed; might be that the x264 process crashed. Hard to tell, since your screenshot excludes the most important part of the log – the very end.

It would be helpful if you posted a complete log of your encoding task that shows everything from start to finish...

Anyway, if you open the very same Avisynth script that you are trying to encode in Simple x264 Launcher in, e.g., VirtualDub (http://virtualdub2.com/), does it open and "play" (seek) properly all the way to the end without problem?

[Metal-HTPC]

I don't have virtual dub but I can play the AVSscript flawless in AVSPmod. Also mpeg2 DVD's can be encoded flawless even with x264 launcher.
So only x264/avc seems to be crashed.

I made a short encode so I have a proper log for you to see:


[2019-10-27][13:42:42] Simple x264 Launcher (Build #1194), built 2019-10-05
[2019-10-27][13:42:42]
[2019-10-27][13:42:42] Job started at 2019-10-27, 13:42:42.
[2019-10-27][13:42:42]
[2019-10-27][13:42:42] Source file : T:\BDencode\Scripte\Sleepaway Camp.avs
[2019-10-27][13:42:42] Output file : T:\BDencode\H264-encode\Sleepaway Camp.264
[2019-10-27][13:42:42]
[2019-10-27][13:42:42] --- SYSTEMINFO ---
[2019-10-27][13:42:42]
[2019-10-27][13:42:42] Binary Path : C:\Program Files (x86)\Video\Encoder\x264
[2019-10-27][13:42:42] Avisynth : Yes
[2019-10-27][13:42:42] VapourSynth : No
[2019-10-27][13:42:42]
[2019-10-27][13:42:42] --- SETTINGS ---
[2019-10-27][13:42:42]
[2019-10-27][13:42:42] Encoder : x264 (AVC/H.264), 32-Bit (x86), 8-Bit
[2019-10-27][13:42:42] Source : Avisynth (avs)
[2019-10-27][13:42:42] RC Mode : 2-Pass
[2019-10-27][13:42:42] Preset : slow
[2019-10-27][13:42:42] Tuning : Film
[2019-10-27][13:42:42] Profile : High
[2019-10-27][13:42:42] Custom : --bluray-compat --level 4.1 --keyint 25 --open-gop --slices 4 --fake-interlaced --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1
[2019-10-27][13:42:42]
[2019-10-27][13:42:42] --- CHECK VERSION ---
[2019-10-27][13:42:42]
[2019-10-27][13:42:42] Detect video encoder version:
[2019-10-27][13:42:42]
[2019-10-27][13:42:42] Creating process:
[2019-10-27][13:42:42] "C:\Program Files (x86)\Video\Encoder\x264\toolset\x86\x264_x86.exe" --version
[2019-10-27][13:42:42]
[2019-10-27][13:42:42] x264 0.158.2984 3759fcb
[2019-10-27][13:42:42] (libswscale 5.4.101)
[2019-10-27][13:42:42] (libavformat 58.28.102)
[2019-10-27][13:42:42] (ffmpegsource 2.31.0.0)
[2019-10-27][13:42:42] built on Jul 19 2019, gcc: 9.1.0
[2019-10-27][13:42:42] x264 configuration: --chroma-format=all
[2019-10-27][13:42:42] libx264 configuration: --chroma-format=all
[2019-10-27][13:42:42] x264 license: GPL version 2 or later
[2019-10-27][13:42:42] libswscale/libavformat/ffmpegsource license: GPL version 2 or later
[2019-10-27][13:42:42]
[2019-10-27][13:42:42] Detect video source version:
[2019-10-27][13:42:42]
[2019-10-27][13:42:42] Creating process:
[2019-10-27][13:42:42] "C:\Program Files (x86)\Video\Encoder\x264\toolset\x86\avs2yuv_x86.exe"
[2019-10-27][13:42:42]
[2019-10-27][13:42:43] Avs2YUV 0.24bm5
[2019-10-27][13:42:43]
[2019-10-27][13:42:43] > x264 revision: 2984 (core #158)
[2019-10-27][13:42:43] > Avs2YUV version: 0.24.5
[2019-10-27][13:42:43]
[2019-10-27][13:42:43] --- GET SOURCE INFO ---
[2019-10-27][13:42:43]
[2019-10-27][13:42:43] Creating process:
[2019-10-27][13:42:43] "C:\Program Files (x86)\Video\Encoder\x264\toolset\x86\avs2yuv_x86.exe" -frames 1 "T:\BDencode\Scripte\sleepaway camp.avs" NUL
[2019-10-27][13:42:43]
[2019-10-27][13:42:43] T:\BDencode\Scripte\sleepaway camp.avs: 1920x1080, YV12, 8-bits, progressive, 25000 fps, 1965 frames
[2019-10-27][13:42:43]
[2019-10-27][13:42:43] Resolution: 1920 x 1080
[2019-10-27][13:42:43] Frame Rate: 25000
[2019-10-27][13:42:43] No. Frames: 1965
[2019-10-27][13:42:43]
[2019-10-27][13:42:43] --- ENCODING PASS #1 ---
[2019-10-27][13:42:43]
[2019-10-27][13:42:43] Creating input process:
[2019-10-27][13:42:43] "C:\Program Files (x86)\Video\Encoder\x264\toolset\x86\avs2yuv_x86.exe" "T:\BDencode\Scripte\sleepaway camp.avs" -
[2019-10-27][13:42:43]
[2019-10-27][13:42:43] Creating encoder process:
[2019-10-27][13:42:43] "C:\Program Files (x86)\Video\Encoder\x264\toolset\x86\x264_x86.exe" --output-depth 8 --bitrate 38200 --pass 1 --stats "T:\BDencode\H264-encode\Sleepaway Camp.stats" --preset slow --tune film --profile high --bluray-compat --level 4.1 --keyint 25 --open-gop --slices 4 --fake-interlaced --colorprim bt709 --transfer bt709 --colormatrix bt709 --sar 1:1 --output "T:\BDencode\H264-encode\Sleepaway Camp.264" --frames 1965 --demuxer y4m --stdin y4m -
[2019-10-27][13:42:43]
[2019-10-27][13:42:45] y4m [info]: 1920x1080p 1:1 @ 25000/1 fps (cfr)
[2019-10-27][13:42:45] x264 [warning]: NAL HRD parameters require VBV parameters
[2019-10-27][13:42:45] x264 [info]: using SAR=1/1
[2019-10-27][13:42:45] x264 [warning]: MB rate (204000000) > level limit (245760)
[2019-10-27][13:42:45] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
[2019-10-27][13:42:45] x264 [info]: profile Main, level 4.1, 4:2:0, 8-bit
[2019-10-27][13:43:51] x264 [info]: frame I:80 Avg QP:51.00 size: 2773
[2019-10-27][13:43:51] x264 [info]: frame P:481 Avg QP:51.00 size: 160
[2019-10-27][13:43:51] x264 [info]: frame B:1404 Avg QP:51.00 size: 123
[2019-10-27][13:43:51] x264 [info]: consecutive B-frames: 4.4% 0.6% 1.4% 93.6%
[2019-10-27][13:43:51] x264 [info]: mb I I16..4: 100.0% 0.0% 0.0%
[2019-10-27][13:43:51] x264 [info]: mb P I16..4: 0.0% 0.0% 0.0% P16..4: 0.1% 0.0% 0.0% 0.0% 0.0% skip:99.8%
[2019-10-27][13:43:51] x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 0.0% 0.0% 0.0% direct: 0.0% skip:100.0% L0:41.4% L1:58.6% BI: 0.0%
[2019-10-27][13:43:51] x264 [info]: final ratefactor: 58.36
[2019-10-27][13:43:51] x264 [info]: direct mvs spatial:47.5% temporal:52.5%
[2019-10-27][13:43:51] x264 [info]: coded y,uvDC,uvAC intra: 1.3% 3.7% 0.0% inter: 0.0% 0.0% 0.0%
[2019-10-27][13:43:51] x264 [info]: i16 v,h,dc,p: 81% 12% 7% 0%
[2019-10-27][13:43:51] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 3% 1% 96% 0% 0% 0% 0% 0% 0%
[2019-10-27][13:43:51] x264 [info]: i8c dc,h,v,p: 100% 0% 0% 0%
[2019-10-27][13:43:51] x264 [info]: Weighted P-Frames: Y:12.7% UV:6.4%
[2019-10-27][13:43:51] x264 [info]: kb/s:47932.93
[2019-10-27][13:43:51] encoded 1965 frames, 29.30 fps, 47932.93 kb/s
[2019-10-27][13:43:51] av2y [info]: T:\BDencode\Scripte\sleepaway camp.avs: 1920x1080, YV12, 8-bits, progressive, 25000 fps, 1965 frames
[2019-10-27][13:43:51] Final file size is 459.9 KB bytes.
[2019-10-27][13:43:51]
[2019-10-27][13:43:51] --- ENCODING PASS #2 ---
[2019-10-27][13:43:51]
[2019-10-27][13:43:51] Creating input process:
[2019-10-27][13:43:51] "C:\Program Files (x86)\Video\Encoder\x264\toolset\x86\avs2yuv_x86.exe" "T:\BDencode\Scripte\sleepaway camp.avs" -
[2019-10-27][13:43:51]
[2019-10-27][13:43:51] Creating encoder process:
[2019-10-27][13:43:51] "C:\Program Files (x86)\Video\Encoder\x264\toolset\x86\x264_x86.exe" --output-depth 8 --bitrate 38200 --pass 2 --stats "T:\BDencode\H264-encode\Sleepaway Camp.stats" --preset slow --tune film --profile high --bluray-compat --level 4.1 --keyint 25 --open-gop --slices 4 --fake-interlaced --colorprim bt709 --transfer bt709 --colormatrix bt709 --sar 1:1 --output "T:\BDencode\H264-encode\Sleepaway Camp.264" --frames 1965 --demuxer y4m --stdin y4m -
[2019-10-27][13:43:51]
[2019-10-27][13:43:52] y4m [info]: 1920x1080p 1:1 @ 25000/1 fps (cfr)
[2019-10-27][13:43:52] x264 [warning]: NAL HRD parameters require VBV parameters
[2019-10-27][13:43:52] x264 [info]: using SAR=1/1
[2019-10-27][13:43:52] x264 [warning]: MB rate (204000000) > level limit (245760)
[2019-10-27][13:43:52] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
[2019-10-27][13:43:52] x264 [info]: profile High, level 4.1, 4:2:0, 8-bit
[2019-10-27][13:45:03] x264 [info]: frame I:80 Avg QP:51.00 size: 684
[2019-10-27][13:45:03] x264 [info]: frame P:481 Avg QP:51.00 size: 138
[2019-10-27][13:45:03] x264 [info]: frame B:1404 Avg QP:51.00 size: 119
[2019-10-27][13:45:03] x264 [info]: consecutive B-frames: 4.4% 0.6% 1.4% 93.6%
[2019-10-27][13:45:03] x264 [info]: mb I I16..4: 0.0% 100.0% 0.0%
[2019-10-27][13:45:03] x264 [info]: mb P I16..4: 0.0% 0.0% 0.0% P16..4: 0.0% 0.0% 0.0% 0.0% 0.0% skip:100.0%
[2019-10-27][13:45:03] x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 0.1% 0.0% 0.0% direct: 0.0% skip:99.9% L0:100.0% L1: 0.0% BI: 0.0%
[2019-10-27][13:45:03] x264 [info]: 8x8 transform intra:100.0%
[2019-10-27][13:45:03] x264 [info]: direct mvs spatial:49.2% temporal:50.8%
[2019-10-27][13:45:03] x264 [info]: coded y,uvDC,uvAC intra: 0.0% 0.0% 0.0% inter: 0.0% 0.0% 0.0%
[2019-10-27][13:45:03] x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 0% 0% 100% 0% 0% 0% 0% 0% 0%
[2019-10-27][13:45:03] x264 [info]: i8c dc,h,v,p: 100% 0% 0% 0%
[2019-10-27][13:45:03] x264 [info]: Weighted P-Frames: Y:12.7% UV:6.4%
[2019-10-27][13:45:03] x264 [info]: kb/s:29403.77
[2019-10-27][13:45:03] encoded 1965 frames, 27.71 fps, 29403.77 kb/s
[2019-10-27][13:45:03] av2y [info]: T:\BDencode\Scripte\sleepaway camp.avs: 1920x1080, YV12, 8-bits, progressive, 25000 fps, 1965 frames
[2019-10-27][13:45:03] Final file size is 282.1 KB bytes.
[2019-10-27][13:45:03]
[2019-10-27][13:45:03] --- COMPLETED ---
[2019-10-27][13:45:03]
[2019-10-27][13:45:03] Job finished at 2019-10-27, 13:45:03. Process took 2 minutes, 20 seconds.

[sneaker_ger]

You have 25000 fps instead of 25 fps.

[LoRd_MuldeR]

I don't have virtual dub

I highly recommend you grab VirtualDub2 from here:
VirtualDub2_43803.zip (https://sourceforge.net/projects/vdfiltermod/files/VirtualDub%20pack/version%2020/VirtualDub2_43803.zip/download)

but I can play the AVSscript flawless in AVSPmod. Also mpeg2 DVD's can be encoded flawless even with x264 launcher.
So only x264/avc seems to be crashed.

According to your log, nothing has crashed. Both encoding passes seem to have completed normally, as far as I can tell. But, as sneaker_ger (https://forum.doom9.org/showthread.php?p=1888806#post1888806) noted, a frame rate of 25000 is really weird! :eek:

Please run the following command manually in a terminal:
avs2yuv_x86.exe -frames 1 "C:\path\to\your\source.avs" NUL

...and then please tell us what the output is.

(You find "avs2yuv_x86.exe" in your Simple x264 Launcher install directory below "toolset\x86" and, of course, you have to adjust the path to your AVS file as needed!)

Output should be something like:
SES UHD Demo Channel.avs: 1920x816, YV12, 8-bits, progressive, 50 fps, 9178 frames

It would also be very interesting to know what the "File Information" dialog in VirtualDub(2) says about your AVS file ;)

[sneaker_ger]

a frame rate of 25000 is really weird! :eek:
It's not simply "weird". It is the root of the problem. He has set "--bitrate 38200" i.e. 38200 kilobits per second. If you distribute these 38200 kilobits to 25000 frames that will 1528 bits per frame. Of course the output will look like garbage if you apply only 1/1000th of the bits you intended to.

[LoRd_MuldeR]

It's not simply "weird". It is the root of the problem. He has set "--bitrate 38200" i.e. 38200 kilobits per second. If you distribute these 38200 kilobits to 25000 frames that will 1528 bits per frame. Of course the output will look like garbage if you apply only 1/1000th of the bits you intended to.

Sure. But I meant that it is weird to get such value at all. Must either be an error in the Avisynth script – which maybe didn't show up in other encoding tools, because those didn't honor the FPS reported by Avisynth and just assumed 25 fps – or a bug in Avs2YUV. I'm pretty sure it is not a problem of Simple x264 Launcher itself, because Simple x264 Launcher does not explicitly set the framerate. The framerate is passed implicitly from Avs2YUV to x264 via YUV4MPEG header.

[Metal-HTPC]

it really was the 25 fps command. I forgot the ".". Sorry for my inability. Everything is alright with your x264 launcher and I will continue to use it. thanks

[Forteen88]

I can't run the newest version of x265 (3.2.1+1-b5c86a6) in Simple x264/x265 Launcher v2.94 (2019-10-05), it complains that it's a too old version of x265.
Also, there is a newer version (not any important feature, but it's compiled with a more newer compiler) of Avs2YUV released than is included in that package,
http://avisynth.nl/index.php/Avs2YUV
Thanks.

EDIT: Thanks for the advice redbtn.

[redbtn]

I can't run the newest version of x265 (3.2.1+1-b5c86a6) in Simple x264/x265 Launcher v2.94 (2019-10-05), it complains that it's a too old version of x265.
Also, there is a newer version (not any important feature, but still) of Avs2YUV released than is included in that package,
http://avisynth.nl/index.php/Avs2YUV
Thanks.
You can use --skip-version-checks
--skip-version-checks ......... Skip x264/x265 version checks, NOT recommended!

[Forteen88]

I'm having errors when I'm encoding with x265 (I updated to x265-3.2+15) using 2-pass with Simple x264/x265 Launcher v2.94 (2019-10-05), it fails in the 2nd pass. Anyone else got this problem?
x265 in CRF-mode works great though.
I only want to use 2-pass mode (to get same average bitrate) to make tests on which --psy-rd & --psy-rdoq values I prefer most.

Maybe I should reinstall Simple x264/x265 Launcher with the old software (x265) to see if 2-pass mode works...

BTW, what happened to LoRd_MuldeR (who created this software)? He has not been online at Doom9 for a long time now (Last Activity: 29th October 2019), I hope that he's OK.

EDIT: Never mind, it seems that the version of x265 had problem with 2-pass encoding. I've not tried it though.

[RyaNJ]

@LoRd_MuldeR: Please add this option to x265 GUI, thank you.

I'd also like to request this too. Thanks :)

[LoRd_MuldeR]

4. Tune: introduce --tune animation option which improves encode quality for animated content

@LoRd_MuldeR: Please add this option to x265 GUI, thank you.
I'd also like to request this too. Thanks :)

Okay, I added this for the next release. I somehow overlooked this request.

BTW, what happened to LoRd_MuldeR (who created this software)? He has not been online at Doom9 for a long time now (Last Activity: 29th October 2019), I hope that he's OK.

Everything is okay. It's just real life kicking in, every now and then ;)

[redbtn]

I'm glad you ok! We were worried.

[Forteen88]

I'm glad you ok! We were worried.+1. Too many great devs here (Didée, Loren Merritt, DS. etc) disappeared.

[tormento]

Notice that http_//download.videolan.org/pub/x264/binaries/ is discontinued as service.

Please update to https_//artifacts.videolan.org/x264/ to get them.

Plus using latest x264 gives following warning:

[2019-12-28][11:02:33] x264 0.159.2991 1771b55
[2019-12-28][11:02:33] (libswscale 5.6.100)
[2019-12-28][11:02:33] (libavformat 58.33.100)
[2019-12-28][11:02:33] built on Dec 16 2019, gcc: 8.2-win32 20190215
[2019-12-28][11:02:33] x264 configuration: --chroma-format=all
[2019-12-28][11:02:33] libx264 configuration: --chroma-format=all
[2019-12-28][11:02:33] x264 license: GPL version 2 or later
[2019-12-28][11:02:33] libswscale/libavformat license: LGPL version 2.1 or later
[2019-12-28][11:02:33]
[2019-12-28][11:02:33] WARNING: Your x264 binary uses an untested core (API) version, take care!
[2019-12-28][11:02:33] This application works best with x264 core (API) version 158. Newer versions may work or not.

[LoRd_MuldeR]

Notice that http_//download.videolan.org/pub/x264/binaries/ is discontinued as service.

Please update to https_//artifacts.videolan.org/x264/ to get them.

I know ;)

But I have been using LigH's builds for quite some time now, because those have FFMS support enabled – which the Videolan.org builds do not have – and because Komisar's builds have not been updated in a long time.

Anyways, as far as I can tell, there have not been any relevant changes since r2984 (the last time I updated the included x264 binaries), except maybe for this VBV-related fix:
https://code.videolan.org/videolan/x264/commit/76669180821692303465b59de9c9e3933db32db2

(Unless you are using CFR+VBV, you don't need to care. And even if you do, the bug they fixed recently probably only occurs under very rare circumstances)

[Forteen88]

LoRd_MuldeR, there is a newer version (not any important features, but it's compiled with a more newer compiler) of Avs2YUV released than is included in that package,
http://avisynth.nl/index.php/Avs2YUV

How do I use that newer version of Avs2YUV in "Simple x264/x265 Launcher v2.94 (2019-10-05)"? I got an error last time I tried to use it after updating Avs2YUV.

BTW, Happy New Year!

[LoRd_MuldeR]

How do I use that newer version of Avs2YUV in "Simple x264/x265 Launcher v2.94 (2019-10-05)"? I got an error last time I tried to use it after updating Avs2YUV.

You can't – without also updating the expected version in the source code.

Also, the only change in Avs2YUV 0.24 "mod 6", since Avs2YUV 0.24 "mod 5" that is currently included with Simple x264 Launcher, is the addition of 4:0:0 (monochrome) output support.

Unless you need exactly that, you don't need to care. Anyhow, next Simple x264 Launcher release will probably be updated to Avs2YUV 0.24 "mod 6".

[LoRd_MuldeR]

Here is a new TEST build that has the latest x264 and Avs2YUV versions included:
x264_launcher-TEST.2020-01-03.exe (https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher-TEST.2020-01-03.exe/download)

[Forteen88]

Thanks for new version. I'll try it out soon.

[deco20]

Lord_Mulder, I have a problem with determining clip properties. It fails on "Get source info" step, but it seems that the command that is used is ok.
When I run it manually, I get following response:
K:\dg.avs: 1280x534, YV12, 8-bits, progressive, 24000/1001 fps, 154508 frames

From what I saw in the code, this step is about extracting some of these values using regex. Is my output somehow different from the one that is expected by the regex?

[LoRd_MuldeR]

Lord_Mulder, I have a problem with determining clip properties. It fails on "Get source info" step, but it seems that the command that is used is ok.
When I run it manually, I get following response:
K:\dg.avs: 1280x534, YV12, 8-bits, progressive, 24000/1001 fps, 154508 frames

From what I saw in the code, this step is about extracting some of these values using regex. Is my output somehow different from the one that is expected by the regex?

Your output from the manual invocation of Avs2YUV looks normal to me. Also, I tried with a similar setup and it seems to work fine for me:
https://i.imgur.com/7k1LJ48.png

I suspect something is going wrong with the Avs2YUV invocation that happens inside Simple x264 Launcher (maybe AVS script fails to load for some reason), so can you please post the complete log from Simple x264 Launcher?

[deco20]

The script itself looks like these:
DGSource("K:\ToEncode\00000.dgi")
Crop(0, 140, 0, -140)
Spline36Resize(1280, 534)

It is correctly interpreted by AvsPmod and I used to do similar things before.

As for the log, there it is:
[2020-01-04][15:39:30] --- SYSTEMINFO ---
[2020-01-04][15:39:30]
[2020-01-04][15:39:30] Binary Path : C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2
[2020-01-04][15:39:30] Avisynth : Yes
[2020-01-04][15:39:30] VapourSynth : No
[2020-01-04][15:39:30]
[2020-01-04][15:39:30] --- SETTINGS ---
[2020-01-04][15:39:30]
[2020-01-04][15:39:30] Encoder : x264 (AVC/H.264), 64-Bit (x64), 8-Bit
[2020-01-04][15:39:30] Source : Avisynth (avs)
[2020-01-04][15:39:30] RC Mode : CRF
[2020-01-04][15:39:30] Preset : veryslow
[2020-01-04][15:39:30] Tuning : <None>
[2020-01-04][15:39:30] Profile : High
[2020-01-04][15:39:30] Custom : --level 4.1 --sar 1:1 --no-fast-pskip --no-dct-decimate --no-mbtree --deblock -3:-3 --ipratio 1.2 --pbratio 1.1 --psy-rd 1.1 --aq-mode 3 --aq-strength 0.7 --aq2-strength 0 --aq2-sensitivity 0 --aq3-mode 0 --bframes 12
[2020-01-04][15:39:30]
[2020-01-04][15:39:30] --- CHECK VERSION ---
[2020-01-04][15:39:30]
[2020-01-04][15:39:30] Detect video encoder version:
[2020-01-04][15:39:30]
[2020-01-04][15:39:30] Creating process:
[2020-01-04][15:39:30] "C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x64\x264_x64.exe" --version
[2020-01-04][15:39:30]
[2020-01-04][15:39:31] x264 0.159.2991+49 524a90c t_mod_New [0-bit@all X86_64]
[2020-01-04][15:39:31] (libswscale 5.5.100)
[2020-01-04][15:39:31] (libavformat 58.29.100)
[2020-01-04][15:39:31] (ffmpegsource 2.31.0.0)
[2020-01-04][15:39:31] built on Dec 21 2019, gcc: 9.2.1 20191212
[2020-01-04][15:39:31] x264 configuration: --chroma-format=all--disable-opencl
[2020-01-04][15:39:31] libx264 configuration: --chroma-format=all--disable-opencl
[2020-01-04][15:39:31] x264 license: Non-Free
[2020-01-04][15:39:31] libswscale/libavformat/ffmpegsource license: nonfree and unredistributable
[2020-01-04][15:39:31] WARNING: This binary is unredistributable!
[2020-01-04][15:39:31]
[2020-01-04][15:39:31] Detect video source version:
[2020-01-04][15:39:31]
[2020-01-04][15:39:31] Creating process:
[2020-01-04][15:39:31] "C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x86\avs2yuv_x86.exe"
[2020-01-04][15:39:31]
[2020-01-04][15:39:31] Avs2YUV 0.24bm6
[2020-01-04][15:39:31]
[2020-01-04][15:39:31] > x264 revision: 2991 (core #159) - with custom patches!
[2020-01-04][15:39:31] > Avs2YUV version: 0.24.6
[2020-01-04][15:39:31]
[2020-01-04][15:39:31] --- GET SOURCE INFO ---
[2020-01-04][15:39:31]
[2020-01-04][15:39:31] Creating process:
[2020-01-04][15:39:31] "C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x86\avs2yuv_x86.exe" -frames 1 K:\dg.avs NUL
[2020-01-04][15:39:31]
[2020-01-04][15:39:34]
[2020-01-04][15:39:34] FAILED TO DETERMINE CLIP PROPERTIES !!!

[LoRd_MuldeR]

Well, according to your log, Avs2YUV did not produce any text output at all. This means it either ran into some kind of error (but in that case we'd expect to see at least some sort of error message) or it just crashed.

Does that exactly same .avs file open correctly (and seek properly) in the 32-Bit (x86) version of VirtualDub (http://virtualdub.sourceforge.net/)?

Also, please check the following: Does this problem only appear with Avs2YUV 0.24bm6, i.e. is this a new problem in the latest TEST build, or did the same thing already happen with Avs2YUV 0.24bm5?

[deco20]

Does that exactly same .avs file open correctly (and seek properly) in the 32-Bit (x86) version of VirtualDub (http://virtualdub.sourceforge.net/)?
Yes, no problems.


Also, please check the following: Does this problem only appear with Avs2YUV 0.24bm6, i.e. is this a new problem in the latest TEST build, or did the same thing already happen with Avs2YUV 0.24bm5?
It didn't work in the earlier version neither. That's why I updated it to see if it works in the latest one.

[Emulgator]

Maybe some coincidence under changed circumstances ? Win10, nVidia driver, that route ?
A lead, maybe...

https://forum.videohelp.com/threads/378319-DGSource-incompatible-with-KNLMeansCL
http://rationalqm.us/board/viewtopic.php?f=8&t=436

[LoRd_MuldeR]

It didn't work in the earlier version neither. That's why I updated it to see if it works in the latest one.

Maybe some coincidence under changed circumstances ? Win10, nVidia driver, that route ?

Yeah, the problems with bugs, especially memory corruptions, is that they often lead to undefined behavior – which means that things may seem to work 99% of the time, but then, all of a sudden, they stop working.

In this situation, every little (seemingly unrelated) change is like rolling the dice again...

What you can try: Strip down your Avisynth script to the bare minimum (e.g. source filter only) and try again. If the problem still appears with the minimal script, try another source filter.

Also: Which exact version of Avisynth are you using? In my experience, the official "v2.6.0 ST" (32-Bit) build is the most reliably. The "MT" builds may introduce all sorts of random hiccups, so try switching back to "ST" if you are using "MT".

(In addition to that, try removing every plug-in DLL from your Avisynth "plugins" directory that is not actually needed, just to be sure!)

[deco20]

Thanks for suggestions, but none of it worked unfortunately.
I have AviSynth 2.6.0 ST 32-Bit installed. I tried to run it with only source filter in the script, I tried to run with only necessary plugins in AviSynth.
I updated also DGDecNV and NVidia drivers, still the same.

If you work with m2ts files, what source filter do you use?

[LoRd_MuldeR]

If you work with m2ts files, what source filter do you use?

I tend to re-mux M2TS files with MKVToolnix (https://mkvtoolnix.download/downloads.html), and then just load the resulting MKV with FFMS2 ;)

[deco20]

I tend to re-mux M2TS files with MKVToolnix (https://mkvtoolnix.download/downloads.html), and then just load the resulting MKV with FFMS2 ;)

Ok, will try that, thank you very much for your help and of course, for your app, it's great.

[tormento]

Here is a new TEST build that has the latest x264 and Avs2YUV versions included
Working here.

:thanks:

[gonca]

x264 license: Non-Free
[2020-01-04][15:39:31] libswscale/libavformat/ffmpegsource license: nonfree and unredistributable
[2020-01-04][15:39:31] WARNING: This binary is unredistributable!
Is this correct?

[LoRd_MuldeR]

Is this correct?

Where do you see this? Did you replace the x264 binaries that were included with the Simple x264/x265 Launcher?

With the x264 binaries that currently ship with Simple x264/x265 Launcher, I see:

x264_x64_launcher\res\toolset\x64\x264_x64.exe --version
x264 0.159.2991 1771b55
(libswscale 5.6.100)
(libavformat 58.35.101)
(ffmpegsource 2.31.0.0)
built on Jan 2 2020, gcc: 9.2.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

[gonca]

Where do you see this?
In deco20's log
I checked the log on a default download version to compare, because it didn't look right
[2020-01-04][15:39:31] x264 0.159.2991+49 524a90c t_mod_New [0-bit@all X86_64]
[2020-01-04][15:39:31] (libswscale 5.5.100)
[2020-01-04][15:39:31] (libavformat 58.29.100)
[2020-01-04][15:39:31] (ffmpegsource 2.31.0.0)
[2020-01-04][15:39:31] built on Dec 21 2019, gcc: 9.2.1 20191212
[2020-01-04][15:39:31] x264 configuration: --chroma-format=all--disable-opencl
[2020-01-04][15:39:31] libx264 configuration: --chroma-format=all--disable-opencl
[2020-01-04][15:39:31] x264 license: Non-Free
[2020-01-04][15:39:31] libswscale/libavformat/ffmpegsource license: nonfree and unredistributable
[2020-01-04][15:39:31] WARNING: This binary is unredistributable!
[2020-01-04][15:39:31]


Edit
I was commenting on deco20's problem

[LoRd_MuldeR]

In deco20's log
I checked the log on a default download version to compare, because it didn't look right

Edit
I was commenting on deco20's problem

So, apparently, deco20 has replaced the x264 binaries that ship with Simple x264/x265 Launcher. It looks like he is using the "t_mod_New" build instead.

I just downloaded the latest "t_mod" build from here (https://github.com/jpsdr/x264/releases/latest) and checked. Indeed, this build prints the "This binary is unredistributable!" warning – which means that whoever is distributing those binaries is probably violating the license! :eek:

Just to make it clear again: Simple x264/x265 Launcher does not ship with "t_mod" build, and never has. Also, this is probably not related to deco20's original problem.

[UPDATE]

New version of x264 "t_mod" build has resolved this issue.

[tormento]

Pssst.... I just noticed you forgot to update x264 & x265 download links ;)

[Forteen88]

Here is a new TEST build that has the latest x264 and Avs2YUV versions included:
x264_launcher-TEST.2020-01-03.exe (https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher-TEST.2020-01-03.exe/download)Thanks! Now I've tried it, and it works great, although I mostly used standard settings when I made my encode. Could you please release a portable version though, if that's not too much trouble?

[tormento]

Could you please release a portable version though, if that's not too much trouble?
Just rename to x264_launcher_portable.exe

[Forteen88]

Just rename to x264_launcher_portable.exeOK, thanks, but there is still stuff in the installation-register with this new Test-version.

[tormento]

I'd like to give a try to HDR encoding and I am kinda newbie in that sector. Using DGIndexNV to decode video, there is something I need specifically to set on x265 to add metainfo and, above all, how is x264 launcher support about hdr?

[Atak_Snajpera]

there is something I need specifically to set on x265 to add metainfo and, above all, how is x264 launcher support about hdr?
example for HDR-PQ
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0050 cd/m2, max: 4000 cd/m2
Maximum Content Light Level : 1529 cd/m2
Maximum Frame-Average Light Level : 380 cd/m2

--colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)" --max-cll "1529,380"

example for HDR-HLG

Color primaries : BT.2020
Transfer characteristics : HLG
Matrix coefficients : BT.2020 non-constant

--colorprim bt2020 --transfer arib-std-b67 --colormatrix bt2020nc --atc-sei 18 --pic-struct 0

[tormento]

example for HDR-PQ
So I don’t have to “demux” meta info before encoding and remux it after?

[Atak_Snajpera]

Only If you work with hdr10+. Older hdr10 uses global static hdr data.

[tormento]

Only If you work with hdr10+

I really miss the good old doom9 guides...

Can you link me some more examples?

I badly need to update my skills with HDR procedures.

Thanks.

[Atak_Snajpera]

What examples?

[tormento]

What examples?

How to “demux” and “remux” HDR data and which tools are needed. Or AVS+ scripts modifications, if needed.

[Atak_Snajpera]

https://github.com/quietvoid/hdr10plus_parser/releases

[tormento]

https://github.com/quietvoid/hdr10plus_parser/releases

Thanks!

[ProWo]

Thank you, mate.

[tormento]

6 months old alert!

Please remove it on next build :)

[tormento]

Please notice that when using NVEncC, the custom encoder parameters accept -u quality but not --preset quality.

Did not try other relevant switches.

[LoRd_MuldeR]

Please notice that when using NVEncC, the custom encoder parameters accept -u quality but not --preset quality.

Did not try other relevant switches.

You cannot set the "--preset" switch from the custom encoder options, because the preset is selected via combobox from basic encoder options. The switch is added to the command-line automatically.

Having said that, the "preset" combobox currently is empty/disabled for NVEncC, probably because it did not support presets when NVEncC support was added...

[tormento]

Having said that, the "preset" combobox currently is empty/disabled for NVEncC, probably because it did not support presets when NVEncC support was added...
Enough to use -u... strange enough it bypasses checks :p

[LoRd_MuldeR]

Enough to use -u... strange enough it bypasses checks :p

Will be fixed in the next release.

[tormento]

Will be fixed in the next release.
[…]
x264 0.160.3000 33f9e14
[…]
WARNING: Your x264 binary uses an untested core (API) version, take care!
[…]
Do I need some condom? :D

[rsotome]

is there a switch to bypass the 6 month alert?

[LoRd_MuldeR]

is there a switch to bypass the 6 month alert?

Sry, new version will be released very soon. Please stay tuned!

[LoRd_MuldeR]

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

Version 2.96 [2020-04-17]
* Updated x264 to revision 3000 (API v160)
* Updated x265 to version 3.3+1
* Updated build environment to Visual Studio 2019 with Update-5
* Updated cURL to version 7.69.1 (2020-03-11)

Version 2.95 [2020-01-03]
* Updated x264 to revision 2991 (API v159)
* Updated Avs2YUV to version 0.24 (BugMaster's mod 6)
* Updated build environment to Visual Studio 2019 with Update-4

[rsotome]

soooooo much better, thank you! oh look, it's able to remember queue's again. :)

[tormento]

Simple x264/x265 Launcher v2.96
Thanks man!

Why x264 binaries are different in size than the ones on Videolan? Do you compile on your own or you take from other sources?

[kebulek]

Thank you for new version, especially for adding tune Animation! :)

@tormento: It's LigH's version.

[LoRd_MuldeR]

Why x264 binaries are different in size than the ones on Videolan?

Videolan.org builds do not have FFMS enabled. Also, apparently, a different (older) version of GCC was used.

[tormento]

Simple x264/x265 Launcher v2.96
NVEncC 5.00 out now :p

[LoRd_MuldeR]

NVEncC 5.00 out now :p

Try here:
https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher-TEST.2020-04-18.exe/download

[tormento]

Try here

:thanks:

Did you included the new switches in the GUI?

[LoRd_MuldeR]

:thanks:

Did you included the new switches in the GUI?

The GUI generally does not handle any switches for you, except for the basic rate-control options and the Preset/Tuning/Profile selection.

Anything else you will have to add to the "Custom Encoder Parameters" field, if it should be required.

[r0lZ]

I am trying to install x264_launcher.2020-04-17.zip (from here (https://github.com/lordmulder/Simple-x264-Launcher/releases/tag/v2.96)) but I can't. BitDefender detects curl.exe as a virus and blocks it, and since the temp directory created by 7-zip when I try to extract the file from the archive is always different, I can't exclude it from the scan.

Tried also the installer, with the same result.

I have managed to send curl.exe to VirusTotal, and indeed, it is considered as a virus by 13 antivirus engines: see here (https://www.virustotal.com/gui/file/5f88c6074d06696e30fb3967e73aa01618f0b927b0ab032cbd6ee50791ddb534/detection).

13/73 is a really bad score. Perhaps you should consider to remove, change or update that exe file ? Anyway, currently, a lot of peoples will be unable to install your program, and it's a pity.

Also, your program verifies the exe it needs, and refuse to work when curl.exe is not present or blocked, so currently, I can't use it.

[EDIT] I have restored the previous version of the launcher from a backup, and the curl.exe file in that release is not detected as a virus (only 1 engine detects it as suspicious). Also, its size is very different: 337 KB instead of 1154 KB. So, I guess that curl.exe in your latest release is really infected. Take care !

[tormento]

BitDefender detects curl.exe as a virus and blocks it

Uninstall any AV you have and use Windows 10 one. It’s one of the best, if not the best indeed.

[videoh]

I confirm that Windows Defender finds no issues with curl.exe.

[Sharc]

It complains about Groucho's Avisynth Info Tool v1.1.0 instead……...

[r0lZ]

Uninstall any AV you have and use Windows 10 one. It’s one of the best, if not the best indeed.
It's not because a specific antivirus doesn't detect it that it is not a virus. Also, M$ is well known for the bad quality of its antivirus programs, and although the latest engine might be better, it is not recommended by most comparative charts. As you can see here (https://www.av-comparatives.org/tests/malware-protection-test-march-2020/), BitDefender is still the best AV, far ahead of Windows Defender. I will certainly not uninstall the excellent BitDefender and trust M$ instead ! I would instead recommend exactly the opposite.

Anyway, I can only repeat that 13/73 is not an acceptable VirusTotal score, and the difference with the previous version means that something is obviously wrong. Even if, out of the blue, the bad score is caused by an unlikely series of false positives, many users will not be able to use the launcher while that file is present. IMO, that means that something must be done to fix the problem.

[LoRd_MuldeR]

Anyway, I can only repeat that 13/73 is not an acceptable VirusTotal score, and the difference with the previous version means that something is obviously wrong. Even if, out of the blue, the bad score is caused by an unlikely series of false positives, many users will not be able to use the launcher while that file is present.

Yup, 13 out of 73 anti-virus programs causing false positives definitely is not acceptable. But this fits the picture. The “quality” of anti-virus software is one sad story.

Just in case anybody missed it, researchers just recently found a serious vulnerability affecting (almost) every anti-virus software on the marked and turning them into self-destructive tools:
https://www.rack911labs.com/research/exploiting-almost-every-antivirus-software/

IMO, that means that something must be done to fix the problem.

Definitely! And that "something" is that people and enterprises really need to stop giving any money to anti-virus companies for as long as they keep on delivering the crapware that they have been selling for decades now. If and only if the anti-virus companies' choice is to either get their stuff fixed or to go bankrupt, then something might change. But, for as long as people keep on complaining about anti-virus-related problems to the innocent software developers – who can do exactly nothing about the cause of the problem, and who hopefully don't waste their time on trying to workaround the symptoms – rather than demanding the required fixes from the anti-virus companies, certainly nothing is going to change...

I have restored the previous version of the launcher from a backup, and the curl.exe file in that release is not detected as a virus (only 1 engine detects it as suspicious). Also, its size is very different: 337 KB instead of 1154 KB. So, I guess that curl.exe in your latest release is really infected. Take care!

cURL has been updated to the latest version. The binary shipped with Simple x264 Launcher is the one provided on the "official" cURL web-site.

Note that, depending on which compiler is used to build cURL, depending on which of the optional dependencies are enabled, and depending on whether dependencies are linked statically or as DLL, the size of the binary may change quite a lot.

(I think older Windows binaries of cURL were linked against Windows' Schannel DLL for SSL/TLS, while the newer ones are statically linked against OpenSSL; probably to enable TLS 1.3 independently of the Windows version)

[jlw_4049]

Just use windows defender. Works perfectly.

Sent from my Pixel 3a using Tapatalk

[videoh]

BitDefender is still the best AV As if we don't have enough shills for BitDefender.

[LoRd_MuldeR]

Just use windows defender. Works perfectly.

"Perfectly" is an exaggeration, IMO, but it is definitely one of the less annoying ones.

The reason is obvious: Microsoft is providing Defender as a "free" (yes, provided you have a Windows license) component. So their interest is not in selling Defender licenses, but in keeping Defender-related support cases at a minimum. Hence, the usual scare tactics (i.e. ensure that there will be alerts about alleged "dangerous" files at regular intervals), which are used by other a/v companies to get their customers into renewing the payed subscription, aren't relevant here.

[jlw_4049]

"Perfectly" is an exaggeration, IMO, but it is definitely one of the less annoying ones.

The reason is obvious: Microsoft is providing Defender as a "free" (yes, provided you have a Windows license) component. So their interest is not in selling Defender licenses, but in keeping Defender-related support cases at a minimum. Hence, the usual scare tactics (i.e. ensure that there will be alerts about alleged "dangerous" files at regular intervals), which are used by other a/v companies to get their customers into renewing the payed subscription, aren't relevant here.

Yes I agree. I've never had any issues with it, as opposed to other virus software programs actually causing me issues and hours and hours of my time trouble shooting something that the virus software was causing the entire time.

[LoRd_MuldeR]

The false positive is probably caused by UPX packing.

Please don't mix up symptom and cause.

If the same EXE file, of which we know it's 100% clean, gets classified as "malware" just because it was packed by UPX, then that is a symptom of a serious bug in the a/v software.

The cause is a bug in the a/v software, not that the file was packed by UPX.

Regardless of the "pros" and "cons" of EXE packing that could be discussed, the use of EXE packers – especially the very popular UPX – per se is perfectly legitimate and therefore must not be blocked by a/v software under any circumstances!

Being able to deal with EXE packes and analyze the actual (uncompressed) code has been a standard feature of a/v software for decades now. If they haven't been able to get this working properly by now, time to find another job...

That's one of the reason I am never a fan of UPX.

Unfortunately, it is exactly this kind of subservient behavior, i.e. changing your perfectly legitimate behavior in order to workaround bugs in A/V software, which makes these people think they can get away with it.

Not going to happen for me ;)

The curl in x264_launcher.2020-04-17.zip gets a 4/72 score now on VirusTotal; on the other hand, the official curl binary (https://curl.haxx.se/windows/) gets a 0/71 score.

Quite possible that tomorrow, after the anti-virus "gods" have rolled their dice again (aka "the next signature update"), these numbers will be the other way around ;)

[videoh]

The false positive is probably caused by UPX packing. That's one of the reason I am never a fan of UPX. The curl in x264_launcher.2020-04-17.zip gets a 4/72 score now on VirusTotal; on the other hand, the official curl binary (https://curl.haxx.se/windows/) gets a 0/71 score. Seems like Simple Launcher (great app) should use the official binary. What did I miss?

[r0lZ]

"Perfectly" is an exaggeration, IMO, but it is definitely one of the less annoying ones.
Of course. An antivirus that doesn't detect "true positive" virus is less annoying than a good antivirus that detects all virus. And if the BitDefender antivirus is the best according to AV Comparatives, it's of course because it doesn't omit some virus, but also because it has almost almost no false positives. So, IMO, it should be trusted.

The reason is obvious: Microsoft is providing Defender as a "free" (yes, provided you have a Windows license) component. So their interest is not in selling Defender licenses, but in keeping Defender-related support cases at a minimum. And therefore probably its ease in letting important viruses through.

I remember that in the past M$ explicitly requested to install a third party antivirus, and explained that Defender is only a small barrier active during the installation of Windows, and that it was essential to replace it with a real, powerful antivirus. I can admit that since XP, Defender has made progress, but the fact is that it remains one of the worst.

Also, a VA provider cannot afford to have a too bad score, or too many false positives, because its reputation depends on it, which also leaves it with little chance of selling its solutions. So, sorry, but I don't think they detect false positives on purpose.

Anyway, I use BitDefender FREE Edition. I can agree that they may try to sell their paid software by scaring you, but it is certainly one of the most silent AV I know, unlike other free AV like Avast for example. So, IMO, the commercial argument is not really convincing.

Anyway, the fact remains that many users will be scared by the AV warning, and will uninstall your program immediately. It's a pity, especially if it is sufficient to install a good version of curl.exe, that doesn't trigger so many false (or true) positives.

The curl in x264_launcher.2020-04-17.zip gets a 4/72 score now on VirusTotal; on the other hand, the official curl binary (https://curl.haxx.se/windows/) gets a 0/71 score.Another evidence that something is wrong. It is always possible that a programmer has built that version on an infected computer. Precautions are essential, as with corona!

For my part, I have only pointed out the problem to enable you to act in the best possible way. I don't want to interfere any more, but for my part, I have replaced the questionable version with a good one. I can no longer ask to check for updates from the program (why?) but at least I can encode again.

[tormento]

Of course.
Omitting my considerations about necessity and dangers of 3rd party AV, I can only suggest you

THIS (https://curl.haxx.se/docs/install.html)

[stax76]

I use curl in the updater function of mpv.net and MediaInfo.NET, in Windows 10 curl is included, in Windows 7 my feature is broken and I don't care, I'm not really spending extra time only for Windows 7 users, who wants the update feature has to install powershell 5.1 and curl.

[tormento]

Try here
Is it normal that with NVEncC I can't set almost anything from GUI? At least I would need profile (main10) and so. The basic things...

P.S: New version out :)

[LoRd_MuldeR]

Is it normal that with NVEncC I can't set almost anything from GUI? At least I would need profile (main10) and so. The basic things...

What exactly you can't set?

The "Tuning" combobox is disabled for NVEncC, because NVEncC doesn't have anything like that. You can still set "Preset" and "Profile" for NVEncC.

Anything else, as always, needs to be set via "Custom Encoder Parameters" edit box...

[LoRd_MuldeR]

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

Version 2.97 [2020-05-15]
* Updated x265 to version 3.3+27
* Updated NVEncC to version 5.01
* Updated cURL to version 7.70.0 (2020-04-29)VapourSynth R49 Warning
There is a bug in VapourSynth R49 that causes vspipe.exe to fail loading the Python DLL. Therefore, Simple x264 Launcher was unable to find a working VapourSynth. Please update to R50 (http://www.vapoursynth.com/2020/05/r50-low-risk-release/), which fixed the issue!

[redbtn]

Big thanks for new release!

[LoRd_MuldeR]

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

Version 2.98 [2020-06-25]
* Updated x264 to revision 3009 (API v160)
* Updated x265 to version 3.4+7
* Updated NVEncC to version 5.06
* Added experimental "dark mode" (use option --dark-gui-mode to enable)
* Updated build environment to Visual Studio 2019 with Update-6

[darkio]

how is the quality using nvenc compared to x265?

[tormento]

Simple x264/x265 Launcher v2.98
I love dark mode.

Tell me there is a way to set it in preferences.ini. :p

[LoRd_MuldeR]

Tell me there is a way to set it in preferences.ini. :p

Not at this time. It's just a crude integration of QDarkStylesheet (https://github.com/ColinDuquesnoy/QDarkStyleSheet), which works fairly well, but also produces quite a few glitches.

I will see if further improvements are possible when I have more time...

how is the quality using nvenc compared to x265?

It's exactly 42.3141 percent worse ;)

(Really, this depends on a whole lot of factors, including the kind of material you are encoding, the selected bit rate and the selected quality preset. So you are best off doing you own tests with settings that fit your workflow!)

[darkio]

I had no doubts, why then is it used here?
I tried something but the results are not satisfactory even at the same bitrate. I did a bluray rip of the alien film, even using the preset faster the results are much better with x265 (I have an i7 4790k). Using nvenc CQP 20 or in vbr mode, it does not improve the quality via gpu

[LoRd_MuldeR]

I had no doubts, why then is it used here?
I tried something but the results are not satisfactory even at the same bitrate. I did a bluray rip of the alien film, even using the preset faster the results are much better with x265 (I have an i7 4790k). Using nvenc CQP 20 or in vbr mode, it does not improve the quality via gpu

Just as an example: With x265, I get ~5.5 fps for "4K" material on my Core-i 6700K, using the "medium" (default) preset. This goes up to at most ~15.7 fps, when using the "ultrafast" preset. With NVEncC, I get ~80 fps for the same input, on my RTX 2070 SUPER (HEVC mode, default preset). So, NVEncC typically runs many times faster than x265. This means that a quality comparison which completely disregards encoding speed is not really "fair" here.

Anyway, it's all about giving users options to choose from. If your goal is to get the maximum quality at a medium to low bitrate, and if you are willing the spend a whole lot of encoding time for that, then using one of the software encoders probably still is your best choice. But, if your goal is to finish the encode as quickly as possible while still getting a "reasonable" quality, then probably nothing will beat a hardware encoder, such as NVEncC.

[jlw_4049]

I had no doubts, why then is it used here?

I tried something but the results are not satisfactory even at the same bitrate. I did a bluray rip of the alien film, even using the preset faster the results are much better with x265 (I have an i7 4790k). Using nvenc CQP 20 or in vbr mode, it does not improve the quality via gpuI usually encode 4k via x265 on my 3900x. It takes about 16 hours.

I really wouldn't recommend encoding 4k on a quad core. Although like Lord said, hardware is an option if you dont mind the quality loss.

Sent from my SM-G986U1 using Tapatalk

[darkio]

rigaya's nvenc 5.12 have 2 pass mode now.

[szabi]

Hi

The latest included x264 version is r3009 from june, however official one (https://artifacts.videolan.org/x264/release-win64/) is newer: x264 r3027 from october.
Is it still get update?

Regards
szabi

[LoRd_MuldeR]

The latest included x264 version is r3009 from june, however official one (https://artifacts.videolan.org/x264/release-win64/) is newer: x264 r3027 from october.

Not that there have been a lot of important changes in x264 (for Windows users), but a new release is up now ;)

[LoRd_MuldeR]

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

Version 2.98 [2020-06-25]
* Updated x264 to revision 3027 (API v161)
* Updated x265 to version 3.4+30
* Updated NVEncC to version 5.20

[szabi]

Not that there have been a lot of important changes in x264 (for Windows users), but a new release is up now ;)

Thanks. :)

EDIT:
Regarding the lots of changes I use x264 with this settings since years.

https://abload.de/img/simplemajou.png

Should I change my preferred settings or I can stay on my oldies one? :)
What do u suggest?

[Emulgator]

It depends what resolution you feed to encoder, how much grain you want to encode,
how much picture deterioration you can stand and which playback device you intend to target.
x264 has not changed much in that regard.

If you aim at 1080p25/29,97 blu-ray for instance and want to have transparency through grain and keep all details,
bufsize and maxrate are too high, while 13Mbps would be too misery.

If you aim at a hardware player or mobile phone and supply denoised, degrained stuff 720p@24/25/29fps,
13Mbps are good to go, while the bufsize and maxrate are still unnecessary high.

[szabi]

Hi
You are right I did not go into details.
I use for 1080p output and all limits are kept due to hardware decoder I have expect nofastpskip which in use to increase quality.
I still use 2 pass encode that is why bitrate is calculated for the size of output however quality is still around 1 pass 17mbps bitrate. At least I hope. :-)
Thanks for your help.
Regards.
szabi

[StainlessS]

JFYI, from long time ago, [2018, I just noticed your reply]

It actually is 0xC0000139, equal to STATUS_ENTRYPOINT_NOT_FOUND, if you interpret it as 32-Bit unsigned integer, which I think is the right thing to do here.

NT_STATUS codes are defined as DWORDs, which are 32-Bit unsigned integer values, but will be typecasted to 32-Bit signed integer values when returned as a process' exit code.

(Hence, if the original unsigned value had its most significant bit set, the signed value will have negative sign)

#include <stdint.h>

int main()
{
const uint32_t code = (uint32_t)(-1073741511);
printf("0x%X\n", code);
return 0;
}
Output:
0xC0000139

I had entered the denary number [1073741511], and then hit the negate key in my calculator, it failed to negate that number before my hex conversion. [10 digit display calculator]

[guest]

Not that there have been a lot of important changes in x264 (for Windows users), but a new release is up now ;)

Hi LoRd MuldeR,

I just happen to find this app today, and I have had a bit of a fiddle with it, and I think it's pretty easy to update x264 & x265, and I notice that it seems to use L Smash as a decoder (is that correct?), anyway, can this be updated by the user ??

Would there be a chance that you could "point" the app to where the sources paths could be chosen, instead of integrated with in the app ? (I'm not really sure what I'm talking about).

I also installed Vapoursynth & Python, but it also ask's for Visual Studio, which looks like it's a fairly large download..is that really required ??

One thing I noticed when I updated x264 from https://artifacts.videolan.org/x264/release-win64/, and renamed it, when I tested a new job, the encoding info window at the bottom of the app, did NOT show all the info that the built in version x264 did (if you know what I'm trying to say) I could send screenshots if you like.

[videoh]

I notice that it seems to use L Smash as a decoder (is that correct?), anyway, can this be updated by the user ?? Just as you discovered with staxrip, you can create your own avisynth or vapoursynth script invoking the source filter and other filters that you like. Then the script can be opened in Simple Launcher.

[guest]

Just as you discovered with staxrip, you can create your own avisynth or vapoursynth script invoking the source filter and other filters that you like. Then the script can be opened in Simple Launcher.

Oh, Hi DG, (are you following me?...lol)...yeah, not really the answer(s) to my question, but nice to know.

I'd just like to know how to update some of the key components, not necessarily "custom" scripts. (unless that's a clue)

For example, where is the L-Smash source, when using this app ??

Cheers

[videoh]

My understanding is that it uses the input capabilities of x264.exe and x265.exe. They are built with understanding of (for example) MKV input. It won't be easy to change those things, which is why Avisynth/Vapoursynth input is the way to go for such flexibility.

Sincerely,
your stalker

[guest]

Sincerely,
your stalker

Nice :)

OK, well, I might have good play around with it the next couple of days, and see if I can make any sense of it.

I was out riding my dirt bike today, so I need a rest.

[kebulek]

Oh no, pop up window with "Your version of Simple x264 Launcher is more than 6 month old!" is back. :rolleyes:

@LoRd_MuldeR: Could you make a new update for us? Thanks.

BTW: "Update web-server" doesn't work.

[dREV]

Hi, I can't seem to get this to work again for some reason. It's telling me this: FAILED TO DETERMINE VERSION INFO !!!

I switched both x264 64 bit with jpsdr's tmod https://github.com/jpsdr/x264/releases and a HEVC 64 bit build ver 3.5.0.20 from DJATOM https://github.com/DJATOM/x265-aMod/releases as I didn't wanna use the one that's included with it. Using the portable version btw.

I didn't change anything else. Simply refuses to encode using 64 bit now. This has been happening for the past 2-3 days. It was just working fine for the last couple of months till then when I stumbled upon this seeking to replace MeGUI with a faster gui that would create and keep the index of lsmash now this. Leaving me going back to my ex, MeGUI, so I can continue to encode with those encoders as of course no issues in MeGUI with those encoders. :scared:

[2021-05-17][08:52:27] Simple x264 Launcher (Build #1210), built 2020-11-19
[2021-05-17][08:52:27]
[2021-05-17][08:52:27] Job started at 2021-05-17, 08:52:27.
[2021-05-17][08:52:27]
[2021-05-17][08:52:27] Source file : Z:\# # DL\Encode\S1\Active 01 (002).avs
[2021-05-17][08:52:27] Output file : Z:\# # DL\Encode\S1\Active 01 (002).264
[2021-05-17][08:52:27]
[2021-05-17][08:52:27] --- SYSTEMINFO ---
[2021-05-17][08:52:27]
[2021-05-17][08:52:27] Binary Path : C:\Users\---\Desktop\! TEST\x264 launcher
[2021-05-17][08:52:27] Avisynth : Yes
[2021-05-17][08:52:27] VapourSynth : No
[2021-05-17][08:52:27]
[2021-05-17][08:52:27] --- SETTINGS ---
[2021-05-17][08:52:27]
[2021-05-17][08:52:27] Encoder : x264 (AVC/H.264), 64-Bit (x64), 8-Bit
[2021-05-17][08:52:27] Source : Avisynth (avs)
[2021-05-17][08:52:27] RC Mode : CRF
[2021-05-17][08:52:27] Preset : placebo
[2021-05-17][08:52:27] Tuning : Animation
[2021-05-17][08:52:27] Profile : High
[2021-05-17][08:52:27] Custom : --level 5.0 --direct auto --partitions all --trellis 2 --b-pyramid normal --b-adapt 2 --threads 0 --deblock 0:0
--bframes 16 --ref 16 --qcomp 0.60 --rc-lookahead 60 --aq-mode 3 --aq-strength 1.00 --lookahead-thread=2 --me tesa --subme 11 --merange 32
--psy-rd 1.00:0 --no-interlaced --transfer iec61966-2-1 --sar 1:1 --fade-compensate 0.3
[2021-05-17][08:52:27]
[2021-05-17][08:52:27] --- CHECK VERSION ---
[2021-05-17][08:52:27]
[2021-05-17][08:52:27] Detect video encoder version:
[2021-05-17][08:52:27]
[2021-05-17][08:52:27] Creating process:
[2021-05-17][08:52:27] "C:\Users\---\Desktop\! TEST\x264 launcher\toolset\x64\x264_x64.exe" --version
[2021-05-17][08:52:27]
[2021-05-17][08:52:28] x264 0.161.3048+53M 0749c36 t_mod_New [(8 & 10)-bit@all X86_64]
[2021-05-17][08:52:28] (libswscale 5.7.100)
[2021-05-17][08:52:28] (libavformat 58.45.100)
[2021-05-17][08:52:28] (ffmpegsource 2.40.0.0)
[2021-05-17][08:52:28] (lsmash 2.16.1)
[2021-05-17][08:52:28] built on Feb 14 2021, gcc: 10.2.1 20200926
[2021-05-17][08:52:28] x264 configuration: --chroma-format=all--disable-opencl
[2021-05-17][08:52:28] libx264 configuration: --chroma-format=all--disable-opencl
[2021-05-17][08:52:28] x264 license: GPL version 2 or later
[2021-05-17][08:52:28] libswscale/libavformat/ffmpegsource license: GPL version 3 or later
[2021-05-17][08:52:28]
[2021-05-17][08:52:28] Detect video source version:
[2021-05-17][08:52:28]
[2021-05-17][08:52:28] Creating process:
[2021-05-17][08:52:28] "C:\Users\---\Desktop\! TEST\x264 launcher\toolset\x86\avs2yuv_x86.exe"
[2021-05-17][08:52:28]
[2021-05-17][08:52:28] Avs2YUV 0.24bm6
[2021-05-17][08:52:28]
[2021-05-17][08:52:28] > x264 revision: 3048 (core #161) - with custom patches!
[2021-05-17][08:52:28] > Avs2YUV version: 0.24.6
[2021-05-17][08:52:28]
[2021-05-17][08:52:28] --- GET SOURCE INFO ---
[2021-05-17][08:52:28]
[2021-05-17][08:52:28] Creating process:
[2021-05-17][08:52:28] "C:\Users\---\Desktop\! TEST\x264 launcher\toolset\x86\avs2yuv_x86.exe" -csp I420 -depth 8 -frames 1
Z:\##DL~1\_B77DA~1\S1VOL1~1\active~1.avs NUL
[2021-05-17][08:52:28]
[2021-05-17][08:52:32] Z:\##DL~1\_B77DA~1\S1VOL1~1\active~1.avs: 852x480, YV12, 8-bits, progressive, 24000/1001 fps, 40054 frames
[2021-05-17][08:52:32]
[2021-05-17][08:52:32] Resolution: 852 x 480
[2021-05-17][08:52:32] Frame Rate: 24000/1001
[2021-05-17][08:52:32] No. Frames: 40054
[2021-05-17][08:52:32]
[2021-05-17][08:52:32] --- ENCODING VIDEO ---
[2021-05-17][08:52:32]
[2021-05-17][08:52:32] Creating input process:
[2021-05-17][08:52:32] "C:\Users\---\Desktop\! TEST\x264 launcher\toolset\x86\avs2yuv_x86.exe" -csp I420 -depth 8 Z:\##DL~1\_B77DA~1\S1VOL1~1\active~1.avs -
[2021-05-17][08:52:32]
[2021-05-17][08:52:32] Creating encoder process:
[2021-05-17][08:52:32] "C:\Users\---\Desktop\! TEST\x264 launcher\toolset\x64\x264_x64.exe" --output-depth 8 --crf 16.0 --preset placebo
--tune animation --profile high --level 5.0 --direct auto --partitions all --trellis 2 --b-pyramid normal --b-adapt 2 --threads 0 --deblock 0:0 --bframes 16
--ref 16 --qcomp 0.60 --rc-lookahead 60 --aq-mode 3 --aq-strength 1.00 --lookahead-thread=2 --me tesa --subme 11 --merange 32 --psy-rd 1.00:0
--no-interlaced --transfer iec61966-2-1 --sar 1:1 --fade-compensate 0.3 --output "Z:\# # DL\Encode\S1\Active 01 (002).264" --frames 40054
--demuxer y4m --stdin y4m -
[2021-05-17][08:52:32]
[2021-05-17][08:52:40] y4m [info]: 852x480p 1:1 @ 24000/1001 fps (cfr)
[2021-05-17][08:52:40] y4m [info]: color matrix: undef
[2021-05-17][08:52:40] x264 [info]: using SAR=1/1
[2021-05-17][08:52:40] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
[2021-05-17][08:52:40] x264 [info]: profile High, level 5.0, 4:2:0, 8-bit
[2021-05-17][08:52:40] x264 [info]: cabac=1 ref=16 deblock=1:0:0 analyse=0x3:0x133 me=tesa subme=11 psy=1 fade_compensate=0.30
psy_rd=1.00:0.00 mixed_ref=1 me_range=32 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=0 chroma_qp_offset=-2
threads=15 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 fgo=0 bframes=16
b_pyramid=2 b_adapt=2 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=23 scenecut=40 intra_refresh=0
rc_lookahead=60 rc=crf mbtree=1 crf=16.0000 qcomp=0.60 qpmin=0:0:0 qpmax=69:69:69 qpstep=4 ip_ratio=1.40 aq=3:1.00
aq-sensitivity=10.00 aq-factor=1.00:1.00:1.00 aq2=0 aq3=0
[2021-05-17][08:52:40] x264 [info]: started at Mon May 17 08:52:34 2021
[2021-05-17][10:23:06] x264 [info]: frame I:316 Avg QP:11.57 size: 83396
[2021-05-17][10:23:06] x264 [info]: frame P:9325 Avg QP:15.16 size: 15423
[2021-05-17][10:23:06] x264 [info]: frame B:30413 Avg QP:18.68 size: 3160
[2021-05-17][10:23:06] x264 [info]: consecutive B-frames: 3.7% 4.4% 10.2% 27.0% 13.3% 14.5% 6.1% 7.4% 2.1% 2.6% 1.4% 2.7% 1.9% 0.8% 0.7% 0.8% 0.6%
[2021-05-17][10:23:06] x264 [info]: mb I I16..4: 10.2% 37.3% 52.5%
[2021-05-17][10:23:06] x264 [info]: mb P I16..4: 2.1% 5.4% 4.3% P16..4: 27.3% 22.6% 10.5% 3.1% 0.6% skip:24.2%
[2021-05-17][10:23:06] x264 [info]: mb B I16..4: 0.3% 0.6% 0.3% B16..8: 25.3% 9.4% 1.9% direct: 2.1% skip:60.2% L0:48.8% L1:43.9% BI: 7.3%
[2021-05-17][10:23:06] x264 [info]: 8x8 transform intra:45.6% inter:46.1%
[2021-05-17][10:23:06] x264 [info]: direct mvs spatial:99.6% temporal:0.4%
[2021-05-17][10:23:06] x264 [info]: coded y,uvDC,uvAC intra: 69.0% 69.8% 54.4% inter: 9.1% 8.9% 4.3%
[2021-05-17][10:23:06] x264 [info]: i16 v,h,dc,p: 31% 36% 2% 30%
[2021-05-17][10:23:06] x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 14% 12% 8% 10% 9% 12% 10% 15%
[2021-05-17][10:23:06] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 22% 8% 8% 10% 9% 10% 8% 10%
[2021-05-17][10:23:06] x264 [info]: i8c dc,h,v,p: 32% 37% 18% 13%
[2021-05-17][10:23:06] x264 [info]: Weighted P-Frames: Y:4.6% UV:3.9%
[2021-05-17][10:23:06] x264 [info]: ref P L0: 49.2% 5.4% 14.2% 7.7% 4.5% 4.3% 2.9% 2.7% 1.5% 1.5% 1.1% 1.3% 0.9% 1.0% 0.8% 0.9%
[2021-05-17][10:23:06] x264 [info]: ref B L0: 61.5% 13.1% 7.7% 4.0% 3.1% 2.1% 1.9% 2.0% 1.2% 0.8% 0.8% 0.7% 0.6% 0.5% 0.2%
[2021-05-17][10:23:06] x264 [info]: ref B L1: 91.1% 8.9%
[2021-05-17][10:23:06] x264 [info]: kb/s:1275.20
[2021-05-17][10:23:06] encoded 40054 frames, 7.374 fps, 1275.20 kb/s, 253.95 MB
[2021-05-17][10:23:06] x264 [info]: ended at Mon May 17 10:23:06 2021
[2021-05-17][10:23:06] x264 [info]: encoding duration 1:30:32
[2021-05-17][10:23:06] av2y [info]: Z:\##DL~1\_B77DA~1\S1VOL1~1\active~1.avs: 852x480, YV12, 8-bits, progressive, 24000/1001 fps, 40054 frames
[2021-05-17][10:23:06] Final file size is 254.0 MB bytes.
[2021-05-17][10:23:06]
[2021-05-17][10:23:06] --- COMPLETED ---
[2021-05-17][10:23:06]
[2021-05-17][10:23:06] Job finished at 2021-05-17, 10:23:06. Process took 90 minutes, 38 seconds.




to this

[2021-05-21][14:59:27] Simple x264 Launcher (Build #1210), built 2020-11-19
[2021-05-21][14:59:27]
[2021-05-21][14:59:27] Job started at 2021-05-21, 14:59:27.
[2021-05-21][14:59:27]
[2021-05-21][14:59:27] Source file : Z:\# # DL\Encode\S1\Active 01 (002).avs
[2021-05-21][14:59:27] Output file : Z:\# # DL\Encode\S1\Active 01 (002).264
[2021-05-21][14:59:27]
[2021-05-21][14:59:27] --- SYSTEMINFO ---
[2021-05-21][14:59:27]
[2021-05-21][14:59:27] Binary Path : C:\Users\--\Desktop\! TEST\x264 launcher
[2021-05-21][14:59:27] Avisynth : Yes
[2021-05-21][14:59:27] VapourSynth : No
[2021-05-21][14:59:27]
[2021-05-21][14:59:27] --- SETTINGS ---
[2021-05-21][14:59:27]
[2021-05-21][14:59:27] Encoder : x264 (AVC/H.264), 64-Bit (x64), 8-Bit
[2021-05-21][14:59:27] Source : Avisynth (avs)
[2021-05-21][14:59:27] RC Mode : CRF
[2021-05-21][14:59:27] Preset : placebo
[2021-05-21][14:59:27] Tuning : Animation
[2021-05-21][14:59:27] Profile : High
[2021-05-21][14:59:27] Custom : --level 5.0 --direct auto --partitions all --trellis 2 --b-pyramid normal --b-adapt 2 --threads 0 --deblock 0:0
--bframes 16 --ref 16 --qcomp 0.60 --rc-lookahead 60 --aq-mode 3 --aq-strength 1.00 --lookahead-thread=2 --me tesa --subme 11
--merange 32 --psy-rd 1.00:0 --no-interlaced --transfer iec61966-2-1 --sar 1:1 --fade-compensate 0.3
[2021-05-21][14:59:27]
[2021-05-21][14:59:27] --- CHECK VERSION ---
[2021-05-21][14:59:27]
[2021-05-21][14:59:27] Detect video encoder version:
[2021-05-21][14:59:27]
[2021-05-21][14:59:27] Creating process:
[2021-05-21][14:59:27] "C:\Users\--\Desktop\! TEST\x264 launcher\toolset\x64\x264_x64.exe" --version
[2021-05-21][14:59:27]
[2021-05-21][14:59:27]
[2021-05-21][14:59:27] FAILED TO DETERMINE VERSION INFO !!!

using the same script!

I tried the skip version from https://github.com/lordmulder/Simple-x264-Launcher#command-line-syntax that didn't seem to work since I did place it in the custom parameter field. Dunno where to place it and according to this https://github.com/lordmulder/Simple-x264-Launcher/issues/14 if I read it right it's not recommended, why? :cool:

Any help on why this is happening? What am I doing wrong?
The program works again when I place the original x264.exe and x265.exe back not surprisingly. :thanks:


And that 6 month update thing is really annoying. Can't turn it off.

Could the author possibly include a feature where when you select the destination I can either type it in or copy and paste my folder location instead of the one it currently is using so it's faster? As I already mention I do tons of trim encodes then append them together and I do see it says something about a batch but I dunno how to do that.

Also, an option to keep jobs on the program as soon as they're on the program as I use tons of scripts with trim like MeGUI and I had a crash with the program adding new jobs while it was encoding and lost everything and had to redo them all... Also an option to not encode right after adding a job. And an option to move more than 1 job on the list up or down and to delete them as well instead of moving them 1 by 1. All could be a on/off toggle in the preference.

I really like this program a lot. Thanks for adding a pause when encoding. Never knew such a thing was possible of all my years encoding with MeGUI. Its neat! Hella lot faster than it too!


[EDIT] Seems downgrading to version 2.98 fixed the issue so far. Strange bug.

[LoRd_MuldeR]

Simple x264/x265 Launcher v3.00
https://github.com/lordmulder/Simple-x264-Launcher/releases/tag/v3.00

Version 3.00 [2021-05-29]
* Updated x265 to version 3.5+2
* Updated NVEncC to version 5.33
* Updated cURL to version 7.76.1 (2021-04-14)
* Updated build environment to Visual Studio 2019 with Update-10
* Do not close application when hibernating the computer

[kebulek]

Thank you!

[zorrax]

Hi
I would like to encode UHD video in x265 format (2pass).
I saw that two parameters ( --scenecut-aware-qp and --vbv-live-multi-pass) are specific for the 2pass.
is it possible to specify these options for the 2pass in simpleX264 ?
thks

[LoRd_MuldeR]

Hi
I would like to encode UHD video in x265 format (2pass).
I saw that two parameters ( --scenecut-aware-qp and --vbv-live-multi-pass) are specific for the 2pass.
is it possible to specify these options for the 2pass in simpleX264 ?
thks

Currently it is not possible to specify custom encoder options only for the second pass. Generally, except for "--pass", the exactly same options should be set for both passes.

So options that are allowed only in a second pass are something new :D

[LoRd_MuldeR]

Simple x264/x265 Launcher v3.01
https://github.com/lordmulder/Simple-x264-Launcher/releases/tag/v3.01

Version 3.01 [2021-12-08]
* Updated x265 to version 3.5+20
* Updated NVEncC to version 5.41
* Replaced GnuPG by CodeSign for checking the auto-update signatures
* Updated build environment to Visual Studio 2022

[Forteen88]

Simple x264/x265 Launcher v3.01Thanks!

[coocooc]

After having installed your latest x64 version (downloaded from github) on Monday, our company virus scanner Trend Micro interrupted your program's attempt to check if there is a newer version available.

The IT summary is attached in the three PNGs. 15 out of 67 hits; but the big ones like BitDefender, McAfee and Sophos are also classifying it as malicious.

Might be the "Predictive machine learning" causing havoc, but it could also be that the installer on github is really infected. Can you please double-check, if it contains what you expect to be therein?


You provide a cryptographic signature there, but I do not know how to check the installer integrity with these files. Any hint for this?

* Replaced GnuPG by CodeSign for checking the auto-update signatures
Is this change maybe the evil that triggers the scanners?

On my private computer your latest version does not trigger an alarm with Microsoft Defender, but it was not installed from github, but updated automatically from within your program.

And btw, thanks for your program and the integration of 10bit and x265 long ago. It still covers most of my needs on a regular basis! :thanks:

[jlw_4049]

After having installed your latest x64 version (downloaded from github) on Monday, our company virus scanner Trend Micro interrupted your program's attempt to check if there is a newer version available.



The IT summary is attached in the three PNGs. 15 out of 67 hits; but the big ones like BitDefender, McAfee and Sophos are also classifying it as malicious.



Might be the "Predictive machine learning" causing havoc, but it could also be that the installer on github is really infected. Can you please double-check, if it contains what you expect to be therein?





You provide a cryptographic signature there, but I do not know how to check the installer integrity with these files. Any hint for this?





Is this change maybe the evil that triggers the scanners?



On my private computer your latest version does not trigger an alarm with Microsoft Defender, but it was not installed from github, but updated automatically from within your program.



And btw, thanks for your program and the integration of 10bit and x265 long ago. It still covers most of my needs on a regular basis! :thanks:Itll be a false positive.

Sent from my SM-G986U1 using Tapatalk

[LoRd_MuldeR]

Might be the "Predictive machine learning" causing havoc, but it could also be that the installer on github is really infected. Can you please double-check, if it contains what you expect to be therein?

"Unknown threats, Predicative Machine Learning" says it all :D

(it's a fancy way of the "antivirus" vendor saying: If we can't find a real threat, then we make up one, 'cause well... somehow we need to justify those license fees you payed for our crapware)


Did you consider verifying the signature that I provide along with all of my release binaries in order to check the integrity and authenticity of the file you downloaded ???

If I do this, then the result looks like: https://i.imgur.com/lXAWtYS.png – which should answer your question ;)



* Replaced GnuPG by CodeSign for checking the auto-update signatures
Is this change maybe the evil that triggers the scanners?

Yes, I'm so evil that I even wrote my own program (https://gitlab.com/lord_mulder/codesign) (based on OpenSSL and released under a Public Domain license) for signing/verifying my release binaries :p

https://i.imgur.com/pcUUBII.png

[coocooc]

Looks like this here, using the .sig2 file:
https://imgur.com/a/qSxbgxo

Do I understand this correctly, that I am missing your public key? I however cannot find it on a key server searching for "mulder2@gmx.de". Is there something I need to do with the .rsa file you also offer in the download section?

[Edit]
Ok, I found your public key on www.muldersoft.com. Maybe you can add a link "Public Key" on the top of your page? I didn't expect the key down there after all the 3rd party tools. :-)

I trusted your key based on the same ID, that I saw on your screenshot above. Is the fingerprint published anywhere?

Is the .rsa file only useful in combination with your CodeSign tool? Kleopatra could not import the RSA key published on muldersoft.com, neither saved as .pem nor as .der file.

Ah, and the downloaded file passed the verification, so it was not hacked for some time. So the virus scanner alarm was a false positive.

[LoRd_MuldeR]

Ok, I found your public key on www.muldersoft.com. Maybe you can add a link "Public Key" on the top of your page? I didn't expect the key down there after all the 3rd party tools. :-)
Also here (https://sourceforge.net/projects/muldersoft/files/lord_mulder.pgp_public_key.v2.asc/download) and here (http://tricksoft.de/lord_mulder.pgp_public_key.v2.asc). Anyway, maybe I will make the public keys more prominent on the website :o

I trusted your key based on the same ID, that I saw on your screenshot above. Is the fingerprint published anywhere?
It's on the website, right above the actual PGP key outline ;)

But be aware that the website shows the full fingerprint, whereas the Kleopatra screenshot only shows a "truncated" fingerprint (last 16 hex digits).

Kleopatra could not import the RSA key published on muldersoft.com, neither saved as .pem nor as .der file.
The RSA public key is provided in the standard OpenSSL/PEM format. This is not a GPG key/certificate though, so GnuPG/Kleopatra cannot import it. The OpenSSL command-line tool can work with such files:
https://www.openssl.org/docs/man1.1.1/man1/rsa.html

Is the .rsa file only useful in combination with your CodeSign tool?
It's a "raw" RSA signature value, encoded in the Base64 format. Probably the easiest way to verify it is by using the CodeSign tool. OpenSSL should work too:
https://pagefault.blog/2019/04/22/how-to-sign-and-verify-using-openssl/

(though OpenSSL's "dgst" command requires the signature value in binary form for verification, not Base64, so you'd have to decode it first, e.g. using OpenSSL's "enc" command)

[coocooc]

It's on the website, right above the actual PGP key outline ;)


This can only be explained with my black&white colour blindness ... :-)

Thanks for your explanations, I will try them when being back at work.

[LoRd_MuldeR]

Simple x264/x265 Launcher v3.02
https://github.com/lordmulder/Simple-x264-Launcher/releases/tag/v3.02

Version 3.02 [2022-06-16]
* Updated x264 to revision 3094 (API v164)
* Updated x265 to version 3.5+37
* Updated NVEncC to version 6.05
* Updated build environment to Visual Studio 2022 with Update-2

[writemaster]

hi LoRd_MuldeR

When will AV1 encoder be added to Simple x264/x265 Launcher?

[tyler durdan]

Can someone give me a guide on this please?

I normally use Staxrip where I just drop the mkv in and i'm good to go.
It seems you cant do that with this one

I cant figure out how to get a valid file for it to work with

I tried splitting the video out with mkvcleaver but still no luck

Can someone help please?

[Emulgator]

What happens if you use .avs script input and preview that in AvsPmod?
LWLibavVideoSource("C:\myfile.mkv")

[almosely]

https://www.directupload.eu/file/d/8604/lpub6q7o_png.htm

... the forced update message is popping up since a few days but I can't do anything to stop that ...

[almosely]

https://www.directupload.eu/file/d/8611/63q8bceo_png.htm

https://www.directupload.eu/file/d/8611/qsj5klgq_png.htm

Now the web-server responds: There's no update available. This should be fine now, but is not: The update notification is repeating at every start, telling me that my version is more than 12 months old.

[rsotome]

Yeah, constant forced "check for update" message & queue no longer saves jobs when you restart.

Could you please maybe look into removing the update requirement & the queue bug?

Thank you.

[LoRd_MuldeR]

Simple x264/x265 Launcher v3.04
https://github.com/lordmulder/Simple-x264-Launcher/releases/tag/v3.04

Version 3.04 [2024-07-14]
* Updated x264 to revision 3191 (API v164)
* Updated x265 to version 3.6+13
* Support for latest VapourSynth versions that no longer support the '--y4m' switch
* Updated cURL to version 8.8.0 (2024-05-22)
* Updated build environment to Visual Studio 2022 with Update-10

[TP2222]

Thanks for Simple x264/x265 Launcher! I have been using it for many years and am very happy!

[Forteen88]

Thanks. How do I use it with the newest x265-4.1+54 version though?

[TP2222]

Thanks. How do I use it with the newest x265-4.1+54 version though? Rename x265-4.1+54 to x265_x64.exe Send to MuldeR -> Simple x264 Launcher v2 -> toolset -> x64.

[Forteen88]

@TP2222
Thanks, but I did that and Simple Launcher couldn't start the x265 encoding (had some "error"). Maybe I had some unusual setting. It used to work well before on older versions.

[Emulgator]

Latest x265 commandline syntax has changed/extended to accommodate MVC IIRC ?

[TP2222]

Failed to download update information! version 3.0.4 (build # 1225). The Check for Updates inscription doesn't go away.

[LoRd_MuldeR]

Failed to download update information! version 3.0.4 (build # 1225). The Check for Updates inscription doesn't go away.
Should be fixed by now.

(Signature of update info was expired and has been renewed today)

Latest x265 commandline syntax has changed/extended to accommodate MVC IIRC ?

If the command-line syntax has changed, some more work may be needed to make the GUI work with newer versions. Will look into this soon™.

[TP2222]

Should be fixed by now.

(Signature of update info was expired and has been renewed today)



If the command-line syntax has changed, some more work may be needed to make the GUI work with newer versions. Will look into this soon™. Yeees! Thank you!

[TP2222]

Hello! Will there be an update of Simple x264/x265 Launcher for x264 0.165? Thank you.

[Emulgator]

You may do that yourself and just replace the offending .exe.

[TP2222]

You may do that yourself and just replace the offending .exe. Thanks for the answer! I am currently using x264-0.165.3222_b35605a. And I get WARNING: Your x264 binary uses an untested core (API) version, take care! This application works best with x264 core (API) version 164.
Simple x264/x265 Launcher works correctly.

[rsotome]

Any chance we'll be getting an update sometime soon?

Even if it's just to remove the (UPDATE NOTIFICATION), maybe permanently? that you have to constantly wait to discard.

Also, queued items no longer save when this happens.

thank you

[djesteban]

Hi,
Any update planned soon that would support x265 4.x and newer version of x264?
Thanks in advance

[dREV]

I came to this site to check if any updates were up and I see a few comments about issues with the annoying update warning and not being able to save new scripts.

While the update thing still occurs it doesn't take long when the program starts, it can still save scripts which is the important thing. The server doesn't seem to work when checking updates. So if it's not saving the scripts I am using version 3.03.1220 if this information is helpful for those with this issue.

And add a copy of your chosen encoders to \x264_launcher.2023-06-24\toolset\x64 folder or x32. Probably make a backup copy of your scripts C:\Users\%profileuser%\AppData\Local\LoRd_MuldeR\Simple x264 Launcher

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

[TP2222]

For my x264 encodings, the most convenient graphical interface is Simple x264/x265 Launcher in conjunction with AvsPmod 64-bit. In any case, a huge thank you to Mr. Lord Mulder, even if he stops updating Simple x264/x265 Launcher.

[almosely]

Since a few weeks or months the update info is popping up at program start again, but connecting to the update server is not possible. Could you repair that or remove this update notification completely?