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

[Chumbo]

Originally Posted by LoRd_MuldeR

And voila... what?

Since the UI did NOT really show what the failure was it could be anything. By running it manually, I was able to see exactly what was failing, i.e., the executable itself. So voila as in running it manually revealed the source of the crash. Anyhow, that's all behind me now thank goodness.

[LoRd_MuldeR]

Added support for custom Avs2YUV parameters:

You can now encode 4:2:2 and 4:4:4 YUV data from Avisynth by passing "-csp I422" or "-csp I444" to Avs2YUV as a custom parameter.
Please remember that you also need to pass the proper "--output-csp" parameter to x264, if you want to encode in 4:2:2 or 4:4:4 YUV.

[Chumbo]

@MuldeR,
I noticed that when the app is already installed, running the setup for an updated version does not "see" the location of the current installation and updates it. I install my apps to drive D so D:\... is my path but the install came up pointing to C:\.... This may be out of your control depending on what setup packing software you use, but it would be nice if it came up and recognize an already installed copy and pointed to its current location.

[LoRd_MuldeR]

Originally Posted by Chumbo

@MuldeR,
I noticed that when the app is already installed, running the setup for an updated version does not "see" the location of the current installation and updates it. I install my apps to drive D so D:\... is my path but the install came up pointing to C:\.... This may be out of your control depending on what setup packing software you use, but it would be nice if it came up and recognize an already installed copy and pointed to its current location.

Yes, the installer does not currently remember the install location from previous installations.

(Will add this in a future build, although the "portable" purist will complain)

[Pat357]

Originally Posted by LoRd_MuldeR

It's blocked as a "custom" parameter, because the GUI will set it for you.

When the input is piped into x264 via Avs2YUV, x264 can't know the original framerate. It just sees the "raw" image data it gets via STDIN.

That's why the GUI will detect the framerate from the original AVS and pass it to x264 via "--fps" parameter.

Lord Mulder,
If you read my first problem again, you'll notice that I was not trying to feed an .avs, but a normal 4:2:2 MKV file.
Does the guy in this case also adds the "--fps" parameter ?
I asked because even for MKV input, --fps is blocked.
This doesn't seem right to me, but I could be wrong....
Why is it still blocked for MKV input ?

[Pat357]

Originally Posted by LoRd_MuldeR

Added support for custom Avs2YUV parameters:
http://code.google.com/p/mulder/downloads/

Thanks a million !!
I'm gonna test it asap.

[LoRd_MuldeR]

Originally Posted by Pat357

Lord Mulder,
If you read my first problem again, you'll notice that I was not trying to feed an .avs, but a normal 4:2:2 MKV file.
Does the guy in this case also adds the "--fps" parameter ?
I asked because even for MKV input, --fps is blocked.
This doesn't seem right to me, but I could be wrong....
Why is it still blocked for MKV input ?

Well, I blocked it in general. That's because there are cases in which setting "--fps" manually would mess up things.

For native MKV input we don't really have to block it. But we also shouldn't need to set it.

If FFMS2 doesn't detect the frame rate of your MKV file correctly, then you should report the problem to FFMS2 guys.

You can still use a simple Avisynth script with FFVideoSource() followed by AssumeFPS() as workaround for now...

(Note that the "--force-cfr" option should not be blocked at all, if that is your concern)

Originally Posted by Pat357

Thanks a million !!
I'm gonna test it asap.

Please also note the instructions in the ReadMe file.

[LoRd_MuldeR]

Added a "Restart Job" button. Also added some info on audio encoding to the ReadMe file.

[nibus]

Excellent utility Lord Mulder!

I use a lot of custom --zones and as such my x264 command line gets pretty long. What do you think about adding a "--zones Parameters:" field in the Add Job box and appending it to the x264 command line?

[Chumbo]

Originally Posted by LoRd_MuldeR

Added a "Restart Job" button. Also added some info on audio encoding to the ReadMe file.

Download:
http://code.google.com/p/mulder/downloads/

Sweet! Thank you.

[LoRd_MuldeR]

Originally Posted by nibus

Excellent utility Lord Mulder!

I use a lot of custom --zones and as such my x264 command line gets pretty long. What do you think about adding a "--zones Parameters:" field in the Add Job box and appending it to the x264 command line?

What would a "zones" parameters edit box do different than the general "custom" parameters box?

After all, both edit boxes would contain additional user-defined CLI parameter that will be passed to x264, right?

So basically we would have two edit boxes for the the same purpose.

If all your zones parameters don't fit into the "custom parameters" edit box, you can make the window wider.

And if they still don't fit in, you can prepare your command-line in your preferred text editor...

[nibus]

Originally Posted by LoRd_MuldeR

What would a "zones" parameters edit box do different than the general "custom" parameters box?

