Simple x264/x265 Launcher v3.02 (2022-06-16) [Archive] - Page 13

LoRd_MuldeR

9th February 2012, 14:12

I thought there is L-smash patch which can encode audio, right?

AFAIK, the "L-smash" project implements an alternative MP4 muxer. I don't think it is specifically for audio encoding :confused:

Anyway, I cannot make use of any features/patches that have not been adopted into mainline x264 yet.

The same goes for UTF-8 support, for example. You still may be able to make use of "unofficial" features through the "custom parameters" edit box.

Did you plan to merge LameXp into this GUI? If yes, it would be awesome ;)

Definitely not. I'm not trying to create an "egg-laying wool-milk-sow" that nobody can maintain...

Can you add option to change priority of x264 & avsyuv processes if possible? The default priority is below normal

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)

naoan

10th February 2012, 10:41

Some improvements:
* Added Drag&Drop support

I'm probably doing something wrong, but the latest version I tried (x264_x64.2012-02-09) doesn't seems to accept drag&drop file. :confused:

LoRd_MuldeR

10th February 2012, 12:22

I'm probably doing something wrong, but the latest version I tried (x264_x64.2012-02-09) doesn't seems to accept drag&drop file. :confused:

Works just fine here. Also I did not change anything about Drag&Drop support since it was added :confused:

Sure you did not launch the application with elevated rights for whatever reason?

Applications running with elevated rights won't accept any drops from a non-elevated process...

(BTW: x264_x64.2012-02-09. That's not the latest version)

Are you sure you dropped the files on the "Main" window?

naoan

10th February 2012, 15:56

Are you sure you dropped the files on the "Main" window?

Ah this was my problem, I'm too used with the old behavior of dragging the file where the open button is. Sorry for the confusion. :D

LoRd_MuldeR

10th February 2012, 16:14

Ah this was my problem, I'm too used with the old behavior of dragging the file where the open button is. Sorry for the confusion. :D

I can add Drag&Drop support for the "Add Job" dialog too. Though dropping multiple files won't work there.

naoan

10th February 2012, 17:23

It's not working here, I probably need to update the launcher though.

LoRd_MuldeR

10th February 2012, 17:43

It's not working here, I probably need to update the launcher though.

What exactly? :confused:

naoan

10th February 2012, 17:47

The drag&drop on add job window, just tried the x264_x64.2012-02-10 version and it's still not working. I'm using windows 7 x64 sp1 if that could help anything.

Edit: And I'm running the app on the same right as explorer/my login.

LoRd_MuldeR

10th February 2012, 18:12

The drag&drop on add job window, just tried the x264_x64.2012-02-10 version and it's still not working. I'm using windows 7 x64 sp1 if that could help anything.

I just said that "I can add Drag&Drop support for the 'Add Job' dialog too", but I did not want to indicate that this is already supposed to be working ;)

naoan

10th February 2012, 19:48

Ah sorry about that, bad day (and eyesight) of me :p, please do if you can, that would be much appreciated. :D

Oh and also, retaining pending job even after closing the launcher would be nice. :D

Edit: one more thing to consider is to give user option of defaulting "Start Job Immediately" checkbox ticked or not. :)

LoRd_MuldeR

10th February 2012, 22:22

Edit: one more thing to consider is to give user option of defaulting "Start Job Immediately" checkbox ticked or not. :)

Whether that checkbox will be checked initially (or not) is controlled dynamically:

If the number of running jobs still is below the user-defined limit, then it will be checked initially. Otherwise it won't be.

LoRd_MuldeR

11th February 2012, 00:41

New version:

This version supports a "portable" mode (see ReadMe for details) and accepts Drag&Drop's in the Add Job dialog.

naoan

11th February 2012, 10:26

Thanks! :D

Chumbo

11th February 2012, 17:15

I just stumbled on this thread. A sweet little app I must say. :) I was hoping it would work with avisynth 32bit like suggested and encode with 64bit x264 but it doesn't work here at all. Basically the same thing happens on each of my systems when attempting any of the 32bit tools, i.e., they crash. I have 3 installations that are all Win7U64bit. Am I missing something to get the 32bit tools to work WITHOUT crashing? Those of you who have it working, was there something specific you did in your Win7 64bit install so the 32bit tools don't crash? I'm at a complete loss.

I get the typical "xxx has stopped working" message for avs2yuv.exe.

@MuldeR,
If I may request a feature please. Any chance of modifying the log area to just be a text box? It would be nice to be able to just copy specific text directly from there. A normal text field there would also still provide the standard context menu to allow to select all and copy. Right now we have to copy everything and open a text editor, paste and then grab a line or command to test. Thanks a lot for considering it.

