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

[Keiyakusha]

I really like this small GUI but sometimes it crashes right after it finishes encoding. I can see the log in the background but I get a windows error message saying that the launcher.exe stopped working. It happens randomly and I can't figure out why. What I can exclude is my hardware, it is stable and not the issue.

I can confirm this. Also it crashed few times in the middle of encoding, but after I closed crash report the gui was still working however not responsive.

[ACrowley]

I don't see how this would be useful...



No need to use an external tool. As I have created the process(es), I already have the handles to suspend/resume them directly.

And if you click the "X" button, the encoding will be paused. Click "No" to resume...

Strange... my Postings are gone ?! i wrote a answer 2 Times ?

Pause/Suspend Mode doeasnt work here sometimes?

[LoRd_MuldeR]

Just be patient, it may take a moment ;)

[McArty]

I can confirm this. Also it crashed few times in the middle of encoding, but after I closed crash report the gui was still working however not responsive.

Me too, using Windows 7 here. But never in the middle of encoding, always at the end (sporadically), trying to right click to copy the log to the clipboard. No big issue, because the encode had ended.

[Chengbin]

LoRd_MuldeR

I'd just like to express my gratitude for this software. I could not praise it enough. The interface, simple, but extremely well designed. I couldn't fault the interface. It is just so ergonomically designed, with the auto save setting, to the command line, to displaying avisynth, avi2yuv, and x264 messages. It is simply fantastic. I'm not sure I've given out such praise for a long time, since I'm usually EXTREMELY HARD TO SATISFY. Maybe a little simplicity is what I needed in my complicated software life.

[ACrowley]

just want to say that the Suspend/Pause mode doesnt work here ..it doesnt work after any wait Time.
?

[LoRd_MuldeR]

Maybe I will implement a "real" suspend option one day ;)

[LoRd_MuldeR]

