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

[LoRd_MuldeR]

Originally Posted by holygamer

I don't really use VirtualDub. Do I just drag the script into VirtualDub then click on the play button?

Yes.

Originally Posted by holygamer

So if there's an error will VirtualDub give a popup showing what plugin is at fault?

If Avisynth reports an error, you will get a message box showing that error. And if Avisynth (or one of the plug-in's involved) crashes, you will see a crash dialog (stack trace).

In case of a crash, it is not easy to figure out what exactly caused it, because the problem may be the result of a specific plug-in combination and/or a specific Avisynth version/variant.

(Especially the "MT" and "x64" forks of Avisynth are anything but rock stable)

[BlockABoots]

Is there a selection of Template profiles i could download anywhere? For 1080p Youtube use mainly

[LoRd_MuldeR]

Originally Posted by BlockABoots

Is there a selection of Template profiles i could download anywhere? For 1080p Youtube use mainly

Nope. And that's because you don't have to

Generally you would simply pick the slowest possible Preset you can afford (speed-wise) and then choose the highest possible CRF you can accept (quality-wise).

You can then save your personal choice as a Template, for convenience.

As for Youtube: They are going to re-encode your clip anyway, so all you can do is provide a "decent" quality source and hope that they won't mess it up too bad.

It's not worth to worry about the details, because their re-encoding is going to hurt the quality anyway...

(The only thing for which I think pre-defined "Templates" could be useful is BluRay encoding, because that requires not-so-trivial combination of parameters)

[r0lZ]

Originally Posted by LoRd_MuldeR

(The only thing for which I think pre-defined "Templates" could be useful is BluRay encoding, because that requires not-so-trivial combination of parameters)

Interesting BTW. Do you know exactly what options must be used? I've read somewhere that they have to be this:

--bluray-compat --profile high --level 4.1 --vbv-maxrate 40000 --vbv-bufsize 30000 --keyint 24 --slices 4
--open-gop --colorprim bt709 --transfer bt709 --colormatrix bt709 --b-pyramid strict --fake-interlaced --aud

Is it correct? Is --fake-interlaced really necessary? And why is it not sufficient to specify --bluray-compat to force all options as they must be?

[LoRd_MuldeR]

"Fake Interlaced" is needed where you want N fps progressive (because you have a progressive source at N fps), but the BluRay standard only allows for N fps interlaced (i.e. 2xN fields/second) - not N fps progressive. x264 will then create an "interlaced" stream (to make BluRay happy), but simply code all blocks as "progressive". That's possible because even in "interlaced mode" H.264 still allows to select between interlaced/progressive for each block (MBAFF). And about the "--bluray-compat" option: It is required but not sufficient to get 100% BluRay compatibility. I guess that's because there are some things that are always needed for BluRay compat and other things that need to be adjusted.

For details see:
http://www.x264bluray.com/

[r0lZ]

Many thanks for your reply. But "Authoring a professional Blu-ray Disc with x264" page doesn't have much information. It specifies only that --fps 24000/1001 --force-cfr must be used if the source has not the correct frame rate. Nothing else. I suppose I'll have to search for "blu-ray" in http://mewiki.project357.com/wiki/X264_Settings

[EDIT] Oops, found how to use the site. The information is in other pages. Thanks again!

[LoRd_MuldeR]

It has very detailed info. Just choose your type of source from the left-side menu

[r0lZ]

Yes, I figured it. I have updated my previous post, but you haven't seen the edit. Anyway, it's perfect. Thanks again.

[VideoFanatic]

I'm fixing VHS-to-DVD conversions with Avisynth. I've found that CRF 17 gives the lowest file size and I've been encoding videos for ages without problems - if I use a higher setting then I can see artefacts.

The problem is that I've got some videos that have a darkness problem that I need to fix with this Avisynth code:
ColorYUV(gamma_y=200, off_y=-32)

But when I encode a video the bitrate is double than what it would be if I didn't use that code. These are just colour corrections so I don't understand why this happens?

[LoRd_MuldeR]

Originally Posted by holygamer

I'm fixing VHS-to-DVD conversions with Avisynth. I've found that CRF 17 gives the lowest file size and I've been encoding videos for ages without problems - if I use a higher setting then I can see artefacts.

The problem is that I've got some videos that have a darkness problem that I need to fix with this Avisynth code:
ColorYUV(gamma_y=200, off_y=-32)

But when I encode a video the bitrate is double than what it would be if I didn't use that code. These are just colour corrections so I don't understand why this happens?

Don't know what your script does exactly to perform the "color correction", but if, for example, it adds any dithering (noise) during the process it should be obvious why the file will be "harder" to compress afterwards and thus needs more bits (at the same CRF).

[r0lZ]

I have a frame rate problem with some versions of x264. The versions included with your launcher work perfectly, but some versions downloaded from x264.nl are not so good. The problem, when the .nl version is used, is that MkvMerge cannot find the frame rate in the h264 stream, and it assumes 25p. When you mux such a x264 file manually with MkvMerge GUI (mmg.exe), it issues a warning that explains that the frame rate must be specified, but I want to automate the encoding and muxing and mkvmerge.exe (CLI) doesn't issue that warning. When the same video is encoded with Simple x264 launcher (or with the exes in your toolbox), there is no warning, and the correct frame rate is used.

Is it a fix included only in some builds, or starting with a specific version number? Where do you download the versions included in your toolbox? Is it possible to test if the user of a GUI uses a version that sets correctly the frame rate in the video stream?

Sorry to ask this question here, as your tool works perfectly, but I think you know certainly what's the origin of that problem, and how to avoid it.

[LoRd_MuldeR]

Originally Posted by r0lZ

I have a frame rate problem with some versions of x264. The versions included with your launcher work perfectly, but some versions downloaded from x264.nl are not so good. The problem, when the .nl version is used, is that MkvMerge cannot find the frame rate in the h264 stream, and it assumes 25p. When you mux such a x264 file manually with MkvMerge GUI (mmg.exe), it issues a warning that explains that the frame rate must be specified, but I want to automate the encoding and muxing and mkvmerge.exe (CLI) doesn't issue that warning. When the same video is encoded with Simple x264 launcher (or with the exes in your toolbox), there is no warning, and the correct frame rate is used.

Is it a fix included only in some builds, or starting with a specific version number? Where do you download the versions included in your toolbox? Is it possible to test if the user of a GUI uses a version that sets correctly the frame rate in the video stream?

Sorry to ask this question here, as your tool works perfectly, but I think you know certainly what's the origin of that problem, and how to avoid it.

As long as you output the stream as MKV file, there should be FPS information included. Storing as a "raw" H.264 stream may not have FPS information included, so then MkvMergeGUI will default to 25 fps. I don't think there should be any differences between x264 builds, as the MKV muxer is a part of x264 code, not from an external library (like GPAC is needed for MP4 muxing). I just include Komisar's builds.

[r0lZ]

Hum, strange. There IS a difference when I encode with the 64bit 8bit-depth version downloaded from x264.nl, and with your x264_8bit_x64.exe. I don't have to specify the frame rate when muxing (with mkvmerge.exe) the files encoded with your version, but I must specify it if I encode with the .nl version (except if the frame rate is 25fps of course). So, there must be a difference.

Your version:

x264 0.128.2216 198a7ea
(libswscale 2.1.101)
(libavformat 54.25.105)
(ffmpegsource 2.17.2.1)
built by Komisar on Sep  6 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

Result when encoding and muxing a small test NTSC movie: 29.97 fps

The .nl version:

x264 0.130.2273 b3065e6
(libswscale 2.1.1)
(libavformat 54.21.2)
(ffmpegsource 2.17.3.0)
built on Feb 27 2013, gcc: 4.7.2
configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: LGPL version 2.1 or later

Result when encoding and muxing the same NTSC movie: 25 fps

Of course, I've used the same encoding and muxing parametres in both cases.

Originally Posted by LoRd_MuldeR

As long as you output the stream as MKV file, there should be FPS information included.

I agree. But it seems that mkvmerge can find the correct frame rate in one case, and it defaults to 25fps in the other case. Why? I'm puzzled.

[LoRd_MuldeR]

Well, you are comparing x264 r2216 to x264 r2273. You should compare the same revisions to be sure. Also I have updated "my" package to x264 r2273 (again Komisar build) too.

(Furthermore, adding "--force-cfr" might help, but I'm not sure)

[r0lZ]

--force-cfr is in my settings.

I'll do other tests later, but it seems that it's not related to the version number. (Or should I consider that the newer version did a regression?) I'll post here if I can understand the problem.

Anyway, thanks for your help.

[LoRd_MuldeR]

Originally Posted by r0lZ

--force-cfr is in my settings.

I'll do other tests later, but it seems that it's not related to the version number. (Or should I consider that the newer version did a regression?) I'll post here if I can understand the problem.

Anyway, thanks for your help.

As long as you are comparing two different versions, we cannot know whether this has something to do with changes in x264 or with the different builds, but I'd say the former is more likely...

[r0lZ]

OK, I did comparisons with the latest versions. Still same problem.

Komisar version (distributed with your launcher):

x264 0.130.2273 b3065e6
(libswscale 2.2.100)
(libavformat 54.63.100)
(ffmpegsource 2.17.3.0)
built by Komisar on Feb 27 2013, gcc: 4.7.2 (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

Command: "x264_8bit_x64.exe" --force-cfr --no-interlaced --sar 32/27 --crf 23 --preset medium --threads 3 --qpfile qpfile.txt --index VideoFile.ffindex --output VideoFile.264 VideoFile.m2v

ffms [info]: indexing input file...
ffms [info]: 720x480p 32:27 @ 3434/143 fps (cfr)
x264 [info]: using SAR=32/27
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
x264 [info]: profile High, level 3.0
x264 [info]: encoding...
x264 [info]: frame I:101 Avg QP:22.06 size: 23023
x264 [info]: frame P:2344 Avg QP:24.75 size: 6615
x264 [info]: frame B:2291 Avg QP:27.08 size: 1654
x264 [info]: consecutive B-frames: 16.3% 51.1% 19.5% 13.1%
x264 [info]: mb I I16..4: 13.5% 68.8% 17.6%
x264 [info]: mb P I16..4: 2.1% 7.7% 0.9% P16..4: 42.6% 17.6% 9.2% 0.0% 0.0% skip:19.9%
x264 [info]: mb B I16..4: 0.1% 0.6% 0.1% B16..8: 36.2% 3.7% 0.8% direct: 2.2% skip:56.4% L0:36.1% L1:56.8% BI: 7.1%
x264 [info]: 8x8 transform intra:71.0% inter:70.7%
x264 [info]: coded y,uvDC,uvAC intra: 69.9% 72.4% 39.2% inter: 22.2% 23.3% 2.0%
x264 [info]: i16 v,h,dc,p: 42% 26% 5% 27%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 12% 16% 7% 9% 11% 8% 10% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 21% 12% 6% 9% 9% 8% 7% 6%
x264 [info]: i8c dc,h,v,p: 55% 18% 19% 8%
x264 [info]: Weighted P-Frames: Y:19.4% UV:8.2%
x264 [info]: ref P L0: 60.1% 18.8% 14.4% 5.7% 1.0%
x264 [info]: ref B L0: 84.4% 14.5% 1.1%
x264 [info]: ref B L1: 96.6% 3.4%
x264 [info]: kb/s:877.10
encoded 4736 frames, 57.14 fps, 877.10 kb/s

The frame rate 3434/143 (24.014 fps) is strange, but apparently correct. At least, there is no perceptible A/V sync problem.

The version downloaded from x264.nl:

x264 0.130.2273 b3065e6
(libswscale 2.1.1)
(libavformat 54.21.2)
(ffmpegsource 2.17.3.0)
built on Feb 27 2013, gcc: 4.7.2
configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: LGPL version 2.1 or later

Command: "x264(NL).exe" --force-cfr --no-interlaced --sar 32/27 --crf 23 --preset medium --threads 3 --qpfile qpfile.txt --index VideoFile.ffindex --output VideoFile.264 VideoFile.m2v

ffms [info]: indexing input file...
ffms [info]: 720x480p 32:27 @ 25/1 fps (cfr)
x264 [info]: using SAR=32/27
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
x264 [info]: profile High, level 3.0
x264 [info]: encoding...
x264 [info]: frame I:101 Avg QP:22.20 size: 22586
x264 [info]: frame P:2344 Avg QP:24.91 size: 6446
x264 [info]: frame B:2291 Avg QP:27.23 size: 1605
x264 [info]: consecutive B-frames: 16.3% 51.1% 19.5% 13.1%
x264 [info]: mb I I16..4: 13.9% 68.6% 17.5%
x264 [info]: mb P I16..4: 2.2% 7.6% 0.9% P16..4: 42.7% 17.2% 9.1% 0.0% 0.0% skip:20.4%
x264 [info]: mb B I16..4: 0.1% 0.6% 0.1% B16..8: 36.0% 3.7% 0.7% direct: 2.1% skip:56.8% L0:36.1% L1:57.0% BI: 6.9%
x264 [info]: 8x8 transform intra:70.7% inter:71.0%
x264 [info]: coded y,uvDC,uvAC intra: 69.3% 71.6% 38.2% inter: 21.7% 22.7% 1.9%
x264 [info]: i16 v,h,dc,p: 42% 26% 5% 27%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 12% 16% 7% 9% 11% 8% 10% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 21% 12% 6% 9% 9% 8% 7% 6%
x264 [info]: i8c dc,h,v,p: 55% 18% 19% 8%
x264 [info]: Weighted P-Frames: Y:19.4% UV:8.2%
x264 [info]: ref P L0: 60.2% 18.9% 14.3% 5.7% 1.0%
x264 [info]: ref B L0: 84.6% 14.3% 1.1%
x264 [info]: ref B L1: 96.6% 3.4%
x264 [info]: kb/s:889.68
encoded 4736 frames, 56.00 fps, 889.68 kb/s

Obviously, the ffms info is not correct. With that version, the frame rate is ALWAYS 25fps, regardless of the source (at least when the source is a MPEG stream extracted from a DVD).
I suppose the bug is caused by libavformat v54.21.2, as the version of ffmpegsource is identical in both builds.

I haven't tested the 32-bit exes, and the 10-bit depth exes, but I suppose they have the same bug.

Anyway, the Komisar version is the one to keep. (It gives also a slightly better compression with identical parameters, and it is slightly faster.) Keep that version for your launcher!

Can you confirm that your versions are the KMod builds from this page? [EDIT] I don't need a reply for that question. They are the "clear" builds.

[r0lZ]

OK, I've downloaded and tested all versions from Komisar's page, and none of them have the frame rate bug.

I've also noticed that the KMod builds have a different output for the progress lines, and I guess they are not compatible with your launcher, for that reason. (I had to modify my PgcEdit plugin to support them.)

I'll stick with the Komisar clear builds for now, as I know that they work well.

Thanks again for your inputs.

[EDIT] Tested also all versions from http://x264.nl/, and all of them have the frame rate bug. So, it seems that it's not a problem with the x32/x64 or 8/10-bit depth versions, but a problem with the libraries used by the author of that builds. (I don't know who he is and how to contact him.)

[LoRd_MuldeR]

Okay, so from your go log we can see that it's actually the FFMS2 (FFmpegSource2) detecting different frame rates for your original input to x264!

That's probably the result of different versions of the FFMS2/Libav libraries being used in those builds.

Looks like they both use the same FFMS version (2.17.3.0), but the Komisar build was made using as lightly never Libav version (54.63.100 -vs- 54.21.2).

[r0lZ]

Yes, that was my conclusion too. The x264 code itself is not the culprit. But it is a fact that it's a very big difference, although both versions have the same build number.
Anyway, you can't help. Sorry for having polluted your thread!