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

[LoRd_MuldeR]

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

Version 2.74 [2016-07-18]
* Updated x265 to version 2.0+2

[almosely]

Hi there,

a few minutes ago I updated Simple x264 Launcher and started a .avs-x264-encoding. Something is working wrong. The first issue is: I chose CRF 18.4 but in the joblist is stated "CRF@18". The job details is displaying the correct value, "--crf 18.4". The second issue is: I got insane quantizers listed in the logfile (I-frames Avg-QP=26.55, P-frames Avg-QP=30.35, B-frames Avg-QP=31.93). Both worked fine with the non-updated version before (I don't remember, which version that was, maybe something from april 2016). When I analyze the encoded file with AVInaptic, I get different, more realistic quantizers (I-slices avg DRF=13.91, P-sclices avg DRF=17.61, B-slices avg DRF=19.06). I know that AVInaptic normally differs from the Simple x264 Launchers logfile, but it has never been that much.

- edit -

the version before the update was: Simple x264 Launcher (Build #1026), built 2016-04-29

now it is: Simple x264 Launcher (Build #1038), built 2016-07-18

- edit -

now I downloaded the older version (2016-04-29) and just installed it over the newer one. Do I need to completely uninstall Simple x264 Launcher before or is this working okay?

- edit -

okay, I re-encoded the same test-vid with the downgraded launcher and got the following values:

- "CRF@18.4" (in the joblist)
- I-frames avg QP=14.83
- P-frames avg QP=18.54
- B-frames avg QP=20.04

AVInaptic tells me:

- I-slices avg DRF= 14.03
- P-slices avg DRF=17.71
- B-slices avg DRF=19.07

That sounds more familiar to me.

[Minister]

L_M - There doesn't seem a means to do a manual 2nd pass with previously created stats with Simple x264. I wonder if you'd consider adding the option?

In my current case I'm working with 30 videos, each of which took about 30 minutes to create the first pass stats, and I need to recode them a 2nd time. For the moment I'll just use the CLI to x264 directly (rather than spend another 15 hours recreating the first passes just so I can work with Simple x264 again), but if you thought you could add those manual pass options in rate control, that would be very helpful.

[LoRd_MuldeR]

Hi there,

a few minutes ago I updated Simple x264 Launcher and started a .avs-x264-encoding. Something is working wrong. The first issue is: I chose CRF 18.4 but in the joblist is stated "CRF@18". The job details is displaying the correct value, "--crf 18.4". The second issue is: I got insane quantizers listed in the logfile (I-frames Avg-QP=26.55, P-frames Avg-QP=30.35, B-frames Avg-QP=31.93). Both worked fine with the non-updated version before (I don't remember, which version that was, maybe something from april 2016). When I analyze the encoded file with AVInaptic, I get different, more realistic quantizers (I-slices avg DRF=13.91, P-sclices avg DRF=17.61, B-slices avg DRF=19.06). I know that AVInaptic normally differs from the Simple x264 Launchers logfile, but it has never been that much.

The CRF value displayed in the job name is a rounded value - for the sake of simplicity. So this is not necessarily the exact CRF value that you specified and that will be passed to x264.

I'm pretty sure that, if you look at the actual x264 command-line (in your log), you will realize that the "correct" CRF value has been passed to x264.

Also note: In CRF mode, the QP values are allowed to fluctuate as needed. The x264 developers decided to make the CRF value live on the same scale as the QP values, but that was a completely arbitrary decision! Internally, x264 will multiply the value that you passed via --crf parameter with some "magic" number in order to compute the actual constant "rate factor" which will be used for encoding. That "magic" number has been tuned so that using --crf x roughly results in an average QP of x. Again, this was an arbitrary decision. And the tuning was done with a specific set of source clips. Consequentiality, you can not expect that --crf x will result in an average QP of exactly x. It may depend a lot on your particular source video!

In a quick test with "--crf 18.4" and "medium" preset, I got this result:
x264 [info]: frame I:401 Avg QP:14.87 size: 35850
x264 [info]: frame P:7835 Avg QP:17.73 size: 13307
x264 [info]: frame B:19384 Avg QP:19.72 size: 5328

[LoRd_MuldeR]

L_M - There doesn't seem a means to do a manual 2nd pass with previously created stats with Simple x264. I wonder if you'd consider adding the option?

Yes, re-using an existing stats file is not currently possible. Simple x264 Launcher automates the whole 2-Pass process for you. Currently I have no plans to change that, sorry.

[Minister]

Yes, re-using an existing stats file is not currently possible. Simple x264 Launcher automates the whole 2-Pass process for you. Currently I have no plans to change that, sorry.

That's ok. I appreciate your responding, and for all the great work you've done with this application. Thanks.

[LoRd_MuldeR]

Here is a new TEST version:
https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher-TEST.2016-08-29.exe/download

x265 and NVEncC updated to latest versions.

[almosely]

Thanks for your reply, Lord_Mulder,

I did know all that before ... And I showed you the difference between your latest version (working wrong) and the older version of your launcher (working right) - but I think, you did not read that. And I told you, that I see the correct crf-value in the logfile, but not in the joblist ... And I showed you too, that I know, that a p-frames Quantizer of 17.xx is completely normal for a crf 18.4 encoding, the same as a p-frame Quantizer with a value of 19.xx would be too - but a value about 30.xx is not right at all (with the actual version of your launcher), especially when the value is about 17.xx, when I encode the same video with the same crf-value with the older version of your launcher.

Either your launcher is working wrong or the used x264-version, in case of the listed, insane quantizers (they are avg quantizers, not peaks).

And, I liked it more, as the crf-value was not rounded. I often encode the same video (5% compression-test) a few times, to find out the crf value I want. A quick look into the joblist, with the correct crf value instead of a rounded one, was a lot more convenient for me.

So, I am still using the "outdated" april-version of your launcher and will not update again, till this is fixed.

[LoRd_MuldeR]

There is nothing to be fixed ;)

As long as Simple x264 Launcher is passing the "correct" CRF value to x264.exe on the command-line – and your confirmed yourself that it does – there is no problem on the Simple x264 Launcher side. The CRF value in the job list is irrelevant.

Furthermore: As far as I can tell, there is no problem on the x264 side either. As explained before, CRF mode does not guarantee that a CRF value of x will result in an average QP of x. CRF mode does not even guarantee that a CRF value of x will result in an average QP close to x. This may be the case for a specific set of "reference" source clips, but it is not guaranteed for all source clips. For your specific source clip it may not be the case at all!

It was a completely arbitrary decision of the x264 developers to make CRF values live on the same scale as QP values! This is just for convenience. They could have decided to make the CRF value live on a 0.0 to 1.0 scale just as well...

(If you still think x264 is doing anything wrong here, you have to bother the x264 developers. But you will probably get the same answer)

[almosely]

Of course I still think theres a problem, but it seems to be within x264. As I said, I encoded the same video with the same parameters, once with your april-version, another time with the newest one. And I got almost twice as high quantizers with your newest one. So, there has to be a problem, but inside x264, as you guessed.

The rounded crf-value in your joblist is not irrelevant TO ME. It would help me, if it would still be the full parameter. As it would help me, if I could see, whether the automatic shutdown is active or not, without going into the prefs before - as I mentioned a few months ago. But, of course, both is YOUR decision and I have to live with that.

Thanks again, anyway, for this nice tool.

[LoRd_MuldeR]

Of course I still think theres a problem, but it seems to be within x264. As I said, I encoded the same video with the same parameters, once with your april-version, another time with the newest one. And I got almost twice as high quantizers with your newest one. So, there has to be a problem, but inside x264, as you guessed.

The meaning of the CRF values has changed many times in the history of x264. Therefore you cannot expect that a specific CRF value still has the same meaning in the "new" that it had in the "old" version.

Also, how do you know the "new" version is performing worse than the "old" version? Did you actually compare the resulting files visually? Or how did you come to the conclusion that the "new" version has a problem?

(Of course you can only compare file of the same file size, otherwise you are comparing apples and oranges. Thus, if necessary, adjust the CRF value so that both versions produce a file of the same size)

[almosely]

I noticed a little variance in resulting quantizers for crf-encondings (listed in the logfiles of x264) over the years and different x264-versions, but never that much (from 18.xx to 30.xx). Mostly I try to get a value of around 19.0 for the average p-frames of my encodings. I did a lot of testing on my smartphone, pc, stand-alone and lcd-tv and found, that this is a very good quality-filesize-relation for me. Sometimes I need a 16.xx CRF-value to achieve that, sometimes CRF 22.xx is enough. If x264 has changed that behaviour that much, for what p-frame-quantizers should I aim now - 30, 34, 27 ... or should I use a CRF-value around 8 or something? I am used to rely on that values. Furthermore, every enconding-guide (Brother Johns ...) I ever read relies on the resulting quantizers (with CRF too) as a quality-scale and proposes something between 18-20 for good encodings. Therefore I downgraded to the older version of your launcher with the old x264-version, to still know what I am doing.

I knew that the "new" version is working wrong (or at least very different), because I updated to the newest version, did run a 5%-compression-test and got 30.xx values for the avg p-frame-quantizers in the logfile of x264 (with a CRF-value of 18.4). Then I downgraded your launcher (without deinstalling before), did the same compression-test again and got 18.xx values for the p-frames (of the same file with the same enconding-parameters). I did not compare visually neither on other ways than looking into the x264-logfiles.

-edit-

I just compared the two logfiles of these compression-tests and found, that the "new" one (with the 30.xx p-frame-quantizers) started a 10-bit-depth-encoding and the "old" one a 8-bit-depth-encoding. Perhaps that explaines the difference? But I just updated to your newest launcher, did run the test, downgraded and did run the test and never adjusted the value for the bit-depth, so maybe the standard-values of your old and new launcher-version have changed?

[LoRd_MuldeR]

I just compared the two logfiles of these compression-tests and found, that the "new" one (with the 30.xx p-frame-quantizers) started a 10-bit-depth-encoding and the "old" one a 8-bit-depth-encoding. Perhaps that explaines the difference? But I just updated to your newest launcher, did run the test, downgraded and did run the test and never adjusted the value for the bit-depth, so maybe the standard-values of your old and new launcher-version have changed?

Of course, 8-Bit vs. 10-Bit makes a significant difference. They don't even use the same QP scale, which means you can't really compare those QP values.

When creating the job, did you select "8-Bit" or "10-Bit" encoder variant? I just did a quick test and Simple x264 Launcher seems to run the "correct" encoder, as selected by the user in job creating dialog.

[almosely]

That is the question. I think, I did not select/adjust anything else than the crf-value. I just updated, draged the .avs-file in and started the encoding. I assumed, that every parameter would be the same as before the update. I think, thats what happened. I did not even think about changing the bit-depth. But I will update again and watch out for the bit-depth-parameter (the standard-value in the gui after the update) and try some encodings with the new launcher version. Sadly I do not have the former test-video to repeat everything exactly, but I will test with another video.

[almosely]

So, I just updated your launcher, made a screenshot before and after that and figured out, that the standard-value for the bit-depth has changed after the update, from 8 bit to 10 bit. That's it. And I tested a little bit more. If I change "encoder", "architecture", "variant", "mode", "quantizer/crf", "preset", "tuning" and "profile" and load a saved template after that, everything is reconfigered like I saved it in the template, but not the bit-depth - this parameter is back on 10-bit. I never use 10-bit to encode. I always encode in 8-bit.

-edit-

I tested a little bit more. It seems that the bit-depth was not been saved in the templates before the update, because now I changed the bit-depth, saved a template, loaded an old template (bit-depth changed to 10 - your new standard value for this parameter), loaded the new template (bit-depth changed to 8). Okay, I will update my templates, then it should be okay.

And ... is there any possibility that your updater will not stress my firewall and fingers next time with around 10-15 clicks to allow your updater to work and complete? I have to click that much every time, because you use random and temporary names for every step in this job.

[LoRd_MuldeR]

I tested a little bit more. It seems that the bit-depth was not been saved in the templates before the update, because now I changed the bit-depth, saved a template, loaded an old template (bit-depth changed to 10 - your new standard value for this parameter), loaded the new template (bit-depth changed to 8). Okay, I will update my templates, then it should be okay.

And ... is there any possibility that your updater will not stress my firewall and fingers next time with around 10-15 clicks to allow your updater to work and complete? I have to click that much every time, because you use random and temporary names for every step in this job.

In the current version, just as in all previous versions, the "8-Bit" encoder variant is the default, not "10-Bit". You can easily confirm that by removing or renaming your "templates.ini", which will reset everything to the defaults.

If you look in "templates.ini" more closely, you will see that the "8-Bit" and "10-Bit" encoder variants are now saved correctly as "encoder_variant=0" and "encoder_variant=1", respectively. Also these values are loaded correctly from the INI file.

However, there has been an "issue" in some older versions, which caused the "encoder_variant" index to not be zero-based (but one-based). So, "8-Bit" had actually been saved as "encoder_variant=1". And "10-Bit" as "encoder_variant=2".

(This is a bit unfortunate, if you still have some "old" templates, yes. But it can not be fixed retrospectively. And, fixing up your "old" templates once, should be fairly trivial to do)

[LoRd_MuldeR]

Here is a new TEST version:
https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher-TEST.2016-09-15.exe/download

x265 updated to latest version.

[LoRd_MuldeR]

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

Version 2.75 [2016-09-25]
* Updated build environment to Visual Studio 2015 with Update-3
* Updated x264 to revision 2721
* Updated x265 to version 2.0+54
* Updated NVEncC to version 2.11

[LoRd_MuldeR]

Here is a new TEST version:
https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher-TEST.2016-10-13.exe/download

WHAT'S NEW:
* Updated x265 to version 2.1+20
* Detection of "portable" VapourSynth (see README for details!)
* Detection of "portable" Avisynth (see README for details!)

[LoRd_MuldeR]

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

Version 2.76 [2016-10-21]
* Updated x265 to version 2.1+25
* Updated NVEncC to version 3.01
* Detection of "portable" VapourSynth (see README for details!)
* Detection of "portable" Avisynth (see README for details!)

[LoRd_MuldeR]

New TEST build with latest x265 encoder:
https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher-TEST.2016-11-06.exe/download

[r0lZ]

Is it possible to use the x264 launcher with VapourSynth installed in portable mode?

I haven't found a way to tell it where VapourSynth and Python are located, and the launcher tells me that VapourSynth is NOT currently installed. I understand that it cannot find it automatically since by definition the portable installation is not tied to the system, but IMO it should be possible to specify the directory somehow, with the preferences dialog or by editing a configuration file. Is it currently possible? If not, can you add that possibility?

[BakaProxy]

LoRd_MuldeR would it be possible to add a feature in which you can set a custom deadlock value or even fully disable it? Because some scripts have long initialization times which exceed the default 60 seconds, which makes batch encoding quite irritating to handle within your GUI.

Thanks in advance.

[LoRd_MuldeR]

LoRd_MuldeR would it be possible to add a feature in which you can set a custom deadlock value or even fully disable it? Because some scripts have long initialization times which exceed the default 60 seconds, which makes batch encoding quite irritating to handle within your GUI.

Thanks in advance.

Please see here:
https://github.com/lordmulder/Simple-x264-Launcher/blob/master/README.md#command-line-syntax

;)

[BakaProxy]

Please see here:
https://github.com/lordmulder/Simple-x264-Launcher/blob/master/README.md#command-line-syntax

;)
Oh it's actually 5 minutes. Then I can rest assured for now, but I would definitely appreciate it if you can set a custom deadlock value. It would save me some time and effort and I'm sure I'm not the only one who could use this, but that's your decision.

Verstuurd vanaf mijn SM-A500FU met Tapatalk

[r0lZ]

Is it possible to use the x264 launcher with VapourSynth installed in portable mode?
Since I haven't received an answer to that question, should I assume that it's impossible?

[LoRd_MuldeR]

Is it possible to use the x264 launcher with VapourSynth installed in portable mode?
Since I haven't received an answer to that question, should I assume that it's impossible?

Sorry, missed that for some reason.

It should be possible now, with the very latest version. But you have to follow instructions exactly:
https://github.com/lordmulder/Simple-x264-Launcher/blob/master/README.md#vapoursynth

[r0lZ]

OK, thanks! I have already "installed" VS Portable elsewhere, but I suppose that I can do an hard or soft link to duplicate it within the extra folder. But IMO, it would be better to have the possibility to specify the path manually, perhaps with a command line argument, or within the preferences.ini file. Just a suggestion.

[EDIT] Using an hard link (called Junction in Windows terminology) works fine, but a soft link doesn't work. So, the directories with the Simple Launcher and with VapourSynth must be on the same physical partition. An additional reason to provide a way to specify the path. ;-)

[LoRd_MuldeR]

New TEST build available:
https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher-TEST.2016-12-09.exe/download

Updated x264 and x265 to the latest versions.

[LoRd_MuldeR]

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

Version 2.77 [2016-12-11]
* Updated x265 to version 2.1+69
* Updated x264 to revision 2744
* Updated NVEncC to version 3.02

[olex99]

I have a weird feature request.

I currently do my encoding on a computer that I only have access to on the weekend. I'm usually doing Home Videos for archiving so I only care about quality, I use QTGMC as my de-interlacer and because of this my encodes average around 0.3fps and can take up for 3 weeks to complete.

I use Simple x264 Launcher as my GUI and it works well, I usually have up to 6 Job running at a time as I only use the Single Threaded Avisynth to do the work.

What I would like is a way to see the status of the encode remotely since I only have access to actually be in front of the encoding computer on the weekend. What I do have access to though is the file system. Is there a chance you can add a feature to allow a log file to be written with the status of the encode while the encode is happening? I could then check this file at any time to see where the encodes are up to. I believe it can be done by piping the output to a text file but I don't have anyway in the software to add that command line from what I can see.

[LoRd_MuldeR]

I have a weird feature request.

I currently do my encoding on a computer that I only have access to on the weekend. I'm usually doing Home Videos for archiving so I only care about quality, I use QTGMC as my de-interlacer and because of this my encodes average around 0.3fps and can take up for 3 weeks to complete.

I use Simple x264 Launcher as my GUI and it works well, I usually have up to 6 Job running at a time as I only use the Single Threaded Avisynth to do the work.

What I would like is a way to see the status of the encode remotely since I only have access to actually be in front of the encoding computer on the weekend. What I do have access to though is the file system. Is there a chance you can add a feature to allow a log file to be written with the status of the encode while the encode is happening? I could then check this file at any time to see where the encodes are up to. I believe it can be done by piping the output to a text file but I don't have anyway in the software to add that command line from what I can see.

Ever heard of VNC (http://www.uvnc.com/downloads/ultravnc.html)? ;)

Really, instead of messing up one tool with too many (unrelated) features, you should use the right tool for each job - and combine them as needed (cf. Unix philosophy (https://en.wikipedia.org/wiki/Unix_philosophy#Origin)).

Having said that, there already is a feature in Simple x264 Launcher to automatically generate a log file for each encoding task.

But this won't be very helpful for you, I guess, because the log file is saved when the encoding task has been completed. The log file is not written (or updated) in "realtime" while the encoding is still running.

And even if the log file was updated in "realtime", it still wouldn't allow you to see the current progress by looking at the file. That's because:

(a) progress lines are not written to the log, because it would completely flood the log. Except for warnings that might pop up throughout the encode, most long lines are either created right at the beginning or at the very end;

(b) even if we wrote all output the the log file in an "unfiltered" way, including progress lines, you still couldn't see progress in "realtime", because the file I/O buffering of the operating system will delay file writes.

[fijam]

I've been using Simple Launcher for over a year now, thanks for that great piece of software.

I have three small pet peeves:
1. it's not possible to edit the paths and filenames in source/output directly (the field is not editable, you need to click [...] and edit it there, then click Save again)

2. there is no way to disable custom parameter validation, e.g. I'd often like to use tmod's --aq2-strength and Simple Launcher will not let me do that ("custom parameters are invalid and will be discarded")

3. my templates quickly grow into a rat's nest, some kind of system with categories for templates (DVD/HDTV/BD, or SD/720p/1080p for example, preferably user-editable) would be nice

[Pulp Catalyst]

what de-interlacing capability does this have?

also, how difficult would it be to add (NNEDI3 + YadifMod) combination? (there are AviSynth and Vapour-synth plugins available for both).

[LoRd_MuldeR]

1. it's not possible to edit the paths and filenames in source/output directly (the field is not editable, you need to click [...] and edit it there, then click Save again)

Yes, that's intentional. If free editing was allowed, the user could enter arbitrary invalid or non-existing paths, so we would have to do (rather complex) validation.

2. there is no way to disable custom parameter validation, e.g. I'd often like to use tmod's --aq2-strength and Simple Launcher will not let me do that ("custom parameters are invalid and will be discarded")

Parameter validation can't be disabled for good reason.

However, there was (yet another) small issue in the parameter validation code. Should be fixed in latest TEST version:
https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher-TEST.2017-01-07.exe/download

3. my templates quickly grow into a rat's nest, some kind of system with categories for templates (DVD/HDTV/BD, or SD/720p/1080p for example, preferably user-editable) would be nice

I will need to think about a solution...

what de-interlacing capability does this have?

also, how difficult would it be to add (NNEDI3 + YadifMod) combination? (there are AviSynth and Vapour-synth plugins available for both).

Yes, those are Avisynth/VapourSynth filters. Using them with Simple x264/x265 Launcher is no different than with any other application that supports Avisynth/VapourSynth input.

If you want to use those deinterlacing filters without frame-serving your source from Avisynth or VapourSynth: Nope, that's not possible ;)

[LoRd_MuldeR]

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

Version 2.78 [2017-01-07]
* Updated x265 to version 2.2+22
* Updated Avs2YUV to version 0.24 (BugMaster's mod 5)
* Added new option to save pending jobs *without* confirmation
* Some fixes to parameter validation code

[masagrator]

I don't know why, but Launcher cannot detect my Avisynth 2.6. Is there a way to write a path to Avisynth? I tried with AviSynth+ and works only with 64-bit plugins... Launcher and avisynth are installed on system partition. I tried reinstalling and nothing. Windows 10 64-bit Education. I checked 2 last versions of Launcher. I tried with "portable version", changing name and copying standalone avisynth to Launcher folder. And still the same.

[LoRd_MuldeR]

I don't know why, but Launcher cannot detect my Avisynth 2.6. Is there a way to write a path to Avisynth? I tried with AviSynth+ and works only with 64-bit plugins... Launcher and avisynth are installed on system partition. I tried reinstalling and nothing. Windows 10 64-bit Education. I checked 2 last versions of Launcher. I tried with "portable version", changing name and copying standalone avisynth to Launcher folder. And still the same.

Simple x264 Launcher will launch encoding tools, e.g. x264, as separate processes. And these tools will then try to load Avisynth.DLL, when needed – usually from the "System32" (or "SysWow64") directory.

The only difference in "portable" mode is that Simple x264 Launcher will add "<InstallPath>\Avisynth\{x86,x64}" to the PATH environment variable before launching the encoder process, so that the encoder process will be able to load Avisynth.DLL from that directory too. Still, programs prefer loading DLL's from the "System32" (or "SysWow64") directory, before they fall back to the directories listed in PATH.

Anyway, you can try running "toolset\x86\avs_check_x86.exe" or "toolset\x64\avs_check_x64.exe" manually and look at the output, in order to check for the availability of 32-Bit or 64-Bit Avisynth, respectively.

[VincAlastor]

Is it possible to add aomenc for testing, please? With your GUI it could be easier to test this new encoder with logs and statistics.

daily nightly builds:
http://forum.doom9.org/showthread.php?p=1778544#post1778544

[LoRd_MuldeR]

Is it possible to add aomenc for testing, please? With your GUI it could be easier to test this new encoder with logs and statistics.

daily nightly builds:
http://forum.doom9.org/showthread.php?p=1778544#post1778544

First of all: I have zero experience with "aomenc".

If it could work a drop-in replacement for x264 or x265 (i.e. it has similar command-line syntax, it has similar input/output capabilities, and it writes similar status messages to the STDOUT), then integration would probably be straight-forward.

Otherwise, I don't know if integration could be done with reasonable efforts. But, in any case, I won't guarantee anything ;)

[LoRd_MuldeR]

For anybody getting this error with latest release, please try the new "hotfix" build below:

https://cloud.githubusercontent.com/assets/470590/21948975/ded54b54-d9ee-11e6-892a-5924b305b920.png

x264_launcher.2017-01-14.exe (https://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Hotfix/x264_launcher.2017-01-14.exe/download)

[GMJCZP]

I have a question: Is a good idea for Bluray ripping use makemkv and later use Simplex264 for definitive coding (video only, of course)?
The quality of image is still good?

[kypec]

The quality of image is still good?

Quality of video will depend on the bitrate and settings you setup for x264 encoder. I personally usually encode with preset=veryslow, CRF=20 and appropriate tuning applied (Film, Animation...)

[BakaProxy]

Quality of video will depend on the bitrate and settings you setup for x264 encoder. I personally usually encode with preset=veryslow, CRF=20 and appropriate tuning applied (Film, Animation...)
I personally like to use qp=21,preset=placebo, deblock=9:-9,aq-strength 0.69 for maximum quality, I swear you you won't notice the difference except for some small dots here and there. 👌👌👌

Verstuurd vanaf mijn SM-A500FU met Tapatalk

[GMJCZP]

In short: Is usable makemkv for video input for simplex264?

[LoRd_MuldeR]

Quality-wise, the Simple x264 Launcher is as good (or bad) as any other x264 front-end. But yes, x264 should be able to reduce the bitrate of a BluRay source quite a bit without much quality loss.

As far as MKV input is concerned, x264 can read MKV files directly, thanks to built-in FFmpegSource support. x265 is still lacking a feature like that, but of course you can always frame-serve your MKV files via Avisynth or VapurSynth...

[GMJCZP]

Thanks, I was worried for the quality input of makemkv video, not for the performance of your program. In short Makemkv and Simplex264 are a good combo for ripping!

[kypec]

Thanks, I was worried for the quality input of makemkv video, not for the performance of your program.
Seems like you've been missing one important point to know:
MakeMKV is a ripping tool, not encoder which means that the visual quality of output MKV file is exactly the same as that of original BD stream, the data are just repacked in different container = mkv (Matroska) instead of ts (MPEG transport stream). ;)

[GMJCZP]

Indeed, thanks. Makemkv's output is lossless. Now I know.

[r0lZ]

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?