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

[LoRd_MuldeR]

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

Release Highlights:
Various installer fixes and improvements

[SeeMoreDigital]

Hi LoRd_MuldeR,

I've just tried upgrading via the applications 'Check for new updates' link and got this: -

http://i60.tinypic.com/2s7te1v.png


Cheers

[LoRd_MuldeR]

Hi LoRd_MuldeR,

I've just tried upgrading via the applications 'Check for new updates' link and got this: -

Cheers

Sorry, somehow the upload got stuck, leading to an incomplete file on the update mirror.

And of course the digital signature didn't match on that incomplete file! I have resumed the upload, so this should be fixed now.

Please try again...

[davidtuning]

Hi I have a problem with the program, I Update to the latest versión and i get this error
http://puu.sh/aVbNb/e14d007c15.jpg

but I have both programs installed it's latest versión: VapourSynth R24, Python 3.4.1 help.

[RTW47]

Chances vs was not installed correctly, you can try running x264_launcher.exe via --console switch and then inspect/post log section responsible for vapoursynth support.
personally don't have any vs detection problems using v2.4.1 and after updating to v2.4.2 with everything 64-bit.
---
by the way, pressing ?\x264 Online Documentation link leads to 'This page can’t be displayed' message inside IE. (and also ?\About...\x264 Encoder\user's manual)
seems like http://mewiki.project357.com/wiki/X264_Settings - no longer available?..

[LoRd_MuldeR]

Hi I have a problem with the program, I Update to the latest versión and i get this error
http://puu.sh/aVbNb/e14d007c15.jpg

but I have both programs installed it's latest versión: VapourSynth R24, Python 3.4.1 help.

According to your screenshot, you are obvisouly using an old version of Simple x264 Launcher!

Support for VapourSynth r24 requires Simple x264 Launcher v2.41 or newer, because VapourSynth r24 has changed the interface in way that is not compatible to previous VapourSynth versions.

If you still have problems with VapourSynth r24 using the latest Simple x264 Launcher version, do what RTW47 has suggested...


by the way, pressing ?\x264 Online Documentation link leads to 'This page can’t be displayed' message inside IE. (and also ?\About...\x264 Encoder\user's manual)
seems like http://mewiki.project357.com/wiki/X264_Settings - no longer available?..

Indeed, the site appears to be down at the moment. If it turns out that the site is gone prermanently, I will change the link...

[r0lZ]

The "X264 Settings" site is working for me.

[hackjack]

i am always getting error on simple x264 when trying to encode x265 video. the file not supported or job failed.please see the image below.

[LoRd_MuldeR]

The "X264 Settings" site is working for me.

It still appears down for me this morning :confused:

(have you tried clearing your browser cache?)

i am always getting error on simple x264 when trying to encode x265 video. the file not supported or job failed.please see the image below.

No double posting please!
https://forum.doom9.org/showthread.php?p=1690176#post1690176

:readrule:

[r0lZ]

Yes, I've just tried again, after having double-checked that the cache was empty, and I can still open the site. However, this (http://www.downforeveryoneorjustme.com/http://mewiki.project357.com/wiki/X264_Settings) indicates that you are not alone having the problem. I suspect a DNS problem, so I've tried to enter the IP directly (69.164.203.52 according to this site (https://www.site24x7.com/find-ip-address-of-web-site.html)) and this time, I can't connect. I don't understand, but anyway the site is down or something else is broken.

[SeeMoreDigital]

Sorry, somehow the upload got stuck, leading to an incomplete file on the update mirror.

And of course the digital signature didn't match on that incomplete file! I have resumed the upload, so this should be fixed now.

Please try again...Thanks... The download update is working fine now ;)

[LoRd_MuldeR]

Yes, I've just tried again, after having double-checked that the cache was empty, and I can still open the site. However, this (http://www.downforeveryoneorjustme.com/http://mewiki.project357.com/wiki/X264_Settings) indicates that you are not alone having the problem. I suspect a DNS problem, so I've tried to enter the IP directly (69.164.203.52 according to this site (https://www.site24x7.com/find-ip-address-of-web-site.html)) and this time, I can't connect. I don't understand, but anyway the site is down or something else is broken.

For me, mewiki.project357.com also resolves to 69.164.203.52. That server responds to ping, but currently won't accept HTTP connections:
>ping mewiki.project357.com

Pinging bravo.bluebottle.net.au [69.164.203.52] with 32 bytes of data:
Reply from 69.164.203.52: bytes=32 time=170ms TTL=51
Reply from 69.164.203.52: bytes=32 time=170ms TTL=51
Reply from 69.164.203.52: bytes=32 time=168ms TTL=51
Reply from 69.164.203.52: bytes=32 time=178ms TTL=51

Ping statistics for 69.164.203.52:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 168ms, Maximum = 178ms, Average = 171ms


>wget http://mewiki.project357.com/
--2014-08-17 16:14:00-- http://mewiki.project357.com/
Resolving mewiki.project357.com... 69.164.203.52
Connecting to mewiki.project357.com|69.164.203.52|:80... failed: Bad file descriptor.

>wget http://69.164.203.52/
--2014-08-17 16:14:30-- http://69.164.203.52/
Connecting to 69.164.203.52:80... failed: Bad file descriptor.

Could be a DNS issue, indeed. Let's wait a few days and probably the problem will be resolved. Otherwise I'll change to a different site for x264 help ;)

In the meantime, the Internet Archive has a recent backup of that site available:
https://web.archive.org/web/20140627075103/http://mewiki.project357.com/wiki/X264_Settings

[Evil_Burrito]

Thank you LoRd_MuldeR for the regular updates. I use Simple x264 or LameXP almost every day.

There are two small things that have always annoyed me (they aren't "bugs" exactly). 1. Auto open installation directory window after install has completed and 2. Automatically pinning shortcuts to the taskbar after install/update.

[LoRd_MuldeR]

1. Auto open installation directory window after install has completed

Well, shouldn't be a big deal to just close the Explorer window, if you don't need it ;)

(Honestly, how often do you re-install or update the Simple x264 Launcher? Not more often then once in a few weeks/months, I suppose)

2. Automatically pinning shortcuts to the taskbar after install/update.

Pretty much the same applies here. Still I may consider making this one optional, if it helps...

[Evil_Burrito]

Honestly? Every time there is an update :p.

:thanks:

[VideoFanatic]

Hi, I would like to be able to do the following with Simple x264 Launcher:

Select a folder of files to encode and select an Avisynth script to use on all the videos.
Simple x264 Launcher would then create an index file for each video with DGDecodeNV. Then the files would be encoded using the Avisynth script.
Once encoding is finished Simple x264 Launcher should mux the audio back with the video output with TSmuxer to m2ts.

I've tried MeGUI but it's very buggy and unreliable. I know you said you won't be doing anything like the above but I was wondering if it would be OK to hire someone to mod Simple x264 Launcher and develop it for me.

Any idea how much that might cost to develop?

[LoRd_MuldeR]

Select a folder of files to encode and select an Avisynth script to use on all the videos. Simple x264 Launcher would then create an index file for each video with DGDecodeNV. Then the files would be encoded using the Avisynth script.

The problem with your idea is that an Avisynth (or VapourSynth) script is not "used" on a video file. The script simply returns video data to the host application, but the host has no means of determining where that video came from. The script may have read the video data from a file using whatever source plug-in, it may have created the video data by combining several input files or it even may have generated that video data all by itself!

Surely, what could be implemented is a "script generator" that outputs a simple Avisynth script to load a single input file trough a pre-defined source plug-in without any fancy extra processing. But what certainly can not be done is writing a program that takes an arbitrary Avisynth script as input and "applies" that script on your specific video file(s). There are far too many possibilities how the script may look and how exactly it would have to be modified to "load" exactly the desired file...

Once encoding is finished Simple x264 Launcher should mux the audio back with the video output with TSmuxer to m2ts.

Audio processing is not currently supported.

Any idea how much that might cost to develop?

I would assume a professional freelancer programmer costs about $100 per hour and that such a project could take quite a few days (á 8 hours) to understand the existing code, implement the required extensions (which may require a significant redesign of the code) and do all the testing.

[VideoFanatic]

Thanks. I know it doesn't support audio. I was referring to DGDecodeNV demuxes the audio and video then after Simple x264 Launcher encodes the video only, TS Muxer would mux the files back together.

So is it OK if I hire someone to mod Simple x264 Launcher? Once the program was finished it would be made available to download for free. Obviously I'd have to call the program "Simple x264 Launcher Batch Mod" or if there's a name you don't want me to use then that's fine.

[Atak_Snajpera]

Why don't you just use TX264 if you need audio as well?

[LoRd_MuldeR]

So is it OK if I hire someone to mod Simple x264 Launcher? Once the program was finished it would be made available to download for free. Obviously I'd have to call the program "Simple x264 Launcher Batch Mod" or if there's a name you don't want me to use then that's fine.

This software is released under the GNU General Public License (GPL). So everybody is granted the right to use the software for free, to redistribute the software, to modify the software according to their needs and even to re-use parts of the software in their own software. No further approval by the author is required. However, be aware that the GPL also requires that any derivative work will be released under the GPL too! Even if you re-use only a small part of the original software in your software, you still must release your software under the GPL too. Just offering your software for free download is not sufficient! You are required to grant your users the same rights that the developer of the original software granted you.

See also:
http://www.gnu.org/licenses/gpl-2.0.html
http://en.wikipedia.org/wiki/Copyleft

[VideoFanatic]

I would like to encode a wrestling show. All HD episodes are approximately the same length at about 2 hours 17 minutes each but when I use CRF 17 I get file sizes of between 7-8.5GB. That's quite a big difference. How does that happen as I looked at the episodes and they each have approximately the same length of talking segmets and action segments (matches).

Anyway is there a way to tell x264 to encode to a target file size? All I can see is 2 pass but it only allows you to enter the bitrate not the filesize.

Is there a quality loss from doing 2 pass versus CRF?

Both episode sources were 13.4GB but after encoding to CRF 17.5 the file size was 6.79GB for one episode and 8.67GB for another. Both sources were copied directly from my satellite box onto my PC without re-encoding then I re-encoded them.

[LoRd_MuldeR]

I would like to encode a wrestling show. All HD episodes are approximately the same length at about 2 hours 17 minutes each but when I use CRF 17 I get file sizes of between 7-8.5GB. That's quite a big difference. How does that happen as I looked at the episodes and they each have approximately the same length of talking segmets and action segments (matches).

CRF mode gives the same quality (roughly!) for different sources, given that you use the same CRF value and given that you do not change other encoder settings. Of course the size can vary greatly between different sources, because source 'A' could be much more "compressible" than source 'B', or vice versa. Consequently, it's not surprising at all that different sources come out at different size, even if the duration is identical. Of course sources with "similar" content are expected to come out at more "similar" sizes. And indeed, despite you have been encoding 2 hours 17 minutes of completely different material (though of similar nature), the difference is file size is only ~20%.

Anyway is there a way to tell x264 to encode to a target file size?

2-Pass mode !?!?!?!? :sly:

All I can see is 2 pass but it only allows you to enter the bitrate not the filesize.

Size = Duration × Bitarte

Inserting the Duration of your movie plus the desired Size and then solving that equation for Bitarte should be pretty doable.

Tough, if you are as lazy as I am, enter "bitrate calculater" into Google ;)

Is there a quality loss from doing 2 pass versus CRF?

CRF and 2-Pass are using the exactly some rate-control algorithm.

So, nope, two files encoded with CRF and 2-Pass will have the exactly same quality, given that they come out at the same bitrate (file size).

[Atak_Snajpera]

Size = bitrate / 8 x duration

[LoRd_MuldeR]

Size = bitrate / 8 x duration

If bitrate is supposed to be in "bits per second", but size is supposed to be in "bytes", then yes.

(I gave the general formular that makes no such presumptions)

[r0lZ]

IMO, 2-pass is slightly less good than CRF, because the encoder is constrained by the given bitrate. The first pass helps greatly to distribute the bitrate according to the "difficulty" to compress the different parts of the movie, but it's still not perfect. (It's why some users prefer to encode in 3-pass, or even more.) In the other hand, CRF has no constraints at all, and can therefore obtain the best quality immediately. Anyway, that considerations are very theoretical, because there is no practical way to encode in CRF and 2-pass modes with exactly the same overall bitrate. But IMO, unless the final file size is really important, CRF is always preferable.

[LoRd_MuldeR]

IMO, 2-pass is slightly less good than CRF, because the encoder is constrained by the given bitrate. The first pass helps greatly to distribute the bitrate according to the "difficulty" to compress the different parts of the movie, but it's still not perfect. (It's why some users prefer to encode in 3-pass, or even more.) In the other hand, CRF has no constraints at all, and can therefore obtain the best quality immediately. Anyway, that considerations are very theoretical, because there is no practical way to encode in CRF and 2-pass modes with exactly the same overall bitrate. But IMO, unless the final file size is really important, CRF is always preferable.

As explained before, 2-Pass and CRF use the exactly same rate-control algorithm :)

