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

[shinchiro]

Today just encoding with your tool with updated x264 (rev 2183) but I get API problem. I don't know if the problem related with your tool or avs2yuv itself :o:

Creating process:
"C:/Program Files (x86)/MuldeR/Simple x264 Launcher v2/toolset/avs2yuv.exe"

Avs2YUV 0.24bm2

x264 revision: 2183 (core #122)
Avs2YUV version: 0.24.2

WARNING: Your revision of x264 uses an unsupported core (API) version, take care!
This application works best with x264 core (API) version 120.

..and then
Warning: Avisynth did not respond for 60 seconds, potential deadlock...

[Marin85]

@Marin85: here's my suggestion for you

Create 2 individual folders e.g. Launcher8b & Launcher10b.
Copy Launcher.exe and other required executables in both folders - these are small enough.
Keep 8-bit x264 executables in the first folder, 10-bit x264 executables in the other.
Put shortcuts to each of your launcher.exe on your desktop or wherever else you need them.
Launch the appropriate launcher as desired ;)


This is very cool idea! :cool: I did not realize at all this could be done this way.

Indeed, my suggestion for 10-bit x264 support was motivated by the fact that replacing 8-bit with 10-bit and vice versa seems like unnecessary complicated step one has to do with many of the other GUIs, too. Well, I guess, not anymore :p

@LoRd_MuldeR: You are probably aware that LAV filters, CoreAVC and the new ffdshow builds can decode 10-bit H.264. Hence installing one of them on HTPC technically gives you hardware support for 10-bit H.264 (though not natively, of course) :p

And thanks for your replies to my other points. I am looking forward to what you are going to code for the "fast-bulk-encoding" (so to replace writing batch scripts..) and the keyboard shortcuts.

[LoRd_MuldeR]

Creating process:
"C:/Program Files (x86)/MuldeR/Simple x264 Launcher v2/toolset/avs2yuv.exe"

Avs2YUV 0.24bm2

x264 revision: 2183 (core #122)
Avs2YUV version: 0.24.2

WARNING: Your revision of x264 uses an unsupported core (API) version, take care!
This application works best with x264 core (API) version 120.

That's not a big deal. The last build of Simple x264 Launcher was tested with x264 core-120.

Now the latest x264 has increased the "core" version to 122 which potentially breaks compatibility - thus the warning message.

Still it's just a warning and you can probably ignore that. I will increase the expected core version to 122 soon...

..and then
Warning: Avisynth did not respond for 60 seconds, potential deadlock...

It means that your Avisynth script either encountered a deadlock or simply took very long to open.

That often happens with FFVideoSource(), if the index file still has to be created. You may use "ffmsindex.exe" to avoid that situation.

If Avisynth takes too long to open (more than 5 minutes), then Simple x264 Launcher will eventually kill the job...

You are probably aware that LAV filters, CoreAVC and the new ffdshow builds can decode 10-bit H.264. Hence installing one of them on HTPC technically gives you hardware support for 10-bit H.264 (though not natively, of course) :p

These all are pure software decoders. Running them on a HTPC doesn't change that fact (CoreAVC does support h/w decoding, but I'm pretty sure not for 10-Bit).

The problem is, when you give people a "10-Bit" option, they will start using it, because "more is better". Most people don't have the technical background to understand what it means.

And indeed, if you test it on your PC or HTPC, then it will play just fine, e.g. with a lavc-based decoder. But as soon as you try on your hardware (standalone) player, the file will fail!

Of course most users will then blame the GUI program for having created a "broken" file :rolleyes:

[Marin85]

These all are pure software decoders.
Yeah, I know, I was merely joking about the hardware part. But one cannot deny that 10-bit x264 has been gathering the hype for some time now, for whatever that is worth. Personally, I have not been able to justify the performance penalty in the case of fullhd encoding. Maybe there is some hidden setting that unlocks the power of 10-bit x264 :p (That is to say that 8-bit x264 is already impressively good.) \\OT

EDIT: My observations on the 10-bit x264 are limited only to 1080 movies only. I have little experience with animation or lower resolutions.

[naoan]

I can no longer see any banding at my usual bitrate/CRF for anime/cartoon with 10 bit encoding. YMMV of course.

[darkio]

@LoRd_MuldeR:
Little question: I've a lot tv show from DVD source and I wish to convert into H264 (mkv) using x264 cli command only without avisynth. Using simplex264gui, I've not problem with crop or resize command, but I've not found a good method for deinterlace my source to 576P. Do exist command for this ? I've read full help command, but I've not found anything useful.

[LoRd_MuldeR]

