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

[LoRd_MuldeR]

Now that doesn't make much sense at all. Whether you write the output to the STDOUT or to some "physical" file must not make any difference! :eek:

So I assume the bug in Avisynth (or more likely in one of the Avisynth plug-ins involved) is one of those nasty bugs that create "corrupted" memory and/or try to access "uninitialized" memory.

In this case, whether you actually get a crash or whether the bug remains unnoticed (which doesn't guarantee that the output will be correct !!!) is sheer luck ;)

And in this situation, small changes, even such that, at first glance, seem to be completely unrelated (like writing to a physical file or to the STDOUT), are only rolling the dice again...

At this point the only promising way to track the problem down: Compile a debug version of the "problematic" plugin and get debugging! Or, if you can't do it yourself, bother the plugin author.


Just out of curiosity: What happens if run exactly this command from the console:
"C:/ChromeDownload/x264mulder/Simple x264 Launcher v2/toolset/avs2yuv_x86.exe" E:\Encoding\LionKing3D\LionKing3D.avs - > foobar.y4m

[GZZ]

"C:/ChromeDownload/x264mulder/Simple x264 Launcher v2/toolset/avs2yuv_x86.exe" E:\Encoding\LionKing3D\LionKing3D.avs - > foobar.y4m

It then start writing a foobar.y4m file, just like if I did

"C:/ChromeDownload/x264mulder/Simple x264 Launcher v2/toolset/avs2yuv_x86.exe" E:\Encoding\LionKing3D\LionKing3D.avs "e:\Encoding\LionKing3D\avs2yuvOutput.y4m"


But the output foobar.y4m file dosnt work. I cant play it in vlc like i can with the avs2yuvOutput.y4m file. x264 dont want to load the file either, giving the error x264 [error]: could not open input file `e:\Encoding\LionKing3D\foobar.y4m'

[LoRd_MuldeR]

It then start writing a foobar.y4m file, just like if I did"C:/ChromeDownload/x264mulder/Simple x264 Launcher v2/toolset/avs2yuv_x86.exe" E:\Encoding\LionKing3D\LionKing3D.avs "e:\Encoding\LionKing3D\avs2yuvOutput.y4m"

Which only proves that using a pipe (alone) does not reliably reproduce the issue.

(That's because with the command I told you to try, you are telling Avs2YUV to write the output to STDOUT, just like when we are piping to the x264 process. Only difference is that this time the pipe will go to the CMD.EXE itself, instead of x264, and that CMD.EXE will dump all the data to a file right away. That's what the ">" operator does)


But the output foobar.y4m file dosnt work. I cant play it in vlc like i can with the avs2yuvOutput.y4m file. x264 dont want to load the file either, giving the error x264 [error]: could not open input file `e:\Encoding\LionKing3D\foobar.y4m'

Well, do the files come out at the same size? And did you compare the content, e.g. in a Hex Editor?

[GZZ]

Well, do the files come out at the same size? And did you compare the content, e.g. in a Hex Editor?

I didnt let it run til the end. The output files are huge. But I will let it run and compare the files and get back to you.

[LoRd_MuldeR]

Well, just add a "trim(0, 100)" at the end of your script for the test. Or does that make the original problem go away?

[GZZ]

Well, just add a "trim(0, 100)" at the end of your script for the test. Or does that make the original problem go away?

I added -frames 100 to the avs2yuv script and then I get 2 files which is only 2 bytes in difference.

The one with "...\foobar.y4m" output works and the other with > "...\foobar2.y4m" dosnt work. After comparing the files. It seams like a line break is inserted in the beginning of foobar2.y4m (Hex 0D 0A). #13#10 (delphi language).

Using a hex editor I can delete those 2 bytes from the beginning of the file and then both foobar2.y4m and foobar.y4m are identical when compared and both plays in vlc player.

So maybe the reason x264 is complaining is because of these 2 bytes when reading std from avs2yuv ?

[LoRd_MuldeR]

Those "wrong" bytes that slipped in most likely are one of those random "corruptions" I was talking about before.

This is one of the funny "effects" that can be caused by a bug, even if it doesn't crash the application altogether. Actually you are lucky if it does crash, because then you at least know that there is a bug somewhere.

...rather then getting corrupted output, which you might not even notice until it's too late ;)


Just for the notes: With a "working" Avisynth script (just FFmpegSoure and no fancy stuff), I get two 100% bit-identical output files:
F:\DeLpHi\x264_x64_launcher\res\toolset>avs2yuv_x86.exe D:\x264\sample.avs test1.y4m
D:\x264\sample.avs: 704x576, 60 fps, 500 frames

F:\DeLpHi\x264_x64_launcher\res\toolset>avs2yuv_x86.exe D:\x264\sample.avs - > test2.y4m
D:\x264\sample.avs: 704x576, 60 fps, 500 frames

F:\DeLpHi\x264_x64_launcher\res\toolset>sha1.exe < test1.y4m
f3a8b521d94d4a3bd0a71d03642a94adea6dc443

F:\DeLpHi\x264_x64_launcher\res\toolset>sha1.exe < test2.y4m
f3a8b521d94d4a3bd0a71d03642a94adea6dc443

F:\DeLpHi\x264_x64_launcher\res\toolset>

[GZZ]

is it something that can be fixed, like deleting the first 2 bytes before writing data to stdout ?

[LoRd_MuldeR]

If it can be fixed, then not by trying to workaround haphazard symptoms of the bug, but by tracking down the cause of the bug - and repairing it.

[samtroy]

@LoRd_MuldeR:

May I ask what exact settings + parameters you personally use for encoding a normal 2h 1080p movie?

Cheers, S.

[LoRd_MuldeR]

@LoRd_MuldeR:

May I ask what exact settings + parameters you personally use for encoding a normal 2h 1080p movie?

Cheers, S.

--crf 20 --preset veryslow

[samtroy]

--crf 20 --preset veryslow

OK.. and no extra parameters at all? Like --level 4.1 for compatability reasons maybe?

[LoRd_MuldeR]

OK.. and no extra parameters at all? Like --level 4.1 for compatability reasons maybe?

Nope.

[egrimisu]

how to use 10bit encode? i select high10 profile but stil x264 x86 8 bit is used.

[LoRd_MuldeR]

8-Bit vs. 10-Bit is a compile-time decision. It's nothing you can change at runtime via option ;)

The "--profile" option of x264 only restricts your other option to (at most) the selected H.264 Profile. It does not enforce the selected Profile, if a lower Profile is sufficient for your file.

In other words: Using 10-Bit H.264 implies the "High 10" Profile, but selecting the "High 10" Profile (alone) does NOT trigger or imply 10-Bit encoding!

You can enable "10-Bit encoding" in the preferences dialog. This will use the 10-Bit x264 binary for subsequent encodes, instead of the 8-Bit x264 binary that is used by default.

[egrimisu]

8-Bit vs. 10-Bit is a compile-time decision. It's nothing you can change at runtime via option ;)

The "--profile" option of x264 only restricts your other option to (at most) the selected H.264 Profile. It does not enforce the selected Profile, if a lower Profile is sufficient for your file.

In other words: Using 10-Bit H.264 implies the "High 10" Profile, but selecting the "High 10" Profile (alone) does NOT trigger or imply 10-Bit encoding!

You can enable "10-Bit encoding" in the preferences dialog. This will use the 10-Bit x264 binary for subsequent encodes, instead of the 8-Bit x264 binary that is used by default.

Fair enough, still what to enter in dialog there nothing in the help related to 10bit?

[LoRd_MuldeR]

Fair enough, still what to enter in dialog there nothing in the help related to 10bit?

:confused:

If you ask how to enable 10-Bit encoding in Simple x264 Launcher, just go to "File" -> "Preferences" and enable "Use 10-Bit version of x264".

It will show a warning. Read that warning and, if you have understood the consequences, click "Continue".

[egrimisu]

:confused:

If you ask how to enable 10-Bit encoding in Simple x264 Launcher, just go to "File" -> "Preferences" and enable "Use 10-Bit version of x264".

It will show a warning. Read that warning and, if you have understood the consequences, click "Continue".

Iddiot me, thanks, nice that you had implemented queue ;)

