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

[guccimane]

Please tell me the x264 log is autosaved in v2 :|

[LoRd_MuldeR]

Please tell me the x264 log is autosaved in v2 :|

Nope, the log's won't be autosaved.

But each job will remain on the list after it has finished until you either delete it or exit the program. So you can go back to the log at any time.

It should be straight forward to copy&past the log into Notepad, if you really need to save it...

[guccimane]

Nope, the log's won't be autosaved.

But each job will remain on the list after it has finished until you either delete it or exit the program. So you can go back to the log at any time.

It should be straight forward to copy&past the log into Notepad, if you really need to save it...

I really needed it and exited the program on accident thinking I'd be able to find the log in %appdata% like V1, but after looking through the code in the repo I realized i was out of luck. :c

[LoRd_MuldeR]

I may add an option to auto-save the logs to the preferences dialog in a future version.

[kypec]

I may add an option to auto-save the logs to the preferences dialog in a future version.
That would be much welcome, TIA!

[lansing]

can you extend the process killing countdown? I've running a heavy script on a 1080 source, and it took quite some time to even start, and then the "warning: x264 did not respond for 60 seconds..." comes up, some time it just kills the whole thing at the start. This last two days I was trying to do it again, both tries the process were timeout on the 10% mark, it's very frustrating.

[LoRd_MuldeR]

Are you using FFmpegSource as your source filter?

[lansing]

Are you using FFmpegSource as your source filter?

i'm using FFmpegSource2

[LoRd_MuldeR]

i'm using FFmpegSource2

FFmpegSource(2) will create an index file first when it opens the source file. This can result in your Avisynth script taking extremely long to initialize for "big" source files :eek:

I highly recommend to create the index file beforehand with the help of ffmsindex.exe. Then pass the path to the index file in your call to FFVideoSource or FFAudioSource.

[lansing]

FFmpegSource(2) will create an index file first when it opens the source file. This can result in your Avisynth script taking extremely long to initialize for "big" source files :eek:

I highly recommend to create the index file beforehand with the help of ffmsindex.exe. Then pass the path to the index file in your call to FFVideoSource or FFAudioSource.

i already has the .ffindex file created in the same folder. Or do you mean I should use FFVideoSource to load the video instead of FFmpegSource2?

[LoRd_MuldeR]

FFmpegSource2 is the name of the project/plugin. The functions provided by FFmpegSource2 are called FFVideoSource() and FFAudioSource().

I mean that you should create you index file beforehand with ffmsindex.exe and then use FFVideoSource() or FFAudioSource() in a way like this:

FFVideoSource("C:\Path to Source\source.mkv", cachefile="C:\Path to Source\source.ffindex")

At the moment when your Avsiynth script is loaded, the index file "C:\Path to Source\source.ffindex" should already exist.

[lansing]

FFmpegSource2 is the name of the project/plugin. The functions provided by FFmpegSource2 are called FFVideoSource() and FFAudioSource().

I mean that you should create you index file beforehand with ffmsindex.exe and then use FFVideoSource() or FFAudioSource() in a way like this:

FFVideoSource("C:\Path to Source\source.mkv", cachefile="C:\Path to Source\source.ffindex")

At the moment when your Avsiynth script is loaded, the index file "C:\Path to Source\source.ffindex" should already exist.

oh, i always thought that the index file will be auto loaded with the video file whenever the source filter was called.:eek:

I try and see what happen, thanks.

[LoRd_MuldeR]

Well, I think the cachefile defaults to the path of the source file + ".ffindex", but that file normally won't exist before you load your Avisynth script for the first time.

If the index file does not exist yet, then FFMS2 will generate the index file during the initialization of your Avisynth script. This can take very long (for big source file) and thus may cause your script to trigger a timeout.

By generating the index file beforehand with the ffmsindex.exe application you can avoid this kind of problem...

[lansing]