Updated x264 to r1332 (JEEB's builds). I also added a Suspend/Resume button, finally. That was more complicated than I had assumed ;)

(The Win32 API makes it pretty hard for us to suspend a process by ID. Finding grandchild-processes created by your child-process isn't very simple either ^^)

[RunningSkittle]

buggie, the pipebuffer was tested heavily by many users here. The conclusion that 4MB was the best in almost every scenario.

[ACrowley]

Updated x264 to r1332 (JEEB's builds). I also added a Suspend/Resume button, finally. That was more complicated than I had assumed ;)

(The Win32 API makes it pretty hard for us to suspend a process by ID. Finding grandchild-processes created by your child-process isn't very simple either ^^)

Thank you

Another Problem is that the gui crashes when encoding is done with a Apprcash Error ?

[LoRd_MuldeR]

Thank you

Another Problem is that the gui crashes when encoding is done with a Apprcash Error ?

Give my exact steps to reproduce the problem. It never happened to me...

[Zarxrax]

Regarding buffer size, what if the buffer was a multiple of frame size? Wouldn't this give optimal performance, as you would always be sending x264 exactly what it needs to encode an entire frame? Since avs2yuv is outputting raw data, we can calculate this from the resolution.

[LoRd_MuldeR]

Regarding buffer size, what if the buffer was a multiple of frame size? Wouldn't this give optimal performance, as you would always be sending x264 exactly what it needs to encode an entire frame? Since avs2yuv is outputting raw data, we can calculate this from the resolution.

I tried that. But it didn't improve things. It seems a 4MB buffer gives the best results under any circumstances. Maybe because that is the maximum memory page size on x86 computers...

[turbojet]

If you look through the benchmarks in this thread you'll see 1 and 2 MB buffer are more often faster than 4, 0 and 8 are some times faster as well, although about 5% max gain. I think it should an option, after all what use is a benchmark to find the fastest encode if you can't all the benchmark settings?

A very significant speed up is using x86 with first pass and veryfast, ultrafast presets, you can gain 20% fps in these situations and in my tests 2 pass is always significantly slower with x64 then it is x86 because you lose 10-15% fps on the first pass.

I've coded both of these in and reduced min x264 version to 1300 because 1332 is much slower, weightp breaks coreavc and is forced unless mbtree, psy-rd is disabled or interlaced is enabled. Also as it's a new feature without any public testing bugs can be expected. The only thing is I get a statement was expected but found a procedure error when compiling and I can't figure out what is causing it. Source here (http://www.mediafire.com/?zcujzzj4wdg) if anyone wants to look at it.

EDIT: also couldn't figure out how to set buffer size with a combobox.

[LoRd_MuldeR]

Weight-P is optional. It's on by default with "smart" (weightp=2) mode, yes. But you can reduce it to "blind" (weightp=1) mode or even disable it (weightp=0).

Additionally some of the faster presets reduce/disable Weight-P. The "baseline" profile will disable Weight-P too!

CoreAVC only has problems with "smart" mode. And even that only in Non-CUDA mode. Furthermore we shouldn't restrict our encodes, just because one decoder is broken.

Instead we should spread weightp=2 encodes and encourage the decoder developers to get their code fixed asap ;)

[dstln]

Hmm... new x64 build is freezing at random points during first pass in a full movie encode :-\ Just stops progressing and I need to abort...
Think it's an x264 build problem, gui or something else?

[LoRd_MuldeR]

I highly doubt a GUI problem, especially if the GUI window does still respond.

Also nothing changed on the GUI's side recently, as long as you don't use the new Suspend/Resume functionality.

So you may want to run x264 x64 from the console, just to be sure!

And it may also be Avisynth (or one of the filters/decoders involved) that stops delivering new data to x264...

[Maccara]

I also got this freeze with the latest. Just a "AviSource" (DV) and interlaced encoding (crf 22, bff, nalhrd, vbv params set & sar, otherwise medium default high profile without tunings, so weight-p was disabled too).

Worked fine from command line (just copy/pasted from GUI log).

Couldn't replicate from GUI either later with another file, so seems random. I find it unlikely GUI would cause something like this (especially since GUI remained functional), unless the "suspend" gets triggered somehow (unlikely).

Maybe some kind of thread-deadlock in new x264, but hard to say at this time.

[dstln]

Hmm... actually, it only happened when I manually used partitions -p8x8,b8x8,i8x8,i4x4

[turbojet]

Weight-P is optional. It's on by default with "smart" (weightp=2) mode, yes. But you can reduce it to "blind" (weightp=1) mode or even disable it (weightp=0).

Additionally some of the faster presets reduce/disable Weight-P. The "baseline" profile will disable Weight-P too!

I should have said there's no way to disable fade detection, setting --weightp 0 still has the slowdown.

CoreAVC only has problems with "smart" mode. And even that only in Non-CUDA mode. Furthermore we shouldn't restrict our encodes, just because one decoder is broken.

dxva bugs are starting to pop up too.

Instead we should spread weightp=2 encodes and encourage the decoder developers to get their code fixed asap ;)

This will only bring up more bug reports that are already known.

I've also had the random freezes with x264.nl and jeeb's builds. x264 doesn't crash it just stops updating and cpu drops to 0. It's happened with gui and cli on 4 full movie sources so far. I haven't been able to complete a second pass. x264 1319 worked on the same sources without a problem.

Tough to rely on this gui when it's locked to x264 1332.

[LoRd_MuldeR]

I didn't encounter any freezes with r1332 so far. But we should update to r1336 now, as it contains "various weightp fixes".

Hopefully the freeze problem some people encounter is gone too...

[LoRd_MuldeR]

Updated x264 to r1336 (JEEB's builds). It's recommended to update from r1332, as there were "various weightp fixes".

Also the minimum x264 revision supported by the GUI was reduced to r1318 again ;)

[dstln]

Still stuck hanging last night on firstpass. :-\

[LoRd_MuldeR]

Still stuck hanging last night on firstpass. :-\

If that problem isn't specific to my launcher (which appearently is the case), then this is the wrong thread to complain.

See here:
http://forum.doom9.org/showthread.php?p=1343696#post1343696

[Keiyakusha]

It seems I found a way to reproduce the crash. Edit: or maybe not...
Anyway it happened 3 times in a row when I watched something with MPC-HC in fullscreen. Message "encoding finished" appeared on top of the video, after I clicked OK, MPC-HC lost its focus (focus lost to launcher.exe) and GUI crashed.

[LoRd_MuldeR]

It seems I found a way to reproduce the crash. Edit: or maybe not...
Anyway it happened 3 times in a row when I watched something with MPC-HC in fullscreen. Message "encoding finished" appeared on top of the video, after I clicked OK, MPC-HC lost its focus (focus lost to launcher.exe) and GUI crashed.

I don't see how another process, such as MPC-HC, could crash my GUI process.

Well, unless MPC-HC injects a DLL into my process and the code in that DLL triggers a crash :p

So are you 100% sure it has something to with MCP-HC? I can't reproduce it here...

[LoRd_MuldeR]

Updated x264 to r1342 (JEEB's builds).

It's recommended to update ASAP, because in earlier revisions Weighted P-Frame Prediction could produce out-of-spec H.264 streams.

[Maccara]

Thanks!

I'll have to say, this is a neat utility for doing the occasional encode.

Only thing I wish this did have, was the ability to select several .avs files which would then all be encoded. Just batching.

I mean, no need for "fancy" queue system with separate settings per encode or anything like that - just set settings once, select a bunch of avs files and out comes a bunch of 264/mp4/mkv files with the avs files' basenames.

Would be a nice addition, but since the sources are provided I can add that myself at some point if I really really need it. :)

[HaraldBluetooth]

Thanks!

I'll have to say, this is a neat utility for doing the occasional encode.

Only thing I wish this did have, was the ability to select several .avs files which would then all be encoded. Just batching.

I mean, no need for "fancy" queue system with separate settings per encode or anything like that - just set settings once, select a bunch of avs files and out comes a bunch of 264/mp4/mkv files with the avs files' basenames.

Would be a nice addition, but since the sources are provided I can add that myself at some point if I really really need it. :)

:cool: It could be very nice to have that feature, so you could go to sleep or work, without wasting too much encoding time. :D

[Forteen88]

Thanks, but --zones doesn't work with this launcher ("error") :P I like to use zones to set even lower quality on end-credits.
EDIT: Though b=0.2 is probably better to use for end-credits than q=29 :P

[LoRd_MuldeR]

Thanks, but --zones doesn't work with this launcher ("error") :P I like to use zones to set even lower quality on end-credits (q=29).

There is no reason why that option shouldn't work. You can enter whatever "custom" parameters you like ;)

But the GUI won't check your custom parameters at all. Not even for correct syntax! The parameters are forwarded to x264 exactly as you enter them.

So probably there was a mistake in your custom parameters. But it's impossible to, because you didn't even paste your log...

[EDIT]

Does x264.exe (not the GUI) crash when using the "--zones" parameter? If so, then this is a bug with x264 or more specifically with x264 compiled under MinGW32.

It's not related to the GUI at all. You'd probably have to get a build of x264.exe that contains the "zone parse fix" patch...

[Forteen88]

... It's not related to the GUI at all. You'd probably have to get a build of x264.exe that contains the "zone parse fix" patch...I used the parameter: --zones 148400,153528,q=29
and I used the x264.r1342 that came with your latest launcher (and it used the x64-version of x264 when I encoded something). I'll try that parameter later (after I've done my current encode without zones, which will take some days) with only x264.r1342 in commandmode (but then with x264 32-bits).

