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

[LoRd_MuldeR]

In toolset/common, netc.exe is detected as a virus by many antivirus programs (VirusTotal score (https://www.virustotal.com/en/file/e8fbec25db4f9d95b5e8f41cca51a4b32be8674a4dea7a45b6f7aeb22dbc38db/analysis/): 10/56). It's probably a false positive, but who know? What is its usage, and can we safely add it to the white list of our antivirus?

Netcat (https://en.wikipedia.org/wiki/Netcat) (aka "nc") is a standard networking tool. Pretty much every Unix/Linux-based OS comes with this standard tool included. Windows doesn't, so a Windows port of Netcat is included with my software.

It's used by my auto-update feature, for fast connectivity tests. It only runs when you let auto-updater check for new updates. Don't worry: Netcat is a 100% legitimate. All you have to do is getting rid of buggy "anti-virus" software.

Recommended reading:
http://robert.ocallahan.org/2017/01/disable-your-antivirus-software-except.html

[r0lZ]

OK, thanks. But note that it's not a single antivirus that is "buggy". As I wrote, 10 different antivirus consider the exe as dangerous, and it's too much to suspect a simple false positive. However, most of them flag it simply as suspect (or Potentially Unwanted Application) rather than as a real virus, probably because the exe can be used to communicate private information over the internet. Of course, I don't suspect your program to use it that way, but it remains that the exe might really be potentially dangerous if it is used by a malicious app, and that it will certainly be quarantined by the anti-virus of many users. Some peoples may be scared and refuse to use your program any more. Perhaps you should consider to use another solution, or integrate the version check within the program itself rather than using an external exe?

Anyway, on my side, I'll simply add it to the white list of my antivirus.

[LoRd_MuldeR]

OK, thanks. But note that it's not a single antivirus that is "buggy". As I wrote, 10 different antivirus consider the exe as dangerous, and it's too much to suspect a simple false positive. However, most of them flag it simply as suspect (or Potentially Unwanted Application) rather than as a real virus, probably because the exe can be used to communicate private information over the internet.

There is a very fundamental difference between the following types of "detections":
Known malware, i.e. a specific well-known software that was strictly written to cause harm and that has been identified undoubtedly
Something that looks somewhat similar to a known malware, i.e. heuristic detection
Software that is 100% legitimate and that is used for 100% legitimate purposes most of the time, but may also be used for causing harm

The big problem with so-called "anti-virus" software is that they do not clearly distinguish these cases!

In case (1) the "anti-virus" software should trigger an alert, yes. In case (2) the "anti-virus" software may still show a warning to the user, but it must be made very clear (not hidden somewhere in the details!) that such heuristic detections are only a very vague assumption and, most likely, the file is 100% legitimate. And, in case (3), the "anti-virus" software should not show anything to the user, with default settings. That's because, if you think about it, pretty much any software belongs into that category! Show me one (non-trivial) legitimate software that couldn't be used to cause harm, in one way or another, if you really want to. It doesn't exist. So, what software they call "potentially dangerous", or not, is a completely arbitrary decision... Microsoft Word, for example, is by far more "potentially dangerous" than NC will every be - c.f. macro virus (https://en.wikipedia.org/wiki/Macro_virus). But, of course, they wouldn't dare to block Microsoft Word, because Microsoft has an army of lawyers...

(Tomorrow they'll try to tell you that x264 itself is "dangerous" program that needs to be blocked, because terrorists may use it to encode their propaganda videos!)


Of course, I don't suspect your program to use it that way, but it remains that the exe might really be potentially dangerous if it is used by a malicious app, and that it will certainly be quarantined by the anti-virus of many users. Some peoples may be scared and refuse to use your program any more. Perhaps you should consider to use another solution, or integrate the version check within the program itself rather than using an external exe?

At the point where a 100% legitimate application needs to be changed to workaround the shortcomings of the so-called "anti-virus" software (that is supposed to protect us from malware) things are going seriously wrong! So, nope. It's not going to happen that I change a single line of code in order to workaround "buggy" anti-virus software. It would be a pointless effort anyway, because there's like a zillion of "anti-virus" products out there and you can't hack around all of them.

(BTW: There is an important philosophy in software designed that says: Don't stuff too many features into a single program; write programs that do one thing, and do it properly; write programs that cooperate! So, if there already exists a well-established tool that does exactly what you need - as is the case here - it is always much preferable to just call that tool, rather than trying to re-invent the wheel)

[r0lZ]

I agree, especially on the difficulty to identify clearly if an exe is a real virus or just a PUA. And it's the major problem with VirusTotal, since when an antivirus doesn't give the green light, VirusTotal counts it as positive, even if it's only a PUA. But the fact remains that a score of 10/56 is scaring for many users, and that may have a bad effect on the reputation of your program. It's why I suggested to integrate the version check within the main exe, but of course it's not mandatory. I hope that your program will not be affected.

Anyway, thanks for your long reply.

[AbeSimpson]

Just recently my x264 logs are now showing timestamps when I save them. I haven't had this before and don't remember turning them on. How can I shut them off?

[LoRd_MuldeR]

Just recently my x264 logs are now showing timestamps when I save them. I haven't had this before and don't remember turning them on. How can I shut them off?

Yes, timestamps are now saved in the logfile for each line. This has been implemented a while ago. It is actually very common that entries in an application log are timestamped, so that you can later trace back what happened when.

There currently is no option to turn it off. And I'm not sure I want (yet another) option for this. If you don't care about the timestamps, you can just ignore them, right?

(it seems you are the first person to even notice ^^)

[AbeSimpson]

Yes, timestamps are now saved in the logfile for each line. This has been implemented a while ago. It is actually very common that entries in an application log are timestamped, so that you can later trace back what happened when.

There currently is no option to turn it off. And I'm not sure I want (yet another) option for this. If you don't care about the timestamps, you can just ignore them, right?

(it seems you are the first person to even notice ^^)

I hadn't done any encoding for a while so I guess they must have shown up since my last one. Thanks for clearing that up.

[rus929]

Gud day LoRd_MuldeR:

First of all, I would like to thank you for this wonderful software that you've shared to us.

Today, I am glad to share my experience that I've discovered by using this software in all of my video encodes.

For the past days, I am using Simple x264/x265 Launcher with Avisynth script in resizing my videos (from 1080p to 720p) using Avisynth's spline64 resizer. I am not into lanczos cause for me it creates more banding on my encodes. By the way my encode settings are 2pass @1500kbps and I am using the medium preset with the following changes: level 4.1, deblock -1:-1, ref=4, subme=8, umh, merange=64, rc-lookahead=96, b-adapt=2 and no p-fast skip. The encodes are good (if not best), but I think it is a little smooth because I think of the spline method.

What I've discovered lately is that, when I put directly the video into the job without using Avisynth script and add a --video-filter resize:1280,XXX as additional command, the resulting encode was superb using the same settings as above. The encode is a little crispier but not so much of having banding effects created. Also, I observe that it saves about an hour of time in first-pass and also save more minutes for the second-pass (since only the x264 executable is only running and no Avs2yuv is running).

Now, what I am wondering is that, is there any possibility that x264 can add an "add-border" function in its video filters cause as of this moment I can add only borders to my encodes using Avisynth's add border command. If you are wondering why, re-encoding videos (i.e. cropped movies) into full 1920x1080p in just single or dual-layer dvd discs and mux them as AVCHD format is beautiful to watch since blu-ray players will play the video in full-1080p/24-frames signal unlike the cropped videos which is converted to 60-frames.

More power and thanks once again.

[sneaker_ger]

The vanilla x264 does not have a border adding filter and I haven't seen any other builds with such filter. By default it uses bicubic resizing. Have you tried AviSynth's BicubicResize() filter for comparison?

[rus929]

The vanilla x264 does not have a border adding filter and I haven't seen any other builds with such filter. By default it uses bicubic resizing. Have you tried AviSynth's BicubicResize() filter for comparison?

Have not tried Avisynth's bicubic. I will try, but my concern now is the time factor.

About the add-border, of my knowledge, there is one application - uncropmkv, but this is an old tool, and i think it uses avisynths too. If x264 can do this internally I think we can save time to encode videos.

I am wondering if LorR_MuldeR can channel this concern to the developers of x264 since he has authority in using their binaries.

Anyway, thanks for the reply.

[LoRd_MuldeR]

Have not tried Avisynth's bicubic. I will try, but my concern now is the time factor.

Piping the input from Avisynth into x264 certainly has some overhead. But, compared to the CPU time spent for the actual encoding, this should usually be negligible. It can have more effect in the (fast) first pass, though.

Anyway, it is quite possible that the Spline64 or Lanczos resizer you have been using in Avisynth produces "sharper" image than the Bicubic resizer used by x264 by default, which, in turn, could effect x264 encoding speed.



I am wondering if LorR_MuldeR can channel this concern to the developers of x264 since he has authority in using their binaries.

:confused:

No, nothing like that. If you want to get in touch with x264 developers, your best bet is the mailing list, I suppose:
https://mailman.videolan.org/listinfo/x264-devel

[rus929]

[QUOTE=LoRd_MuldeR;1798618]Piping the input from Avisynth into x264 certainly has some overhead. But, compared to the CPU time spent for the actual encoding, this should usually be negligible. It can have more effect in the (fast) first pass, though.

Right, since upon examining the running executable on the first pass, x264 and avs2yuv share almost 50-50 on the CPU, unlike without piping it from the Avisynth which x264 has it all. On the final encoding though, still piping it through Avisynth, avs2yuv get about 10-20% of CPU.

I tried, BicubicResize of Avisynth, to my eye, launching the mkv file directly to Simple x264/x265 Launcher has sharper image than that of Avisynth (not that it has great difference though, but on the time it finish to encode, more than an hour).

Btw, I am wondering why using the 64bit version of x264, when launching the file through Avisynth it uses the 32bit version of avs2yuv, but it has a 64bit version on the same folder?

Anyway, thanks for the info of reaching x264 developer.

Gud day, and more power.

[LoRd_MuldeR]

Right, since upon examining the running executable on the first pass, x264 and avs2yuv share almost 50-50 on the CPU, unlike without piping it from the Avisynth which x264 has it all. On the final encoding though, still piping it through Avisynth, avs2yuv get about 10-20% of CPU.

This is not really surprising. The "faster" your encoding settings are (and "fast first-pass" uses very fast settings!) the more CPU time is spent for I/O processing - relative to the time spent for the actual encoding.

You have the same effect - more or less - when decoding the input directly with x264. But, in that case, you don't have two separate processes, so you can't "see" the effect easily.

(Still I would assume that I/O overhead with Avs2YUV is a bit higher)


Btw, I am wondering why using the 64bit version of x264, when launching the file through Avisynth it uses the 32bit version of avs2yuv, but it has a 64bit version on the same folder?

...because "official" Avisynth does not have a 64-Bit version yet. And 64-Bit x264 can not load a 32-Bit Avisynth DLL. So we use 32-Bit Avs2YUV (with 32-Bit Avisynth) and then pipe the input into 64-Bit x264.

There is an "unofficial" 64-Bit fork of Avisynth, but it is considered deprecated now. Avisynth+, which is yet another "unofficial" fork of Avisyth, also does have a 64-Bit version available. But not everybody is using Avisynth+.

And even if you use a "native" 64-Bit Avisyth, you would still need to have all of your plug-ins as "native" 64-Bit versions too. Many "legacy" plug-ins are 32-Bit only, though.

(BTW: There is an option in the preferences to use 64-Bit Avisynth input, provided that a 64-Bit Avisynth is installed)

[aegisofrime]

Hey Lord Mulder!

Been using this nifty little tool without too much trouble for a while now, all of a sudden this starts happening:

http://i.imgur.com/vmWBS3O.png

I'm on Windows 10. I have tried downloading your installer and reinstalling, but the same thing happens. :confused:

[LoRd_MuldeR]

Hey Lord Mulder!

Been using this nifty little tool without too much trouble for a while now, all of a sudden this starts happening:

http://i.imgur.com/vmWBS3O.png

I'm on Windows 10. I have tried downloading your installer and reinstalling, but the same thing happens. :confused:

That's weird. This error would indicate that "imageformats\qsvg4.dll" is missing, or could not be loaded. But after a re-install this would have (or at least: should have) been fixed :confused:

Make sure that there is a "qsvg4.dll" in the sub-folder "imageformats" immediately below the directory where your "x264_launcher.exe" resides.

Also make sure that "QtSvg4.dll" and "QtXml4.dll" are in the same directory where your "x264_launcher.exe" resides. If either of those is missing from application directory, the "qsvg4.dll" plug-in cannot be loaded.

Finally, make sure you don't have any files mixed from older program versions or, more critically, older compiler versions. Actually, I suggest to completely delete the install directory, then make a "clean" re-install.

If you launch "x264_launcher.exe" with extra option "--console", anything noteworthy in the log?

[CrosstownTraffic]

Starting with version v2.69 the file "netc.exe" has been included in the /toolset/common directory. As of this post, this file shows up on 10 of 61 potential scans (https://www.virustotal.com/en/file/e8fbec25db4f9d95b5e8f41cca51a4b32be8674a4dea7a45b6f7aeb22dbc38db/analysis/) via VirusTotal. Symantec correctly and best identifies this as netcat (https://en.wikipedia.org/wiki/Netcat) which is a fairly popular program for managing connections.

The release notes for v2.69 (https://github.com/lordmulder/Simple-x264-Launcher/releases/tag/v2.69) suggest that the addition of netc.exe was related to auto-update functionality.

Note: Occasionally your Antivirus program may mistakenly detect "malware" (virus, trojan, worm, etc.) in some of the files here.
This is called a "false-positive" and the files are actually innocent (clean). It's a failure in your specific Antivirus software.
In case you encounter such problems, go to http://www.virustotal.com/ and check the file again with multiple Antivirus engines!
And take care with results like "suspicious", "generic" or "packed". Those are *not* real hits, they are just wild speculation...

Could this please be updated to include exactly what file(s) show up like this, and some technical explanation for why this is so? I have tons of software that manages to automatically update (including some open source software!) without using something like netcat, so I am wondering why this was chosen. Thank you very much for all of your tireless work on this software over the years.

EDIT: Look at the other executables that create or otherwise interact with this version of netcat on VirusTotal. All of them are trojans, backdoors, and other terrible software. I tried quarantining/deleting netc.exe but x264/x265 Launcher refuses to run without it -- why is this so? Who cares if it can check for recent updates or not on run?

[Rodger]

That's weird. This error would indicate that "imageformats\qsvg4.dll" is missing, or could not be loaded. But after a re-install this would have (or at least: should have) been fixed :confused:

Make sure that there is a "qsvg4.dll" in the sub-folder "imageformats" immediately below the directory where your "x264_launcher.exe" resides.

Also make sure that "QtSvg4.dll" and "QtXml4.dll" are in the same directory where your "x264_launcher.exe" resides. If either of those is missing from application directory, the "qsvg4.dll" plug-in cannot be loaded.

Finally, make sure you don't have any files mixed from older program versions or, more critically, older compiler versions. Actually, I suggest to completely delete the install directory, then make a "clean" re-install.

If you launch "x264_launcher.exe" with extra option "--console", anything noteworthy in the log?

SAME error here....never had any problems...didn´t use it for a while...did absolutely nothing else than just updating it....
BAM....always this error.

tried the sugguested console run se pic attached...


/EDIT: Tried fresh install in a totally different directory....NOPE! Same error...this release does NOT work.
Windows10 pro 64bit?!

[r0lZ]

I confirm that there is a big problem with the latest version (2017-01-07), after a fresh install of the portable version from the ZIP archive. But I have a different error message:
---------------------------
x264_launcher_portable.exe - Application Error
---------------------------
The application was unable to start correctly (0xc0000005). Click OK to close the application.
---------------------------
OK
---------------------------

[LoRd_MuldeR]

Sorry for late replay, just returned from business trip.

Starting with version v2.69 the file "netc.exe" has been included in the /toolset/common directory. As of this post, this file shows up on 10 of 61 potential scans (https://www.virustotal.com/en/file/e8fbec25db4f9d95b5e8f41cca51a4b32be8674a4dea7a45b6f7aeb22dbc38db/analysis/) via VirusTotal. Symantec correctly and best identifies this as netcat (https://en.wikipedia.org/wiki/Netcat) which is a fairly popular program for managing connections.

Yes, NC is a widely-used standard network tool, available on pretty much any Unix/Linux system "out of the box". My software ships with a Win32 port of NC, because Windows doesn't ship with NC included.

I'm well aware that some braindead so-called "anti-virus" software is defames NC as "potentially dangerous" software :rolleyes:

If you want this fixed, then please call your anti-virus vendor and ask them to hire some developers that actually have a clue what they are doing. Be reassured that I don't have any plans to stop using/including NC in my software.

See also:
* https://forum.doom9.org/showpost.php?p=1795630&postcount=1652
* https://forum.doom9.org/showpost.php?p=1795879&postcount=1654

Recommended reading:
http://robert.ocallahan.org/2017/01/disable-your-antivirus-software-except.html

I confirm that there is a big problem with the latest version (2017-01-07), after a fresh install of the portable version from the ZIP archive. But I have a different error message:
---------------------------
x264_launcher_portable.exe - Application Error
---------------------------
The application was unable to start correctly (0xc0000005). Click OK to close the application.
---------------------------
OK
---------------------------

Hmm, have you tried this?
https://forum.doom9.org/showpost.php?p=1793404&postcount=1642

Possible UPX issue. I got this error once on one of my machines, but it was gone after a reboot and I couldn't reproduce it since then...

[Rodger]

Works!
No more "qsvg4.dll" error.
Application starts now just like it used to.

Thx@mulder

[LoRd_MuldeR]

Works!
No more "qsvg4.dll" error.
Application starts now just like it used to.

Thx@mulder

Okay, thanks for confirming. I will probably push a new build on the update servers soon. Not tonight though.

[CrosstownTraffic]

Yes, NC is a widely-used standard network tool, available on pretty much any Unix/Linux system "out of the box". My software ships with a Win32 port of NC, because Windows doesn't ship with NC included.

I'm well aware that some braindead so-called "anti-virus" software is defames NC as "potentially dangerous" software :rolleyes:


Again, thanks for taking the time to write this software & respond to my forum post.
Your post lacks technical explanation for why you need to use netcat.
Your post last technical explanation about why your software can't launch without it.
Again, tons of other software manages to auto-update without using such a vastly large network library for such a simple task.


Your software, your dance. But the author of software that includes something like this telling me "oh they just don't know what they're talking about" without any technical explanation just isn't good enough for me to potentially violate security.

Again, I implore you to list the files that trigger anti-virus scanners regardless of your personal opinions of them and post a technical explanation for why you must use this software.

[CrosstownTraffic]

Yes, NC is a widely-used standard network tool, available on pretty much any Unix/Linux system "out of the box". My software ships with a Win32 port of NC, because Windows doesn't ship with NC included.

Yes, as I indicated I know what netcat is -- what I'm seeking is a technical explanation of why you chose to include it in your software, and why your software is unable to run without it.

I'm well aware that some braindead so-called "anti-virus" software is defames NC as "potentially dangerous" software :rolleyes:

If you want this fixed, then please call your anti-virus vendor and ask them to hire some developers that actually have a clue what they are doing. Be reassured that I don't have any plans to stop using/including NC in my software.


You have no idea how confidence-destroying that reads. "Those quacks at the Food and Drug Administration tell us that drug is unsafe, but what do they know?" It turns out they know a lot, actually, which is why users trust them to protect their machines. They certainly more than 99.9% of users out there, which is why they exist in the first place.

A couple links to other posts involving your rant against anti-virus software because you've chosen to include such an expansive suite of network tools just for auto-update functionality doesn't help here. Not to mention in the one link you say it's for "fast connectivity tests" -- for gods sake, is that really necessary for the daily function of your software?

I implore you to seek another, accepted method of auto-updating your software or at least provide an option to run the software without auto-update functionality on initial run. You mention disabling auto-update but you can't do that unless you run the software, and to do that you must allow netcat to run.

Regardless of your protestations against anti-virus software vendors, I don't understand why you require netcat to run if it truly is just there to provide software updates.

Again, thanks for writing the software and taking the time to reply. I'm sure this will go absolutely nowhere and I'll move on to other software. I do hope you reconsider.

[r0lZ]

Possible UPX issue. I got this error once on one of my machines, but it was gone after a reboot and I couldn't reproduce it since then...
Strange, but true. Just tested again this morning after a fresh boot, and it works fine. I did not need to install the hotfix.
It would be nice to understand the origin of the problem. It is well known that Windows is terribly unstable, but normally it is not necessary to reboot to run a program!

[LoRd_MuldeR]

You have no idea how confidence-destroying that reads. "Those quacks at the Food and Drug Administration tell us that drug is unsafe, but what do they know?" It turns out they know a lot, actually, which is why users trust them to protect their machines. They certainly more than 99.9% of users out there, which is why they exist in the first place.

A couple links to other posts involving your rant against anti-virus software because you've chosen to include such an expansive suite of network tools just for auto-update functionality doesn't help here. Not to mention in the one link you say it's for "fast connectivity tests" -- for gods sake, is that really necessary for the daily function of your software?

I implore you to seek another, accepted method of auto-updating your software or at least provide an option to run the software without auto-update functionality on initial run. You mention disabling auto-update but you can't do that unless you run the software, and to do that you must allow netcat to run.

Regardless of your protestations against anti-virus software vendors, I don't understand why you require netcat to run if it truly is just there to provide software updates.

Again, thanks for writing the software and taking the time to reply. I'm sure this will go absolutely nowhere and I'll move on to other software. I do hope you reconsider.

And you probably have no idea how annoying it is, when you create a perfectly legitimate software (containing only 3rd-party tools each of which is perfectly legitimate too), you donate your work to the OpenSource community, and then some braindead so-called "anti-virus" company comes along and accuses your product of being or containing malware - causing unaware users to send you loads of angry email, asking why you are spreading malware!

If this was one of the projects that I'm doing for a company, I would just forward this case to our legal department. Our lawyers would do the required phone call and tomorrow the "anti-virus" company would have the problem fixed - either that or they could watch how they are sued to death. Anyway, as things are, this is just one of my "private" projects that I'm doing for fun. I don't have an army of lawyers to keep the "anti-virus" companies in their place. So, all I can do is try to educate people and tell them the facts. The day that I change a single line of my code to escape unjustified defamation committed by "anti-virus" companies is not going to happen. It would be a pointless endeavor anyway, because there is a zillion of "anti-virus" products on the market that tend to change their behavior on a daily basis, so you couldn't workaround all of them, even if you would be willing to waste your time on this - their propaganda is working well, it seems.


Strange, but true. Just tested again this morning after a fresh boot, and it works fine. I did not need to install the hotfix.
It would be nice to understand the origin of the problem. It is well known that Windows is terribly unstable, but normally it is not necessary to reboot to run a program!

I think it is related to:
Changes in 3.93 (29 Jan 2017):
* UPX has moved to GitHub - the new home page is https://upx.github.io
* fixed some win32/pe and win64/pe regressions introduced in 3.92

UPX 3.93, which I used in the TEST build, seems to have it fixed. New version will be released soon.

[LoRd_MuldeR]

Simple x264 Launcher v2.79
https://github.com/lordmulder/Simple-x264-Launcher/releases/tag/v2.79

Version 2.79 [2017-03-23]
* Updated x265 to version 2.3+22
* Fixed possible application startup error "0xc0000005"

[CrosstownTraffic]

And you probably have no idea how annoying it is, when you create a perfectly legitimate software (containing only 3rd-party tools each of which is perfectly legitimate too)

I actually do have a very good idea, except instead of anti-virus it was Microsoft and it cost my company hundreds of thousands in contracts.

you donate your work to the OpenSource community

Which I have thanked you at every point for doing, but does not excuse any of this behavior nor the attitude.

and then some braindead so-called "anti-virus" company comes along and accuses your product of being or containing malware - causing unaware users to send you loads of angry email, asking why you are spreading malware!

Did you even look at the VirusTotal report? A number of well-known, actual white hat software firms list netcat as malware! It does way, way more than you need for auto-update. Your blistering anti-anti-virus company rants aside, you've still been unable to produce a technical reason why you chose netcat for auto-update, and unable to produce a technical reason your software cannot run without the auto-update portion turned off.

If this was one of the projects that I'm doing for a company, I would just forward this case to our legal department. Our lawyers would do the required phone call and tomorrow the "anti-virus" company would have the problem fixed - either that or they could watch how they are sued to death.

The very fact that you think this would ever land in court in a "real" project tells me just how little you know about this process, and publishing actual software that isn't a side open source project.

Anyway, as things are, this is just one of my "private" projects that I'm doing for fun. I don't have an army of lawyers to keep the "anti-virus" companies in their place. So, all I can do is try to educate people and tell them the facts.

You've done nothing to "educate" me with "facts" about why you use netcat for auto-update! All you've done is rant against companies labeling netcat as malware.

The day that I change a single line of my code to escape unjustified defamation committed by "anti-virus" companies is not going to happen. It would be a pointless endeavor anyway, because there is a zillion of "anti-virus" products on the market that tend to change their behavior on a daily basis, so you couldn't workaround all of them, even if you would be willing to waste your time on this - their propaganda is working well, it seems.

You are startlingly myopic. I caution against users from using your software, and recommend they look at other applications in this subforum. Your lack of professionalism as a developer and questionable development choices should send red flags.

[LoRd_MuldeR]

Did you even look at the VirusTotal report? A number of well-known, actual white hat software firms list netcat as malware! It does way, way more than you need for auto-update. Your blistering anti-anti-virus company rants aside, you've still been unable to produce a technical reason why you chose netcat for auto-update, and unable to produce a technical reason your software cannot run without the auto-update portion turned off.

First of all, to make one thing clear: I can do whatever I want in my software. As long as I don't distribute actual malware - which of course I never did and never will do! - an anti-virus company is not entitled to judge about my work!

Heck, who do these megalomaniac people think they are? Do they think they are the "programming police", telling other developers how to write their code and how not? That's totally insane! We call such behavior "censorship"! :mad:

Secondly, I'm well aware of the VirusTotal report. Generally VirusTotal is useful, yes. Still, even if 100 out of 100 so-called "anti-virus" engines were reporting a program that every sane person knows is 100% legitimate as "potentially dangerous" (or similar oversimplified nonsense), then this would still be a wrong accusation. And, a wrong accusation doesn't become any more "true", just because it is repeated many times!

Finally, even though I'm not required (not at all!) to justify what I'm doing to any anti-virus company (or to you), the reasons I'm using NC for connectivity check is because it is faster than attempting a "real" HTTP connection via WGet.


The very fact that you think this would ever land in court in a "real" project tells me just how little you know about this process, and publishing actual software that isn't a side open source project.

Just to make it clear: I'm publishing commercial software on a regular basis. Or, more precisely, the company that pays me for developing commercial products for them, publishes the software under their brand.

And, on a regular basis, our software gets blocked by so-called "anti-virus" software - as we learn from people contacting our support. Guess what? I forward the case to the legal department, so they can do the required phone calls. And, once called by the lawyers of a "not so small" company, the anti-virus company will retreat quickly and promise to put our software on their "white-list" as soon as possible. They know why! ;)

If they continued blocking our product for no justified reason, while they are not blocking our competitor's product, this would be an illegal manipulation of the market. It would indicate they have a secret agreement with our competitor to hold our product off the market. If such case ever went to the court, it almost certainly would end up really expensive for them. That's why they always retreat quickly and the case never goes to court. Again: They know why! ;)

(But, as explained before, for the "private" projects I'm doing in my free time, I don't have any lawyers available to keep the "anti-virus" thugs in their place. Otherwise we wouldn't have this discussion)


You are startlingly myopic. I caution against users from using your software, and recommend they look at other applications in this subforum. Your lack of professionalism as a developer and questionable development choices should send red flags.

Why am I not surprised that this discussion ends up in the usual „either you change your software in the way that I want, or I'm going to spread derogative comments about your work“ blackmail attempt?

Be assured that it's not going to work. Been through that :)

[r0lZ]

the reasons I'm using NC for connectivity check is because it is faster than attempting a "real" HTTP connection via WGet.Funny that you use that reason to justify your choice, because I have never seen a program so sloooow to check for new versions. Each time I see the message telling that there is a long time since the last update check, I have to decide to either skip this one and be annoyed the next time, or accept to lose between 15 and 30 seconds and let the check happen. Personally, I use "real HTTP" to check for the updates of my programs, and it takes less than one second to complete (unless, I agree, if the site is down). It is a fact that HTTP is MUCH faster than your method (at least under Windows).

Anyway, as you wrote, there is no reason to justify yourself. But it I were you, I would be much more concerned by the fact that the current situation is scaring for many users, and may (and certainly has) a negative impact on the reputation of your software. The fact that some picky anti-virus may be culprit doesn't change that report. It's why I don't understand your will to leave things as they are. But of course, once again, you are free.

[LoRd_MuldeR]

Funny that you use that reason to justify your choice, because I have never seen a program so sloooow to check for new versions. Each time I see the message telling that there is a long time since the last update check, I have to decide to either skip this one and be annoyed the next time, or accept to lose between 15 and 30 seconds and let the check happen. Personally, I use "real HTTP" to check for the updates of my programs, and it takes less than one second to complete (unless, I agree, if the site is down). It is a fact that HTTP is MUCH faster than your method (at least under Windows).

Sorry, but it is technically impossible that establishing a full HTTP connection (as, e.g., WGet would do) can ever be faster than establishing only a TCP connection (as NC probing does).

That is because HTTP is an "application" layer protocol built-on top of the TCP "transport" layer protocol. Therefore, when establishing a HTTP connection, the first thing that happens is that a TCP connection will be established. Once that TCP connection has been established, HTTP will start sending the actual application-level payload (HTTP request header) over the established TCP connection. So, at the point where HTTP just starts doing its work, NC is already done with its job.

I don't know how you got those numbers (between 15 and 30 seconds), but for me the update check clearly takes less than ~10 seconds – and that's with my slowish DSL "home" connection! (small town, so no VDSL or FTTH)

If "your" way to update works significantly faster than "mine", it is probably because you are checking a single server. And when that server is down, then you give up (I assume). That's how I started too. But I had to learn, the hard way, that relying on a single update server is a bad idea! If the only update server breaks away (permanently) it leaves thousands of existing installations unable to update - forever. Consequently, I'm now using a bunch of update mirrors (currently 16), which greatly improves reliability. But, of course, nothing in life is for free. Providing many mirrors means that the application needs to find a "working" update mirror - which is done by probing. And NC does this way faster than, e.g., WGet.

See here:
http://muldersoft.com/temp/GVbsVBSXhCT3woAD/web_update.zip

[LoRd_MuldeR]

Funny that you use that reason to justify your choice, because I have never seen a program so sloooow to check for new versions. Each time I see the message telling that there is a long time since the last update check, I have to decide to either skip this one and be annoyed the next time, or accept to lose between 15 and 30 seconds and let the check happen. Personally, I use "real HTTP" to check for the updates of my programs, and it takes less than one second to complete (unless, I agree, if the site is down). It is a fact that HTTP is MUCH faster than your method (at least under Windows).
Sorry, but it is technically impossible that establishing a full HTTP connection (as, e.g., WGet would do) can ever be faster than establishing only a TCP connection (as NC probing does).

That is because HTTP is an "application" layer protocol built-on top of the TCP "transport" layer protocol. Therefore, when establishing a HTTP connection, the first thing that happens is that a TCP connection will be established. Once that TCP connection has been established, HTTP will start sending the actual application-level payload (HTTP request header) over the established TCP connection. So, at the point where HTTP just starts doing its work, NC is already done with its job.

I don't know how you got those numbers (between 15 and 30 seconds), but for me the update check clearly takes less than ~10 seconds – and that's with my slowish DSL "home" connection! (small town, so no VDSL or FTTH)

If "your" way to update works significantly faster than "mine", it is probably because you are checking a single server. And when that server is down, then you give up (I assume). That's how I started too. But I had to learn, the hard way, that relying on a single update server is a bad idea! If the only update server breaks away (permanently) it leaves thousands of existing installations unable to update - forever. Consequently, I'm now using a bunch of update mirrors (currently 16), which greatly improves reliability. But, of course, nothing in life is for free. Providing many mirrors means that the application needs to find a "working" update mirror - which is done by probing. And NC does this way faster than, e.g., WGet.

See here:
http://muldersoft.com/temp/GVbsVBSXhCT3woAD/web_update.zip

FWIW, I have tweaked the update checker algorithm a bit, so that it should now complete faster, most of the time:
https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2017-03-30.exe/download

Now never takes longer than ~3 seconds for me. This has been achieved by reducing the initial connection timeouts. So, if the first chosen mirror happens to be "slow", it will now timeout quickly, so that another (hopefully more responsive) mirror can be tested within a narrow time frame. The timeouts will be increased, successively, if mirrors continue to fail. That is required to deal with sluggish Internet connections...

[Atak_Snajpera]

Alternatively You can hide this "slowness" using background thread. When you run app extra thread should also check for updates. If updates are available some baloon notification could pop-up or maybe some flashing icon somewhere.

Regarding automatic updates I'm using different method in RipBot264. Instead of using 16 mirrors I'm relying on just single URL. However If specified address in .ini file is dead then Updater is using DuckDuckGo to find new location. Works well as long as DuckDuckGo is on-line ;)

[LoRd_MuldeR]

Simple x264 Launcher v2.80
https://github.com/lordmulder/Simple-x264-Launcher/releases/tag/v2.80

Version 2.80 [2017-04-01]
* Another attempt to fix application startup error "0xc0000005"
* Some tweaks to speed-up the update checker

[Sparktank]

Thanks a lot!

I'm new to x265, for testing.
So I find this quick and easy to start up.

Much easier than other bloated GUI's that try cater to so many other uses.

[hasenscharte]

@Lord Mulder: Awesome tool! Using the x64 tool versions is now easy as pie :thanks:

Anyway, could there be an option to have the log file saved to the source directory?

[LoRd_MuldeR]

Anyway, could there be an option to have the log file saved to the source directory?

There already is an option, in the "preferences" dialog, to have the log saved automatically, but logs will currently always be saved to:
%LOCALAPPDATA%\LoRd_MuldeR\Simple x264 Launcher\logs

Of course it would not be too difficult to make the logging directory configurable, or even have an option to write the log to the same directory where the output file is located. But I'm not sure I want to have yet another option for this.

(Writing the log to the same directory where the source file is located would be problematic, as there is no guarantee that this directory is "writable")

[hasenscharte]

as there is no guarantee that this directory is "writable"
Maybe then to the destination directory?

[LoRd_MuldeR]

Maybe then to the destination directory?

Yeah, quite possible. We could simply save the log to "<output_path>.log", for example. But I don't want yet another option for this. Maybe I'll change it completely.

[LoRd_MuldeR]

New TEST build:
https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2017-04-15.exe/download

* Updated x265 to version 2.3+32
* Updated NVEncC to version 3.07
* Save log files to the same directory as the output file

[docholliday]

Add option for 2pass method to see output file size.

[LoRd_MuldeR]

Add option for 2pass method to see output file size.

Uh? https://forums.yoworld.com/images/smilies/dizzy.png

[docholliday]

Uh? https://forums.yoworld.com/images/smilies/dizzy.png

2pass methode allows the user to specify a specific target file size but, i can not see this option in simple x264.

[LoRd_MuldeR]

2pass methode allows the user to specify a specific target file size but, i can not see this option in simple x264.

Nope, 2-Pass mode allows for specifying the desired target average bitrate.

2-Pass mode is enabled by setting the "--pass [1|2]" option in conjunction with the "--bitrate" option. See here for details:
https://manpages.debian.org/jessie/x264/x264.1.en.html

Example usage:

Two-pass with a bitrate of 1000kbps:

x264 --pass 1 --bitrate 1000 -o <output> <input>
x264 --pass 2 --bitrate 1000 -o <output> <input>


The target file size is defined by "duration_in_seconds × target_average_bitrate". So, if we knew the exact duration of the clip, we could compute the average bitrate that yields the desired file size.

However, we do not know the duration of the clip by the time that the job is created (i.e. appended to the queue) ;)

[LoRd_MuldeR]

Simple x264 Launcher v2.81
https://github.com/lordmulder/Simple-x264-Launcher/releases/tag/v2.81

Version 2.81 [2017-05-06]
* Updated x265 to version 2.4+6
* Updated NVEncC to version 3.07
* Save log files to the same directory as the output file

[LoRd_MuldeR]

Just because it fits so nicely into the whole "anti-virus" discussion:

Widely used so-called "anti-virus" products (Sophos, Kaspersky, Cisco) have been found to block the "kill-switch" domain that the WannaCry malware (you probably have heard about it in the news) is trying to contact before it kills itself. In other words: While the malware would normally have killed itself already, because the "kill-switch" domain is in existence now, the so-called "anti-virus" software made sure that malware remains active by preventing connections to that domain.

https://blog.fefe.de/?ts=a7e81647

So, not only is the "snake oil" not going to save you, in this case it can make things a whole lot worse, even for other users... (this not the first example, of course, but a particularly striking one)

[LoRd_MuldeR]

Simple x264 Launcher v2.82
https://github.com/lordmulder/Simple-x264-Launcher/releases/tag/v2.82

Version 2.82 [2017-05-26]
* Updated x264 to revision 2829
* Updated x265 to version 2.4+22

[LoRd_MuldeR]

Simple x264 Launcher v2.83
https://github.com/lordmulder/Simple-x264-Launcher/releases/tag/v2.83

Version 2.83 [2017-06-11]
* Updated x264 to revision 2833
* Updated x265 to version 2.4+36

[iSeries]

Is there a way for --output nul for the first of a two pass encode?

[LoRd_MuldeR]

Is there a way for --output nul for the first of a two pass encode?

Not at the moment. What would be the rationale? Do you think writing the first-pass output file to disk has any noteworthy speed effect?

[iSeries]

No speed effect, but surely less writes to the hard drive is better?

Also, more of a general x264 question. Its been a while since I've done any encoding but I remember from some time ago that when using ffms2 having to explicitly state --fps and --force-cfr in the command line as ffms2 fairly often got it wrong. Is this still the case?