So if you make two encodes of the same source, one with 2-Pass and one with CRF, the two encodes will come out at the same quality - given that they come out at the same file size (bitrate). Really the only difference between 2-Pass and CRF is that 2-Pass mode can hit a predefined average bitrate. 2-Pass does that by adjusting the "rate factor" automatically so that the desired bitrate is hit, while CRF uses a fixed rate-factor (as the name implies). Otherwise they are pretty much the same. So any quality difference between 2-Pass and CRF you may have observed is because the files came out at different bitrate (size) - in which case the comparison was biased/unfair, of course - or because other settings were different.

BTW: The first pass of a 2-Pass encode is simply run in ABR mode. The only info that the second pass will reuse from the first pass is a rough approximation of the "complexity" of each frame. That's also why you can use "very fast" settings during the first pass, even when the second pass will use "slow" settings: The approximation of the frame "complexities" will still be reasonably accurate and all the rest doesn't matter at all.

BTW 2.0: Using three or even more passes with x264 is nonsense, except for the extremely rare case when the second pass didn't hit the target bitrate (happens almost never for "real world" footage).


CRF and 2-pass use the exact same bit distribution algorithm. If you do a CRF encode and a 2-pass encode at the same bitrate, the results will be nearly identical.

Hypothetically, there could be a bug in the 2-pass code that didn't show up in CRF, but outside of a hypothetical bug workaround, this is probably not a good suggestion.What do you think about using more than two passes?

