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

[kypec]

You're abusing the concept of CFR vs 2-pass encode, that's all. This GUI is simply not designed to do weird=illogical things.

[Kuningas]

Concept is to use constant ratefactor advantages (reducing the quality of 'less important' high-motion frames) getting the file of needed size. It's not weird and illogical. It's the only way )

[LoRd_MuldeR]

Concept is to use constant ratefactor advantages (reducing the quality of 'less important' high-motion frames)

That's what both, 2-Pass and CRF do: The quality of two files of the same size, one encoded with 2-Pass and one with 1-Pass CRF, is equivalent!

I don't get the point what doing the first pass of a 2-Pass encode in CRF mode is good fore...

getting the file of needed size. It's not weird and illogical. It's the only way )

Hitting a specific file size is what 2-Pass mode can do, but CRF cannot. So in case you need to hit a specific size, use 2-Pass. Otherwise use CRF.

It's that simple ;)

[Kuningas]

one encoded with 2-Pass and one with 1-Pass CRF, is equivalent!

CRF mode is much more smarter then 2-pass mode.
CRF raises the quantizers in "fast" scenes where the loss won't be visible anyway and lower the quantizers in "slow" scenes. While encoding in two pass average bitrate mode "high motion" scenes will get a significant higher bitrate than "static" scenes. That's why pq cann't be equivalent. In practice, CRF+second pass mode looks noticeablely better.

[LoRd_MuldeR]

CRF mode is much more smarter then 2-pass mode.

Nope, it isn't. Please stop spreading wrong information :rolleyes:

CRF raises the quantizers in "fast" scenes where the loss won't be visible anyway and lower the quantizers in "slow" scenes.

Correct, but applies to 2-Pass mode as well.

(Also you should say "blocks" instead of "scenes", now with MB-Tree rate-control being used)

While encoding in two pass average bitrate mode "high motion" scenes will get a significant higher bitrate than "static" scenes.

Correct, but applies to CRF mode as well.

That's why pq cann't be equivalent.

I guess you mean "CQP" (aka "constant quantizer"). And of course CQP cannot be equivalent to CRF/2-Pass. But CQP was never mentioned!


Example:

The upper one was encoded with 1-Pass CRF, the lower one was encoded as a "normal" 2-Pass:

(Note that both files have the same total size, i.e. the same average bitrate!)

http://i47.tinypic.com/w0j01v.jpg

You notice something regarding the bitrate distribution? ;)

Upper: cabac=1 / ref=16 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / weightp=2 / keyint=750 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=24.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=2:1.00

Lower: cabac=1 / ref=16 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / weightp=2 / keyint=750 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=284 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=2:1.00

[kypec]

You notice something regarding the bitrate distribution? ;)

Yeah, I noticed that 2-pass encode exhibits even larger variances around the local bitrate peaks - which simply proves Kuningas was wrong in his assumption. 2-pass method provides more aggressive distribution of bitrate across slow vs fast-motion scenes though the differences are probably so negligible that they cannot be observed with standard human visual quality comparisons.
:goodpost: LM as usually.

[diimaan]

Hi LM


PipeBuffer by LoRd_MuldeR <mulder2@gmx.de>, Version 1.03

Usage:
pipebuf.exe <program_out> [<args>] : <program_in> [<args>] : [<buffer_size>]

Options:
<program_out> Executable to read stdout from
<program_in> Executable to write stdin to
<args> Optional command-line arguments
<buffer_size> Pipe buffer in MByte [0]


i want to pass the buffer size as 4m for my encode!
can you show it in a simple example for me?

my avs (m1.avs):

Loadplugin("D:\dgmpgdec158\DGDecode.dll")
Loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\AutoCrop.dll")

mpeg2source("D:\sample\dvd2avi.d2v")

Crop(0,56,-8,-56)
Spline64Resize(848,360)


how can i pass the input via pipebuf and then to the launcher or x264_64! :confused:

[diimaan]

I just copied this from the clipboard!


D:\x264_x64.2010-04-25\pipebuf.exe D:\x264_x64.2010-04-25\avs2yuv.exe D:\sample\m1.avs - : D:\x264_x64.2010-04-25\x264_x64.exe --preset slower --crf 21.0 --level 30 --sar 1:1 --output NUL --frames 1035 --demuxer y4m --stdin y4m - : 4