LoRd_MuldeR

11th February 2012, 17:28

I was hoping it would work with avisynth 32bit like suggested and encode with 64bit x264 but it doesn't work here at all. Basically the same thing happens on each of my systems when attempting any of the 32bit tools, i.e., they crash.

That's obviously some local problem.

I have 3 installations that are all Win7U64bit. Am I missing something to get the 32bit tools to work WITHOUT crashing? Those of you who have it working, was there something specific you did in your Win7 64bit install so the 32bit tools don't crash? I'm at a complete loss.

Nope, works "out of the box". I am using 64-Bit Windows 7 on my main development machine too and have not encountered any problems so far.

I regularly use use 32-Bit DGDecodeNV (with 64-Bit x264), for example. As far as I know, it doesn't have a 64-Bit equivalent.

If I remember correctly, you have reported similar problems before. So your problem is probably not related to the Simple x264 Launcher at all...

You have a specific software, e.g. a specific Virus Scanner or Firewall, installed on all "problematic" systems? If so, get rid of it!

Also it certainly won't hurt to clean-up your Avisynth plug-in's folder. Throw out everything you don't really need. Or even load all plug-in's explicit.

I got all kinds of strange crashes with old/buggy/incompatible Avisynh plug-in DLL's in the past. Last but not least: Use Avisynth 2.5.8 stable.

I get the typical "xxx has stopped working" message for avs2yuv.exe.

Time to load up a debugger and find out what is wrong... Does the very same AVS file open and play fine with VirtualDub or MPlayer?

What if you run "avs2yuv.exe input.avs -o output.y4m" from the console manually ???

If I may request a feature please. Any chance of modifying the log area to just be a text box? It would be nice to be able to just copy specific text directly from there. A normal text field there would also still provide the standard context menu to allow to select all and copy. Right now we have to copy everything and open a text editor, paste and then grab a line or command to test. Thanks a lot for considering it.

Not easily possible, as I use a QListView there. AFAIK there is nothing like a QTextView.

Sure, I could use a simple QTextEdit widget, but then I had to keep the content manually in sync with the logging data :rolleyes:

Having the View atomically synchronize itself with the log Model is so much cleaner and nicer...

Chumbo

12th February 2012, 02:21

That's obviously some local problem.
I figured as much but have been unable to track it down since it happens exactly the same on 3 computers and a VM.
Nope, works "out of the box". I am using 64-Bit Windows 7 on my main development machine too and have not encountered any problems so far.

I regularly use use 32-Bit DGDecodeNV (with 64-Bit x264), for example. As far as I know, it doesn't have a 64-Bit equivalent.

If I remember correctly, you have reported similar problems before. So your problem is probably not related to the Simple x264 Launcher at all...
Lucky you. ;) This is why I did a clean install in a VM to see if that resolved anything and it did not. For me, "out of the box" still crashed the same dang way. And you are correct, I have reported the same problem specifically to try to fix it. I brought it up here because I wasn't sure if your app was doing something "internally" to link 32bit AVS to work with 64bit x264. I found out it does not. :(
You have a specific software, e.g. a specific Virus Scanner or Firewall, installed on all "problematic" systems? If so, get rid of it!

Also it certainly won't hurt to clean-up your Avisynth plug-in's folder. Throw out everything you don't really need. Or even load all plug-in's explicit.

I got all kinds of strange crashes with old/buggy/incompatible Avisynh plug-in DLL's in the past. Last but not least: Use Avisynth 2.5.8 stable.
I'd like to get the VM install working since it's new and "clean" and only has very few things installed on it, i.e., basic stuff like AviSynth 2.5.8 stable.
Time to load up a debugger and find out what is wrong... Does the very same AVS file open and play fine with VirtualDub or MPlayer?
Debugger time is right. Yes, I use VirtualDub and VirtualDub64 to test my AVS scripts and the script loads fine in VirtualDub. I use MPC-HC to play the AVS and it plays fine.
What if you run "avs2yuv.exe input.avs -o output.y4m" from the console manually ???
Actually that's what I did to see why it failed. The crash dialog does not come up when it fails from the UI so I ran it manually to see the source of the failure and voila.

Thanks for looking at the edit box possibility. Do you know if the current control you're using can add a "Copy Line" item on the context menu? That would be nice. Not a big deal honestly, just more of a convenience thing to not have to open another program. ;)

BTW, when a job fails, any chance of adding an option to reset it so it can be run again? Again, not a big deal, just a convenience thing. Thanks again.

Chumbo

12th February 2012, 02:45

...I got all kinds of strange crashes with old/buggy/incompatible Avisynh plug-in DLL's in the past. Last but not least: Use Avisynth 2.5.8 stable.

