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

[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