After all, both edit boxes would contain additional user-defined CLI parameter that will be passed to x264, right?

So basically we would have two edit boxes for the the same purpose.

If all your zones parameters don't fit into the "custom parameters" edit box, you can make the window wider.

And if they still don't fit in, you can prepare your command-line in your preferred text editor...

I see your point, it would be redundant. True, you can just make the window wider, but this is kind of a pain if you have a really long command line. What if the custom parameters box had 2-3 lines with word-wrap? That would make the command line more accessible without any redundant boxes.

[reff24]

Thank you for your work. is prorgam getting better and better! I hope it is not set like AutoMKV and co! So stay on the ball and keep going

[LoRd_MuldeR]

Originally Posted by nibus

I see your point, it would be redundant. True, you can just make the window wider, but this is kind of a pain if you have a really long command line. What if the custom parameters box had 2-3 lines with word-wrap? That would make the command line more accessible without any redundant boxes.

Please try with the attached version. Right-click + "Open Editor" will open the multi-line editor.

[nibus]

Originally Posted by LoRd_MuldeR

Please try with the attached version. Right-click + "Open the Text-Editor" will open the multi-line editor.

Awesomesauce. Works perfectly!

[shinchiro]

Originally Posted by LoRd_MuldeR

What is wrong about that?

If you think that running a process at a higher priority would make it run any "faster", then you are wrong!

Priorities only make a difference when various processes are ready to execute at the same moment and thus compete for the CPU.

In that case the process with the higher priority is served first. And we generally want that to be the GUI (foreground) process.

Running x264 at "below normal" priority means: Use all the CPU time you can get, but don't thwart any of the "foreground" processes.

Thus, as long as you don't run other "CPU intensive" workload at the same time, a "below normal" priority won't slow down x264...

(Though it will noticeably improve the reactivity of the GUI front-end and other programs, e.g. web-browser and stuff)

I never know about that. btw, in my observation, x264 encode faster (maybe finished 2-5 minutes early when encoding 720p anime with duration 24 minutes) when I changed it to normal

And I only do that when I want to leave my pc on for a night for encoding and nothing intensive program running along. Since megui has this option, I would like to see this feature in this tool too

[LoRd_MuldeR]

Originally Posted by shinchiro

I never know about that. btw, in my observation, x264 encode faster (maybe finished 2-5 minutes early when encoding 720p anime with duration 24 minutes) when I changed it to normal

If x264 encodes any faster* by raising the priority, then this means another process running on your system was competing with x264 for the CPU.

(*) And here we are talking about a speed-up that does NOT fall within the normal fluctuations!

[VideoFanatic]

Could you please explain this to me:

I encoded the same file at different speed settings and got the following sizes:

CRF 17 Medium: 49 MB
CRF 17 Super Fast: 59 MB

I thought the slows speeds are supposed to give the same file size but a better quality file? Medium should be better quality than Super Fast yet Medium has a much smaller file size. I looked at both files on my TV and I can't tell them apart.

[vdcrim]

Originally Posted by holygamer

I thought the slows speeds are supposed to give the same file size but a better quality file?

You really should check the available x264 documentation, as LoRd_MuldeR already showed you in your other thread. From http://mewiki.project357.com/wiki/X264_Settings#preset:

Change options to trade off compression efficiency against encoding speed.

Compression efficiency can be defined as quality/bitrate. Now, x264 allows you to encode with two different approaches:

• Aim for a certain filesize: use '--bitrate' and a number of passes, usually 2.
• Aim for a certain uniform quality: use '--CRF'. This only approximates to constant quality though.

Taking this to the efficiency definition, you'll have this:

• For bitrate mode, 'preset' is a trade off between speed and perceptual quality. A slower preset gives better quality results.
• For CRF mode, 'preset' is a trade off between speed and bitrate (assuming CRF were a perfect index of quality). A slower preset gives (generally) a smaller filesize.

[shinchiro]

Originally Posted by holygamer

Could you please explain this to me:

I encoded the same file at different speed settings and got the following sizes:

CRF 17 Medium: 49 MB
CRF 17 Super Fast: 59 MB

I thought the slows speeds are supposed to give the same file size but a better quality file? Medium should be better quality than Super Fast yet Medium has a much smaller file size. I looked at both files on my TV and I can't tell them apart.

Dude, you are using crf. Generally, when using crf, crf will try to get certain degree of quality based on the value you give in no matter what preset you use. Note that, the slower the preset, more compression can be attained so smaller the size. You are using same crf value for both test so expect negligible similar quality (since you are watching on tv)

Originally Posted by holygamer

I thought the slows speeds are supposed to give the same file size but a better quality file?

This only apply to 2pass. Open bitrate calculator in megui and calculate bitrate for 59mb. Take note that bitrate and use that for both test. Then you will say slower preset will give more quality than faster preset.