Useless waste of time. 99% of any benefit you'll get from it can be gotten by running the first pass with --slow-firstpass instead running a third pass, and even that benefit is tiny.


See also:
http://git.videolan.org/?p=x264.git;a=blob;f=doc/ratecontrol.txt;h=e93ced2aa374a4a36fa1f34121358d943a28f6bc;hb=dd79a61e0e354a432907f2d1f7137b27a12dfce7

[r0lZ]

OK, thanks for the clarification. (I'm also sure that doing more than 2 passes is overkill, but some peoples are strange and do it anyway.)

Anyway, I think that my conclusion is still valid: Unless you need a specific file size, it is better to use CRF, because CRF gives you the quality you want anyway, regardless of the complexity of the movie. If you encode in 2-pass, with a target quality in mind, you have to figure out the bitrate to obtain that quality. It's something virtually impossible to do for an human being. CRF does it automatically for you. And there is obviously another good reason to prefer CRF: the speed of the overall encoding process.

[VideoFanatic]

OK I tried 2 pass and entered a bitrate of 7500 but MediaInfo says the bitrate is 7908 variable bitrate. I want the max variable bitrate to not go above 7500. How can I do that?

I was wondering, is there no way for you to add a feature to the program where you can enter a target file size and the program does a 2 pass to get to that file size?

[LoRd_MuldeR]

OK I tried 2 pass and entered a bitrate of 7500 but MediaInfo says the bitrate is 7908 variable bitrate. I want the max variable bitrate to not go above 7500. How can I do that?

I wouldn't blindly trust what MediaInfo says here, because determining a "bitrate" for a variable bitrate file is kind of tricky ;)

x264 will print out the actual average bitrate at the end of the encode. That's the number of total bits written divided trough the duration of your input. And that's what you can rely on!

Also keep in mind, the bitrate that you enter for x264 is the VIDEO bitrate only. If you are going to add AUDIO too, this will be added to the file size afterwards.

I was wondering, is there no way for you to add a feature to the program where you can enter a target file size and the program does a 2 pass to get to that file size?

The problem is that you'd need to know the duration of the file beforehand in order to compute the target bitrate, based on a desired file size.

Determining the duration of an Avisynth script source is straight forward, because we can query the total number of frames and the number of frames per second.

But for other types of input it's not so easy, especially if we use x264's built-in decoders ;)