Apparently there is no deinterlace filter among the built-in video filters of x264. Use one of the various Avisynth deinterlacers, such as QTGMC.

I think there are some patched x264 builds with built-in "Yadif" filter. But Yadif isn't a great deinterlacer anyway - it's okay for the speed it delivers, but something like QTGMC is much better.

Another option would be using FFmpeg or MEncoder instead of the x264 CLI encoder. These should provide various deinterlacing options without using Avisynth.

[Marin85]

I hope I am not overflowing your topic too much, but the whole talking about replacing x264 builds got me an idea about a little but useful thing, namely to include a shortcut to the program folder of Simple x264 Launcher somewhere in the menus, similarly to what AvsPmod has for the Avisynth plugins. I believe it will be useful to those who want to always stay on the cutting edge with x264 builds or would like to use their own (possibly patched) builds.

[reff24]

When will these functions (http://forum.doom9.org/showpost.php?p=1561664&postcount=688)? That would be a real enrichment!

[LoRd_MuldeR]

When will these functions (http://forum.doom9.org/showpost.php?p=1561664&postcount=688)? That would be a real enrichment!

As said before, there are no plans for that.

[reff24]

Too bad that would add value to this very good program even further. and bring more users and inspire.

[Chumbo]

Any chance of getting the estimated time of completion added to the status of avs2yuv as well as the current/total frames? I liked having that info when running x264 directly. Thanks for considering it.

[LoRd_MuldeR]

Any chance of getting the estimated time of completion added to the status of avs2yuv as well as the current/total frames? I liked having that info when running x264 directly. Thanks for considering it.

x264 calculates/outputs that info, not avs2yuv!

If, however, you feed x264 with data from the STDIN (like when you use avs2yuv), it cannot know the number of total frames!

Therefore you have to use the "--frames" switch and this way tell x264 the total number of frames. Then it will display progress, as usual.

(That's exactly what the Simple x264 Launcher does to get x264 print status messages)

[Chumbo]

x264 calculates/outputs that info, not avs2yuv!

If, however, you feed x264 with data from the STDIN (like when you use avs2yuv), it cannot know the number of total frames!

Therefore you have to use the "--frames" switch and this way tell x264 the total number of frames. Then it will display progress, as usual.

(That's exactly what the Simple x264 Launcher does to get x264 print status messages)
Aha, so that's why that info doesn't show up. I was wondering about that. Thanks for the clear explanation as always. :)

[Abyssal]

Resizing is supported just fine. If you don't resize on the Avisynth side, you can use x264's resize filter with a simple custom command.

(It has been explain in this thread)



10-Bit already is supported in the only way it can be supported: You will have to replace the 8-Bit x264 binary with a 10-Bit x264 binary.

If you get errors with the 10-Bit binary, then please give me detailed instructions on how to reproduce the issue...

I actually got it to work now. I might have used a bad x264 revision or the file might have been corrupted or so. I know from previous experience some GUIs tend to have problems with some x264s - some with just a single, others with more. I just grabbed the latest now and it worked mighty fine. Still in encoding process though but so far so good. :)

[shinchiro]

Just some idea. What do you think about adding option to delay starting of queued jobs? Like 10, 20 minutes.. Because some folk may not have proper cooling down system when encoding like laptop. So the delay option may help to cool down the laptop when there are ton of awaiting queued jobs in the gui

*I just speak out idea which come out from my mind. Ignore it if you think unnecessary ;)

[LoRd_MuldeR]

Just some idea. What do you think about adding option to delay starting of queued jobs? Like 10, 20 minutes.. Because some folk may not have proper cooling down system when encoding like laptop. So the delay option may help to cool down the laptop when there are ton of awaiting queued jobs in the gui

*I just speak out idea which come out from my mind. Ignore it if you think unnecessary ;)

This makes no sense at all. A typical encode takes hours. This means the CPU will be running at 100% for several hours during the encode. And CPU's are made to run stable under these conditions! So if your CPU is "overheating" when you put it under full load for a longer time, which may result in throttling or finally in an emergency power-off, then there obviously is something seriously wrong with your cooling! This means you will have to get an adequate cooling. If that happens with a "new" laptop, then this indicates that the laptop is a faulty design, so you should get your money back. If it happens with an "older" laptop that used to work fine, there probably is too much dust inside and you need to clean the dust out.

Putting a pause of 20 minutes between two consecutive encodes doesn't help at all here! If the computer was running stable for hours to finish the previous encode, then it will continue to do so with the next encode - no break between the encodes is required. And if the computer does NOT run stable, it will probably power-off itself (or just crash/freeze) during the encode, i.e. long before it reaches the pause. In any case, inserting a pause would only be an ugly workaround for the symptoms of inadequate cooling. Rather than applying such workarounds and risking hardware damage in the long term, you should fix the cause of the problem, i.e. get an adequate cooling for your CPU...

