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.