so the 4 in the above mentioned code means 4 MB?
and in the place of NUL if i mention a mkv or h264 and run from the pipebuf cli will it encode?

like say


@echo off
"D:\x264_x64.2010-04-25\pipebuf.exe" D:\x264_x64.2010-04-25\avs2yuv.exe D:\sample\m1.avs - : D:\x264_x64.2010-04-25\x264_x64.exe --preset slower --crf 21.0 --level 30 --sar 1:1 --output D:\m1.mkv --frames 1035 --demuxer y4m --stdin y4m - : 4
pause


or am I doing anything wrong here?

[diimaan]

wow it's running man... :D
thanks LM... :)

but my doubt is that, do we have to mention the frames if we are not running a benchmark and running a real encode?

[diimaan]

on a windows 64 vista machine!

1280 720 video
crf 22
only SAR 1:1 mentioned no other custom commands


Source: D:\sample\m1.avs
Preset: Slow
Tuning: None
Profile: High
Params: --sar 1:1

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 1035 frames, 10.40 fps, 2175.10 kb/s
encoded 1035 frames, 10.29 fps, 2175.10 kb/s
encoded 1035 frames, 10.52 fps, 2175.10 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 1035 frames, 11.01 fps, 2174.50 kb/s
encoded 1035 frames, 11.01 fps, 2174.50 kb/s
encoded 1035 frames, 10.56 fps, 2174.50 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 1035 frames, 10.78 fps, 2174.50 kb/s
encoded 1035 frames, 11.01 fps, 2174.50 kb/s
encoded 1035 frames, 11.01 fps, 2174.50 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 1035 frames, 11.01 fps, 2174.50 kb/s
encoded 1035 frames, 11.01 fps, 2174.50 kb/s
encoded 1035 frames, 11.01 fps, 2174.50 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 1035 frames, 11.01 fps, 2174.50 kb/s
encoded 1035 frames, 11.01 fps, 2174.50 kb/s
encoded 1035 frames, 11.01 fps, 2174.50 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 1035 frames, 11.01 fps, 2174.50 kb/s
encoded 1035 frames, 10.78 fps, 2174.50 kb/s
encoded 1035 frames, 10.56 fps, 2174.50 kb/s


but it stops on 8 MByte!
I can see ppl running the benchmark till 128MByte! but how?

[LoRd_MuldeR]

I just copied this from the clipboard!


D:\x264_x64.2010-04-25\pipebuf.exe D:\x264_x64.2010-04-25\avs2yuv.exe D:\sample\m1.avs - : \
D:\x264_x64.2010-04-25\x264_x64.exe --preset slower --crf 21.0 --level 30 --sar 1:1 --output NUL \
--frames 1035 --demuxer y4m --stdin y4m - : 4

so the 4 in the above mentioned code means 4 MB?

Yup.

and in the place of NUL if i mention a mkv or h264 and run from the pipebuf cli will it encode?

The "NUL" device will simply discard everything you write on it. Writing the output to the NUL device makes sense for the first pass of a 2-Pass encode.

Of course for the second pass of a 2-Pass encoder or for a 1-Pass CRF encode you would specify a "real" file there...

but it stops on 8 MByte!
I can see ppl running the benchmark till 128MByte! but how?

The buffer sizes to test are hard-coded. In older versions more (and bigger) buffer sizes were tested.

That was before it turned out that such very large buffers don't help ;)

But of course you can still test arbitrary buffer sizes by calling pipebuf.exe/x264.exe manually from the console.

[Kuningas]

Nope, it isn't. Please stop spreading wrong information

I'll try. )

Also you should say "blocks" instead of "scenes", now with MB-Tree rate-control being used

I don't use mbtree for some reasons.

I guess you mean "CQP" (aka "constant quantizer").

I meant pq aka "picture quality".

And of course CQP cannot be equivalent to CRF/2-Pass. But CQP was never mentioned!