[VideoFanatic]

OK but I always use Avisynth and you say when using Avisynth it's easy to determine the duration with that. So is there any chance you could add that feature please? Perhaps you could add a warning that "target file size" only works when using Avisynth?

[VideoFanatic]

I was wondering, you said CRF and 2 pass gives the same quality. Is there any reason not to use ABR mode in the same bitrate as I would in a 2 pass?

[Asmodian]

Yes, the quality would be significantly worse. ABR is not the same as CRF. To hit a specific size with optimal quality two passes are needed.

[LoRd_MuldeR]

I was wondering, you said CRF and 2 pass gives the same quality. Is there any reason not to use ABR mode in the same bitrate as I would in a 2 pass?

2-Pass mode can predict the size of future frames, since it has information from the first pass. ABR mode, on the other hand, can only extrapolate from what has been encoded thus far, because it has no info on future frames.

If, for example, there happens to be a very complex section near the end of the movie, then 2-Pass mode "knows" about this beforehand. So it can reduce the bitrate, to some degree, at the beginning of the movie, in order to "save" enough bits for the end of the movie, where those bits will be more than helpful. ABR mode obviously can not do this. When it reaches the complex section at the end of the movie, it has to get along with the number of bits that are still left at this point.

CRF mode also has no info on future frames. But it doesn't need to. Since CRF doesn't need to hit a specific file size (average bitrate), it can simply use as many bits as it deems appropriate...