(All above comments apply for computers which are running the CPU at "standard" clock frequency, of course. If your CPU became unstable as a result of "overclocking" attempts, revert to the defaults ASAP!)

[Chumbo]

@LoRd_MuldeR,
I had a real strange issue come up today. I noticed that one of my files did not encode. After some digging I found, eventually, that avs2yuv was crashing on pass 2 for some reason. I hope you may be able to shed some light on this. So pass 1 encodes just fine (I'm feeding the avs file via avs2yuv into x264 64bit) and creates the stats files. But when I get to pass 2 avs2yuv reports the following after I ran it manually to see what's going on:avs2yuv "file_p1.avs" -
file_p1.avs: 1920x1080, 60000/2002 fps, 12396 frames
YUV4MPEG2 W1920 H1080 F60000:2002 Ip A0:0 C420mpeg2
error: wrote only 3085668 of 3110400 bytes
In case you're wondering, the avs file is reading a dgi file. This is only happening on this one file out of 45 files of which the other 44 were fine. Let me know if you need more info. Thank you.

[LoRd_MuldeR]

Doesn't make much sense that avs2yuv crashes with the same AVS script in the second pass, while the first one runs trough fine.

That's because avs2yuv doesn't know anything about passes. It just requests the raw video data from Avisynth and passes it to the STDOUT, where x264 will grab the data.

Consequently pass 1 or 2 doesn't make any difference for avs2yuv. It has absolutely no idea who or what is reading the data (and what for) that it writes to the STDOUT ;)

But the error "wrote only X of Y bytes" indicates that x264 (or whatever process the pipe was connected to) terminated before avs2yuv could write all data.

(So probably x264 just crashed/failed for some reason! Didn't x264 output any error/warning message ???)


To make sure that avs2yuv (or Avisynth) isn't failing, you may try this:
for %%i in (1 2 3 4) do (
avs2yuv "file_p1.avs" - > NULL
)

If avs2yuv/Avisynth doesn't crash with four passes in sequence, it certainly won't crash with two passes and x264 either.

[Chumbo]

Doesn't make much sense that avs2yuv crashes with the same AVS script in the second pass, while the first one runs trough fine.

That's because avs2yuv doesn't know anything about passes. It just requests the raw video data from Avisynth and passes it to the STDOUT, where x264 will grab the data.

Consequently pass 1 or 2 doesn't make any difference for avs2yuv. It has absolutely no idea who or what is reading the data (and what for) that it writes to the STDOUT ;)

But the error "wrote only X of Y bytes" indicates that x264 (or whatever process the pipe was connected to) terminated before avs2yuv could write all data.

(So probably x264 just crashed/failed for some reason! Didn't x264 output any error/warning message ???)


To make sure that avs2yuv (or Avisynth) isn't failing, you may try this:
for %%i in (1 2 3 4) do (
avs2yuv "file_p1.avs" - > NULL
)
I found the problem. It was the frame count. MediaInfo was returning 12430 and avs2yuv is reporting 12396. Not sure why MI is reporting a number that is so far off. Usually it's only off by one or two frames at most. This is the first time I've seen this far off. I updated the frame count and ran the 2nd pass manually and it worked fine.

Just FYI, x264 did report the following, but initially I thought it may have been due to the "error" I posted from avs2yuv:y4m [info]: 1920x1080p 1:1 @ 30000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
Process terminated with code: 4294967295

[nibus]

a few random ideas:

1) Right click on completed jobs > export log to file
2) add a maximize button
3) add a horizontal scrollbar for viewing long command lines of jobs in progress.

Once again, thanks for your excellent work L. Mulder.

[Chumbo]

I tried to output the info provided by avs2yuv to a file, e.g.,avs2yuv -frames 1 "file_p1.avs" NUL > TEST.LOG.txtBut I just get a 0-byte file so nothing was written to it. Is there a way to "capture" the info provided likefile_p1.avs: 1920x1080, 60000/2002 fps, 12396 framesso I can parse out the frames? I use MediaInfo currently but that seems to not be accurate as in my earlier issue I posted. So I'd rather just use the info provided from avs2yuv if possible. In addition to sending it to a file it would also allow using it in a batch file for loop to parse out the data. Thank you.

[LoRd_MuldeR]

1) Right click on completed jobs > export log to file

We already have a "Copy to Clipboard" option in the lower panel, which can do that pretty much.

