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

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