[hello_hello]

OK I tried 2 pass and entered a bitrate of 7500 but MediaInfo says the bitrate is 7908 variable bitrate. I want the max variable bitrate to not go above 7500. How can I do that?

Try checking with Bitrate Viewer (http://www.winhoros.de/docs/bitrate-viewer/). As far as I'm aware it's accurate.

[szabi]

Hi

I use latest build (884), which came x264v2453.
I see newer x264v2479 is out.
Can x264 be replaced in toolset directory? Without any issue?

bye
szabi

[LoRd_MuldeR]

Can x264 be replaced in toolset directory?

Yes.

Without any issue?

Usually there should be no problem, if you replace it with a newer version.

There can be problems if you apply non-standard patches...

[VideoFanatic]

Can I request a small feature please. At the moment when you modify a profile it gives you the option to select a profile to overwrite. But I can't always remember the name of the profile I was editing and want to overwrite because it has a long name.

Could you instead do this: https://docs.google.com/document/d/1OlFuehIssbrsiP3LltOs9JkehR5I7o43LyHAMulxGhc/edit

When you change a setting of a saved profile it will add "<Modified>" to the Template Name. Could you add a Save button so it will overwrite the profile name (the "<Modified>" text will not be a part of the save name) without asking what profile to save as.

[VideoFanatic]

What do I expect? I expect that, if I neither use "--profile" nor "--level", then x264 will set the "correct" Profile and Level for me. That is: the lowest possible Profile that my stream complies to as well as the lowest possible Level that my stream complies - given the current input file and the current encoder settings. Consequently, manually enforcing an even higher Profile or an even higher Level would make no sense. Enforcing a lower Profile can make sense, e.g. if I need to stick within "Main" Profile, because my playback device can only do "Main" Profile but not "High" Profile. Enforcing a lower Level, on the other hand, is almost always a very bad idea, as explained and demonstrated in the previous post (https://forum.doom9.org/showpost.php?p=1696566&postcount=1395).



You can't modify Profiles, because they are predefined by the H.264 standard. All H.264 Profiles that x264 recognizes should be selectable from the "Profile" combobox.

Sorry I was referring to Templates. Would it be possible to add what I asked please?

[LoRd_MuldeR]

Sorry I was referring to Templates. Would it be possible to add what I asked please?

What about this: When you click the "Save as..." button, it the initial name will be that of the last profile you have loaded?

[VideoFanatic]

What about this: When you click the "Save as..." button, it the initial name will be that of the last profile you have loaded?

That would be fine. Thanks

[szabi]

Yes.

Usually there should be no problem, if you replace it with a newer version.

There can be problems if you apply non-standard patches...
Thnx, it worked. :)

[LoRd_MuldeR]

That would be fine. Thanks

Try with this version please:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_launcher.2014-10-11.exe/download

[VideoFanatic]

I don't want to install it, do you have a portable version please like what's on VideoHelp.com?

[LoRd_MuldeR]

I don't want to install it, do you have a portable version please like what's on VideoHelp.com?

The installer contains the exactly same files as the ZIP package does. And it doesn't do much more than extracting those files to the target directory. There is no such thing as a separate "portable" version.

I don't have time to upload a ZIP package now. If you don't "trust" my installer for whatever reason, use 7-Zip/UniversalExtract to unzip the files. Or simply use a tool like Sandboxie ;)