(Just paste into Notepad and save)

2) add a maximize button

Because running apps in fullscreen mode is so "cool" these days? :p
http://cache.lifehacker.com/assets/images/17/2011/09/win8start.jpg

3) add a horizontal scrollbar for viewing long command lines of jobs in progress.

I don't really like a horizontal scrollbar. There already is a tooltip, which you can use to reveal unduly long lines...

[LoRd_MuldeR]

I tried to output the info provided by avs2yuv to a file, e.g.,avs2yuv -frames 1 "file_p1.avs" NUL > TEST.LOG.txtBut I just get a 0-byte file so nothing was written to it. Is there a way to "capture" the info provided likefile_p1.avs: 1920x1080, 60000/2002 fps, 12396 framesso I can parse out the frames? I use MediaInfo currently but that seems to not be accurate as in my earlier issue I posted. So I'd rather just use the info provided from avs2yuv if possible. In addition to sending it to a file it would also allow using it in a batch file for loop to parse out the data. Thank you.

That's probably because DGDecodeNV only outputs the frames that are actually decodable, i.e. it may skip some "orphaned" frames at the beginning or at the end of the stream.

At the same time MediaInfo does not decode at all. It probably just counts the number of frames, but I doubt it actually processes the data inside those frames - would take much too long.

Consequently I use avs2yuv to get the exact number of frames that the AVS script will return. A command like 'avs2yuv -frames 1 "file_p1.avs" NUL 2> Output.txt' should work.

(Avs2yuv writes all status/error messages to the STDERR stream, like most tools do. That's done in order to keep the STDOUT stream "free" for the actual output data)

[Chumbo]

That's pretty much what I figured. I had tried the 2>&1 to redirect it to STDOUT so I can use the command directly in the for loop rather than output to a file and then process the file. I must have mistyped something because that wasn't working. It is now however so I'm not sure what the heck was going on. BTW, I use DGAVCDecodeDI but it's probably built using the same base code as the NV version.

[LoRd_MuldeR]

That's pretty much what I figured. I had tried the 2>&1 to redirect it to STDOUT so I can use the command directly in the for loop rather than output to a file and then process the file.

That works as long as you don't output any real data to the STDOUT.

If you let avs2yuv output the frames to STDOUT, so x264 can process that data via a pipe, then redirecting the STDERR messages to the STDOUT would corrupt the video data!

I must have mistyped something because that wasn't working. It is now however so I'm not sure what the heck was going on. BTW, I use DGAVCDecodeDI but it's probably built using the same base code as the NV version.

The situation is the same as with any other source filter: You simply can't rely on the source filter to decode the same exact number of frames as MediaInfo (or some other analyze tool) reports for the input file, because of skipped frames at the beginning/end of the stream or because of different handling of "broken" frames. Also the AVS script may contain filters that change the number of frames, just think of ChangeFPS, SelectEven/Odd, Bob and friends.

After all, you won't get around asking Avisynth how many frames it is going to return for the given script...

[GEfS]

You should make 2 boxes to choose 8-bit and 10-bit encoder.
Using 4 files like: x264-8bit-x86.exe, x264-8bit-x64.exe, x264-10bit-x86.exe, x264-10bit-x64.exe.
It make your program double-size but i think 20mb or 30mb not a problem for now.
And auto-update x264 function isn't a bad idea.

P/s: Sorry for my bad english, i'm not english speaker.

[LoRd_MuldeR]

You should make 2 boxes to choose 8-bit and 10-bit encoder.
Using 4 files like: x264-8bit-x86.exe, x264-8bit-x64.exe, x264-10bit-x86.exe, x264-10bit-x64.exe.
It make your program double-size but i think 20mb or 30mb not a problem for now.

It's a problem for me, because it takes twice the time for me to upload a new version - and that for a feature that probably only ~1% of the users need.

Unless we have widespread h/w support for 10-Bit H.264, it will remain a niche product. Users will complain about "broken" encodes, if their h/w player doesn't play it :rolleyes:

And auto-update x264 function isn't a bad idea.

Patches welcome ;)

Of course a patch is worthless, unless you can provide and maintain the update-sever as well...

[Atak_Snajpera]

It's a problem for me, because it takes twice the time for me to upload a new version - and that for a feature that probably only ~1% of the users need.
with 7-zip ULTRA compression I managed to compress all four versions to 6.5 MB !

http://i.imgur.com/maxTn.png

[LoRd_MuldeR]

with 7-zip ULTRA compression I managed to compress all four versions to 6.5 MB !

http://i.imgur.com/maxTn.png

