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

[WasF]

Why does the GUI enforce the use of a preset ? Where is the "none" entry in the drop menu ?

[LoRd_MuldeR]

The "Medium" preset is identical to x264's default.

Actually x264 first sets its defaults, then applies the selected preset and finally applies all other user options, if any.

(The "Medium" preset is implemented as changing nothing)

[WasF]

That was fast ! Thanks.
Would help (psychologically that is) if you added a "none" entry that secretly applies "Medium".

Now this launcher is looking close to perfection !
One concern though: can it really pause the encode ? I remember this as a hot topic few years ago, and artifacts were feared and all..
I guess you just suspend the process. To your knowledge, does x264 tolerate this with no effect on the output ?
(really, this feature should be implemented in x264 itself - like through a signal)

[VideoFanatic]

I'm not an expert but from what I've experienced and read, using dgavcnv will make decoding your video faster (serve the frames faster to your encoder) depending on what pure video engline your cuda card has.You do not need a high end card to get faster decoding, what you need is one with the latest vp engine. the vp engine doesn't change. i.e if you buy a $50 card with vp5 or a $500 card with vp5, it will still do the same job as it's the same vp on both.
http://neuron2.net/dgdecnv/dgdecnv.html is the software's webpage.

Thanks. I know about that webpage already but I was just wondering why the link on the following page to DGVC1DecNV doesn't work. Does that program no longer exist?:

http://www.videohelp.com/tools/DGAVCDec

Also on the http://neuron2.net/dgdecnv/dgdecnv.html page I don't see anything that mentions VP engine. Could you please show me a page from that software documentation that mentions VP engines?

Any idea what the cheapest VP5 supported graphics card is?

[mini-moose]

I was just wondering why the link on the following page to DGVC1DecNV doesn't work. Does that program no longer exist?:

DGVC1DecNV link I guess doesn't work cause that's an old version of what is now DGDecNV, for VC1 streams only. It was migrated into DGDecNV which supports also h264 and mpeg2 in addition to VC1 (all in one).
It costs a little but you get tons of licenses. I believe DGVC1DecNV was a payware as well.
I don't see anything that mentions VP engine. Could you please show me a page from that software documentation that mentions VP engines?
Any idea what the cheapest VP5 supported graphics card is?

I will need to search for it but you can have a look through the dgavcnv support forum. It should be discussed there. for example:
http://neuron2.net/board/viewtopic.php?f=8&t=199
http://neuron2.net/board/viewtopic.php?f=8&t=167

When you download the software package it comes with some html documentations. Might have more info there.

see also what op wrote earlier:
http://forum.doom9.org/showpost.php?p=1582382&postcount=846

I think GT 520 is one of the cheaper ones.
you can look here at a list of gpus, find the ones that say vp5 and compare prices:
http://en.wikipedia.org/wiki/Nvidia_PureVideo#Table_of_PureVideo_.28HD.29_GPUs

edit:

look at the DGDecodeNVManual.html and DGIndexNVManual.html that come with the application package:
"The "NV" in the name "DGDecodeNV" indicates that this version of the program is designed for use with the VP2 (or greater) GPU decoder on some Nvidia video cards...."

[VideoFanatic]

OK now I'm confused. I saw a post that said "DGDecNV has allowed us to decode video using CUDA, as well as the option we have always had to decode using VP". How do I know which to use? CUDA or VP?

[mini-moose]

OK now I'm confused.

you seem to be overthinking it. I don't know a whole lot on how something works just what it does for my needs:)

DGAVCNV decodes streams using the purevideo (vp) engine on nvidia cuda cards. You load your video on this tool, save it to a project file. Serve the project file on your .avs script and encode. Simple :)

[LoRd_MuldeR]

OK now I'm confused. I saw a post that said "DGDecNV has allowed us to decode video using CUDA, as well as the option we have always had to decode using VP". How do I know which to use? CUDA or VP?

CUDA is an interface to access the graphic's processor (GPU) for running "arbitrary" calculations. OpenCL and DirectCompute basically do the same. However nobody would implement a video decoder on the GPU using CUDA (or OpenCL or DirectCompute). That's because all graphic's cards from the last ~8 years have dedicated video decoding units! NVidia calls it "PureVideo HD" while AMD/ATI calls it "Unified Video Decoder" (UVD). Once again, several interfaces to access the graphic card's hardware video decoder unit exist, such as DirectX Video Acceleration (DXVA). Another one, created by NVidia and supported exclusively by NVidia cards, is CUVID (the "CUDA Video API"). Don't confuse CUVID with CUDA itself! Applications using CUDA are using the actual GPU and they have to upload their own program code (called a "kernel") into the GPU. At the same time, applications using CUVID are simply using the hardwired video decoder unit, which is not programmable at all.