[darknoob]

Just wanted to say thank you Lord for making the new version with batch process, so much easier now queuing up test encodes. Also now I can see my RF after first pass, good stuff mate!

[nibus]

After upgrading to the newest version I'm getting constant crashes from avs2yuv:


Problem signature:
Problem Event Name: APPCRASH
Application Name: avs2yuv_x86.exe
Application Version: 0.0.0.0
Application Timestamp: 4e78e870
Fault Module Name: avisynth.DLL
Fault Module Version: 2.6.0.3
Fault Module Timestamp: 4f7b27cf
Exception Code: c0000005
Exception Offset: 00066e34
OS Version: 6.1.7601.2.1.0.256.4
Locale ID: 1033
Additional Information 1: 9bb2
Additional Information 2: 9bb2af9eb5b5e3c312278cd2f1aa9dbe
Additional Information 3: 9af5
Additional Information 4: 9af54169938890e76fe9ec03370a170d


This is on a Sandy Bridge 2600K, 8gb Ram, running at 4.0ghz. I didn't have any problems with the previous version. However it appears to run fine on my non-overclocked i7 930.

Is x264_x64.2012-07-22.exe the previous build? I will try it with that version and make sure it still runs stable.

[LoRd_MuldeR]

All previous versions can be found here:
http://code.google.com/p/mulder/downloads/list?can=1&q=simple&sort=-uploaded&colspec=Filename+Summary+Type+Uploaded+Size+DownloadCount