Well, I use NSIS to build the distribution package. But that can use LZMA compression, just like 7-Zip does.

Maybe I will look into a solution, once I have some more spare time...

[LoRd_MuldeR]

Okay, I finally added an option to switch between 8-Bit and 10-Bit x264 at runtime ;)

It makes the distribution package somewhat bigger (15 MB instead of 10 MB), but hopefully it will be helpful for some people.

There will be an extensive warning message, when the user checks the "10-Bit encoding" option...

[kypec]

@LM - today I finally got around to try out your new V2 launcher app. Looks great but I can't open x264 help screen no matter what :(
The opened window is always empty with the error message below:
Failed to create x264 process :-(
Avs2YUV help window shows fine though...
I didn't update x264 binaries, everything comes from your install package.

[LoRd_MuldeR]

@LM - today I finally got around to try out your new V2 launcher app. Looks great but I can't open x264 help screen no matter what :(

That's a regression in Build #291. I will fix that as soon as possible...

[LoRd_MuldeR]

That's a regression in Build #291. I will fix that as soon as possible...

Should be fixed now :cool:

[kypec]

Should be fixed now :cool:
:thanks: for super quick bug fix!

[GEfS]

Okay, I finally added an option to switch between 8-Bit and 10-Bit x264 at runtime ;)

It makes the distribution package somewhat bigger (15 MB instead of 10 MB), but hopefully it will be helpful for some people.

There will be an extensive warning message, when the user checks the "10-Bit encoding" option...

I love that but why don't you make this option in "Add job" step.
Like this (the block is smaller, sorry for my graphic skill)
http://i.imgur.com/39Fwg.jpg

[VideoFanatic]

When I click on the output file button, MKV is always selected by default. Is there any hack I could use to set the default as h264?

[LoRd_MuldeR]

When I click on the output file button, MKV is always selected by default. Is there any hack I could use to set the default as h264?

It will remember what you used last time...

[VideoFanatic]

Version 2.02.202 doesn't. Whenever I add a new job it remembers the template I used but the output always has MKV selected by default.

[LoRd_MuldeR]

Version 2.02.202 doesn't. Whenever I add a new job it remembers the template I used but the output always has MKV selected by default.

Works for me:
http://www.mediafire.com/?l8qfpr6zwoa5ux0

[VideoFanatic]

I thought it might not have worked because I was using an Avisynth script but just now I added an MPV file, selected h264 output and added the job. I then added another MPV file but MKV was still selected by default. What would cause this to happen? Is there any way I can make it have h264 selected by default?

[LoRd_MuldeR]

I thought it might not have worked because I was using an Avisynth script but just now I added an MPV file, selected h264 output and added the job. I then added another MPV file but MKV was still selected by default. What would cause this to happen? Is there any way I can make it have h264 selected by default?

Nope, you can't make any file extension the default explicit.

As said before, the application will remember the last extension that was used. See the clip from my previous post...

[VideoFanatic]

I believe you but for me it's not remembering the last extension used for the output file and I don't understand why!

[VideoFanatic]

I watched the clip and I believe that it works for you but for me it's not remembering the last extension used for the output file and I don't understand why! I have Vista 32 bit. I also just installed your program on a brand new PC which has Windows 7 64-bit but I get the same problem.

[shinchiro]

@LoRd_MuldeR
Let say if my pc shutdown unexpectedly during encoding or I want just to close it and continue later, is it possible to resume the encoding? If I interupt x264 encoding, the encoded video is still there so if there are method to continue it, that would be great

[LoRd_MuldeR]

@LoRd_MuldeR
Let say if my pc shutdown unexpectedly during encoding or I want just to close it and continue later, is it possible to resume the encoding? If I interupt x264 encoding, the encoded video is still there so if there are method to continue it, that would be great

Nope, with x264 it is not possible to resume an encode that has been aborted. That's because the internal encoder state is lost irreversibly! :eek:

If you want to suspend the encode and resume it later, you can use the "Pause" function of Simple x264 Launcher. This will suspend the x264 process, but it won't terminate the process.

Or, if you need to turn the power off, you can use the Hibernation feature of Windows. Then the encode will continue after the system has been booted the next time...

[AiDz0r]

handy :D giving it a try. :D Waiting for it to finish encoding ^.^

[AiDz0r]

omg... I just finished the encoding. Why isn't there any sound? I Have to use parameters?


EDIT: I tried using avs and added "audio=true" still no luck.

[LoRd_MuldeR]

omg... I just finished the encoding. Why isn't there any sound? I Have to use parameters?

Read the Readme file, please...

[dstln]

Fantastic updates, thanks :)