As for DGDecNV: It is based on CUVID and thus the minimum hardware requirement is an NVidia card with VP2 (i.e. the second generation of "PureVideo HD") or newer. Look at the table (http://en.wikipedia.org/wiki/PureVideo#Table_of_PureVideo_.28HD.29_GPUs) to see which cards are suitable...

[LoRd_MuldeR]

That was fast ! Thanks.
Would help (psychologically that is) if you added a "none" entry that secretly applies "Medium".

I prefer to stick with the same names that x264 itself uses.

One concern though: can it really pause the encode ? I remember this as a hot topic few years ago, and artifacts were feared and all..
I guess you just suspend the process. To your knowledge, does x264 tolerate this with no effect on the output ?
(really, this feature should be implemented in x264 itself - like through a signal)

Interestingly the Win32 API doesn't provide a function to suspend a complete process. Instead we have to enumerate all threads of the process and suspend them one-by-one. Later we will enumerate the process' threads again and resume them one-by-one. In case of x264, however, it is sufficient to just suspend/resume the "main" thread ;)

And yes, this should be perfectly safe. Actually the operating system's scheduler suspends and resumes the processes/threads running on your computer all the time. This is called "preemptive multi-tasking" and it is the way how multi-tasking is implemented on all modern operating systems - including Microsoft Windows. Please see here (http://en.wikipedia.org/wiki/Preemption_%28computing%29#Preemptive_multitasking) for details!

In other words: Operating systems, except for special "real time" operating systems, never give any timing guarantees. Thus a program requiring that it never gets suspended (for longer than x seconds) is bound to fail in the first place...

(BTW: The only "side effect" of suspending the x264 process I ever noticed is that the "fps" and "eta" progress indicators will get confused)

[WasF]

I prefer to stick with the same names that x264 itself uses.

That was.. not so fast this time :p But hey: worth the wait, though ! :D
Don't worry, my suggestion was of "psychological" order, to remove the false impression that the GUI was imposing something it shouldn't impose..
Funny to see how "open sourcers" keep having allergies to this kind of stuff ! (dirty codename: usability :devil:).