[VideoFanatic]

The installer contains the exactly same files as the ZIP package does. And it doesn't do much more than extracting those files to the target directory. There is no such thing as a separate "portable" version.

I don't have time to upload a ZIP package now. If you don't "trust" my installer for whatever reason, use 7-Zip/UniversalExtract to unzip the files. Or simply use a tool like Sandboxie ;)

Thanks, I used the installer and the saving feature works.

There's a portable version here: http://www.videohelp.com/tools/Simple-x264-Launcher

I unzip it and it works, it's got all the template and preferences file in the same directory. Can I make a suggestion please. Why not only provide the portable version since it's less hassle. I don't see the point in using an installer when I can just unzip the portable version and it's ready to use.

I think you've told me before that the installer just extracts files but every time a see an installer I always think it installs something! It's not that I don't trust your installer, it's just that I don't want registry entries, etc written to windows when I can just use a portable version.

[LoRd_MuldeR]

There's a portable version here: http://www.videohelp.com/tools/Simple-x264-Launcher

As said before, there is no such thing as a separate "portable" version.

Apparently, Videohelp.com is just mirroring my files. Still, the files contained in the installer and in the ZIP package are one and the same! Calling the ZIP package a "portable version" is misleading here :rolleyes:

If you would have a look at the REAMDE file, it explains very well how to enable "portable" mode. And that's completely regardless of how you obtained the files...


Why not only provide the portable version since it's less hassle.

All binaries that I provide (installer and ZIP package) support the "portable" mode. There's no separate "portable" version. Again I advise you to have a look at the README file ;)


I don't see the point in using an installer when I can just unzip the portable version and it's ready to use.

