Log in

View Full Version : Simple x264/x265 Launcher v3.02 (2022-06-16)


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 [35] 36 37 38 39 40

GMJCZP
29th June 2017, 01:43
When I make a simple update with the setup, in the "About..." option does not show version 2.83, still showing 2.81.

LoRd_MuldeR
29th June 2017, 15:47
No speed effect, but surely less writes to the hard drive is better?

I don't think you really need to worry about this.

On the other hand, it's quite easy to just set the output filename to NUL in the first pass, so I will probably add an option for this.

LoRd_MuldeR
29th June 2017, 15:52
When I make a simple update with the setup, in the "About..." option does not show version 2.83, still showing 2.81.

Not quite sure what you mean with "update with the setup". But if it shows "v2.81" in the about screen, then you are running v2.81, not v2.83.

The setup program can "overwrite" (upgrade) an existing installation, so you do not need to uninstall to old version first. Anyway, the setup program will install whatever version is contained in the particular setup package that you are installing. Old setup package will install old version. You need to download the latest (https://github.com/lordmulder/Simple-x264-Launcher/releases/latest) setup program from the project site and install that! Or just let the auto-update function upgrade your existing "v2.81" installation to the latest...

(I just tested that v2.81 will upgrade to v2.83 flawlessly and couldn't notice any issues)

iSeries
29th June 2017, 19:39
I don't think you really need to worry about this.

On the other hand, it's quite easy to just set the output filename to NUL in the first pass, so I will probably add an option for this.

Thank you! :-)

GMJCZP
30th June 2017, 04:40
Fixed issue, I was using an old setup, thank you.

Shb
3rd July 2017, 03:21
Firstly, thanks for all the work! I'm using this pretty much daily and it's been great.

Recently, I've been having a slight issue with hitting the deadlock timer. I've been using the --no-deadlock-detection switch to avoid the problem for the most part, however I'm somewhat confused as to why both creating the avs2yuv and x264 process take a long time. Before the latest version, these would start almost immediately, but on the current version (I think I updated in-app and it said to build #1114), each of these processes takes well over the 5 minutes before deadlocking kicks in. I've even tried manually indexing the files but the same outcome occurs.

Is there anything I can provide you with to assist?

Edit: Seems it was source-specific. I tried a different source and it had none of the same issues.

LoRd_MuldeR
5th July 2017, 20:33
Firstly, thanks for all the work! I'm using this pretty much daily and it's been great.

Recently, I've been having a slight issue with hitting the deadlock timer. I've been using the --no-deadlock-detection switch to avoid the problem for the most part, however I'm somewhat confused as to why both creating the avs2yuv and x264 process take a long time. Before the latest version, these would start almost immediately, but on the current version (I think I updated in-app and it said to build #1114), each of these processes takes well over the 5 minutes before deadlocking kicks in. I've even tried manually indexing the files but the same outcome occurs.

Is there anything I can provide you with to assist?

Edit: Seems it was source-specific. I tried a different source and it had none of the same issues.

Well, the included avs2yuv hasn't changed for ages. x264 has been updated recently, but there should be no change effecting "startup" time.

If avs2yuv or x264 takes a long time to start or even triggers "deadlock" detection, then it almost certainly means that Avisynth (or more precisely: your Avisynth script) takes a very long time to initialize.

A typical cause for this is FFMS2 (or whatever source filter you use) taking a long time to index the source. But there could be other reasons, e.g. your script is just painfully slow overall.

r0lZ
6th July 2017, 08:51
Personally, I check my script in AvsPmod (https://avspmod.github.io) before encoding it with Simple X264 Launcher. With AvsPmod, I have a visual feedback, and if something goes wrong, I can see the avisynth error message. And the indexing of the source is already finished when I decide to encode. With that method, I have no startup problem any more.

Shb
6th July 2017, 14:09
Personally, I check my script in AvsPmod (https://avspmod.github.io) before encoding it with Simple X264 Launcher. With AvsPmod, I have a visual feedback, and if something goes wrong, I can see the avisynth error message. And the indexing of the source is already finished when I decide to encode. With that method, I have no startup problem any more.

That's what I have been doing, and I didn't have any issues with any source up until the one I posted about. Even after moving on to different sources I am back to normal again, I'm just not sure why it struggled. There was nothing unusual about the script, just resizing and a slight bit of cropping. Along the lines of:


FFVideoSource("..\source.mkv")
Crop(0, 20, 0, -20)
Spline36ResizeMod(1024, 552)

No deinterlacing or anything intensive at all. It seemed as though the file was being reindexed every single time no matter if the index file already existed.

LoRd_MuldeR
6th July 2017, 19:04
That's what I have been doing, and I didn't have any issues with any source up until the one I posted about. Even after moving on to different sources I am back to normal again, I'm just not sure why it struggled. There was nothing unusual about the script, just resizing and a slight bit of cropping. Along the lines of:


FFVideoSource("..\source.mkv")
Crop(0, 20, 0, -20)
Spline36ResizeMod(1024, 552)

No deinterlacing or anything intensive at all. It seemed as though the file was being reindexed every single time no matter if the index file already existed.

Try setting the "cachefile" option explicitly in your FFVideoSource() call.

LoRd_MuldeR
15th July 2017, 21:39
Simple x264 Launcher v2.84
https://github.com/lordmulder/Simple-x264-Launcher/releases/tag/v2.84

Version 2.84 [2017-07-12]
* Updated x264 to revision 2851
* Updated x265 to version 2.5+2

tormento
17th September 2017, 17:34
I read, from website, I can use portable AviSynth:
InstallPath\
├─ x264_launcher_portable.exe
└─ extra\
└─ Avisynth\
├─ x86\
│ ├─ avisynth.dll <32-Bit>
│ ├─ devil.dll <32-Bit>
│ └─ etc…
└─ x64\
├─ avisynth.dll <64-Bit>
├─ devil.dll <64-Bit>
└─ etc…
Imaging I can put there AviSynth+, how can I place there plugins too, with the same structure of AviSynth+, forgetting forever the PITA of installing AviSynth?

LoRd_MuldeR
17th September 2017, 19:08
I read, from website, I can use portable AviSynth:
InstallPath\
├─ x264_launcher_portable.exe
└─ extra\
└─ Avisynth\
├─ x86\
│ ├─ avisynth.dll <32-Bit>
│ ├─ devil.dll <32-Bit>
│ └─ etc…
└─ x64\
├─ avisynth.dll <64-Bit>
├─ devil.dll <64-Bit>
└─ etc…
Imaging I can put there AviSynth+, how can I place there plugins too, with the same structure of AviSynth+, forgetting forever the PITA of installing AviSynth?

My experience with Avisynth+ is limited.

When you install "normal" Avisynth, it will offer you the "Standalone, Unpack Files only" install option. That will extract the required files. For "portable" use, those files need to be placed exactly as described in the README file.

You can try doing the same with Avisynth+. If case that there is no "Standalone, Unpack Files only" option in the Avisynth+ installer, you will need to extract the required files in a different way...

LoRd_MuldeR
7th October 2017, 10:33
Simple x264 Launcher v2.85
https://github.com/lordmulder/Simple-x264-Launcher/releases/tag/v2.85

Version 2.85 [2017-10-04]
* Updated x265 to version 2.5+22
* Updated build environment to Visual Studio 2017 with Update-3

LoRd_MuldeR
27th February 2018, 22:05
Simple x264 Launcher v2.86

Version 2.86 [2018-02-27]
* Updated x264 to revision 2901 (API v155)
* Updated x265 to version 2.7+1
* Updated NVEncC to version 3.30
* x264 encoder now uses combined 8-Bit/10-Bit binaries
* Moved "Shutdown computer" option from preferences to application menu
* Updated build environment to Visual Studio 2017 with Update-5

Cedvano
1st March 2018, 16:57
I fall down on this sotfware and it's wonderful

Thank you, it's so simple to convert UHD with this software.

Atak_Snajpera
2nd March 2018, 11:34
Lord_Mulder
You can reduce archive size from 54.8 MB (zip) to 32.7 MB (7z ULTRA preset). ZIP compression efficiency is a joke in 2018 ;)

You could use ffmpeg to pipe directly from .mkv
http://i.cubeupload.com/dEdlSS.png

tormento
9th March 2018, 12:51
@Lord_Mulder

Do you plan to add HDR support?

LoRd_MuldeR
9th March 2018, 19:11
Lord_Mulder
You can reduce archive size from 54.8 MB (zip) to 32.7 MB (7z ULTRA preset). ZIP compression efficiency is a joke in 2018 ;)

Yes, I know, LZMA (7z) beats Deflate (ZIP) by far. That's why the EXE installer uses LZMA.

ZIP is used for the "portable" version for max. compatibility. After all, the only archive format Windows supports "out of the box" is ZIP.

(Yes, CAB works too and compresses slightly better, but Explorer fails horribly to extract CAB's with sub-folders)

You could use ffmpeg to pipe directly from .mkv
http://i.cubeupload.com/dEdlSS.png

Maybe in a future version. Currently I have no time for bigger improvements like this, as my "real-life" job is keeping me busy ;)

And, of course, I'd much prefer, if x265 CLI finally adopted the FFMS2 input module from x264 CLI...

LoRd_MuldeR
9th March 2018, 19:14
@Lord_Mulder

Do you plan to add HDR support?

I have no idea. What changes in GUI you would be required to "add HDR support" :confused:

(If you are referring to "HDR support" support in x264 or x265, you would have to ping the x264/x265 developers. That's not my business)

AYColumbia
27th April 2018, 00:02
Hi,
I just installed the latest NVIDIA driver 397.31 and now avs2yuv_x64.exe crashes. I found the info below in the event viewer. Note that rolling driver back to prior version 391.35 works fine. I confirmed this on my laptop (GeForce GTX 960M) and my media server (Geforce GTX 650).

Faulting application name: avs2yuv_x64.exe, version: 0.0.0.0, time stamp: 0x57b61de5
Faulting module name: nvcuda.dll, version: 24.21.13.9731, time stamp: 0x5adc2e79
Exception code: 0xc0000005
Fault offset: 0x00000000001280ef
Faulting process id: 0x5c4
Faulting application start time: 0x01d3ddb05c0c63d7
Faulting application path: c:\MultiMediaTools\Simple x264 Launcher v2\toolset\x64\avs2yuv_x64.exe
Faulting module path: C:\WINDOWS\SYSTEM32\nvcuda.dll
Report Id: 282ad1ed-1fca-41a4-bc35-68fffdc1550e
Faulting package full name:
Faulting package-relative application ID:


I run the line below to get info I need like # of frames which has been working flawlessly until the new driver.

cmd /c ""c:\MultiMediaTools\Simple x264 Launcher v2\toolset\x64\avs2yuv_x64.exe" -frames 1 "media_p1.avs" NUL 2>&1"

The avs file only has two lines, i.e.,

LoadPlugin("c:\MultiMediaTools\DGDecNV\x64 Binaries\DGDecodeNV.dll")
DGSource("media_p1.dgi")

I was able to load/play the avs file in vdub64 just to be sure. Let me know if you need any other info.

tormento
27th April 2018, 12:55
Hi,I just installed the latest NVIDIA driver 397.31 and now avs2yuv_x64.exe crashes.
Same here. Did not try to rollback yet but same symptoms.

MeGUI_x64 gives errors too.

EDIT: rollback to 391.35 and error disappeared. Very strange indeed.

Jim_Pansen
28th April 2018, 07:18
Hi Mulder,

thank you very much for this helpful tool.

Could you please add a regular field to locate a chapter index file to can assign it to a job more easy?
Parameter --qpfile QPFILE_NAME
http://www.x264bluray.com/advanced-features/chapters

The parameter would be best controlled in the GUI since the cmd line is not much handy for modifications.
An the file must be changed for each file!

Another feature request is to can define different speed for first pass in 2-pass mode.

Thanks to consider about it
best regards
Jim

r0lZ
28th April 2018, 09:04
I just installed the latest NVIDIA driver 397.31 and now avs2yuv_x64.exe crashes.It seems that this version of the driver is full of problems. I have read here (in French) (https://www.tomshardware.fr/articles/geforce-397.31-bug-pilote-carte-graphique,1-67457.html) that if you install it for a GTX 1060, the installer asks to reboot the computer after each reboot! nVidia is currently working on a solution. Perhaps the solution will fix the avs2yuv bug too.
In the meantime, the article suggests to skip this update, or, if it has already been installed, use the Display Driver Uninstaller (https://www.wagnardsoft.com) and then re-install the previous version (v391.35) (http://www.nvidia.com/download/driverResults.aspx/132845/en-us).

LoRd_MuldeR
28th April 2018, 14:21
Hi,
I just installed the latest NVIDIA driver 397.31 and now avs2yuv_x64.exe crashes. I found the info below in the event viewer. Note that rolling driver back to prior version 391.35 works fine. I confirmed this on my laptop (GeForce GTX 960M) and my media server (Geforce GTX 650).

Faulting application name: avs2yuv_x64.exe, version: 0.0.0.0, time stamp: 0x57b61de5
Faulting module name: nvcuda.dll, version: 24.21.13.9731, time stamp: 0x5adc2e79
Exception code: 0xc0000005
Fault offset: 0x00000000001280ef
Faulting process id: 0x5c4
Faulting application start time: 0x01d3ddb05c0c63d7
Faulting application path: c:\MultiMediaTools\Simple x264 Launcher v2\toolset\x64\avs2yuv_x64.exe
Faulting module path: C:\WINDOWS\SYSTEM32\nvcuda.dll
Report Id: 282ad1ed-1fca-41a4-bc35-68fffdc1550e
Faulting package full name:
Faulting package-relative application ID:


I run the line below to get info I need like # of frames which has been working flawlessly until the new driver.

cmd /c ""c:\MultiMediaTools\Simple x264 Launcher v2\toolset\x64\avs2yuv_x64.exe" -frames 1 "media_p1.avs" NUL 2>&1"

The avs file only has two lines, i.e.,

LoadPlugin("c:\MultiMediaTools\DGDecNV\x64 Binaries\DGDecodeNV.dll")
DGSource("media_p1.dgi")

I was able to load/play the avs file in vdub64 just to be sure. Let me know if you need any other info.

Well, avs2yuv_x64.exe is just the "wrapper" around Avisynth.DLL. So, if you see crashes in avs2yuv_x64.exe, it is almost certainly not a problem in avs2yuv_x64.exe itself but a crash in Avisynth.

Furthermore, as long as you are using the "official" stable version of Avisyth, crashes in Avisynth are caused by "buggy" plug-ins more often than not.

Here the case seems quite clear: You are using "DGDecodeNV.dll" plug-in (GPU-based decoder DLL) and that seems to not work correctly with latest NVIDIA driver. The crash of avs2yuv_x64.exe is just the symptom of the underlying problem.

I cannot say whether there is a bug in "DGDecodeNV.dll" (which I don't have) that happens to trigger with latest NVIDIA driver, or whether the latest NVIDIA driver is bugged. Comments by others seem to indicate the latter...

LoRd_MuldeR
28th April 2018, 14:29
Hi Mulder,

thank you very much for this helpful tool.

Could you please add a regular field to locate a chapter index file to can assign it to a job more easy?
Parameter --qpfile QPFILE_NAME
http://www.x264bluray.com/advanced-features/chapters

The parameter would be best controlled in the GUI since the cmd line is not much handy for modifications.
An the file must be changed for each file!

This seems a bit specific for me to justify another GUI option.

If you need to use a different "--qpfile" for each input file, you can use the variables "$(INPUT)" or "$(OUTPUT)" in your custom parameters...


Another feature request is to can define different speed for first pass in 2-pass mode.

Thanks to consider about it
best regards
Jim

x264 and x265 automatically applies "faster" settings to the first pass of a 2-Pass encode, unless you specify "--slow-first-pass" option.

The idea is that you can use the same settings (Preset) for both passes and still the encoder automatically uses "faster" settings in the first pass for those settings that won't effect the 2nd pass...

AYColumbia
28th April 2018, 19:03
@r0lZ,
Thanks for the info. I'll wait for the next driver release.

@LoRd_MuldeR,
I think you're right as what you said makes sense. Hopefully next driver release fixes the current mess.

Jim_Pansen
28th April 2018, 19:15
This seems a bit specific for me to justify another GUI option.
Mmmh, it's needed to define precise chapter points for Blu-ray compatible streams.

If you need to use a different "--qpfile" for each input file, you can use the variables "$(INPUT)" or "$(OUTPUT)" in your custom parameters...
Thank you for the hint, but sorry, I don't know exactly what to do.
Sure I know how to drop the parameter into the line of custom parameters. :)
But I must admit, I'm not familar with the syntax, is it propritairy?
I can put it into the custom parameter line and add the job to queue.
But what happens next? Where has the files and folders to be defined?
Will simpleX264 launcher ask me for that?

x264 and x265 automatically applies "faster" settings to the first pass of a 2-Pass encode, unless you specify "--slow-first-pass" option.

The idea is that you can use the same settings (Preset) for both passes and still the encoder automatically uses "faster" settings in the first pass for those settings that won't effect the 2nd pass...
Thanks!

Do you consider about capabilities to can re-edit jobs already in queue?
Do you even consider about to can save and restore queues like a project?

best
Jim

LoRd_MuldeR
28th April 2018, 19:28
Thank you for the hint, but sorry, I don't know exactly what to do.
Sure I know how to drop the parameter into the line of custom parameters. :)
But I must admit, I'm not familar with the syntax, is it propritairy?
I can put it into the custom parameter line and add the job to queue.
But what happens next? Where has the files and folders to be defined?
Will simpleX264 launcher ask me for that?

It is explained in the program ;)

https://i.imgur.com/gUCtiJo.png?1

Instead of writing a specific file name, such as --qpfile "c:\foo\bar\baz.qpfile", you can, for example, write --qpfile "$(INPUT).qpfile".

This is going to load the file "<whatever_the_input_file_is>.qpfile" as the qpfile.


Do you consider about to re-edit jobs already in queue?

Just select "Restart Job", which effectively clones the existing into a new one and also allows you to edit the job.


Do you even consider about to can save and restore queues like a project?

Not at this point, sorry.

sneaker_ger
28th April 2018, 21:31
x264 and x265 automatically applies "faster" settings to the first pass of a 2-Pass encode, unless you specify "--slow-first-pass" option.
This is not true for x265 anymore.

http://x265.readthedocs.io/en/default/cli.html#cmdoption-slow-firstpass

LoRd_MuldeR
28th April 2018, 22:14
This is not true for x265 anymore.

http://x265.readthedocs.io/en/default/cli.html#cmdoption-slow-firstpass

In what way? Seems to do exactly what one would expect:

x265:
--slow-firstpass, --no-slow-firstpass

Enable first pass encode with the exact settings specified. The quality in subsequent multi-pass encodes is better (compared to first pass) when the settings match across each pass. Default enabled.

When slow first pass is disabled, a turbo encode with the following go-fast options is used to improve performance:
[…]

x264:
--slow-firstpass

Don't force these faster settings with --pass 1:
[…]

sneaker_ger
28th April 2018, 22:18
Enable first pass encode with the exact settings specified. The quality in subsequent multi-pass encodes is better (compared to first pass) when the settings match across each pass. Default enabled.



Version 2.0
Release date - 13th July, 2016

- multi-pass: First pass now uses slow-firstpass by default, enabling better RC decisions in future passes
http://x265.readthedocs.io/en/default/releasenotes.html#version-2-0

LoRd_MuldeR
28th April 2018, 23:27
Okay, so x265 now has "--slow-firstpass" enabled by default, and you actually have to pass "--no-slow-firstpass" in order to get faster settings in the first pass.

Doesn't change the basic idea though: We still can use the same settings for both passes, and simply add "--no-slow-firstpass" in order to speed up the first pass (instead of adding "--slow-firstpass" in order to not peed up the first pass).

Jim_Pansen
2nd May 2018, 02:59
This is going to load the file "<whatever_the_input_file_is>.qpfile" as the qpfile.
This works really fine!
I did not realize the mouse-over description!
Thank you very much!

Jim

tormento
4th May 2018, 16:14
397.55 (http://nvidia.custhelp.com/app/answers/detail/a_id/4661) out

Any hero to try? :)

EDIT: Tried and same error. Back to past.

AYColumbia
5th May 2018, 17:34
397.55 (http://nvidia.custhelp.com/app/answers/detail/a_id/4661) out

Any hero to try? :)

EDIT: Tried and same error. Back to past.
I use DGDecNV so I checked the forum there and sure enough someone did report issues that are fixed in the latest DG tools slipstream of 2053. If you're using this, then grab the latest. I did and it does now work fine with 397.31 which didn't prior. I normally don't install hot fix releases but just the official releases but I'm sure it'll work fine with .55 too.

LoRd_MuldeR
11th May 2018, 16:08
Simple x264 Launcher v2.87
https://github.com/lordmulder/Simple-x264-Launcher/releases/tag/v2.87

Version 2.87 [2018-05-11]
* Updated x265 to version 2.7+348
* Updated NVEncC to version 4.01
* Updated build environment to Visual Studio 2017 with Update-7

jorX
13th June 2018, 23:52
In my XP - SP3 install, any version following the 2.84 doesn't works;
It says: "process exited with error code: -1073741511" without further explanation(s).
Any hints?
Thank you

lansing
25th July 2018, 08:07
How do I set bit depth for NVEncC? I tried to put "--output-depth 10" on the custom parameter but it gave me the warning "forbidden parameter".

StainlessS
25th July 2018, 09:04
In my XP - SP3 install, any version following the 2.84 doesn't works;
It says: "process exited with error code: -1073741511" without further explanation(s).
Any hints?
Thank you

-1073741511 is hex 0x3ffffec7,

Only found a few mentions of that error code via google,
here is one concerning problem with a Qt4 dll:- http://www.qtcentre.org/threads/26213-exited-with-code-1073741511

LoRd_MuldeR
12th August 2018, 15:36
In my XP - SP3 install, any version following the 2.84 doesn't works;
It says: "process exited with error code: -1073741511" without further explanation(s).
Any hints?
Thank you

-1073741511 == 0xC0000139 == STATUS_ENTRYPOINT_NOT_FOUND
The procedure entry point %hs could not be located in the dynamic link library %hs.

I suppose you see that in that log inside of Simple x264 Launcher?

It would indicate that whatever encoder (x264? x265?) you are trying to use is missing a required function from one of its required DLLs.

Probably means that Windows XP is no longer supported by the effected encoder.

(Which wouldn't be much of a surprise, considering that Windows XP has reached "end of life" more than four years ago)

[UPDATE]

Indeed, current "x264.exe" imports various functions from KERNEL32.DLL that have not been available on Windows XP yet:
https://i.imgur.com/LtNswSW.png

(Also imports some functions from BCRYPT.DLL, which is missing entirely on Windows XP)

LoRd_MuldeR
12th August 2018, 16:00
-1073741511 is hex 0x3ffffec7

It actually is 0xC0000139, equal to STATUS_ENTRYPOINT_NOT_FOUND, if you interpret it as 32-Bit unsigned integer, which I think is the right thing to do here.

NT_STATUS codes are defined as DWORDs, which are 32-Bit unsigned integer values, but will be typecasted to 32-Bit signed integer values when returned as a process' exit code.

(Hence, if the original unsigned value had its most significant bit set, the signed value will have negative sign)

#include <stdint.h>

int main()
{
const uint32_t code = (uint32_t)(-1073741511);
printf("0x%X\n", code);
return 0;
}
Output:
0xC0000139

LoRd_MuldeR
13th August 2018, 20:11
Simple x264 Launcher v2.88
https://github.com/lordmulder/Simple-x264-Launcher/releases/tag/v2.88

Version 2.88 [2018-08-11]
* Updated x264 to revision 2932 (API v157)
* Updated x265 to version 2.8+57

vehf263
11th October 2018, 19:19
Hi,

I installed Simple Launcher using .exe setup and extracting from .zip.
In both cases Launcher says it has no Vapoursynth installed.

I tried to do so according your readme.html. No luck.

InstallPath\
├─ x264_launcher_portable.exe
└─ extra\
└─ Avisynth\
├─ x86\
│ ├─ avisynth.dll <32-Bit>
│ ├─ devil.dll <32-Bit>
│ └─ etc…
└─ x64\
├─ avisynth.dll <64-Bit>
├─ devil.dll <64-Bit>
└─ etc…

It's your path to install both Vapoursynth and Avisynth from your readme.html.

The path you provide is not enough clear or is not actual.
Please I need a today's path to install both Vapoursynth and Avisynth.

Thank you.

LoRd_MuldeR
11th October 2018, 20:02
Hi,

I installed Simple Launcher using .exe setup and extracting from .zip.
In both cases Launcher says it has no Vapoursynth installed.

I tried to do so according your readme.html. No luck.

InstallPath\
├─ x264_launcher_portable.exe
└─ extra\
└─ Avisynth\
├─ x86\
│ ├─ avisynth.dll <32-Bit>
│ ├─ devil.dll <32-Bit>
│ └─ etc…
└─ x64\
├─ avisynth.dll <64-Bit>
├─ devil.dll <64-Bit>
└─ etc…

It's your path to install both Vapoursynth and Avisynth from your readme.html.

The path you provide is not enough clear or is not actual.
Please I need a today's path to install both Vapoursynth and Avisynth.

Thank you.

If you want to use Avisynth and/or VapourSynth in "portable" mode, you need to follow the install instructions exactly:
http://muldersoft.com/docs/x264_launcher_readme.html#portable-mode

Also note that the files need to be arranged exactly as depicted in the README file. And especially note the remark about "embeddable Python", if you want to use VapourSynth portable!

Last but not least, you can launch "x264_launcher.exe" with option "--console" to get more details about Avisynth/VaopurSynth detection...

videoh
12th October 2018, 02:00
Minor cosmetic issue:

http://rationalqm.us/misc/sl.png

Thanks for this great program.

vehf263
12th October 2018, 11:20
Hi,

Thank you for your patience.

One more question.
How can I execute some particular Avisynth scripts while using Simple x264 Launcher?

Thank you.

LoRd_MuldeR
12th October 2018, 22:35
Minor cosmetic issue:

Should be somewhat better in new version.

One more question.
How can I execute some particular Avisynth scripts while using Simple x264 Launcher?

Uhm? :confused:

You "execute" an Avisynth script simply by selecting as the source file for your encoding job, and then launching that job – if that was the question.

LoRd_MuldeR
12th October 2018, 22:36
Simple x264 Launcher v2.89
https://github.com/lordmulder/Simple-x264-Launcher/releases/tag/v2.89

Version 2.89 [2018-10-12]
* Updated x264 to revision 2935 (API v157)
* Updated x265 to version 2.9+1
* Improved initial window size on the "High DPI" screen
* Updated build environment to Visual Studio 2017 with Update-8

vehf263
13th October 2018, 15:29
You "execute" an Avisynth script simply by selecting as the source file for your encoding job, and then launching that job – if that was the question.

Hmm :confused:

Will such a script of three actually working string work without any error?

#LoadPlugin("C:\Program Files\MeGUI\tools\ffms\ffms2.dll")
#FFVideoSource("D:\Temp00\StatusQuo.video.mkv", fpsnum=30000, fpsden=1001, threads=1)
#
selectTotal1=framecount()/100
selectTotal2=selectTotal1*2
selectrangeevery(selectTotal2,50)
#

you generate an index file by your internals, so there is no needs to generate it in this tiny script.