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

[LoRd_MuldeR]

I know that, what I'm saying is that if an encoding starts at the same time while I'm muxing a video then the FPS encoding speed will drop by up to half from 13FPS to 6.5 FPS. That's normal due to 2 programs using the CPU at the same time. What I'm saying is, is that when the muxing has completed after a couple of minutes and Simple x264 Launcher is the only program using the CPU again, the encoding speed does not go back up to 13 FPS.

And I already explained to you why that is ;)

Back to the car analogy: If you start at 12:00 at your home and you know that you would arrive at your destination at 18:00, given that you drive at maximum speed of 100 km/h all the time, but then you get into a traffic jam and need to drive only 50 km/h for a period of 2 hours, can you still arrive at 18:00? No you can't! Even if you drive 100 km/h again for the rest of the way.

Here the car's current speed corresponds to the percentage of CPU time the encoder process gets assigned. And the time of arrival corresponds to the overall encoding time, and thus to the (average) encoder throughput, i.e. the number of frames processed per second. That's because the number of frames is fixed, but the encoding time may vary.

[VideoFanatic]

The car analogy seems to say that if you're due to arrive at 6PM but you get caught in a traffic jam then of course your journey will take longer. I understand that. Obviously the encoding will take longer if I mux a video at the same time as doing the encoding because the CPU power will be shared between them. What I'm saying is that I got 13FPS before I started muxing a video then when I started muxing a video, the encoding speed halved. After the muxing was complete, the encoding speed did not go back to 13FPS even though nothing else was using the CPU. Of course the encoding will take longer due to the time lost, the problem is that the FPS speed stays at half even after the muxing was complete.

If I was to do the same thing with HC Encoder for example, the FPS speed goes back to normal after I've finished muxing a video. Why does that not happen with your program? Could you fix it please.

[LoRd_MuldeR]

You seem to make the assumption that the "FPS" value displayed by x264 is something like an average over the last few seconds only. But it's not! It's simply the number of frames processed so far, divided by the number of seconds that have passed since the encode started. In other words, it's x264's current estimate of the overall average throughput. Thus, it should go up, slightly and slowly, after your other processes have terminated. But it clearly cannot reach the maximum of 13 fps again - just like you said yourself: the journey will take longer... (or in other words: in the end, the FPS will be lower)

1701 int64_t i_time = x264_mdate();
1702 if( i_previous && i_time - i_previous < UPDATE_INTERVAL )
1703 return i_previous;
1704 int64_t i_elapsed = i_time - i_start;
1705 double fps = i_elapsed > 0 ? i_frame * 1000000. / i_elapsed : 0;

You can make the experiment: Suspend the x264 process with Process Explorer (http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx) for a longer time, near the start of the encode. Then resume it. You will then see an FPS value near zero ;)

[LoRd_MuldeR]

Using latest stabe build and experimental too gives me an error when I click on Show Help screen for x264 and Avs2YUV.
https://dl.dropboxusercontent.com/u/19804113/Forumi/Slike/Doom9/ScreenShot00180.png
Encoding works fine for normal files. I didn't try AVS script yet.I see what the problem is. Will be fixed shortly!

Fixed version is available now :)

[detmek]

Thanks. Works just fine.

[LoRd_MuldeR]

Uploaded a new build. OpenCL workaround has been removed, as it is not needed anymore.

[Dion]

Would you be willing to add a priority option for the CPU usage.

High
Above Normal
Normal
Below Normal <--- This is what it currently defaults too.
Low

I would like to run it in low. Without having to manually do it everytime.

[LoRd_MuldeR]

I can add that, if there really is a use-case for this.

[CarlPig]

I will vote for the option.

[LoRd_MuldeR]

Okay, I have added the option to the preferences.

[Chumbo]

Okay, I have added the option to the preferences.
I was about to +1, but I see you caved. ;) Good call. :D

[Dion]

Okay, I have added the option to the preferences.

Thank You.. Great option.. Can confirm its working in low now.

[VideoFanatic]