Time to load up a debugger and find out what is wrong...
...
You are indeed LoRd_MuldeR. :D After a year of being unable to resolve this damn issue, you said the right thing to put me on the right track. So I checked the event viewer and saw thisFaulting application name: avs2yuv.exe, version: 0.0.0.0, time stamp: 0x4e78e870
Faulting module name: bass_ape.dll_unloaded, version: 0.0.0.0, time stamp: 0x4383b3ab
Exception code: 0xc0000005
Fault offset: 0x003d2be0
Faulting process id: 0x19bc
Faulting application start time: 0x01cce9257a2ce816
Faulting application path: D:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\avs2yuv.exe
Faulting module path: bass_ape.dll
Report Id: b9a3e916-5518-11e1-b339-ef7a097f6cd3
Pointed directly the file causing the crash. I removed all the bass* files from the AviSynth plugins folder and voila! Unbelievable. I can't believe in all this time it didn't occur to me to check the event viewer. Sheesh. Anyhow, can't thank you enough. I hope this helps anyone else who may be running into the same issue.

The reason, obviously, why it's blowing up in the VM "clean" install is that I copied the plugins folder to make sure I had the files needed not realizing that I was copying outdated ones too.

I'll need to see if there are new versions of the Bass* files or if all I need is the BassAudio.dll. Either way, I'll restore them back one at a time to see if only bass_ape is the problem or the others as well.
:thanks:

LoRd_MuldeR

12th February 2012, 02:52

Debugger time is right. Yes, I use VirtualDub and VirtualDub64 to test my AVS scripts and the script loads fine in VirtualDub. I use MPC-HC to play the AVS and it plays fine.

That's really strange. So VirtualDub opens (and plays !?) your script just fine, but Avs2YUV does not? :scared:

What if you run "avs2yuv.exe input.avs -o output.y4m" from the console manually ???Actually that's what I did to see why it failed. The crash dialog does not come up when it fails from the UI so I ran it manually to see the source of the failure and voila.

And voila... what? :confused:

Pat357

12th February 2012, 02:57

Nice little tool you have ! Thanks a lot for creating it.
I have however 2 problems with it :

1. When I want to specify "--fps 24" as a custom parameter for x264_x64, I says it's invalid and deletes all other custom settings too.
If you check in the x264 help "--fps .." IS a valid parameter.
Any reason why this is blocked ?
I tried to encode a 24fps MKV file (remuxed .TS file), I got an encoded MKV file, but the header in mediainfo indicated a VFR instead of 24 fps for the framerate.
The input .mkv file had 24 fps in mediainfo and the whole file plays at 24 fps.
Some splitters rely on the FPS in the header, so I want 24fps there instead of VFR, because the file is not VFR !

2. My input file is native 4:2:2, but when I created an AVS-script (gives 4:2:2 output) and input this in your tool, I noticed AVS2YUV converted it to 4:2:0.
That's not what I want. I used profile High422 and used --csp-input i422 and --csp-output i422 as custom parameters for x264, but no avail : AVS2YUV always converted to 4:2:0.
I have no place in the tool to enter parameters for AVS2YUV, and as a matter fact, I would want that avs2yuv would not touch the color-space and just pass-through as it is.
Is this possible ?

Another solution could be that avs2yuv outputs the color-space based on the profile :
for "High422" (output i422 then) and in case of profile "High444", avs2yuv should output i444.
For all other profiles just output 4:2:0.
Is this more feasible to add to your nice tool ?

LoRd_MuldeR

12th February 2012, 03:07

1. When I want to specify "--fps 24" as a custom parameter for x264_x64, I says it's invalid and deletes all other custom settings too.
If you check in the x264 help "--fps .." IS a valid parameter.
Any reason why this is blocked ?

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.

2. My input file is native 4:2:2, but when I created an AVS-script (gives 4:2:2 output) and input this in your tool, I noticed AVS2YUV converted it to 4:2:0.
That's not what I want. I used profile High422 and used --csp-input i422 and --csp-output i422 as custom parameters for x264, but no avail : AVS2YUV always converted to 4:2:0.
I have no place in the tool to enter parameters for AVS2YUV, and as a matter fact, I would want that avs2yuv would not touch the color-space and just pass-through as it is.
Is this possible ?

This would require to pass a custom "-csp" parameter to Avs2YUV, which is not currently possible. The default is "-csp I420", but you would need "-csp I422".

Also I think it will require experimental Avisynth 2.6, because Avisynth 2.5 cannot output YV16. And Avs2YUV apparently cannot pass through YUY2, only YV16.