But Avs2YUV neither is my work nor did I change the included Avs2YUV binaries lately...

I've always been using the latest version from here:
http://komisar.gin.by/tools/avs2yuv/

What you are experiencing is probably a crash in Avisynth or (more likely) in one of the Avisynth plug-in's involved.

Does the very same Avisynth script open in VirtualDub and play through all the way to the end?

[nibus]

What you are experiencing is probably a crash in Avisynth or (more likely) in one of the Avisynth plug-in's involved.

Does the very same Avisynth script open in VirtualDub and play through all the way to the end?

It appears to play fine in VirtualDub, though I haven't had time to run through the entire video.

After reverting to x264_x64.2012-07-22.exe I still have the crash, though without the avs2yuv notice. The application just reports that x264 is not responding. Each time it appears to be in a different portion of the video.

The only other thing that has changed was a small mvtools2.dll update (http://forum.doom9.org/showthread.php?p=1386559#post1386559). That is probably the cause of the crash, though it's strange that it only happens on my newer i7 box.

I'm trying the encode again without filters; will report back.

[LoRd_MuldeR]

That's the problem with software testing: The fact that you didn't get a crash, doesn't prove the absence of bugs ;)

Depending on the nature of the bug, it may only be triggered under specific conditions. The conditions may even not be deterministic, which is especially true for "race conditions" errors!

And with memory corruption bugs, like "buffer overruns" or "dangling pointers", it's sheer luck whether you get an instant crash or "only" corrupted output (or no effect at all).

[nibus]

The encode runs fine without filters so it's probably an issue with mvtools2 or MT. Thanks for your help Mulder.

[GZZ]

in preferences I have checked "Automatically save output to log file when job has finished" - Where can I locate this log file, its not among my movie source files and I have tried look in the temp folder where the .ffindex file are saved. Can you give me a hint on where to find it ?

[r0lZ]

C:\Users\<YOU>\AppData\Local\LoRd_MuldeR\Simple x264 Launcher\logs\

[RockTheBass]

Hey!

Thaks for this great x264 encoder software! :) I love it!
I want to ask something. I downloaded the newest version (v2.06), I installed and I checked the version of x264 encoders:
toolset\x264_8bit_x64.exe

x264 core:128 r2216 198a7ea

I downloaded the newest x64 8bit version EXE from there: http://x264.nl/ and I checked this version also:

x264 core:128 r2216 198a7ea

The versions are same, but I noticed there are difference between the file sizes.
\Simple x264 Launcher v2\toolset\x264_8bit_x64.exe 9,034,240 Bytes

x264.nl_x64_8bit\x264.exe 10,607,616 Bytes.

Can someone explain why is difference these file sizes? I thought, x264 Simple Launcher uses the original x264 files. May I should replace the original files that located in \toolset\ folder with the www.x264.nl files?

Thank you! :)

[LoRd_MuldeR]