Is there any way you could please add a sound alert functionality so that when a new item in the queue starts encoding it will play a sound or a popup message?

This would be useful because at the moment I do restoration with Avisynth. I find that if an encoding starts at the same time I try to mux a file or do something else CPU intensive then the encoding speed will drop to up to half the normal speed and when CPU intensive task has finished the encoding speed does not go back to normal. An encoding could be half way finished before I realise it was encoding at half speed.

If I got an audio alert, I could check that the video was encoding at the correct speed. If it wasn't then I could abort it and start it again after I've finished doing my CPU intensive task.

[LoRd_MuldeR]

Is there any way you could please add a sound alert functionality so that when a new item in the queue starts encoding it will play a sound or a popup message?

This would be useful because at the moment I do restoration with Avisynth. I find that if an encoding starts at the same time I try to mux a file or do something else CPU intensive then the encoding speed will drop to up to half the normal speed and when CPU intensive task has finished the encoding speed does not go back to normal. An encoding could be half way finished before I realise it was encoding at half speed.

If I got an audio alert, I could check that the video was encoding at the correct speed. If it wasn't then I could abort it and start it again after I've finished doing my CPU intensive task.

Indeed, I could add that as yet another option, disabled by default - so people don't go mad about those sound effects ;)

[VideoFanatic]

That would be much appreciated, thanks.

[LoRd_MuldeR]

That would be much appreciated, thanks.

(BTW: It seems you are still interpreting the FPS indicator in the wrong way, although we had discussed that before)

[Dion]

This version seems to require the use of the new x264 build. Is there a reason for that?

Simple x264 Launcher v2.17 (2013-07-05)

[LoRd_MuldeR]

The minimum supported version is forced to the latest revision from the "stable" branch. Currently that is:
http://git.videolan.org/?p=x264.git;a=commit;h=585324fee380109acd9986388f857f413a60b896

This is done in order to prevent people from using old/outdated revisions with known bugs. Also the GUI is developed and tested with up-to-date x264. Using some very old build may not work well.

But if you insist in using some outdated build, this requires exactly one line of code to change ;)

[Dion]

Was just more of a general wondering. I use custom x264 builds with your launcher. And they wouldn't work. So I had to grab the latest custom. But yes it would be nice to not have this restriction.

It was only one rev down from the latest too. So it wasn't that out of date.

[LoRd_MuldeR]

Was just more of a general wondering. I use custom x264 builds with your launcher. And they wouldn't work. So I had to grab the latest custom. But yes it would be nice to not have this restriction.

It was only one rev down from the latest too. So it wasn't that out of date.

I have added a CLI option to skip the version check. Use at your own risk :p

[Atombossler]

I have added a CLI option to skip the version check. Use at your own risk :p
Hi Lord Moulder.
I would also like to make some feature requests. :D
1. editable profiles in some kind of mask would be comfortable.
2. adjustable delay after encode finish to proper unload heavy gpu tasks (1-10 sec.), causes possible hickups now time by time.
3. Some sort of network render feature :devil:
But however, nice work till now! :thanks:

[LoRd_MuldeR]

1. editable profiles in some kind of mask would be comfortable.

Profiles are defined by the H.264 standard, so we cannot edit them.

But if you are talking about templates, you can simply load a template by selecting from the "template" combobox, then edit everything as desired and finally save your changes via "Save As" button.

Not sure what else you may need...

2. adjustable delay after encode finish to proper unload heavy gpu tasks (1-10 sec.), causes possible hickups now time by time.

Once the x264 process terminates there is nothing left that would need to time to "unload".

Don't know what you mean with "hickups", but it seems there is something wrong either with your system or your input chain...

3. Some sort of network render feature :devil:

Not supported by x264. Feature that is not supported cannot be exposed in the GUI ;)

