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 :

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]

Originally Posted by kypec

@Marin85: here's my suggestion for you

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

This is very cool idea! 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

@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)

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]

Originally Posted by shinchiro

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...

Originally Posted by shinchiro

..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...

Originally Posted by Marin85

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)

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

[Marin85]

Originally Posted by LoRd_MuldeR

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 (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? That would be a real enrichment!

[LoRd_MuldeR]

Originally Posted by reff24

When will these functions? 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]

Originally Posted by 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.

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]

Originally Posted by LoRd_MuldeR

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]

Originally Posted by LoRd_MuldeR

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]

Originally Posted by 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

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]

Originally Posted by 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
)

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