"The advantage of the CRF mode is that it suits the human
perception much better than the QP mode. For example it will raise the quantizers in "fast" scenes where the
loss won't be visible anyway and lower the quantizers in "slow" scenes. Therefore the CRF mode should
give the same subjective quality as QP mode, but it usually achieves a significant higher compression. It's
recommended to prefer CRF mode over QP mode, although CRF is a bit slower. When switching from QP to
CRF mode, you may want to slightly lower the quantizer. This should give approximately the same file size
as before, but better visual quality! Another important advantage of CRF mode is that it will benefit from
adaptive quantization, something that QP mode can't do."

So, CRF is much more subjectively closer to CQP than 2pass mode.

The good example of using crf + 2pass: I encode with CRF and try to get the file size not bigger than X. But it unfortunately become a bit larger. What to do? Start new encoding and loose time for 2 passes? Or I can use stats from CRF mode and make just 2nd pass. It's obvious.

So. The rule is - use CRF or CRF+2pass (when you missed).

Here's real HD comparision (Anger Management BD CEE AVC).

crop + spline36resize+

selectTotal=framecount()/50
selectrangeevery(selectTotal,50)

CRF:
http://i50.tinypic.com/5zmb6x.jpg

Commandline for x264:
"C:\Programs - W7\x264_x64.2010-04-25\pipebuf.exe" "C:\Programs - W7\x264_x64.2010-04-25\avs2yuv.exe" Q:\HDProjects\anger\anger.avs - : "C:\Programs - W7\x264_x64.2010-04-25\x264_x64.exe" --crf 17.50 --level 4.1 --ref 12 --no-fast-pskip --bframes 8 --weightp 2 --no-mbtree --b-pyramid normal --b-adapt 2 --deblock -3:-3 --subme 10 --trellis 2 --partitions all --me umh --merange 48 --thread-input --vbv-bufsize 62500 --vbv-maxrate 50000 --aq-mode 1 --aq-strength 0.8 --psy-rd 1.0:0 --ssim --output Q:\HDProjects\anger\anger-crf175-aq08-psy100-b8-1629-me48-2.mkv --frames 2505 --demuxer y4m --stdin y4m - : 4

x264 [info]: frame I:56 Avg QP:17.33 size: 99584
x264 [info]: frame P:505 Avg QP:18.70 size: 52507
x264 [info]: frame B:1944 Avg QP:20.94 size: 25136
x264 [info]: consecutive B-frames: 1.9% 0.9% 3.8% 15.5% 22.0% 39.4% 9.1% 3.6% 3.7%

2-PASS:
http://i48.tinypic.com/14vo0hy.jpg

Commandline for x264:
"C:\Programs - W7\x264_x64.2010-04-25\pipebuf.exe" "C:\Programs - W7\x264_x64.2010-04-25\avs2yuv.exe" Q:\HDProjects\anger\anger.avs - : "C:\Programs - W7\x264_x64.2010-04-25\x264_x64.exe" --bitrate 6200 --pass 2 --stats Q:\HDProjects\anger\anger-crf175-aq08-psy100-b8-1629-me48-2pass.mkv.x264-stats --level 4.1 --ref 12 --no-fast-pskip --bframes 8 --slow-firstpass --weightp 2 --no-mbtree --b-pyramid normal --b-adapt 2 --direct auto --no-dct-decimate --deblock -3:-3 --subme 10 --trellis 2 --partitions all --me umh --merange 48 --thread-input --vbv-bufsize 62500 --vbv-maxrate 50000 --aq-mode 1 --aq-strength 0.8 --psy-rd 1.0:0 --ssim --output Q:\HDProjects\anger\anger-crf175-aq08-psy100-b8-1629-me48-2pass.mkv --frames 2505 --demuxer y4m --stdin y4m - : 4

x264 [info]: frame I:56 Avg QP:17.66 size:102710
x264 [info]: frame P:505 Avg QP:21.39 size: 45379
x264 [info]: frame B:1944 Avg QP:21.11 size: 26195
x264 [info]: consecutive B-frames: 1.9% 0.9% 3.8% 15.5% 22.0% 39.4% 9.1% 3.6% 3.7%

CRF - 2-PASS:
http://thumbnails5.imagebam.com/8396/d011de83955964.jpg (http://www.imagebam.com/image/d011de83955964) http://thumbnails25.imagebam.com/8396/d3bca083955975.jpg (http://www.imagebam.com/image/d3bca083955975)