updating my problem, i just encoded for 4 hours to 10% done, and this time i was there to see the error. It was avs2yuv_x86.exe crashing that was causing the timeout, and it was one of my virtualdub plugin i used that was causing the crash.:(

[LoRd_MuldeR]

updating my problem, i just encoded for 4 hours to 10% done, and this time i was there to see the error. It was avs2yuv_x86.exe crashing that was causing the timeout, and it was one of my virtualdub plugin i used that was causing the crash.:(

If avs2yuv_x86.exe crashes, you obviously have another problem.

It's a problem with Avisynth or, more likely, one of the Avisynth plug-in's involved. Crash has nothing to do with a timeout!

(Any message about a "timeout" would only be an incidental symptom of the crash that has occurred)

[shinchiro]

updating my problem, i just encoded for 4 hours to 10% done, and this time i was there to see the error. It was avs2yuv_x86.exe crashing that was causing the timeout, and it was one of my virtualdub plugin i used that was causing the crash.:(
It might be possible that the source was corrupt. Try checking its crc32

[hunter_aran]

Wow. This tool is awesome! Is doesn't crash all the time like MeGUI and the speed up is very helpful!

Sorry if this has already been mentioned (tried reading through then searching again), but I'm having a problem with the aspect ratio as far as what is being reported in Mediainfo.

I generate a file (h264 or Mp4, doesn't matter) and then set the same DAR in the container when muxing. The PAR/SAR and DAR are the same and Mediainfo keeps showing two lines, one for "original aspect ratio" and another for "display aspect ratio". Now I've been told that when both lines are present and contain the same ratio (ie 4:3), this means that the aspect ratio in the stream and container vary, even if it is a small percent.

I have tried setting the SAR/PAR in x264 at 8:9, which is the correct AR and looks perfect and I have tried NOT setting it in x264 and instead writing it to the stream in YAMB/MP4box and it doesn't matter! Mediainfo always lists two lines for the AR. This is the same workflow I was using for stuff in MeGUI, so I am pretty sure the muxing programs (MP4Box and Subler) are not to blame. But no matter what I do, I can't get the files output by this program to match up the container and stream AR.

Any ideas? I really really want to switch over to this and dump Megui completely... :)

[LoRd_MuldeR]

You can use the "--sar" option to set the desired Sample (Pixel) Aspect Ratio.

[richeerichhh]

Just updated to version 2 of A Simple x264 Launcher. For some reason I keep getting these two messages when I start the program.
http://dl.dropbox.com/u/1045428/aviSerror01.PNG
followed by
http://dl.dropbox.com/u/1045428/aviSerror02.PNG

I have AviSynth (32-bit) installed. I know it works because I use it with AvsP and it works fine with the old A Simple x264 Launcher.

The wierd thing is that when I'm transcoding my BluRay's it plays well with AviSynth, despite the warning. But if I'm trancoding a DVD, using DGDecode, it won't work.
Now mind you it does work quite nicely in the old x264 launcher. Any solutions as to what could be causing this?

Thanks in advance.

[LoRd_MuldeR]

Well, the program will load the Avisynth.dll (the 32-Bit one!) and, if the DLL could be loaded, check the Avisynth version number.

So the warning indicates that either the Avisynth.dll could not be loaded or that the version number could not be detected or that the version number was smaller than 2.5.

Note that you might be able to get more detailed info on what the problem is by launching the program with the "--console" parameter.

[richeerichhh]

Thanks for your response, I'm running AviSynth version 2.58.

http://dl.dropbox.com/u/1045428/aviVersion.PNG

however this is what I got when I ran the launcher with the "--console" parameter.

http://dl.dropbox.com/u/1045428/launcher-debug.PNG

[hunter_aran]

You can use the "--sar" option to set the desired Sample (Pixel) Aspect Ratio.

Yes when I do this and set --sar 8:9 and then set the same thing when muxed, mediainfo still displays the two lines indicating that there is a discrepancy.

[richeerichhh]

What muxing program are you using? MKVToolnix/MKVMerge? What kind of file container are you encoding too. I would suggest encoding to a MKV file and see if that helps. Also don't set the DAR while muxing, let the x264 launcher set it for you.

[LoRd_MuldeR]

however this is what I got when I ran the launcher with the "--console" parameter.

This means that Avisynth triggered a crash (exception) while the version number is queried.

According to your screenshot, however, you are using the official 2.58 release of Avisynth, which is the latest "official" release and the version that I use too.

Are you 100% sure there aren't several Avisynth DLL's floating around on your system? AvsP might actaully be using a different DLL...

It might also be worth a try to clean-up your Avisynth plug-in's directory. Wouldn't be the first time that some buggy/deprecated plug-in DLL causes trouble!

[richeerichhh]

Thanks for your help. Where about should I go looking for AviSynth.dll? System32 folder? Or what .dll file am I looking for specifically? I'll also clean out my AviSynth plug-in folder to see if that helps any.

The thing that gets me though, is that your original "Simple x264 Launcher" work without errors with my current configuration. Any idea why that would be?

[LoRd_MuldeR]

Thanks for your help. Where about should I go looking for AviSynth.dll? System32 folder? Or what .dll file am I looking for specifically? I'll also clean out my AviSynth plug-in folder to see if that helps any.

The DLL search order on Windows is as follows:

The directory from which the application loaded, i.e. where the EXE file is located.
The system directory. Use the GetSystemDirectory() function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory() function to get the path of this directory.
The current directory. This can be anything depending on how the application was launched!
The directories that are listed in the PATH environment variable.


The application will load the first "Avisynth.dll" that it will find in any of these directories - in DLL search order.

The thing that gets me though, is that your original "Simple x264 Launcher" work without errors with my current configuration. Any idea why that would be?

The old version didn't even check for Avisynth :rolleyes:

[richeerichhh]

BTW I'm running Win 7 Ultimate x64.

Okay so I uninstalled and reinstalled AviSynth. It is currently in its default settings. Even the plugin directory contains only the default plugins. While it was installing I snapped a screenshot of where it put it's dll's.
http://dl.dropbox.com/u/1045428/AVSinstall.PNG
Looks correct right? Except where did it really install those two files? Here!
http://dl.dropbox.com/u/1045428/here.it.is.PNG

Strangely enough, I used those two functions you suggested to find my System Directory. This is what it gave me.

http://dl.dropbox.com/u/1045428/getsysinfo.PNG
The information makes sense to me. It also makes sense that SysWOW64 would be the 64 bit System directory. However I didn't or wouldn't install AviSynth 64 bit. Another weird thing is that if I move the two files (avisynth.dll & devil.dll) to the System32 directory AviSynth fails to work on both AvsP and your original version of "A Simple x264 Launcher" I tried to move one and both files to the "Simple x264 Launcher" directory but it failed to load.

http://dl.dropbox.com/u/1045428/doesnt.wrk.in.dir.PNG

So if the launcher is searching the System Directory which in my case is System32, but AviSynth installed the .dll's in SysWOW64 then it would make sense that it couldn't find them. However it still doesn't make sense that it doesn't find AviSynth when I put both .dll's into the launcher's .exe directory, especially if it searches it first.

I also tried putting the .dlls in the 16-bit directory which is C:\Windows\System, but that didn't work, or did placing them in any of the folders in my PATH. Thoughts?

[LoRd_MuldeR]

The information makes sense to me. It also makes sense that SysWOW64 would be the 64 bit System directory. However I didn't or wouldn't install AviSynth 64 bit. Another weird thing is that if I move the two files (avisynth.dll & devil.dll) to the System32 directory AviSynth fails to work on both AvsP and your original version of "A Simple x264 Launcher" I tried to move one and both files to the "Simple x264 Launcher" directory but it failed to load.

On 64-Bit Windows the "system" directory for 32-Bit applications (the one that would be relevant here) is located at:
C:\Windows\Syswow64

At the same time the "system" directory for 64-Bit applications is located at:
C:\Windows\System32

But to make things even more complex, a 32-Bit application will see "Syswow64" as "System32", unless File System Redirection is disabled.


Anyway, your error message means that the Avisynth DLL was loaded. It only crashed in the code that determines the version number.

That's why I though there might be different DLL's on your computer, e.g. one in the "system" folder and another one in the AvsP directory.

In that case AvsP would use its own DLL, while Simple x264 Launcher would fall back to the DLL from the "system" folder.

It was just an idea! Still you may give the Dependency Walker (http://www.dependencywalker.com/) a try, which will show you the DLL that is used. Just be sure to press F7.

I also tried putting the .dlls in the 16-bit directory which is C:\Windows\System, but that didn't work, or did placing them in any of the folders in my PATH. Thoughts?

Normally you put the Avisynth.DLL into the "System32" folder (or "Syswow64" on 64-Bit Windows) and that's it.

That's also where the installer will install the DLL.

(If the installer says it installed the DLL to "System32", this actually means "Syswow64" on 64-Bit Windows, due to the File System Redirection)

[hunter_aran]

What muxing program are you using? MKVToolnix/MKVMerge? What kind of file container are you encoding too. I would suggest encoding to a MKV file and see if that helps. Also don't set the DAR while muxing, let the x264 launcher set it for you.

I made sure there was nothing in the script to signal DAR, only --sar in the x264 options. If there is another way to set it in the program, I don't know it. If I do not set --sar and instead add it later using mp4box it does the same thing. In the past mp4box was able to overwrite any wrong aspect info in the stream so i am confised why it doesn't work now. I'll try mkv and see if it makes a difference...

I am primarily using Subler to add the aspect in the container for correct quicktime display (this was the only guaranteed way I've found to do this) and for apple devices. Subler works with other files created by Megui and Handbrake as we speak, so I don't think it's broken. Maybe it's a mediainfo problem?

[hunter_aran]

When I try creating an mkv, mediainfo reports one line, "display aspect ratio" only but when I remux to mp4 it still creates two lines. Could x264 be rounding some numbers here to create an sar that's a small percent off? That's what MeGUI was doing until I realized there was a setting for acceptable aspect error and it was at 2%. After changing to 0%, the files were perfect with the aspect ratios matching. I am at a loss still why mp4box can't correct this after the fact, since it was able to before.

The funny thing is that there is no cropping on these files, they are 640x480 so this was supposed to be easier...

Any help is appreciated. Thanks.

[laserfan]

The DLL search order on Windows is as follows:

The directory from which the application loaded, i.e. where the EXE file is located.
The system directory. Use the GetSystemDirectory() function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory() function to get the path of this directory.
The current directory. This can be anything depending on how the application was launched!
The directories that are listed in the PATH environment variable.

The application will load the first "Avisynth.dll" that it will find in any of these directories - in DLL search order.

On 64-Bit Windows the "system" directory for 32-Bit applications (the one that would be relevant here) is located at:
C:\Windows\Syswow64

At the same time the "system" directory for 64-Bit applications is located at:
C:\Windows\System32

But to make things even more complex, a 32-Bit application will see "Syswow64" as "System32", unless File System Redirection is disabled...

...Still you may give the Dependency Walker (http://www.dependencywalker.com/) a try, which will show you the DLL that is used. Just be sure to press F7.

Normally you put the Avisynth.DLL into the "System32" folder (or "Syswow64" on 64-Bit Windows) and that's it.

That's also where the installer will install the DLL.

(If the installer says it installed the DLL to "System32", this actually means "Syswow64" on 64-Bit Windows, due to the File System Redirection)

LM you are a treasure-trove of good information today. I have added the above to my "tips" file, thank you very much. :)

[dado023]

hiya,

are there any templates for download, for example template for youtube HD.....you hope you know what i mean :)

[LoRd_MuldeR]

No, there are no "pre-built" templates available for download. And you shouldn't need any!

Since x264 has added the Preset/Tuning system, configuring x264 has become straight forward. There are no "secret" options or "magic" values you need to know ;)

If at all, configuring x264 to create a BluRay-compatible stream requires some additional knowledge. But x264bluray (http://sites.google.com/site/x264bluray/) has all the info you need for that...

[dado023]

thanks for the fast response :)

since i need to upscale some videos to 1080p, i will have to use avs script, so i have done a bit googling around and found this http://goo.gl/296HY
I wonder what version of avisynth build, for this task, do you prefer on 32bit system on quadcore CPU?

[LoRd_MuldeR]

thanks for the fast response :)

since i need to upscale some videos to 1080p, i will have to use avs script, so i have done a bit googling around and found this http://goo.gl/296HY
I wonder what version of avisynth build, for this task, do you prefer on 32bit system on quadcore CPU?

There is no need to go the Avisynth route, just for resizing. It's possible to use Avisynth, for the task, of course. And the stable Avisynth v2.58 is fine.

But x264's internal resize filter should work just as well here. You can simply add "--video-filter resize:width=1280,height=720,method=spline" to the advanced options!

BTW: Why do you need to upsize at all? Upsizing some SD source video to HD resolution doesn't magically make it "HD quality" ;)

[dado023]

hey, thanks for the x264 resize info, i didn't know it was built in...now i see in wiki it even has crop :)

y, i am aware there is no gain in quality when upsizing, but i use it for youtube upload 1080p, so when youtube re-compresses it it gives more bitrate to video, at least that is what i have read in few youtube related threads....

[hunter_aran]

Just an update, I found out by trial and error that certain files are creating the aspect problem so it's nothing to do with this program or the version of x264. I don't understand why some episodes on this dvd have a par of 8:9 while others do not even though they display the same at 4:3. Might be that ITU thing which I don't completely understand yet. Kinda stupid if the dvd uses different PAR on different videos. Anyway, carry on. :rolleyes:

[r0lZ]

Hi Lord! I have exactly the same problem as richeerichhh, after a fresh install of Avisynth 2.5.8 (Dec 22, 2008).

Previously, I had two different avisynth.dll files: the one installed with the normal Avisynth installer (I don't remember the exact version number, but it was a v2.5), and another version installed by Format Factory, in its own directory. That second version was registered in my registry, and I think it was used by my scripts. Your program worked very well.

I've decided to uninstall FF and Avisynth, and re-install the latest Avisynth version, to get rid of the multiple avisynth dlls floating around. Since the new install, I have the same error message "Exception in Avisynth initialization code!". As far as I know, there is now only one avisynth.dll on my system. Could it be a bug in the dll?

BTW, can I suggest to print the path of the dll that is being checked to the console?

I'm running Win7 x64.

BTW, I have also another suggestion. Could you add a "Use input folder" checkbox near the output field? Currently, I have to change the path of the output file each time I drop an AVS script on the program's window, and it's a pain (especially when I forget to change the path and I close the window after the encoding process, as I don't know where the 264 file has been saved). Thanks in advance!

[LoRd_MuldeR]

First of all, there is no registry entry that tells applications where the Avisynth DLL is located, when using the "native" interface.

The DLL will be located (and loaded) according to the DLL search order:
http://forum.doom9.org/showpost.php?p=1572343&postcount=776

(Things would be different if we were talking about a COM/ActiveX DLL, like DirectShow filters. But that's not the case here!)

However there is a registry entry to indicate the path of the Avisynth Plugin's directory! And this one indeed might have changed on your system recently.

If Avisynth causes an unhandled exception during initialization, it means that Avisynth (or more likely one of the various Plugin DLL's!) has a bug.

Either that, or my application is calling the Avisynth DLL in an invalid way that triggers the crash. But it works fine for me. With Avisynth 2.58, on Windows 7 (x64).

Also my code to load the Avisynth DLL and check the version number (that's all I do!) was borrowed from x264's Avisynth input module ;)

I suspect it's some buggy Plugin DLL (or some DLL loaded by one of the Plugin DLL's) that causes the trouble! Certainly wouldn't be the first time...

[r0lZ]

I suspect it's some buggy Plugin DLL (or some DLL loaded by one of the Plugin DLL's) that causes the trouble! Certainly wouldn't be the first time...
Right! I've found the culprit: ffavisynth (http://avisynth.org.ru/docs/english/externalfilters/ffavisynth.htm). More precisely, if I remove ffavisynth.avsi, there is no crash any more. That script contains only:Load_Stdcall_Plugin("ffavisynth.dll")
I still don't know if it's the ffavisynth.dll that causes the crash, or the way it is loaded by the avsi, but the problem is solved. Thanks for your tips!

BTW, will you consider my suggestion to add the "Use input folder" checkbox?

[LoRd_MuldeR]

Right! I've found the culprit: ffavisynth.

Why I am not surprised? :)

BTW, will you consider my suggestion to add the "Use input folder" checkbox?

Normally the x264 Launcher will remember the last "save to" directory. I think that should work fine for most users!

But I see that it won't work if you encode from AVS files located in different directories each time and always want to save the output file in the same directory as the corresponding source.

Will consider adding an option for this purpose...

[r0lZ]

But I see that it won't work if you encode from AVS files located in different directories each time and always want to save the output file in the same directory as the corresponding source.

Will consider adding an option for this purpose...It's exactly what I am doing.

Thanks!

[LoRd_MuldeR]

r0lZ, please try with the new build.

[r0lZ]

Hum, I see no differences. What change should I test?

[LoRd_MuldeR]

Hum, I see no differences. What change should I test?

I added an option "Save output to the same folder where the source is located", which should be exactly what you requested ;)

(If you can't see that option, make sure you have downloaded build #340)

[r0lZ]

Oh, yes, sorry! I've looked for that option in the Add Job dialog. :rolleyes:
Anyway, it does exactly what I wanted. Thanks again!

[wiak]

holy monkeys you update this?, thx a million i kinda liked this one

[r0lZ]

Another suggestion: can you add an option to fall back to Avisynth 32bit when an avisynth script cannot be rendered with avisynth x64? I have sometimes several encodes in the queue. Most of them are compatible with avisynth x64, but some are not, because they use a 32bit plugin. It is a pity to have to wait for the 64bit batch to complete to launch another batch in x32 mode. (Another way to solve that problem would be to put the x64 option in the New Job dialog, to allow the user to specify it on a per script basis, but personally I think it is better to try the x64 mode anyway. However, I'm not sure you can do it, as currently, when a script fails, the avisynth error is correctly printed to the log, but the launcher concludes that the rendering was successful.)

Also, maybe I haven't looked at the right place, but after having enabled the option to save the log automatically when the job is finished, I can't find it in the destination directory. Is it a bug?

[LoRd_MuldeR]

Another suggestion: can you add an option to fall back to Avisynth 32bit when an avisynth script cannot be rendered with avisynth x64? I have sometimes several encodes in the queue. Most of them are compatible with avisynth x64, but some are not, because they use a 32bit plugin. It is a pity to have to wait for the 64bit batch to complete to launch another batch in x32 mode.

No, that's not possible. If x264 or AVS2YUV fails to open the input, e.g. because the Avisynth script failed to initialize, the GUI cannot know why it failed. In that case it's up to the user to read the error message (from the log) and correct his mistake. In theory the GUI could parse the error message and try to guess the reason for the problem. But a missing plugin will probably result in a "Script error: there is no function named Foobar" message. There are several reasons why a such error could appear. A missing plugin (or 64-Bit Avisynth being unable to load the 32-Bit plugin) is only one possibility out of many. In most cases a simple typo will be the cause of this kind of error...

Also, maybe I haven't looked at the right place, but after having enabled the option to save the log automatically when the job is finished, I can't find it in the destination directory. Is it a bug?

Should be located at:
%LOCALAPPDATA%\LoRd_MuldeR\Simple x264 Launcher\logs

[r0lZ]

No, that's not possible. If x264 or AVS2YUV fails to open the input, e.g. because the Avisynth script failed to initialize, the GUI cannot know why it failed. In that case it's up to the user to read the error message (from the log) and correct his mistake. In theory the GUI could parse the error message and try to guess the reason for the problem. But a missing plugin will probably result in a "Script error: there is no function named Foobar" message. There are several reasons why a such error could appear. A missing plugin (or 64-Bit Avisynth being unable to load the 32-Bit plugin) is only one possibility out of many. In most cases a simple typo will be the cause of this kind of error...
I understand. But I suggested that feature as an option, so that, if the x64 version fails, the program could try the x32 version anyway. Of course, that second try may fail too, but it will probably succeed if it's just a x32 plugin problem. Of course, if it fails twice, the user will have to fix the typo normally. At least, it should be possible to render most scripts. (Anyway, I test all my scripts in AvsPmod and with a player before launching the encoding.)

Should be located at:
%LOCALAPPDATA%\LoRd_MuldeR\Simple x264 Launcher\logs
Thanks!