There is no such thing as "original" x264 files. x264 is OpenSource software and released as source code (http://en.wikipedia.org/wiki/Source_code). There are no "official" binaries (http://en.wikipedia.org/wiki/Software_build) ;)

Everybody can make his/her own builds. And the resulting file size will depend on many things, like the compiler version that was used, the compiler settings that were used, the libraries included in the build (or not), the versions of the included libraries, the debug symbols being stripped (or not), and so on. The binaries might even have been compressed with an "exe packer" like UPX...

I didn't compile x264 myself this time. The binaries I included in the Simple x264 Launcher download are those provided by Komisar (http://komisar.gin.by/) and the differences to JEEB's binaries (http://x264.nl/) should be negligible.

[RockTheBass]

Ohh, I understand. Thank you very much for quick answer! Please keep up this great software, and continue your work as you always do :) :cool:


There is no such thing as "original" x264 files. x264 is OpenSource software and released as source code (http://en.wikipedia.org/wiki/Source_code). There are no "official" binaries (http://en.wikipedia.org/wiki/Software_build) ;)

Everybody can make his/her own builds. And the resulting file size will depend on many things, like the compiler version that was used, the compiler settings that were used, the libraries included in the build (or not), the versions of the included libraries, the debug symbols being stripped (or not), and so on. The binaries might even have been compressed with an "exe packer" like UPX...

I didn't compile x264 myself this time. The binaries I included in the Simple x264 Launcher download are those provided by Komisar (http://komisar.gin.by/) and the differences to JEEB's binaries (http://x264.nl/) should be negligible.

[VideoFanatic]

I've installed the latest version of your program (2.06) on a new Windows 7 64-bit installation. I can't drag and avs files into your program. Even if I open the job window and drag it into the source file box, it doesn't work. The only way I can open a file is to manually select the file in the directory.

On my Vista 32-bit PC I had the 22nd July 2012 version and I could drag and drop an AVS file into main window and it would automatically populate the job source file.

[LoRd_MuldeR]

Are you sure you really have the latest version?

Qt v4.8.3 broke Drag&Drop on the Window platform. After I knew about that issue, I reverted to Qt v4.8.2 and uploaded a new build.

So please make sure you got build #360 and you also updated all the DLL's, i.e. do not copy over the EXE file only!

(BTW: The Drag&Drop issue is already fixed for the next Qt version and I will update to Qt 4.8.4 as soon as it becomes available)

[VideoFanatic]

I downloaded your program from here (http://forum.doom9.org/showpost.php?p=1234822&postcount=1) under "Download new version with queuing support". That page gave me this: x264_x64.2012-09-26.exe

I've no idea what you're talking about in regards to updating all the DLL's. I just double-clicked on the exe file to install the program as I did in the past. What else do I need to do?

I loaded the About page in your program and it says it's version 2.06.360. If the drag and drop feature is supposed to work in the 2012-09-26 version then how do I make it work because it doesn't work for me!

[LoRd_MuldeR]

Build #360 (https://mulder.googlecode.com/files/x264_x64.2012-09-26.exe) (2012-09-26) is the latest version, indeed.

That version ships with Qt 4.8.2, which you can check in the "About" dialog too. There is nothing special you need to do to get Drag&Drop working, it is supposed to work "out of the box".

For me it definitely does work using build #360 (2012-09-26). I'm using Windows 7 and never tested Vista, but that really shouldn't make a difference :confused:

Anyway, if there ware some problem with Drag&Drop already in Qt 4.8.2, then there isn't much I can do. The problem would have to be reported to the Qt bugtracker, so the Qt guys can fix it.

BTW: You are not running Simple x264 Launcher with "elevated" rights, do you? Drag&Drop from a none-elevated application (e.g. Explorer) into an elevated one doesn't work...

BTW2: You might want to give my LameXP program a try. It is being built with Qt 4.8.3, but incorporates a Qt patch that is supposed to fix the Drag&Drop issue introduced in Qt 4.8.3.

[VideoFanatic]

My apologies. It was Explorer++ that was causing the problem. That program doesn't seem to allow drag and drop.

[VideoFanatic]

The program is portable, nothing is installed, it just copies the folders onto your PC. To uninstall it, just delete the "installation" folder.

[LoRd_MuldeR]

Hello,

nice app!

Some suggestions/requests though:

(1) You can easily add "--level" to the advanced options, if you really need to enforce a specific Level. Most of the time it is recommended to simply let x264 set the most suitable Level for your footage.

(2) You can easily update the x264 binaries. Unless the new x264 build broke compatibility with the command-line interface (which usually doesn't happen), the GUI doesn't need to be updated. I upload new packages from time to time, but I can't create a new package for each x264 revision number.

(3) What about allowing additional "--tune" entries in the advanced options? I don't really like adding more controls to the configurations dialog. Especially because those two tunes that you might want to add additionally are not useful and not recommended for the great majority of the users (both, "zerolatency" and "fastdecode", strongly cripple the encoder settings for a highly specific purpose).

(4) Avisynth is considered a prerequisite for Simple x264 Launcher. After all this app was primarily written to use 32-Bit Avisynth with 64-Bit x264. So I won't remove the warning message, because a missing Avisynth means that a major feature of Simple x264 Launcher will be broken. But I'm planning to add VapourSynth support soon ;)

(5) holygamer said it all. The "installer" is pretty much an SFX archive. To uninstall, use Ctrl+Del on the install folder :)

[Kisa_AG]

(2) You can easily update the x264 binaries.

Hello LoRd_MuldeR.

Thanks for this GREAT tool!

Please can you describe which x264 binaries is possible to use? If I remember correctly, in the past you've recommend Generic binaries from Komisar (komisar.gin.by). But Komisar don't update binaries since x264 r2216.
Is it possible to use generic binaries from x264.nl? Is there any the difference?
Thanks!

[kypec]

Please can you describe which x264 binaries is possible to use? If I remember correctly, in the past you've recommend Generic binaries from Komisar (komisar.gin.by). But Komisar don't update binaries since x264 r2216.
Is it possible to use generic binaries from x264.nl? Is there any the difference?
Thanks!
I believe replacing x264 binaries with JEEB's builds from x264.nl should be just fine. I did it in the past too when komisar's builds were "delayed" ;)

[LoRd_MuldeR]

You can pick whatever builds you prefer, as long as they aren't broken and have been build with all the libs you need - which should apply to all builds from the "usual" sources ;)

Yet another source is the MeGUI update server:
http://megui.org/auto/

[VideoFanatic]

In VideoRedo I move through my video 1 second at a time. MPEG2s are fast to navigate but h264 is slow and at worst it's realtime.

See the 2nd post here: http://www.videoredo.net/msgBoard/showthread.php?t=29834


He basically says to use shorter GOPs and try to set it to insert an I/IDR frame every second or so.

How do I do that in Simple x264 Launcher?

[LoRd_MuldeR]

MPEG-2 is much(!) simpler than H.264, so decoding MPEG-2 is much faster than H.264. Not very surprising ;)

Furthermore, the longer your GOP's are, the slower seeking (navigation) will be. That's because decoding can only start at an key-frame. If you seek to a certain frame number and that frame doesn't happen to be a key-frame, then decoding has to start at the key-frame that precedes the desired frame. Then all the frames, from the key-frame up to the desired frame, have to be decoded (maybe skipping the B-Frames). Consequently, the larger the distance between the key-frames is, the more frames will have to be decoded on each seek operation (in average case). And thus a larger key-frame distance results in "slower" seeking. That's pretty much the same with MPEG-2 and H.264.

So if you want to ensure that seeking is "fast", you will have to limit the key-frame (IDR-Frame, in H.264) distance. Simply add "--keyint x" to the advanced options and replace x with the desired number. Default is 250. If you want one key-frame per second, you would set "--keyint 25", given that your footage is 25 fps. Needless to mention that setting a shorter key-frame distance will hurt compression efficiency...

[VideoFanatic]

Setting it to 50 makes navigation much faster but slower than MPEG2. I only lose 72 MB per 1 hour 30 minute file instead of 300 MB if I set it to 0! When you fill a Bluray disc that's only a loss of 504 MB compared to 2.1 GB. Zero gives navigation speeds as fast as MPEG2.

Just wondering if other programs have fast navigation by default (low keyframe distance) such as handbrake because I haven't heard of other people having slow navigation after using other programs to encode to h264?

I take it that the keyframe distance setting is the only way to speed up navigation?

[LoRd_MuldeR]

Setting it to 50 makes navigation much faster but slower than MPEG2.

...as expected ;)