(In theory it would be possible to run multiple encoder instances on different machines and finally stitch together the individual pieces. But besides the fact that this is totally not compatible with 2-Pass RC, it's far out of the scope of this application)

[AGKnotUser]

I'm using an AVS script which takes a long time to start up due to it's indexing a large vc1 file. x264 Launcher times out during this indexing. Could you add an option to either defeat or lengthen the timeout period?

Thanks.

[Atombossler]

@AGKnotUser
Just index this file before you use it.

@LoRd_MuldeR
Yes, Templates Is what I meant.
For example how do I change the order of the templates?

The Graphics Card Ram needs time to unload because the before transfered data has to be removed after processing finished.

I know x264 doesn't support a network render feature.
However you can split the job into little chunks via Avisynth and stich it together as you said.
I never made 2-pass RC, so not neccessary.
But I guessed it's out of reach for the little gui. :cool:

[AGKnotUser]

@AGKnotUser
Just index this file before you use it.



Yes I know that. It's what I've been doing. It just would be a little easier if I could let Simple x264 Launcher do it instead.

[LoRd_MuldeR]

Yes, Templates Is what I meant.
For example how do I change the order of the templates?

You can't change the order. The templates appear in alphabetic order.

The Graphics Card Ram needs time to unload because the before transfered data has to be removed after processing finished.

As soon as a process terminates, all of its memory gets released automatically and immediately. That's a core principle of all modern OS.

[Atombossler]

That's true.
And in 95% of times it works well.
But sometimes not and it's recognizable that the RAM still is unloading.
I don't know how reliable those tools are (hwinfo, gpu observer), but it takes 1 or 2 seconds to finish (RAM usage falling).
Well, it should'nt behave like this but it does. :scared:

[LoRd_MuldeR]

Well, as soon as the x264 process terminates, that RAM is "free" by definition. Even if some kind of lazy/delayed clean-up is going on, that RAM still has to be treated as free memory. So if another process tries to allocate that memory, right after the previous process has terminated, it may encounter some delay in the memory allocation, yes. But it must not encounter any "out of memory" issues. If it does, this would indicate some serious flaw in the driver code!

Adding an "artificial" delay doesn't make much sense to me. Whether you encounter the delay during the memory allocation or you encounter an additional delay before process creating doesn't make much of a difference. Except that the "artificial" delay will be encountered always, even when it isn't required at all. For most users adding an artificial delay will only be pointless and annoying. Also we have no idea how long the delay has to be...

[Atombossler]

Annoying if it can't be disabled and unknown delay could be adjustable from 0-5 sec in preferences.
In general this setting is disabled by default so nobody have to be annoyed.
I know that people ask for that feature in other encoding app as well so it's not only me who need that kind of feature.
But feel free to ignore it. :cool:

[LoRd_MuldeR]

Annoying if it can't be disabled and unknown delay could be adjustable from 0-5 sec in preferences.
In general this setting is disabled by default so nobody have to be annoyed.
I know that people ask for that feature in other encoding app as well so it's not only me who need that kind of feature.

Adding new features, even optional ones, adds more complexity to the application. I won't do this, unless there is a compelling reason. Especially when it comes to such "ugly" workarounds.

As explained before, there is no advantage in adding an "artificial" delay before the next process is created. Whether you experience the delay, because the process takes a little longer to allocate the memory or because the process creation is delayed artificially be the GUI, makes no difference. Except that in the latter case we need extra complexity in the GUI code. That plus we might be waiting longer than necessary (or we even might be waiting for nothing).

[LoRd_MuldeR]

Here is a new experimental version with VapourSynth input support:

Note: Requires VapourSynth r19 or later to be installed. Download it here (http://www.vapoursynth.com/).

[aegisofrime]

Hi Lord Mulder! Thanks for what is perhaps the first GUI to support VS :)

I would just like to report that I have this problem where after encoding a certain amount of frames, the launcher reports that x264 is not responding and is in a possible deadlock. My VS script is just a QTGMC of a DVD, nothing too complex. The same QTGMC settings and x264 settings complete successfully when I use x264 directly.

Any ideas on how to resolve this issue? :thanks:

[LoRd_MuldeR]

The timeout interval is already set to 5 minutes. I think if x264 doesn't update the progress at least once within 5 minutes, something is seriously wrong.

Anyway, I don't know how "optimized" QTGMC is in VapourSynth, compared to the Avisynth original. Maybe it's really that slow and thus triggers the timeout. So did you do some benchmarking?

Also, at which phase does it time out? Can you please post your log...

Finally, how can you use x264 "directly" with QTGMC? If you open the source directly in x264 (not via Avisynth or VapourSynth), there will be no QTGMC processing and things will be a lot faster, obviously.

[aegisofrime]

The timeout interval is already set to 5 minutes. I think if x264 doesn't update the progress at least once within 5 minutes, something is seriously wrong.

Anyway, I don't know how "optimized" QTGMC is in VapourSynth, compared to the Avisynth original. Maybe it's really that slow and thus triggers the timeout. So did you do some benchmarking?

Also, at which phase does it time out? Can you please post your log...

Finally, how can you use x264 "directly" with QTGMC? If you open the source directly in x264 (not via Avisynth or VapourSynth), there will be no QTGMC processing and things will be a lot faster, obviously.

Woops. I guess I left some important information out, or my phrasing isn't that good. :(

When I said that I used x264 directly with QTGMC, I meant that I was piping the output of the Vapoursynth script to x264 like so:

vspipe.exe Meh.vpy - -y4m | x264.exe --crf 21 --preset "slower" --tune "film" --demuxer y4m --output Meh.mkv -

The same script, Meh.vpy is also what I load into Simple Launcher. So, I kept everything is the same in both cases as best as I can; The script settings, and x264 settings. I also made sure to copy the x264 file that I usually use into the launcher's toolsets directory, to keep everything the same.

As for a log... I'm not sure where to find one. I don't see any option in the launcher to save or view a log, nor is there a log file in the installation directory or the folder of my script...

Meanwhile the best I can provide is this:

http://i.imgur.com/9knSLrN.png

Thanks for your time!

[LoRd_MuldeR]

You can right-click in the lower pane and select "Copy to Clipboard" in order to copy the log.

Also: If you use a different x264 binary than what ships with the Simple x264 Launcher, are you sure your x264 binary works with Simple x264 Launcher properly at all?

If, e.g., your binary contains patches that alters the progress output, then Simple x264 Launcher won't be able to recognize the progress updates...

(Anyway, I could send you a build with more diagnostic output later)

[aegisofrime]

You can right-click in the lower pane and select "Copy to Clipboard" in order to copy the log.

Also: If you use a different x264 binary than what ships with the Simple x264 Launcher, are you sure your x264 binary works with Simple x264 Launcher properly at all?

If, e.g., your binary contains patches that alters the progress output, then Simple x264 Launcher won't be able to recognize the progress updates...

(Anyway, I could send you a build with more diagnostic output later)

Well, anyway I compared the hashes of the default binary in the toolset, and the one I use, and they are the same. There shouldn't be an issue there I guess :p

Alright, will wait for the diagnostic version. :D

[LoRd_MuldeR]

Here is a new experimental version with VapourSynth input support:

Note: Requires VapourSynth r19 or later to be installed. Download it here (http://www.vapoursynth.com/).

Here is a small update (install on top of the above download!) that adds a new option to disable the deadlock detection:

Please see the README file for details...

[Evil_Burrito]

That's true.
And in 95% of times it works well.
But sometimes not and it's recognizable that the RAM still is unloading.
I don't know how reliable those tools are (hwinfo, gpu observer), but it takes 1 or 2 seconds to finish (RAM usage falling).
Well, it should'nt behave like this but it does. :scared:

Maybe your monitoring program just isn't configured to update the interface hundreds of times a second, so the read out it isn't actually "real-time" (unnecessary use of resources).

Also, it is possible your system and or gpu is using power adaption. So, for example, it finishes a process and lowers the performance before going back to maximum state of the next job. Although, this would only slow you down a couple to a few milliseconds (depending on the speed and cycles of the memory).

Thanks Mulder for keeping Simple x264 and this thread up to date! :thanks:

[LoRd_MuldeR]

I have released a new version with support for VapourSynth input.

[Dion]

This release always says I don't have VapourSynth. So I click ignore.

It always ask me everytime I start the program :/

[Chumbo]

I have released a new version with support for VapourSynth input.
Thank you. BTW, title shows 2013-07-07.

[LoRd_MuldeR]

This release always says I don't have VapourSynth. So I click ignore.

It always ask me everytime I start the program :/

Not sure what you want to say :confused:

1) You don't have VapourSynth installed -> install VapourSynth (download (http://www.vapoursynth.com/))

2) You don't want to use/install VapourSynth at all -> simply ignore the warning (or see the README on how to disable it permanently)