Last but not least you would also need to pass "--csp-output I422" to x264, because by default x264 would convert the I422 input back to I420...

Chumbo

12th February 2012, 03:42

And voila... what? :confused: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

13th February 2012, 00:38

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

13th February 2012, 01:49

@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

13th February 2012, 01:53

Pat357

13th February 2012, 16:28

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

13th February 2012, 16:30

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

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

LoRd_MuldeR

13th February 2012, 16:38

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)

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

Please also note the instructions in the ReadMe file.

LoRd_MuldeR

15th February 2012, 01:13

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

nibus

15th February 2012, 05:48

Chumbo

15th February 2012, 17:25

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

16th February 2012, 00:58

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

16th February 2012, 01:09

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

16th February 2012, 01:58

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

16th February 2012, 02:17

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

16th February 2012, 02:40

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

Awesomesauce. :D Works perfectly!

shinchiro

17th February 2012, 16:06

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 :rolleyes:

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

17th February 2012, 16:28

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 :rolleyes:

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

18th February 2012, 04:02

vdcrim

18th February 2012, 04:49

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

18th February 2012, 06:10

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)

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.

sneaker_ger

18th February 2012, 06:56

Also note that CRF does not guarantee constant quality for different settings. Especially not on medium vs superfast, as the latter does not use mb-tree while the former does.

LoRd_MuldeR

18th February 2012, 13:27

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.

Using a "slower" preset does improve the compression efficiency. That is the "quality per bit" ratio.

However there is absolutely no guarantee that, in CRF (or CQ) mode, the total size of the file will still be the same after you switch the preset ;)

Consequently, if you want to compare the quality of "Superfast" and "Medium" presets, you need to ensure your files have an identical size.

So you need to use "2-Pass" mode (with identical target bitrate) for this kind of test. And be sure to pick a reasonable bitrate!

Once you have verified for yourself that "Medium" preset gives better results, you can go back to CRF mode and tweak your CRF value as needed.

Hint: The same CRF value will give "very similar" quality for different sources. But only as long as no other influential settings are changed...

reff24

19th February 2012, 14:40

You can add any configuration on a menu item? Loading template (Custom Matrix)?

VideoFanatic

20th February 2012, 02:19

kypec

20th February 2012, 09:22

Is there any way to force the aspect ratio to 4:3 with your program or avisynth? My MPEG2 is 4:3 when I view it on my PC. Mediainfo and Videoredo also say it's 4:3. However when I use your program my video is stretched to 1.50:1. With HC Encoder I just selected 4:3 to prevent that.
That's because you didn't specify SAR explicitly for elementary stream descriptors and you didn't do it either in target container (MP4 or MKV).
Just add --sar 8:9 option to your command line and you'll get proper 4:3 display ratio for your 3:2 source clip (probably some 720 x 480 NTSC MPEG2). ;)

Is there any way to get your program to have the output selected as h264 by default? At the moment mkv is always selected first.This behaviour annoys me a bit as well because I use raw .264 output too for my encodes but I think unless LM rewrites the code there's no way we two would be satisfied 100%, MKV is likely more preferred output type for general audience. :p

LoRd_MuldeR

20th February 2012, 13:54

Is there any way to get your program to have the output selected as h264 by default? At the moment mkv is always selected first.

In my opinion MKV should be the standard output format. With a "raw" H.264 file you cannot do much. Most players won't even be able to play that! The only thing you can do (and probably will do) is muxing the "raw" stream to MKV (or MP4). And if you are going to mux the stream anyway (e.g. for adding the audio), you can mux from the MKV file just as well. MKVMergeGUI accepts MKV's as input just fine. You also have to be aware that 99% of all users believe that if a file does not play immediately on double-click in Windows Explorer, then that file is "broken" and the application who created the file is to blame! Thus by making MKV the default output format, I can save about ten angry e-mails per day. There could be some discussion whether the default format should be MKV or MP4. While MP4 would be "more standard", I believe that most people prefer MKV these days. And the people who don't care will probably get the best results with MKV too...

I have a dual core PC. At the moment it takes me 2 hours 45 minutes to encode a 1 hour 30 minute video on VeryFast CRF 17. How much faster would it be if I had more cores?

As x264 scales very well up to at least 16 cores, you can expect ~2x speed-up for a Quadcore and ~3x speed-up for a Hexacore.

That is for a CPU of the same generation. If you replace an older Dualcore processor with a modern Quadcore (or Hexacore), you can get even more speed-up, due to improved "per core" performance.

Of course you can only expect speed-up, if you aren't bottle-necked by "slow" input, such as a slow single-threaded Avisynth script. x264 can't encoder faster than the input gets delivered.