The only "side effect".. is that the "fps" and "eta" progress indicators will get confused
That rings a bell ! I seem to remember this as "slow restart", when it's actually the indicators that get crooked. I guess the fps and eta values are computed using absolute time, not "actually running time", so it's normal. This is why this should be supported by x264 itself: the process can't know it got suspended, and could receive this info through a signal and subtract the "pause time" from absolute time.
(I remember now: the "hot topic" I mentioned was actually about complete stop/resume, not just pause, which, I guess, is not even on x264 people's radar, given that they don't even support pause/resume. Would be a huge convenience though, but, hey, it's open source, so, remember, dirty codename again !)

Alright, Simple x264 Launcher::Pesky_users++ (how is this good news for you ?! :sly:)

[LoRd_MuldeR]

It should be obvious that the average "fps" (and thus the "eta") is approixmated as follows:
FPS = frames_processed_so_far / ( time(right_now) - time(start_of_encode) )

In therory it would be possible to use the time that the process has actually been active on the CPU, referred to as the process' "virtual time". But it would be neccesarry to use platform-specific functions to determine this info, making the code less portable. Also the "eta" would then be expressed in "virtual" time rather than "real" time, which is confusing for the user! Imagine two instances of x264 are running in parallel and each instance uses ~50% of the CPU time. In that case the "virtual" time of each process would be running at 0.5x speed of the "real" time. Thus, in this case and if we calculated the "eta" based on "virtual" time, then an "eta" auf 1 hour would mean the user still has to wait ~2 hours for the encode to finish. Not very obvious...

[WasF]

Yes: when the system scheduler is involved, it's hard to deduce the real run time.
That's why I was talking about an external information telling the process explicitly: now, you nap. Or: now, you wake up.
This would be trivial to use : just subtract the difference from your timeline : time(right_now) - time(start_of_encode) - cumulated_naps
No guessing involved.
P.S.: and less portable is fine by me, if it gets me this convenience ! It can be made a patch, to preserve the main codebase.:rolleyes:

[bugmen0t]

hai, mulder :D

can you make a tutorial how to use this app

i can find how to resize ouput video :(

thnks for reply

[LoRd_MuldeR]

hai, mulder :D

can you make a tutorial how to use this app

i can find how to resize ouput video :(

thnks for reply

This is just a simple GUI for the x264 encoder.

However there are different ways to resize the input video. If you use an Avisynth script as your source, simply use one of Avisynth' resize functions in your script:
http://avisynth.org/mediawiki/Resize

If you use FFMS2/LAVF input, you can use x264' built-in resize filter, by adding "--video-filter resize:640,480" to the custom x264 options. (replace the numbers as needed!)

[r0lZ]

If you use FFMS2/LAVF input, ...Why? It is not possible to resize any input video type with x264?

[LoRd_MuldeR]

Why? It is not possible to resize any input video type with x264?

Sure it is. But with FFMS2/LAVF input the built-in filters are your only option, while with With Avisynth input you can apply filters on the Avisynth side as well.

Also I'm assuming that in case bugmen0t is using Avisynth input, he should be familiar with Avisynth scripting and thus should be able to add the Resize() filter to his script easily.

An surprisingly large number of users seem to have problems with figuring out the correct syntax for x264's built-in filters ;)

[r0lZ]

Ah, OK. I did not understand your reply correctly. I thought you said that with avisynth, your only option is to use the avisynth resize.

BTW, I'm still wondering what is the fastest resize (with equivalent filter quality). Avisynth or x264?
And it is better to let avisynth do the resize to leave more processor time to x264 for the h264 encoding stricto-sensu?

[LoRd_MuldeR]

Why should letting Avisynth do the resize leave more processor time to x264? They are running on the same CPU! And, unless you put Avisynth into its own process (e.g. via avs2yuv), they even run in the context of the same process! So whether you spend those CPU cycles required for the resize in x264's resize code or in Avisynth' resize code doesn't matter at all - as long as we assume neither code is faster. Whether the resize code in Avisynth or the resize code in libswscale (that's what x264 uses) is better optimized for speed, I have no idea. The resize algorithms they implement mostly are the same (Bilinear, Bicubic, Lanczos, Spline resize). Nonetheless I think using Avisynth input causes at least some performance overhead, compared to the built-in decoders. On the other hand, most Avisynth users use FFVideoSource() from FFMS2 nowadays, which is exactly the same library that x264's built-in decoder uses by default. So it shouldn't make much difference. For me there are three main reasons to use Avisynth: Complex filter scripts that x264 can't do (QTGMC is the best example here!), sources that x264 can't read by itself (e.g. something that needs Avisynth' AVISource or DirectShowSource) and GPU-based decoding via DGDecodeNV - the latter indeed does free some CPU cycles for x264, because it leaves the decoding to the hardware decoder. In all other cases I wouldn't use Avisynth input...

[r0lZ]

Thanks for the extended and clear reply.

When I'll have some time, I will try to compare the performances of the avisynth and x264 resize filters...

[bugmen0t]

thnks for advice mulder :D

"--video-filter resize:640,480"
seems good for me :p
http://photoserver.ws/images/7aDd4e059ddc241d9.gif

[lansing]

hi I'm trying to encode my bluray video with 10bit encoding, so I checked the "use 10-bit" setting, but i keep getting random "warning: avisynth process exited with error code: -1073741819" during the encoding, and then the whole process just stopped and was labeled completed.

What is wrong?

[LoRd_MuldeR]

hi I'm trying to encode my bluray video with 10bit encoding, so I checked the "use 10-bit" setting, but i keep getting random "warning: avisynth process exited with error code: -1073741819" during the encoding, and then the whole process just stopped and was labeled completed.

What is wrong?

Obviously Avisyth (or one of the plug-in's involved) has crashed, i.e. your problem is not related to Simple x264 Launcher.

(As always in this situation, try to open the exact same script in VirtualDub and check if it plays all the way from start to finish)

[lansing]

Obviously Avisyth (or one of the plug-in's involved) has crashed, i.e. your problem is not related to Simple x264 Launcher.

(As always in this situation, try to open the exact same script in VirtualDub and check if it plays all the way from start to finish)

ok, thanks. I was loading a virtualdub plugin in my script, and just tested with a preroll of 1, and everything seems alright now.

[mini-moose]

I know you were all against my suggestion to include a separate cmd option for 1st pass on 2-pass option but the new x264 feature kind of requires it, in fact it even requires using a different avs (if one is using avs). Of course since it's a "simple" launcher maybe it's not meant to support this feature.

[LoRd_MuldeR]

I know you were all against my suggestion to include a separate cmd option for 1st pass on 2-pass option but the new x264 feature kind of requires it, in fact it even requires using a different avs (if one is using avs). Of course since it's a "simple" launcher maybe it's not meant to support this feature.

What feature should that be ???

[mini-moose]

What feature should that be ???

"Support changing resolutions between passes with macroblock-tree
Implement a basic separable bilinear filter to rescale the quantizer offsets.
Structure inspired by swscale, but floating-point instead of fixed-point.
Not as optimized as it could be, but it's quite fast already.

Example compression penalties on a 720p video game recording:
First pass with 720p and second as 480p: ~-1.5% (vs. same res)
First pass with 480p and second as 720p: ~-3% (vs. same res)"

[LoRd_MuldeR]

This commit allows x264 to change the resolution between passes - now also with MB-Tree rate-control enabled. The commit message also shows some examples of the expected compression penalty for doing so.

It certainly does not say that it is recommended to change the resolution between passes. Actually the expected compression penalty means that you do not want to change the resolution between passes, unless you absolutely have to...

(There may be specific use-cases for changing the resolution between passes, but that's certainly not what a regular user should be doing. Thus I see no reason to encourage people to do it, just because "it can be done")

[mini-moose]

This commit allows x264 to change the resolution between passes - with MB-Tree rate-control enabled.

yes, I'm aware of what it is.
As I said maybe it's not the place for app called "simple" to mess about with "advanced". Mentioned it cause it's a new feature which require some changes between passes.
However since you already have an option to add custom x264 parameters, simple can become advanced for non-default users, so I thought it's worth mentioning.

[mini-moose]

I tried using .avs for load/crop/fps but resize via x264. With the x264 version that comes with the app I get considerably slower encodes than using the x264.nl one (both supposed to be Komisar's but seem different).

Much slower on 1st pass and just slightly less on second.
I tested the same encode with the app and with a batch file using app x264 and x264.nl one and the results correspond with what I described above.

App x264:
1st - encoded 10001 frames, 39.66 fps, 5354.61 kb/s
2nd - encoded 10001 frames, 24.81 fps, 5374.17 kb/s

x264.nl x264:
1st - encoded 10001 frames, 65.23 fps, 5354.61 kb/s
2nd - encoded 10001 frames, 26.60 fps, 5374.17 kb/s

x264 resize was: --vf resize:width=1280,height=696,method=spline,sar=1:1

resizing in .avs produces same speeds for both x264.exe versions.

[kypec]

can I ask what builds of x264 you are using? self compiled? the logs suggest it may be the same one available on x264.nl but I noticed the ones coming with the application are slightly smaller in size (same for avs2yuv).
Looking closely into the log output will tell you who has built it: x264 0.125.2200 999b753
(libswscale 2.1.100)
(libavformat 54.6.100)
(ffmpegsource 2.17.1.3)
built by Komisar on May 23 2012, gcc: 4.7.0 (multilib.generic.Komisar) (http://komisar.gin.by/)
configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

x264 revision: 2200 (core #125)

[mini-moose]

Looking closely into the log output will tell you who has built it

yes, I have checked the logs. It's a little confusing.
Though both x264.nl and the one that comes with the launcher are said to be komisar's, the one downloadable is 10.1mb and the launcher one is 8.5mb. I guess the build with launcher is different.

I replaced the one in toolset with the one from the website and ran it. It doesn't show a compiler name and has some other differences. I wouldn't care too much if they didn't behave differently with the parms described before.

launcher (8.5mb):
x264 0.125.2208 d9d2288
(libswscale 2.1.100)
(libavformat 54.17.100)
(ffmpegsource 2.17.2.1)
built by Komisar on Jul 19 2012, gcc: 4.7.1 (multilib.generic.Komisar)
configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

x264.nl (10.1mb):
x264 0.125.2208 d9d2288
(libswscale 2.1.0)
(libavformat 54.9.0)
(ffmpegsource 2.17.2.1)
built on Jul 18 2012, gcc: 4.7.1
configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: LGPL version 2.1 or later

both are r2208 x64 of course.

[LoRd_MuldeR]

I took the builds that are bundled with Simple x264 Launcher directly from Komisar's web-site (http://komisar.gin.by/).

They have been built with GCC 4.7.1, while the builds on x264.nl (http://x264.nl/) apparently have been built with GCC 4.5.3 - assuming the info on the web-site is correct.

If I understand you correctly, the Komisar web-site build is slower, but only when the "built-in" resize filte is used? - I assume you verified this with multiple runs to rule out the usual fluctuations.

Well, this may be caused by a different version of libswsclae - the library used by x264's built-in resize filter. Or by the different GCC version. Or by a combination of both.

BTW: Other people have complained about "unusal" slow resizing before, so there indeed might be a problem with Komisar's GCC 4.7 build and the "resize" filter. I don't resize a lot ;)

[mini-moose]

If I understand you correctly, the Komisar web-site build is slower, but only when the "built-in" resize filte is used? - I assume you verified this with multiple runs to rule out the usual fluctuations.


correct. I did a few runs using the build you use - with and without the launcher.

[r0lZ]

And when you use the AviSynth resize, is it faster or slower (with a similar resize filter giving proximately the same quality)?

[mini-moose]

And when you use the AviSynth resize, is it faster or slower

avisynth resizing is same for both x264 builds from what I remember. Certainly nothing that seemed out of the ordinary different.

[r0lZ]

Yes, I understand that. But what I would like to know is if the avisynth resize is faster or slower than the x264 resize. It is difficult to compare them, as we can't be sure that they offer exactly the same quality, but an approximation of the speed difference would be an interesting information anyway.

[mini-moose]

I would like to know is if the avisynth resize is faster or slower than the x264 resize.

x264 seems to be faster. I can't tell you if it's as good but it has the same type of resizers avisynth does : fastbilinear, bilinear, bicubic, experimental, point, area, bicublin, gauss, sinc, lanczos, spline (method names copied from the x264 help). Though I think it doesn't make a big difference when you are using single pass encodes unless you use faster presets. It's more evident in fast passes (like 1st pass in 2-pass).

[r0lZ]

OK, thanks for the info.
BTW, do you know what the "experimental" resize is? Is it reliable?

[mini-moose]

BTW, do you know what the "experimental" resize is? Is it reliable?

no idea. I stick the ones I know from avisynth.

[DaRkBoZ]

Hey :)

Thanks a lot for this excellent tool.

I've read in your documentation that you don't want to make it compatible with x264 binaries others than the one you packed with it.

Would it be possible to make an exception about that ? I use a special compilation of x264 with many patches and until then it was working with it, but now i dunno why it can't obtain the version from the --version switch, but it work perfectly when i call it myself from cmdline.

That would be awesome if you could make it work with it (or maybe just add an option so that the x264 version is ignored or/and forced :) )

The version i use are from here : http://astrataro.wordpress.com/category/encode/x264/

Theses custom builds are great especially the 8bit one with the AQ modding, and the 10 bits one i use for the FGO patch aside from others (i know jeebs build have the FGO patch, but i find them to be less fast and crashed on me on many occasions, and he didn't updated to 2208 yet (only 2200).

Thanks a lot in advance for your reply about that, i would really like to continue using your GUI :)

[Keiyakusha]

I use these builds with no problems so far Oo
Maybe you didn't renamed them correctly?
On x264.nl these are JEEB's builds too. At least that's what they say in parentheses.

P.S.
These AQ patches are no good imho. The only thing they can - make everything flat. They are probably good for encoding flash vector animation. Perhaps that's why they forever "patches" and not official.

[DaRkBoZ]

Oh it was working before the latest x264 launcher (v2.05.346) now with this version and the Taro x264 v2208, i get this error.

--- CHECK VERSION ---

Creating process:
D:/ENCODES/sx264launcher/toolset/x264_10bit_x64.exe --version
FAILED TO DETERMINE X264 VERSION !!!

when i do it by hand with the cmdline i obtain

(Taro v2208)

x264 0.125.2208+677+32 26f090e tMod [10-bit@4:2:0 X86_64]
(libswscale 2.1.100)
(libavformat 54.18.100)
(ffmpegsource 2.17.2.1)
built on Jul 20 2012, gcc: 4.7.1
configuration: --bit-depth=10 --chroma-format=420
x264 license: Non-Free
libswscale/libavformat/ffmpegsource license: nonfree and unredistributable
WARNING: This binary is unredistributable!

(Taro v2200)

x264 0.125.2200+666+30 20c70fc tMod [10-bit@4:2:0 X86_64]
(libswscale 2.1.0)
(libavformat 54.3.0)
(ffmpegsource 2.17.1.3)
built on May 25 2012, gcc: 4.7.0
configuration: --bit-depth=10 --chroma-format=420
x264 license: Non-Free
libswscale/libavformat/ffmpegsource license: nonfree and unredistributable
WARNING: This binary is unredistributable!

So i guess the launcher can't parse the version number correctly and it make it crash :)

PS : I agree with you for the AQmode patch mod 1 & mod2 but the 8 bits patch with MixAQ and OreAQ yield interesting result when you want 8 bits, but yeah i'am in it especially for the FGO patch since jeebs didn't updated his, and they're a bit less fast and stable :)

[Keiyakusha]

Hmm, let me make it clear.... when you try to add --version in custom commandline in GUI and run this job - it fails? If so, I never tried this. Why would anyone want to do it?
For normal encoding without specifying weird commandline options latest Launcher with 2208 taro's builds worked for me just about yesterday... And I remember I tried every his build including "light" package. Unfortunately can't verify this mystery right now.

[DaRkBoZ]

i don't add --version as a custom command line in the launcher.

The launcher do it itself to determine the version, if you use a too old x264 version the launcher will tell you and will not launch the encode (that's what i had when i used jeebs 2200 it tell you the launcher can't work with version under 2201)

Why would i add myself the --version to the custom cmd line ^^

EDIT : Ok lol since you told me it was working well for you, i kinda begun searching for alternative issues/solutions, i finally found what was the issue after using a process spy, i use a passive protection program, and this dumb silly apps was blocking the new x264 binary, now i added it to the trusted files and it work ! damn i'am feeling dumb now haha. Well moving along then, thanks for the info Keiya, and sorry about taking your time.

Well at least now i can enjoy again this nice launcher

[LoRd_MuldeR]

I've read in your documentation that you don't want to make it compatible with x264 binaries others than the one you packed with it.

Hello, DaRkBoZ.

I just want to make clear that my intention certainly is not to make the Simple x264 Launcher "incompatible" with other x264 binaries. The program is written to work with the latest "official" x264 version. The binaries included in the package are just "vanilla" builds and they have been tested to work with the GUI properly, so for most users it is recommended to stick with these binaries. Nonetheless other x264 binaries will work just as well - as long as they don't break compatibility with the "standard" x264 CLI syntax or the "standard" x264 console output format.

BTW: The program has to parse the version number, because it will refuse to run with outdated x264 versions. This is required to ensure that the user doesn't use some "archaic" x264 version which is lacking support for some of the CLI options used by the GUI. Furthermore people tend to be lazy with keeping their software up-to-date. As x264 is constantly improving and fixing bugs, it certainly doesn't hurt to enforce an update now and then! I know that this can be annoying, if you depend on a "special" build that contains certain patches you want to use. However, if these patches haven't been ported to up-to-date x264 or nobody is building with these patches anymore, then this shows that those patches either have become obsolete or whatever approach they tried to implement turned out to be the wrong way...

Anyway, glad to hear that you solved your problem ;)

[DaRkBoZ]

Hey, thanks ;)

Oh yeah sorry about that, i didn't wished to say it like this, not that you didn't wanted to make it incompatible with other x264 releases, more like you prefered to keep your launcher as close as standard and not code special feature for everything out there (and on this point i agree, and understand :) )

Anyway yeah i'am happy to be able to use my fav launcher again, thx again :cool:

Oh btw when i'am here, i wished to ask, would it be possible in the future to be able to modify a profile you created beforehand and save it directly instead of only having the "save as" ? :)

thanks :)

[wcwman18]

Any plans to provide audio support at all?

[LoRd_MuldeR]

Simple x264 Launcher is a GUI for x264. As long as x264 doesn't support audio encoding, the answer is no ;)

Having said that, there is an "unofficial" x264 audio support branch, which you can use for audio encoding via x264. Such builds will work with the Simple x264 Launcher.

There even is some information in the Readme file. If you haven't read that file yet, you may want to have a look now...

[Atak_Snajpera]

if you need audio support then you should just use ffmpeg. x264 with audio encoding is just silly.

[LoRd_MuldeR]

if you need audio support then you should just use ffmpeg. x264 with audio encoding is just silly.

...or one of the various "Swiss army knife" GUI's that use x264 plus some AAC/Vorbis encoder plus some MP4/MKV muxer to handle video encoding, audio encoding and muxing all at once.

Simple x264 Launcher was never created to be yet another MeGUI clone ;)