Actually, a lot of people want the software to be "installed" locally - with shortcuts, a proper uninstaller and everything. So if only a ZIP package was provided, these people would not be happy and ask "Why only a ZIP file that I have to extract manually, when the installer is much more convenient?" Furthermore, the installer is much less error prone than the ZIP package! The installer makes sure that all files are extracted and that the correct directory structure will be preserved. It will also clean-up leftovers from a previous install. If the ZIP package is extracted manually, we can only hope that the user will extract all files. And we can only hope that whatever "unzip" tool he is using was setup to retain the directory structure...


I think you've told me before that the installer just extracts files but every time a see an installer I always think it installs something!

Well, I hope the installer does install something. Would be a rather nonsensical installer, if it didn't install anything :D

Though, in the case of Simple x264 Launcher, the installation process pretty much consists of extracting the program files, creating the shortcuts and registering the uninstaller.

(Yes, creating registry entries to make the system "recognize" the uninstaller is unavoidable. Those entries will be removed by the uninstaller)


It's not that I don't trust your installer, it's just that I don't want registry entries, etc written to windows when I can just use a portable version.

I think you should be using a tool like Sandboxie (http://www.sandboxie.com/) then. It probably makes your day ;)

[THEAST]

I started using Simple x264 Launcher instead of MeGUI since it offers the options to "pause" the encode. Yesterday I started an encode that was supposed to take nearly 6 hours to finish, paused the encode at 30% and hibernated my machine and today I started my machine and resumed the encode without issues but currently, the average fps and the eta are incorrect because it seems the time since the start of the encode is taken into account when calculating the average fps, instead of the time the encode has been active and hence, the eta is also incorrect. If possible, I'd really appreciate it if this issue is addressed in the upcoming versions.
Also I was wondering if there are any known issues with pausing the encode and hibernating the machine while it is paused.

Edit: I just noticed that Simple x264 Launcher's report is based on what x264 itself is reporting and the issue happens because x264 doesn't know it is being paused; is there a way to get around this?

[LoRd_MuldeR]

I started using Simple x264 Launcher instead of MeGUI since it offers the options to "pause" the encode. Yesterday I started an encode that was supposed to take nearly 6 hours to finish, paused the encode at 30% and hibernated my machine and today I started my machine and resumed the encode without issues but currently, the average fps and the eta are incorrect because it seems the time since the start of the encode is taken into account when calculating the average fps, instead of the time the encode has been active and hence, the eta is also incorrect. If possible, I'd really appreciate it if this issue is addressed in the upcoming versions.
Also I was wondering if there are any known issues with pausing the encode and hibernating the machine while it is paused.

This has been discussed several times before: The "FPS" value displayed by x264 is simply the total number of frames that have been encoded thus far divided through the total time that has elapsed since the encoding process was
started. Consequently, if you suspend the encoding process, time continues to go by, but no frames are encoded. Thus you will see the "FPS" value go down ;)

Edit: I just noticed that Simple x264 Launcher's report is based on what x264 itself is reporting and the issue happens because x264 doesn't know it is being paused; is there a way to get around this?

Yes, change the x264 code to compute the "FPS" in a different way. For example, on each progress update, they could take the number of frames that have been encoded since the last progress update and divide that through the time that has elapsed since the last progress update. Of course that would result in much more "unsteady" FPS. Maye some gradual update function like "FPS[i+1] = (α × FPS[i]) + ((1-α) × FPS_current)" could be used to compensate.

[THEAST]

Well, modifying x264 code isn't really something I'm capable of; I thought correcting the issue would be easier on Simple x264 Launcher since it is aware of when the process is paused and when it is working but it's most probably not on your list of priorities. I can live with it though, it's not really that big of an issue. :)

[LoRd_MuldeR]

Well, modifying x264 code isn't really something I'm capable of; I thought correcting the issue would be easier on Simple x264 Launcher since it is aware of when the process is paused and when it is working but it's most probably not on your list of priorities. I can live with it though, it's not really that big of an issue. :)

Nope. FPS is computed by x264 itself and the GUI simply displays that value. I theory, the GUI could implement its own FPS computation, but I hate to implement redundant functions ;)

I'd rather suggest you bother the x264 guys with your request...