If you make a video compression scheme more complex (H.264), it cannot decode as fast as its much simpler predecessor (MPEG-2). Better compression costs more CPU cycles. As always in life, nothing's for free.

I only lose 72 MB per 1 hour 30 minute file instead of 300 MB if I set it to 0! When you fill a Bluray disc that's only a loss of 504 MB compared to 2.1 GB. Zero gives navigation speeds as fast as MPEG2.

If you compare file sizes, I guess you encoded in CRF mode. As has been explained about one million times in this forum, the same CRF value does not give the same quality, as soon as you change other options - such as the key frame interval (or anything else). So you are comparing apples to bananas, i.e. your numbers don't say anything.

BTW: Setting "--keyint 0" means unrestricted, which means the key-frame interval will be infinite. That's the worst case for seeking! The encoder will still put key-frames at scene changes though, which mitigates things a bit.

Oups, "--keyint 0" means auto, not infinite. If you wanted an infinite key-frame interval (which you obviously don't want here!), you'd have to use "--keyint infinite".

Just wondering if other programs have fast navigation by default (low keyframe distance) such as handbrake because I haven't heard of other people having slow navigation after using other programs to encode to h264?

Pretty much ALL applications that you can download/use (legally) for free and that output H.264 video are based on x264. And x264 uses 250 as the default key-frame distance. Of course front-ends like Handbrake or whatever might set their own defaults, overwriting x264's defaults. Using lower key-frame distance by default would mean faster seeking but worse compression. As for Simple x264 Launcher, it doesn't mess with x264's defaults, so you get what x264's uses by default (and what the select Preset/Tuning applies!) unless you overwrite the setting explicitly...

I take it that the keyframe distance setting is the only way to speed up navigation?

Yes! That and how navigation is implemented in the application which navigates through the H.264 stream. DGIndexNV, for example, creates an index file first. Creating the index file takes some time, indeed, because the whole file needs to parsed once. But once you have the index, seeking is fast and accurate (at least as fast as it can possibly be). Other apps might seek through the H.264 more or less "blindly" until the desired frame is found. This doesn't need an index file, but obviously will be much slower (in average case).

[docholliday]

How can i use it,cant use comand line,,,I want use 2pass and High L4.1 and Audio AC3 448 5.1,Can u help me?

[LoRd_MuldeR]

How can i use it,cant use comand line,,,I want use 2pass and High L4.1 and Audio AC3 448 5.1,Can u help me?

No need to scream!

If you want 2-Pass rate-control and "High" Profile, then I would suggest to select those from the GUI ;)