3) You have VapourSynth (R19+) installed but still get the warning -> you probably found a bug

[Dion]

Not sure what you want to say :confused:

1) You don't have VapourSynth installed -> install VapourSynth (download (http://www.vapoursynth.com/))

2) You don't want to use/install VapourSynth at all -> simply ignore the warning (or see the README on how to disable it permanently)

3) You have VapourSynth (R19+) installed but still get the warning -> you probably found a bug

I did click Ignore warning. It comes back everytime I restart the app.

I run in portable mode from USB drive.

[LoRd_MuldeR]

I did click Ignore warning. It comes back everytime I restart the app.

I understood that. But what exactly is your problem?

As long as VapourSynth is not installed on your system, the warning is legitimate and it will re-appear for obvious reasons.

If, however, it appears despite VapourSynth is installed, this would indicate a bug. So please clarify...

[Chumbo]

Would you consider adding a "Don't show this warning again" check box so those of us not planning on using Vaporsynth, at least not any time soon, wouldn't have to continually click on Ignore every time the UI is loaded? Thanks for considering it.

[Dion]

I understood that. But what exactly is your problem?

The problem is.. It always ask.

I too would like an option to disable it permanently ( I thought Ignore would do this ). At least for portable mode.

edit: imo vapoursynth is too new. There should be no option to check for it. And an option in the options to enable it. For people experimenting with it.