As you can see CRF gives more bitrate for static scenes than 2-PASS. And don't waste it - look at first mega leap on bitrate viewer screen.
And look at quants )

[7ekno]

Can prove anything you want if you "gimp" parameters to prove it ... mb-tree and b-pyramids would help bring CRF closer to your "two pass" graph ...

7ek

[LoRd_MuldeR]

Updated x264 binaries to r1649 (Komisar's builds).

[komisar]

LoRd_MuldeR, small typo? :)
http://komisar.gin.by/test/lm01.png

[LoRd_MuldeR]

LoRd_MuldeR, small typo? :)
http://komisar.gin.by/test/lm01.png

Indeed :p

[LoRd_MuldeR]

Updated x264 binaries to r1659 (Komisar's builds).

[LoRd_MuldeR]

Updated x264 binaries to r1666 (Komisar's builds).

[LoRd_MuldeR]

Another small request LM if I may...
After the encoding process completed there is output window shown with report details which is fine of course.
When CRF was used (1-pass method in general probably) there is only one option presented for right-click: Copy to clipboard.
This is also good and I like it this way because frankly, what other actions could anyone want to do with final report, isn't it?
However, when 2-pass encode completes, the window has different right-click menu:

[...]

IMHO it's rather counter-productive this way because I need to make two clicks now to get the contents copied into clipboard (first Select all, then Copy).
Could this menu be replaced to be identical with CRF style report, please?

Done.

[kypec]

:thanks: a lot LM!

I guess you made a little typo here...

Last edited by LoRd_MuldeR; 10th July 2010 at 15:52. Reason: Update x264 binaries to r1659

[stinman]

I been trying to learn cli x264,I am having a hard time writing commands.Thought I would try this.I only encode bluray movies and use mkv anymore.I all ways used BDRebuilder or ripbot264.Now you got this new GOP thing for blurays and ripbot does not use it.I just loaded a whole movie (movie only) I never thought about audio.I usually just demux with tsmuxer and remux audio in later.I loaded the stream right from the BDAV folder,drilled down to stream.This is what I did - preset slow --tune film --aq-mode 2 --crf 21 --level 4.1 --keyint 24 --min-keyint 2 --open-gop bluray --b-pyramid strict --ref 4 --weightp 0 --slices 4 --vbv-bufsize 30000 --vbv-maxrate 40000 --aud --nal-hrd vbr --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" I copied this from a post that sharktooth made.I loaded this into the custom parameters.I hit encode and away it went,says 4:33 hrs on x64bit Phenom II 955BE oc to 3.6.Did I screw up by not demuxing first?Or does it demux?if so where are the temporary files? I really didn't think I had it set right,since it took off I am letting it go.It only does video right?I am a n00b at cli,i can use tools and gui's good.I hope it does what I want,Thanks for your tool Lord Mulder

[LoRd_MuldeR]

I been trying to learn cli x264,I am having a hard time writing commands.Thought I would try this.I only encode bluray movies and use mkv anymore.I all ways used BDRebuilder or ripbot264.Now you got this new GOP thing for blurays and ripbot does not use it.I just loaded a whole movie (movie only) I never thought about audio.I usually just demux with tsmuxer and remux audio in later.I loaded the stream right from the BDAV folder,drilled down to stream.This is what I did - preset slow --tune film --aq-mode 2 --crf 21 --level 4.1 --keyint 24 --min-keyint 2 --open-gop bluray --b-pyramid strict --ref 4 --weightp 0 --slices 4 --vbv-bufsize 30000 --vbv-maxrate 40000 --aud --nal-hrd vbr --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" I copied this from a post that sharktooth made.I loaded this into the custom parameters.I hit encode and away it went,says 4:33 hrs on x64bit Phenom II 955BE oc to 3.6.Did I screw up by not demuxing first?Or does it demux?if so where are the temporary files? I really didn't think I had it set right,since it took off I am letting it go.It only does video right?I am a n00b at cli,i can use tools and gui's good.I hope it does what I want,Thanks for your tool Lord Mulder

This post is very confusing. What exactly is your question ???

About demuxing: You didn't tell us what kind of source file you are feeding into x264 CLI. But if that file is a video file stored in some container (AVI, Matroska, MP4, TS, etc) then it will be demuxed for sure. x264 currently only processes the video part of the source file and ignores the audio part. The demuxing and decoding is done by FFMS2 (libavformat/libavcodec) and it does NOT create a temporary file. The demuxing/decoding is done "on the fly". However FFMS2 will have to index the source file first. And (optionally) an index file can be saved, so the index doesn't have to be re-created next time...

[stinman]

This post is very confusing. What exactly is your question ???

You didn't tell us what kind of source file you are feeding into x264 CLI. But if that file is a video file stored in some container (AVI, Matroska, MP4, TS, etc) then it will be demuxed for sure. x264 currently only processes the video part of the source file and ignores the audio part. The demuxing is done by FFMS2 (libavformat/libavcodec) and it does NOT create a temporary file. The demuxing/decoding is done "on the fly".


Sorry I was confusing,I loaded a Bluray movie that was on my HD it was a m2ts, I used tsMuxer to keep the movie only and the English DTSHD-MA on my HD,the movie was in h264 1920-1080.Like I said,I can not write commands unless I see them first.The commands that I put into the custom parameters I copied from a post I seen, that made a file bluray compliant,.You answered with out knowing.It does demux and ignores the audio.I had been trying to use just x264 cli for awhile and couldn't get it right.So I stuck with GUI's.When I loaded this and it worked I was surprised and excited,I hope that crf 21 will do well.The movie it self was 22.1 GB,I try to keep them around 7.xx GB.
I was also just giving you a compliment,if this turns out well then 4.5hrs is good.I may need to go with 18,19,20.i don't know because usually I do 2pass for size.Thanks again!! This is great!!
BDRebuilder uses the new "GOP" settings in x264 * none: Open-GOP disabled. * normal: Open-GOP enabled. * bluray: . Open-GOP enabled. A less efficient version of open-GOP, normal mode doesn't work when authoring Blu-Rays.This is the GOP thing I spoke of in my first post.



stinman

[LoRd_MuldeR]

Updated x264 binaries to r1677 (Komisar's builds).

[stinman]

Lord Mulder I really like your tool,i get to learn the commands,it is way faster than other gui's I have used.I want to say thanks for this tool,it works great for me!

[LoRd_MuldeR]

Lord Mulder I really like your tool,i get to learn the commands,it is way faster than other gui's I have used.I want to say thanks for this tool,it works great for me!

I doubt that my GUI is any faster (or slower) than other x264 GUI's. If a GUI has a significant impact on encoding speed, then something is seriously wrong ;)

(If you mean the user can get started "faster" than with other more complex/advanced GUI's, then you are probably right)

[Keiyakusha]

I'm also not sure what stinman means but last time I tried megui (before Zathor started to work on it), I was able to see actual form few seconds after I launched it.

[ckmox]

Lord Mulder any chance of adding input boxes for the resize filter of x264?

[LoRd_MuldeR]

Lord Mulder any chance of adding input boxes for the resize filter of x264?

Not planned. You can put "--vf resize:x,y" to the options input box easily, if needed.

[LoRd_MuldeR]

Updated x264 binaries to r1683 (Komisar's builds).

[stinman]

I doubt that my GUI is any faster (or slower) than other x264 GUI's. If a GUI has a significant impact on encoding speed, then something is seriously wrong ;)

(If you mean the user can get started "faster" than with other more complex/advanced GUI's, then you are probably right)
I guess that's what I meant,plus I can set what I want and do not have to know how to write commands,plus you use the latest x264x64 which is a bit faster for me than say BDRebuilder.I have not been able to load a raw H264 file.If I demux a bluray with tsmuxer to get the DSTHD-MA file and the H264 file,then try to load only the H264 file it has a fatal error,but when I load the m2ts file from the stream folder it works just fine.Does it not accept raw h264 files?

[LoRd_MuldeR]

I guess that's what I meant,plus I can set what I want and do not have to know how to write commands,plus you use the latest x264x64 which is a bit faster for me than say BDRebuilder.I have not been able to load a raw H264 file.If I demux a bluray with tsmuxer to get the DSTHD-MA file and the H264 file,then try to load only the H264 file it has a fatal error,but when I load the m2ts file from the stream folder it works just fine.Does it not accept raw h264 files?

If x264 was built with FFM2 (FFmpegSource2) enabled, which is the case with the x264 builds that I include, then x264 can "accept" anything that the FFmpeg libraries (libavformat/libavcodec) are able to handle. Anyway, if FFM2 fails on the "raw" H.264 stream, you can still use Avisynth input. Use DGAVCIndex (http://www.videohelp.com/tools/DGAVCDec) to create an .dga index file from your H.264 file and then use a simple Avisynth script, like this:

AVCSource("C:\Some Folder\Foobar.dga")

[stinman]

If x264 was built with FFM2 (FFmpegSource2) enabled, which is the case with the x264 builds that I include, then x264 can "accept" anything that the FFmpeg libraries (libavformat/libavcodec) are able to handle. Anyway, if FFM2 fails on the "raw" H.264 stream, you can still use Avisynth input. Use DGAVCIndex (http://www.videohelp.com/tools/DGAVCDec) to create an .dga index file from your H.264 file and then use a simple Avisynth script, like this:

AVCSource("C:\Some Folder\Foobar.dgs")

Thanks,I think I can do that.If not I'll just stick with the BDMV/Stream/xxx.m2ts file.i do want to learn though.
stinman

[LoRd_MuldeR]

Updated x264 binaries to r1688 (Komisar's builds).

[Forteen88]

Thanks for this program. Please update x264-binaries to r1698. And could be as good as including a CRF 2-pass mode?

@stinman: To make your comments more readable you should use a space after your commas and full stops.

[LoRd_MuldeR]

Thanks for this program. Please update x264-binaries to r1698.

I upload new packages with updated x264 binaries now and then.

But there's absolutely nothing that prevents you from updating the binaries yourself at anytime you like ;)

And could be as good as including a CRF 2-pass mode?

CRF is single pass by definition!

Well, I know that one can run a CRF encode and then re-use the stats file from the CRF encode to run a second pass of a 2-Pass encode.

But I don't get the point of that :rolleyes:

If the user wants to hit a specific file size (or average bitrate) then "normal" 2-Pass will work just fine. Otherwise CRF does the job...

[Gser]

Are you using the multi-threaded version of FFMS2?

[Forteen88]

@LoRd_MuldeR: Nothing that prevents me from updating the binaries myself (I actually already did that), but some people probably don't bother doing that (or don't know how to), and it's IMO better to make sure that they use the latest x264.

The point with 2-pass CRF is to get more accurate VBV, but as gravy, also a tiny better --direct auto

EDIT: Thanks for the info concerning Lookahead-VBV, although it was announced by D.S. the 17th August 2009, not "ages" ago (although you might use that word as slang?!)

[LoRd_MuldeR]

@LoRd_MuldeR: Nothing that prevents me from updating the binaries myself (I actually already did that), but some people probably don't bother doing that (or don't know how to), and it's IMO better to make sure that they use the latest x264.

That's why I update the package now and then :p

But I certainly won't update the package for every single x264 revision. You really cannot complain about a two-weeks-old revision...

The point with 2-pass CRF is to get more accurate VBV

Nonsense. VBV is always accurate, also in 1-Pass CRF mode.

x264 will never violate the VBV constraints without throwing a fat warning message. And if this ever happens, you either use absurd settings or you just found a bug ;)

(There were some problems with 1-Pass VBV long ago, before Lookahead VBV was implemented. But that's fixed since ages)

[LoRd_MuldeR]

Thanks for the info concerning Lookahead-VBV, although it was announced by D.S. the 17th August 2009, not "ages" ago (although you might use that word as slang?!)

So that was more than a year ago. That is "ages ago" in x264 development, with a rate of approximately ten commits and three API changes per day :p

[HaraldBluetooth]

MuldeR - I'm also satisfied with you monthly updates (or so), but for those who can't find the place, where you get the latest x264 binaries (Komisar's builds), you could place a link on the first page of this thread.

[komisar]

HaraldBluetooth, http://komisar.gin.by/

[LoRd_MuldeR]

Updated x264 binaries to r1703 (Komisar's builds).

[LoRd_MuldeR]

Updated x264 binaries to r1713 (Komisar's builds).

[JnZ]

Source: D:\test.avs
Preset: Veryslow
Tuning: Film
Profile: High
Params: --deblock -2:-2

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 3136 frames, 22.58 fps, 1041.64 kb/s
encoded 3136 frames, 22.86 fps, 1041.64 kb/s
encoded 3136 frames, 22.55 fps, 1041.64 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 3136 frames, 25.70 fps, 1041.63 kb/s
encoded 3136 frames, 26.13 fps, 1041.63 kb/s
encoded 3136 frames, 26.35 fps, 1041.63 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 3136 frames, 26.58 fps, 1041.63 kb/s
encoded 3136 frames, 26.58 fps, 1041.63 kb/s
encoded 3136 frames, 25.92 fps, 1041.63 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 3136 frames, 26.13 fps, 1041.63 kb/s
encoded 3136 frames, 26.35 fps, 1041.63 kb/s
encoded 3136 frames, 26.13 fps, 1041.63 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 3136 frames, 26.13 fps, 1041.63 kb/s
encoded 3136 frames, 25.92 fps, 1041.63 kb/s
encoded 3136 frames, 25.92 fps, 1041.63 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 3136 frames, 25.50 fps, 1041.63 kb/s
encoded 3136 frames, 25.92 fps, 1041.63 kb/s
encoded 3136 frames, 26.35 fps, 1041.63 kb/s


Almost 4fps boost. Good job.

Could you provide configurable option "bring to front after encoding finish" ? It bothers me between passes.

Anyway thanks for nice GUI.:thanks:

[ChiDragon]

Thanks for the nice tool. Not sure if benchmarks are still wanted but here's my results:

Source: E:\New Encodes\test.avs
Preset: Placebo
Tuning: None
Profile: High
Params: --merange 32 --deblock -3:-3 --sar 1:1

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 3001 frames, 4.22 fps, 862.76 kb/s
encoded 3001 frames, 4.30 fps, 862.76 kb/s
encoded 3001 frames, 4.30 fps, 862.76 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 3001 frames, 4.55 fps, 862.76 kb/s
encoded 3001 frames, 4.60 fps, 862.76 kb/s
encoded 3001 frames, 4.76 fps, 862.76 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 3001 frames, 4.61 fps, 862.76 kb/s
encoded 3001 frames, 4.58 fps, 862.76 kb/s
encoded 3001 frames, 4.60 fps, 862.76 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 3001 frames, 4.86 fps, 862.76 kb/s
encoded 3001 frames, 4.65 fps, 862.76 kb/s
encoded 3001 frames, 4.57 fps, 862.76 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 3001 frames, 4.61 fps, 862.76 kb/s
encoded 3001 frames, 4.63 fps, 862.76 kb/s
encoded 3001 frames, 4.79 fps, 862.76 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 3001 frames, 4.60 fps, 862.76 kb/s
encoded 3001 frames, 4.65 fps, 862.76 kb/s
encoded 3001 frames, 4.57 fps, 862.76 kb/s

[Temuthril]

Typo?
http://img832.imageshack.us/img832/9572/launcherm.jpg

[LoRd_MuldeR]

Typo?
http://img832.imageshack.us/img832/9572/launcherm.jpg

There obviously is a "by" missing. I will fix that for the next release. Thanks for the report.

[stinman]

Lord_MuldeR if you was to ever quit updating this for what ever reason,could we replace the x64x264 in the folder and it still work? I just can't seem to learn how to use the command line,maybe one day,but your program I like the most and is so simple.Thanks again for your help.I know I've said that 3 or 4 times but it needs to be said!

[LoRd_MuldeR]

Lord_MuldeR if you was to ever quit updating this for what ever reason,could we replace the x64x264 in the folder and it still work?

Sure! At least as long as the x264 developers don't break the compatibility with the current CLI parameters.

And if that ever happens, one would need to adjust the code in my application accordingly - which every freshman programmer should be able to do ;)

Of course I'm not planning to quit updating this tool anytime soon...

I just can't seem to learn how to use the command line,maybe one day,but your program I like the most and is so simple.Thanks again for your help.I know I've said that 3 or 4 times but it needs to be said!

http://mewiki.project357.com/wiki/X264_Settings