http://img24.imageshack.us/img24/3603/clipboard05p.png

Level 4.1 can be enforced by adding --level 4.1 to the advanced options. And, as x264 is a video encoder, it doesn't encode audio.

[docholliday]

Tnx mate,but how can i resize for example i want 720p Resize,How can i do that ?

[LoRd_MuldeR]

You can (a) use an Avisynth script as input and then invoke one of the various Avisynth Resize-Filters (http://avisynth.org/mediawiki/Resize) in your script or (b) use x264's internal/built-in resize filter.

For the latter, simply add --video-filter resize:width=1280,height=720,method=lanczos to the advanced options. For details have a look here (http://mewiki.project357.com/wiki/X264_Settings#video-filter).

[VideoFanatic]

I sometimes get this error code: WARNING: Avisynth process exited with error code: 1. Usually I get a popup saying what plugin is at fault but these last few times I didn't. How can I find out what plugin is at fault?

It's weird, I got that message yet the encoding says it was 100% completed yet it obviously isn't as it only encoded a part of the file.

[LoRd_MuldeR]

This usually indicates Avisynth (or more likely one of the Avisynth plug-in's involved) has crashed!

You may try to open the identical script in VirtualDub and then try to play all the way through the end of the clip...

[VideoFanatic]

I don't really use VirtualDub. Do I just drag the script into VirtualDub then click on the play button? So if there's an error will VirtualDub give a popup showing what plugin is at fault?