[LoRd_MuldeR]

The problem is.. It always ask.

I too would like an option to disable it permanently ( I thought Ignore would do this ). At least for portable mode.

edit: imo vapoursynth is too new. There should be no option to check for it. And an option in the options to enable it. For people experimenting with it.

As I told you above, that there is and option to disable the Avisynth and/or VapourSynth check. It is described in the README file!

Anyway, since it seems that most people just ignore the documentation, I have added a new option to the preferences dialog now.

Would you consider adding a "Don't show this warning again" check box so those of us not planning on using Vaporsynth, at least not any time soon, wouldn't have to continually click on Ignore every time the UI is loaded? Thanks for considering it.

It's not easily possible to add a checkbox into a QMessageBox. You will find a few hacks, if you google for "QMessageBox + checkbox", but the result is not satisfying.

QErrorMessage does provide a checkbox, but it is not suitable for other reasons. That's why I implemented a different solution (see "preferences" dialog).

[Dion]

As I told you above, that there is and option to disable the Avisynth and/or VapourSynth check. It is described in the README file!

Anyway, since it seems that most people just ignore the documentation, I have added a new option to the preferences dialog now:
http://www.mediafire.com/download/l0fanzrkyptfc76/x264_x64.2013-08-09.zip

No I saw it. But having to run a special command while using the app in "Portable Mode" is kind of a hassle. Defeats the whole point of being portable imo. Thanks for adding the option.. appreciate it.

[LoRd_MuldeR]

No I saw it. But having to run a special command while using the app in "Portable Mode" is kind of a hassle

It's not related to portable mode at all. And if you want to always pass a specific command-line option, you can just create a shortcut or a batch file.

Anyway, with the new version you can simply disable the warning directly inside the program...

[docholliday]

When i want to setup VapourSynth it gives me this error.

http://i.imgur.com/4wPdToE.jpg