EDIT: Thanks, I'll try that x264-build after I'm done with my current encode.
EDIT2: --zones worked when I changed x264-build...

[LoRd_MuldeR]

Your error description remains extremely vague. Anyway, try to replace the "x264_x64.exe" with that one:
http://komisar.gin.by/x264.1342kGIT.core2.x86_64.exe

(Note that you must rename the download to "x264_x64.exe" and replace the existing file)

[hxhxd]

LoRd_MuldeR, thanks for the great tool.
There's a feature request: Would you add the "delete intermediate files" feature?

edit: another feature request: automatic save program output into a log file.

Thanks!

[Rodger]

Before that there really should be implemented a shutdown feature.

Maybe Lord Mulder lets us know where this little puppy is headed.
Possibly someone is able/willing to support/help?!

[LoRd_MuldeR]

Updated x264 to r1347 (Komisar's builds).

[LoRd_MuldeR]

Updated x264 to r1352 (Komisar's builds).

[poisondeathray]

Nice little GUI! Simple, easy to use.

Small feature request: It's not a big deal, but since x264 supports .flv export now, can you add that too?

There might be a small spelling error, when it says "compleded" instead of "completed"

Thanks

[LoRd_MuldeR]

Small feature request: It's not a big deal, but since x264 supports .flv export now, can you add that too?

Done.

There might be a small spelling error, when it says "compleded" instead of "completed"

Fixed. Please re-download.

[poisondeathray]

Done.



Fixed. Please re-download.


Wow that was quick :)

[Rodger]

Little support/idea from my site, if not already known.

calling "rundll32.exe powrprof.dll,SetSuspendState" within a txt file named as a *.cmd does send the PC into sleeping mode.

A Shutdown / StandBy Option really is neccesary, when encodes take 2-3 hours or even more with "insane" settings.

[reik]

Hi,

first, i like your tool and use it for 1080p rips.
Can you add a small feature please? --> A logfile destination folder..
I would like to have a view on the quants from 1.pass just if the 2.pass has still started.. So i can see, if its worth waiting to complete the 2.pass or to abort and start again with more or less bitrate.

Keep on! :thanks:
reik

[turbojet]

Sounds good in practice reik and I've been searching for an estimated quality indicator in x264 for awhile now. But I found out ratefactor given from the first pass can be very inaccurate depending on what settings differ between first and second pass. It's better than nothing though. A few months ago I asked an x264 developer about rate factor updates/display during second pass for an accurate quality estimation. He said it would be added and I'm hopefully waiting for it.

[henryho_hk]

Download link seems broken...

[LoRd_MuldeR]

Works for me :confused:

[DarkZell666]

Works here also :)

[egrimisu]

I ha ve problem, everithing forks fine if using mpegsource or directshowsource or DGDecode_mpeg2source, but when using avisource the x264 launcher freezes at the step "preparing for encode" . However i can suspend it with no problems, or minimeze it.

[LoRd_MuldeR]

Probaply an issue with Avisynth/AVISource or (more liekly) the result of a borked VFW Codec. Try FFmpegSource2 as a replacement for AVISource.

[yesgrey]

There is a typo in the benchmarking text. It appears "Analayzing source file:".

[LoRd_MuldeR]

Thanks, will fix the typo with next release!