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

[LoRd_MuldeR]

Simple x264/x265 Launcher

This application is a lightweight GUI front-end for the x264 H.264/AVC
as well as the x265 H.265/HEVC encoder, based on the Qt toolkit.

Some key features of the Simple x264/x265 Launcher software include:

* Support for creating H.264/AVC (x264) and H.265/HEVC (x265) files
* Fully self-contained, *no* additional Codecs or Plugin's are required
* 64-Bit as well as 32-Bit encoder binaries are fully supported
* Optionally the "high bit-depth" encoder variants can be selected
* Batch encoding (job control) support is implemented
* If desired, multiple encoding jobs can be executed concurrently
* Adding new jobs via command-line interface is supported
* Input from the Avisynth *and* VapurSynth frame servers is supported
* 32-Bit Avisynth/VapourSynth can be mixed with 64-Bit x264/x265
* Straightforward encoder setup thanks to the Preset and Tuning system
* Custom encoder parameters can be added, if desired
* Easily manage your encoder configurations with user-defined templates
* Consistent "look & feel" on all systems thanks to the Qt toolkit


System Requirements:

* Windows Vista with Service Pack 2 or any later Windows system
* 64-Bit Windows is highly recommended (32-Bit Windows works as well)
* The CPU must support at least the MMX and SSE instruction sets
* Avisynth input only available with Avisynth 2.5+ installed
* VapourSynth input only available with VapourSynth R19+ installed
* YV16/YV24 color spaces require Avisynth 2.6 (see section 10)

Simple x264 Launcher is 100% standalone, i.e. it does *not* require
Mircrosoft.NET, Java Runtime Environment or other dependencies.

The required Qt DLLs and encoder binaries are included in the setup.

http://i.imgur.com/x7D7UDQ.png
http://i.imgur.com/hbJ8uFX.pnghttp://i.imgur.com/LCT4gdc.png


Download the latest version here:
https://github.com/lordmulder/Simple-x264-Launcher/releases/latest
https://osdn.net/projects/x264-launcher/releases/
https://bitbucket.org/muldersoft/simple-x264-launcher/downloads/
https://www.assembla.com/spaces/simple-x264-x265-launcher/documents
https://www.mediafire.com/folder/7sac4w9fdszuf/x264_x64_Launcher

See also:
http://www.portablefreeware.com/?id=2240


Note: Occasionally your Antivirus program may mistakenly detect "malware" (virus, trojan, worm, etc.) in some of the files here.
This is called a "false-positive" (http://antivirus.about.com/od/whatisavirus/g/falsepositive.htm) and the files are actually innocent (clean). It's a failure in your specific Antivirus software.
In case you encounter such problems, go to http://www.virustotal.com/ and check the file again with multiple Antivirus engines!
And take care with results like "suspicious", "generic" or "packed". Those are *not* real hits, they are just wild speculation...

[LoRd_MuldeR]

352x288 with "slow" settings on WindowsXP x64-Edition:

Source: C:\TEMP\x264\sample.avs
Params: --crf 22 --subme 9 --me umh --bframes 4 --b-adapt 2 --b-pyramid --direct auto --ref 6 --mixed-refs --trellis 2 --weightb --8x8dct

[Mode: 32-Bit, Pipe Buffer: 0 MByte]
encoded 2262 frames, 49.21 fps, 463.48 kb/s
encoded 2262 frames, 49.48 fps, 463.48 kb/s
encoded 2262 frames, 49.43 fps, 463.48 kb/s

[Mode: 64-Bit, Pipe Buffer: 0 MByte]
encoded 2262 frames, 56.84 fps, 463.48 kb/s
encoded 2262 frames, 56.31 fps, 463.48 kb/s
encoded 2262 frames, 56.97 fps, 463.48 kb/s

[Mode: 64-Bit, Pipe Buffer: 1 MByte]
encoded 2262 frames, 55.11 fps, 463.48 kb/s
encoded 2262 frames, 56.88 fps, 463.48 kb/s
encoded 2262 frames, 55.23 fps, 463.48 kb/s

[Mode: 64-Bit, Pipe Buffer: 2 MByte]
encoded 2262 frames, 55.89 fps, 463.48 kb/s
encoded 2262 frames, 47.14 fps, 463.48 kb/s
encoded 2262 frames, 55.85 fps, 463.48 kb/s

[Mode: 64-Bit, Pipe Buffer: 4 MByte]
encoded 2262 frames, 56.91 fps, 463.48 kb/s
encoded 2262 frames, 56.15 fps, 463.48 kb/s
encoded 2262 frames, 56.93 fps, 463.48 kb/s

[Mode: 64-Bit, Pipe Buffer: 8 MByte]
encoded 2262 frames, 56.53 fps, 463.48 kb/s
encoded 2262 frames, 56.50 fps, 463.48 kb/s
encoded 2262 frames, 56.05 fps, 463.48 kb/s

[Mode: 64-Bit, Pipe Buffer: 16 MByte]
encoded 2262 frames, 55.59 fps, 463.48 kb/s
encoded 2262 frames, 56.22 fps, 463.48 kb/s
encoded 2262 frames, 55.62 fps, 463.48 kb/s

[Mode: 64-Bit, Pipe Buffer: 32 MByte]
encoded 2262 frames, 54.38 fps, 463.48 kb/s
encoded 2262 frames, 51.74 fps, 463.48 kb/s
encoded 2262 frames, 54.73 fps, 463.48 kb/s

[Mode: 64-Bit, Pipe Buffer: 64 MByte]
encoded 2262 frames, 51.80 fps, 463.48 kb/s
encoded 2262 frames, 51.59 fps, 463.48 kb/s
encoded 2262 frames, 51.37 fps, 463.48 kb/s

[Mode: 64-Bit, Pipe Buffer: 128 MByte]
encoded 2262 frames, 45.06 fps, 463.48 kb/s
encoded 2262 frames, 45.00 fps, 463.48 kb/s
encoded 2262 frames, 45.18 fps, 463.48 kb/s

352x288 with "fast" settings on WindowsXP x64-Edition:

Source: C:\TEMP\x264\sample.avs
Params: --crf 22 --subme 2 --me hex --analyse none

[Mode: 32-Bit, Pipe Buffer: 0 MByte]
encoded 2262 frames, 373.14 fps, 542.81 kb/s
encoded 2262 frames, 386.07 fps, 542.81 kb/s
encoded 2262 frames, 392.37 fps, 542.81 kb/s

[Mode: 64-Bit, Pipe Buffer: 0 MByte]
encoded 2262 frames, 362.85 fps, 542.82 kb/s
encoded 2262 frames, 357.46 fps, 542.82 kb/s
encoded 2262 frames, 358.31 fps, 542.82 kb/s

[Mode: 64-Bit, Pipe Buffer: 1 MByte]
encoded 2262 frames, 403.21 fps, 542.82 kb/s
encoded 2262 frames, 396.63 fps, 542.82 kb/s
encoded 2262 frames, 374.07 fps, 542.82 kb/s

[Mode: 64-Bit, Pipe Buffer: 2 MByte]
encoded 2262 frames, 378.96 fps, 542.82 kb/s
encoded 2262 frames, 386.01 fps, 542.82 kb/s
encoded 2262 frames, 391.21 fps, 542.82 kb/s

[Mode: 64-Bit, Pipe Buffer: 4 MByte]
encoded 2262 frames, 370.27 fps, 542.82 kb/s
encoded 2262 frames, 389.19 fps, 542.82 kb/s
encoded 2262 frames, 370.21 fps, 542.82 kb/s

[Mode: 64-Bit, Pipe Buffer: 8 MByte]
encoded 2262 frames, 323.84 fps, 542.82 kb/s
encoded 2262 frames, 328.25 fps, 542.82 kb/s
encoded 2262 frames, 331.28 fps, 542.82 kb/s

[Mode: 64-Bit, Pipe Buffer: 16 MByte]
encoded 2262 frames, 300.32 fps, 542.82 kb/s
encoded 2262 frames, 355.66 fps, 542.82 kb/s
encoded 2262 frames, 378.01 fps, 542.82 kb/s

[Mode: 64-Bit, Pipe Buffer: 32 MByte]
encoded 2262 frames, 329.02 fps, 542.82 kb/s
encoded 2262 frames, 368.34 fps, 542.82 kb/s
encoded 2262 frames, 334.37 fps, 542.82 kb/s

[Mode: 64-Bit, Pipe Buffer: 64 MByte]
encoded 2262 frames, 393.39 fps, 542.82 kb/s
encoded 2262 frames, 316.81 fps, 542.82 kb/s
encoded 2262 frames, 330.56 fps, 542.82 kb/s

[Mode: 64-Bit, Pipe Buffer: 128 MByte]
encoded 2262 frames, 394.49 fps, 542.82 kb/s
encoded 2262 frames, 328.30 fps, 542.82 kb/s
encoded 2262 frames, 312.00 fps, 542.82 kb/s

Seems bigger pipe buffer doesn't help much here. Default value (0 MByte) aka "let Windows choose" already gives good results :o

Maybe 1 MB or 2 MB may be a good choice ???

[Fishman0919]

loadplugin("DGAVCDecode.dll")
AVCSource("file.dga")
Spline64Resize(1280,720)
trim(0, 3500)
ConvertToYV12()

First 3501 frames from Journey to the Center of the Earth (2008)
BluRay 1080p

Vista 64

Source: C:\Temp\test.avs
Params: --crf 22

[Mode: 32-Bit, Pipe Buffer: 0 MByte]
encoded 3501 frames, 30.45 fps, 2896.24 kb/s
encoded 3501 frames, 31.07 fps, 2896.24 kb/s
encoded 3501 frames, 31.15 fps, 2896.24 kb/s

[Mode: 64-Bit, Pipe Buffer: 0 MByte]
encoded 3501 frames, 31.61 fps, 2896.23 kb/s
encoded 3501 frames, 31.96 fps, 2896.23 kb/s
encoded 3501 frames, 31.98 fps, 2896.23 kb/s

[Mode: 64-Bit, Pipe Buffer: 1 MByte]
encoded 3501 frames, 32.22 fps, 2896.23 kb/s
encoded 3501 frames, 32.27 fps, 2896.23 kb/s
encoded 3501 frames, 31.88 fps, 2896.23 kb/s

[Mode: 64-Bit, Pipe Buffer: 2 MByte]
encoded 3501 frames, 32.26 fps, 2896.23 kb/s
encoded 3501 frames, 32.24 fps, 2896.23 kb/s
encoded 3501 frames, 32.27 fps, 2896.23 kb/s

[Mode: 64-Bit, Pipe Buffer: 4 MByte]
encoded 3501 frames, 31.71 fps, 2896.23 kb/s
encoded 3501 frames, 31.83 fps, 2896.23 kb/s
encoded 3501 frames, 31.88 fps, 2896.23 kb/s

[Mode: 64-Bit, Pipe Buffer: 8 MByte]
encoded 3501 frames, 32.03 fps, 2896.23 kb/s
encoded 3501 frames, 32.14 fps, 2896.23 kb/s
encoded 3501 frames, 32.05 fps, 2896.23 kb/s

[Mode: 64-Bit, Pipe Buffer: 16 MByte]
encoded 3501 frames, 31.56 fps, 2896.23 kb/s
encoded 3501 frames, 31.56 fps, 2896.23 kb/s
encoded 3501 frames, 31.56 fps, 2896.23 kb/s

[Mode: 64-Bit, Pipe Buffer: 32 MByte]
encoded 3501 frames, 30.77 fps, 2896.23 kb/s
encoded 3501 frames, 31.13 fps, 2896.23 kb/s
encoded 3501 frames, 31.13 fps, 2896.23 kb/s

[Mode: 64-Bit, Pipe Buffer: 64 MByte]
encoded 3501 frames, 29.90 fps, 2896.23 kb/s
encoded 3501 frames, 29.98 fps, 2896.23 kb/s
encoded 3501 frames, 29.97 fps, 2896.23 kb/s

[Mode: 64-Bit, Pipe Buffer: 128 MByte]
encoded 3501 frames, 27.69 fps, 2896.23 kb/s
encoded 3501 frames, 27.80 fps, 2896.23 kb/s
encoded 3501 frames, 27.65 fps, 2896.23 kb/s



Source: C:\Temp\test.avs
Params: --crf 22 --filter 0,0 --ref 3 --mixed-refs --bframes 3 --b-pyramid --keyint 24 --min-keyint 2 --direct auto --b-adapt 2 --subme 7 --trellis 2 --partitions all --8x8dct --me umh --merange 24 --no-fast-pskip

[Mode: 32-Bit, Pipe Buffer: 0 MByte]
encoded 3501 frames, 13.99 fps, 3174.75 kb/s
encoded 3501 frames, 14.05 fps, 3174.75 kb/s
encoded 3501 frames, 14.03 fps, 3174.75 kb/s

[Mode: 64-Bit, Pipe Buffer: 0 MByte]
encoded 3501 frames, 15.15 fps, 3174.75 kb/s
encoded 3501 frames, 15.22 fps, 3174.75 kb/s
encoded 3501 frames, 15.21 fps, 3174.75 kb/s

[Mode: 64-Bit, Pipe Buffer: 1 MByte]
encoded 3501 frames, 15.26 fps, 3174.75 kb/s
encoded 3501 frames, 15.27 fps, 3174.75 kb/s
encoded 3501 frames, 15.27 fps, 3174.75 kb/s

[Mode: 64-Bit, Pipe Buffer: 2 MByte]
encoded 3501 frames, 15.29 fps, 3174.75 kb/s
encoded 3501 frames, 15.29 fps, 3174.75 kb/s
encoded 3501 frames, 15.25 fps, 3174.75 kb/s

[Mode: 64-Bit, Pipe Buffer: 4 MByte]
encoded 3501 frames, 15.27 fps, 3174.75 kb/s
encoded 3501 frames, 15.26 fps, 3174.75 kb/s
encoded 3501 frames, 15.25 fps, 3174.75 kb/s

[Mode: 64-Bit, Pipe Buffer: 8 MByte]
encoded 3501 frames, 15.25 fps, 3174.75 kb/s
encoded 3501 frames, 15.21 fps, 3174.75 kb/s
encoded 3501 frames, 15.24 fps, 3174.75 kb/s

[Mode: 64-Bit, Pipe Buffer: 16 MByte]
encoded 3501 frames, 15.17 fps, 3174.75 kb/s
encoded 3501 frames, 15.20 fps, 3174.75 kb/s
encoded 3501 frames, 15.17 fps, 3174.75 kb/s

[Mode: 64-Bit, Pipe Buffer: 32 MByte]
encoded 3501 frames, 15.07 fps, 3174.75 kb/s
encoded 3501 frames, 15.08 fps, 3174.75 kb/s
encoded 3501 frames, 15.09 fps, 3174.75 kb/s

[Mode: 64-Bit, Pipe Buffer: 64 MByte]
encoded 3501 frames, 14.68 fps, 3174.75 kb/s
encoded 3501 frames, 14.64 fps, 3174.75 kb/s
encoded 3501 frames, 14.70 fps, 3174.75 kb/s

[Mode: 64-Bit, Pipe Buffer: 128 MByte]
encoded 3501 frames, 14.37 fps, 3174.75 kb/s
encoded 3501 frames, 14.33 fps, 3174.75 kb/s
encoded 3501 frames, 14.32 fps, 3174.75 kb/s

[turbojet]

X2 3800+ at 2.5 ghz, Vista 64

CoreAVC feeding a 1920x1080 stream, just directshowsource in avs.Params: --crf 22

[Mode: 32-Bit, Pipe Buffer: 0 MByte]
encoded 1377 frames, 4.10 fps, 9437.87 kb/s
encoded 1377 frames, 3.78 fps, 9437.87 kb/s
encoded 1377 frames, 3.89 fps, 9437.87 kb/s

[Mode: 64-Bit, Pipe Buffer: 0 MByte]
encoded 1377 frames, 4.06 fps, 9437.88 kb/s
encoded 1377 frames, 4.08 fps, 9437.88 kb/s
encoded 1377 frames, 4.14 fps, 9437.88 kb/s

[Mode: 64-Bit, Pipe Buffer: 1 MByte]
encoded 1377 frames, 4.12 fps, 9437.88 kb/s
encoded 1377 frames, 4.10 fps, 9437.88 kb/s
encoded 1377 frames, 4.22 fps, 9437.88 kb/s

[Mode: 64-Bit, Pipe Buffer: 2 MByte]
encoded 1377 frames, 4.30 fps, 9437.88 kb/s
encoded 1377 frames, 4.06 fps, 9437.88 kb/s
encoded 1377 frames, 3.47 fps, 9437.88 kb/s

[Mode: 64-Bit, Pipe Buffer: 4 MByte]
encoded 1377 frames, 3.48 fps, 9437.88 kb/s
encoded 1377 frames, 4.48 fps, 9437.88 kb/s
encoded 1377 frames, 4.40 fps, 9437.88 kb/s

[Mode: 64-Bit, Pipe Buffer: 8 MByte]
encoded 1377 frames, 4.15 fps, 9437.88 kb/s
encoded 1377 frames, 4.17 fps, 9437.88 kb/s
encoded 1377 frames, 4.08 fps, 9437.88 kb/s

[Mode: 64-Bit, Pipe Buffer: 16 MByte]
encoded 1377 frames, 4.11 fps, 9437.88 kb/s
encoded 1377 frames, 4.07 fps, 9437.88 kb/s
encoded 1377 frames, 4.34 fps, 9437.88 kb/s

[Mode: 64-Bit, Pipe Buffer: 32 MByte]
encoded 1377 frames, 4.34 fps, 9437.88 kb/s
encoded 1377 frames, 4.23 fps, 9437.88 kb/s
encoded 1377 frames, 4.18 fps, 9437.88 kb/s

[Mode: 64-Bit, Pipe Buffer: 64 MByte]
encoded 1377 frames, 3.90 fps, 9437.88 kb/s
encoded 1377 frames, 3.93 fps, 9437.88 kb/s
encoded 1377 frames, 3.97 fps, 9437.88 kb/s

Thanks for your launcher app btw, I've been getting some good use out of it.

If your intention is to go beyond 32 vs 64 bit and do a good benchmark from different cpus, might I make a suggestion to make a more accurate test? That's include a small 1080p m2ts, dgavcdecode.dll, .dga and 2 avs for 720p and 1080p, and have a 'fast' encode setting and 'normal' encode setting both as a part of the benchmark.

[LoRd_MuldeR]

If your intention is to go beyond 32 vs 64 bit and do a good benchmark from different cpus, might I make a suggestion to make a more accurate test? That's include a small 1080p m2ts, dgavcdecode.dll, .dga and 2 avs for 720p and 1080p, and have a 'fast' encode setting and 'normal' encode setting both as a part of the benchmark.

My intention is mainly to find out whether the 64-Bit version (using piped input) is truly faster than the 32-Bit version (using native AVS input).

Also I try to find out whether any user-defined buffer size can give a benefit over the default buffer size (aka "let Windows decide").

[RunningSkittle]

DGDecode_mpeg2source("D:\dvdrips\totoro\VTS_07_VOBID_009_CELLID_001_1.d2v")
tfm(order=1).tdecimate(mode=1)
crop( 8, 6, -6, -14)
LanczosResize(720,384)

Q6600@ 3.0ghz
Vista X64
4gb DDRII 800

Short clip from R1 Totoro:
Source: D:\dvdrips\totoro\VTS_07_VOBID_009_CELLID_001_1.avs
Params: --crf 18 --ref 5 --mixed-refs --bframes 3 --b-adapt 2 --b-pyramid --weightb --deblock -1:-1 --trellis 2 --partitions all --8x8dct --me umh --aud

[Mode: 32-Bit, Pipe Buffer: 0 MByte]
encoded 437 frames, 21.55 fps, 1792.72 kb/s
encoded 437 frames, 21.60 fps, 1792.72 kb/s
encoded 437 frames, 21.68 fps, 1792.72 kb/s

[Mode: 64-Bit, Pipe Buffer: 0 MByte]
encoded 437 frames, 24.09 fps, 1792.72 kb/s
encoded 437 frames, 23.86 fps, 1792.72 kb/s
encoded 437 frames, 23.92 fps, 1792.72 kb/s

[Mode: 64-Bit, Pipe Buffer: 1 MByte]
encoded 437 frames, 24.29 fps, 1792.72 kb/s
encoded 437 frames, 24.15 fps, 1792.72 kb/s
encoded 437 frames, 24.17 fps, 1792.72 kb/s

[Mode: 64-Bit, Pipe Buffer: 2 MByte]
encoded 437 frames, 24.02 fps, 1792.72 kb/s
encoded 437 frames, 23.98 fps, 1792.72 kb/s
encoded 437 frames, 24.02 fps, 1792.72 kb/s

[Mode: 64-Bit, Pipe Buffer: 4 MByte]
encoded 437 frames, 23.90 fps, 1792.72 kb/s
encoded 437 frames, 23.98 fps, 1792.72 kb/s
encoded 437 frames, 24.09 fps, 1792.72 kb/s

[Mode: 64-Bit, Pipe Buffer: 8 MByte]
encoded 437 frames, 23.53 fps, 1792.72 kb/s
encoded 437 frames, 23.37 fps, 1792.72 kb/s
encoded 437 frames, 23.60 fps, 1792.72 kb/s

[Mode: 64-Bit, Pipe Buffer: 16 MByte]
encoded 437 frames, 23.38 fps, 1792.72 kb/s
encoded 437 frames, 23.83 fps, 1792.72 kb/s
encoded 437 frames, 23.89 fps, 1792.72 kb/s

[Mode: 64-Bit, Pipe Buffer: 32 MByte]
encoded 437 frames, 23.47 fps, 1792.72 kb/s
encoded 437 frames, 23.74 fps, 1792.72 kb/s
encoded 437 frames, 23.58 fps, 1792.72 kb/s

[Mode: 64-Bit, Pipe Buffer: 64 MByte]
encoded 437 frames, 23.12 fps, 1792.72 kb/s
encoded 437 frames, 22.65 fps, 1792.72 kb/s
encoded 437 frames, 22.50 fps, 1792.72 kb/s

[Mode: 64-Bit, Pipe Buffer: 128 MByte]
encoded 437 frames, 22.57 fps, 1792.72 kb/s
encoded 437 frames, 23.23 fps, 1792.72 kb/s
encoded 437 frames, 23.04 fps, 1792.72 kb/s

[RunningSkittle]

avcsource()
trim(0,999)

First 1000 frames from Dead space. 1080p.


[Mode: 32-Bit, Pipe Buffer: 0 MByte]
encoded 1000 frames, 3.26 fps, 17443.48 kb/s
encoded 1000 frames, 3.26 fps, 17443.48 kb/s
encoded 1000 frames, 3.28 fps, 17443.48 kb/s

[Mode: 64-Bit, Pipe Buffer: 0 MByte]
encoded 1000 frames, 3.58 fps, 17443.48 kb/s
encoded 1000 frames, 3.50 fps, 17443.48 kb/s
encoded 1000 frames, 3.47 fps, 17443.48 kb/s

[Mode: 64-Bit, Pipe Buffer: 1 MByte]
encoded 1000 frames, 3.50 fps, 17443.48 kb/s
encoded 1000 frames, 3.49 fps, 17443.48 kb/s
encoded 1000 frames, 3.52 fps, 17443.48 kb/s

[Mode: 64-Bit, Pipe Buffer: 2 MByte]
encoded 1000 frames, 3.51 fps, 17443.48 kb/s
encoded 1000 frames, 3.63 fps, 17443.48 kb/s
encoded 1000 frames, 3.63 fps, 17443.48 kb/s

[Mode: 64-Bit, Pipe Buffer: 4 MByte]
encoded 1000 frames, 3.64 fps, 17443.48 kb/s
encoded 1000 frames, 3.63 fps, 17443.48 kb/s
encoded 1000 frames, 3.64 fps, 17443.48 kb/s

[Mode: 64-Bit, Pipe Buffer: 8 MByte]
encoded 1000 frames, 3.64 fps, 17443.48 kb/s
encoded 1000 frames, 3.64 fps, 17443.48 kb/s
encoded 1000 frames, 3.64 fps, 17443.48 kb/s

[Mode: 64-Bit, Pipe Buffer: 16 MByte]
encoded 1000 frames, 3.63 fps, 17443.48 kb/s
encoded 1000 frames, 3.62 fps, 17443.48 kb/s
encoded 1000 frames, 3.45 fps, 17443.48 kb/s

[Mode: 64-Bit, Pipe Buffer: 32 MByte]
encoded 1000 frames, 3.63 fps, 17443.48 kb/s
encoded 1000 frames, 3.64 fps, 17443.48 kb/s
encoded 1000 frames, 3.58 fps, 17443.48 kb/s

[Mode: 64-Bit, Pipe Buffer: 64 MByte]
encoded 1000 frames, 3.60 fps, 17443.48 kb/s
encoded 1000 frames, 3.60 fps, 17443.48 kb/s
encoded 1000 frames, 3.60 fps, 17443.48 kb/s

[Mode: 64-Bit, Pipe Buffer: 128 MByte]
encoded 1000 frames, 3.58 fps, 17443.48 kb/s
encoded 1000 frames, 3.58 fps, 17443.48 kb/s
encoded 1000 frames, 3.57 fps, 17443.48 kb/s

[roozhou]

My intention is mainly to find out whether the 64-Bit version (using piped input) is truly faster than the 32-Bit version (using native AVS input).

Also I try to find out whether any user-defined buffer size can give a benefit over the default buffer size (aka "let Windows decide").

Once I have 64-bit Windows installed, i will try to add directshow input support, which is already done in win32, to 64-bit x264.

Unfortunately i cannot run your test coz i don't have 64-bit Windows installed at present.:(

[LoRd_MuldeR]

Once I have 64-bit Windows installed, i will try to add directshow input support, which is already done in win32, to 64-bit x264.

That certainly would be an interesting option, but we'd still need to use 64-Bit DirectShow filters and 64-Bit Avisynth. So it may be good for certain purposes (use DirectShow input, have a suitable DirectShow 64-bit Decoder available and don't need Avisynth), but it doesn't solve the basic problem - the lack of 32-Bit Avisynth input. Therefore it's not hard to predict that the pipe method will be around for quite some time...

[roozhou]

That certainly would be an interesting option, but we'd still need to use 64-Bit DirectShow filters and 64-Bit Avisynth. So it may be good for certain purposes (use DirectShow input, have a suitable DirectShow 64-bit Decoder available and don't need Avisynth), but it doesn't solve the basic problem - the lack of 32-Bit Avisynth input. Therefore it's not hard to predict that the pipe method will be around for quite some time...

Most of avisynth plugins are open source. Try to make them compile for 64-bit. If it fails, just drop it.

P.S. ffdshow's built-in filters are awesome. Resizer in ffdshow runs 50%~100% faster than avisynth's.

[LoRd_MuldeR]

Most of avisynth plugins are open source. Try to make them compile for 64-bit. If it fails, just drop it.

Good luck with that :)

[Atak_Snajpera]

it looks like 4mb buffer works well

[LoRd_MuldeR]

it looks like 4mb buffer works well

Agreed. More than 4 MB seems to be no good. Also "slow" settings seem to profit from 64-Bit more than "fast" settings.

[Atak_Snajpera]

Also "slow" settings seem to profit from 64-Bit more than "fast" settings.
I'm not surprised :)

[turbojet]

Do you plan on adding a queue system to the launcher?
If you did add a queue system I'd use it regularly, at the speeds I run at every little bit of speed helps.

I'm not aware of any gui with x64 264 support and a queue system. So I might not be the only one wanting something like this.

I like the simple ui, one thing I do wish I could do is delete saved command lines I don't want to keep. Would that be possible as well?

Also is there a way to define buffer in the command line?

[vucloutr]

here with some really slow settings, OS: Server 2008 x64, CPU: Q6600@3GHz
Source: D:\x264launcher\720p.avs
Params: --keyint 240 --min-keyint 24 --bframes 4 --b-adapt 2 --b-pyramid --ref 9 --deblock -3,-2 --crf 19
--ipratio 1.4 --pbratio 1.0 --aq-strength 0.8 --direct auto --weightb --me esa --merange 24 --subme 9
--mixed-refs --8x8dct --no-fast-pskip --no-dct-decimate --deadzone-intra 9 --deadzone-inter 5
--no-psnr --no-ssim --thread-input

[Mode: 32-Bit, Pipe Buffer: 0 MByte]
encoded 334 frames, 2.50 fps, 10648.77 kb/s
encoded 334 frames, 2.50 fps, 10648.77 kb/s
encoded 334 frames, 2.49 fps, 10648.77 kb/s

[Mode: 64-Bit, Pipe Buffer: 0 MByte]
encoded 334 frames, 2.68 fps, 10648.77 kb/s
encoded 334 frames, 2.67 fps, 10648.77 kb/s
encoded 334 frames, 2.67 fps, 10648.77 kb/s

[Mode: 64-Bit, Pipe Buffer: 1 MByte]
encoded 334 frames, 2.68 fps, 10648.77 kb/s
encoded 334 frames, 2.68 fps, 10648.77 kb/s
encoded 334 frames, 2.68 fps, 10648.77 kb/s

[Mode: 64-Bit, Pipe Buffer: 2 MByte]
encoded 334 frames, 2.68 fps, 10648.77 kb/s
encoded 334 frames, 2.68 fps, 10648.77 kb/s
encoded 334 frames, 2.69 fps, 10648.77 kb/s

[Mode: 64-Bit, Pipe Buffer: 4 MByte]
encoded 334 frames, 2.68 fps, 10648.77 kb/s
encoded 334 frames, 2.68 fps, 10648.77 kb/s
encoded 334 frames, 2.67 fps, 10648.77 kb/s

[Mode: 64-Bit, Pipe Buffer: 8 MByte]
encoded 334 frames, 2.67 fps, 10648.77 kb/s
encoded 334 frames, 2.68 fps, 10648.77 kb/s
encoded 334 frames, 2.68 fps, 10648.77 kb/s

[Mode: 64-Bit, Pipe Buffer: 16 MByte]
encoded 334 frames, 2.67 fps, 10648.77 kb/s
encoded 334 frames, 2.67 fps, 10648.77 kb/s
encoded 334 frames, 2.69 fps, 10648.77 kb/s

[Mode: 64-Bit, Pipe Buffer: 32 MByte]
encoded 334 frames, 2.70 fps, 10648.77 kb/s
encoded 334 frames, 2.68 fps, 10648.77 kb/s
encoded 334 frames, 2.66 fps, 10648.77 kb/s

[Mode: 64-Bit, Pipe Buffer: 64 MByte]
encoded 334 frames, 2.66 fps, 10648.77 kb/s
encoded 334 frames, 2.67 fps, 10648.77 kb/s
encoded 334 frames, 2.68 fps, 10648.77 kb/s

[Mode: 64-Bit, Pipe Buffer: 128 MByte]
encoded 334 frames, 2.67 fps, 10648.77 kb/s
encoded 334 frames, 2.67 fps, 10648.77 kb/s
encoded 334 frames, 2.67 fps, 10648.77 kb/s

[LoRd_MuldeR]

Do you plan on adding a queue system to the launcher?

Not planned.

I'm not aware of any gui with x64 264 support and a queue system. So I might not be the only one wanting something like this.

Think 64-Bit support will be added to RipBot264, if not done already.

I like the simple ui, one thing I do wish I could do is delete saved command lines I don't want to keep. Would that be possible as well?

Edit the INI file :p

Also is there a way to define buffer in the command line?

Yes. In the commandline for pipebuf.exe ;)

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]

[LoRd_MuldeR]

Updated x264 binaries to r1088 (built by Skystrife) and set default buffer size to 4 MB, as that seems to perform best ;)

[turbojet]

Pity you don't plan on adding a little queue. Do you mind if I have someone try to add one?

Good news about RipBot264 getting x64 support. It's a gui I use every once in awhile.

Where is the .ini file for the launcher?

Thanks for the pipebuf info.

[LoRd_MuldeR]

Pity you don't plan on adding a little queue. Do you mind if I have someone try to add one?

The sources are attached, available for anybody who thinks they can be helpful ;)

So if anybody feels like implementing a queue, have your fun :D

[LoRd_MuldeR]

Updated x264 binaries to r1096 (Komisar build).

[LoRd_MuldeR]

Updated x264 binaries to r1101 (Skystrife builds).

[Rodger]

Hallo Mulder, hier ein paar brand neue Resultate von mir:
Vista Home Premium 64bit, 4GB Ram, E8400@3537Mhz, P45 Mainboard.

Source: D:\Temp\MTV - h264_576p.avs
Params: --crf 22

[Mode: 32-Bit, Pipe Buffer: 0 MByte]
encoded 7475 frames, 66.70 fps, 1604.27 kb/s
encoded 7475 frames, 66.78 fps, 1604.27 kb/s
encoded 7475 frames, 67.04 fps, 1604.27 kb/s

[Mode: 64-Bit, Pipe Buffer: 0 MByte]
encoded 7475 frames, 69.44 fps, 1604.29 kb/s
encoded 7475 frames, 69.53 fps, 1604.29 kb/s
encoded 7475 frames, 69.31 fps, 1604.29 kb/s

[Mode: 64-Bit, Pipe Buffer: 1 MByte]
encoded 7475 frames, 69.75 fps, 1604.29 kb/s
encoded 7475 frames, 69.65 fps, 1604.29 kb/s
encoded 7475 frames, 69.69 fps, 1604.29 kb/s

[Mode: 64-Bit, Pipe Buffer: 2 MByte]
encoded 7475 frames, 69.09 fps, 1604.29 kb/s
encoded 7475 frames, 69.47 fps, 1604.29 kb/s
encoded 7475 frames, 68.96 fps, 1604.29 kb/s

[Mode: 64-Bit, Pipe Buffer: 4 MByte]
encoded 7475 frames, 68.97 fps, 1604.29 kb/s
encoded 7475 frames, 69.13 fps, 1604.29 kb/s
encoded 7475 frames, 69.62 fps, 1604.29 kb/s

[Mode: 64-Bit, Pipe Buffer: 8 MByte]
encoded 7475 frames, 67.28 fps, 1604.29 kb/s
encoded 7475 frames, 67.37 fps, 1604.29 kb/s
encoded 7475 frames, 67.60 fps, 1604.29 kb/s

[Mode: 64-Bit, Pipe Buffer: 16 MByte]
encoded 7475 frames, 65.11 fps, 1604.29 kb/s
encoded 7475 frames, 65.07 fps, 1604.29 kb/s
encoded 7475 frames, 65.20 fps, 1604.29 kb/s

[LoRd_MuldeR]

Updated x264 binaries to r1107 (Komisar builds).

[LoRd_MuldeR]

Updated x264 binaries to r1109 (Skystrife builds).

My recent test shows significant speed-up between 32-Bit and 64-Bit:
Source: C:\TEMP\x264\sample.avs
Params: --crf 22 --subme 9 --me umh --analyse all --8x8dct --bframe 4 --b-adapt 2 --ref 6 --b-pyramid --trellis 2 --weightb --mixed-refs --direct auto

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 2262 frames, 55.68 fps, 457.49 kb/s
encoded 2262 frames, 57.09 fps, 457.49 kb/s
encoded 2262 frames, 57.88 fps, 457.49 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 2262 frames, 67.55 fps, 457.49 kb/s
encoded 2262 frames, 67.08 fps, 457.49 kb/s
encoded 2262 frames, 67.18 fps, 457.49 kb/s

That's a nice 20% speed-up for high (but not overkill) settings, even though the pipe is involved :)

[Atak_Snajpera]

Could you test with faster settings --subme 7 --bframe 3 --b-adapt 1 --ref 3 --trellis 1

[LoRd_MuldeR]

Yup: That's still a speed-up of ~1% to ~3%. Bigger fluctuations this time.

Source: C:\TEMP\x264\sample.avs
Params: --crf 22 --subme 7 --bframe 3 --b-adapt 1 --ref 3 --trellis 1

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 2262 frames, 201.07 fps, 441.97 kb/s
encoded 2262 frames, 202.20 fps, 441.97 kb/s
encoded 2262 frames, 202.18 fps, 441.97 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 2262 frames, 209.21 fps, 441.97 kb/s
encoded 2262 frames, 204.48 fps, 441.97 kb/s
encoded 2262 frames, 192.51 fps, 441.97 kb/s

[Atak_Snajpera]

Could you try with 1080p source?

[LoRd_MuldeR]

This time 64-Bit was slightly slower:

Source: C:\Crowdrun1080p.avs
Params: --crf 22 --subme 7 --bframe 3 --b-adapt 1 --ref 3 --trellis 1

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 500 frames, 3.46 fps, 20170.88 kb/s
encoded 500 frames, 3.54 fps, 20170.88 kb/s
encoded 500 frames, 3.53 fps, 20170.88 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 500 frames, 3.37 fps, 20170.88 kb/s
encoded 500 frames, 3.37 fps, 20170.88 kb/s
encoded 500 frames, 3.36 fps, 20170.88 kb/s

[Atak_Snajpera]

Could you try again with the same source but with your insane settings? :)

[LoRd_MuldeR]

Could you try again with the same source but with your insane settings? :)

No, takes too long. Maybe tomorrow ;)

[LoRd_MuldeR]

Updated x264 binaries to r1113 (Skystrife builds).

[hd1080]

Can i do with your programm 2pass encodes?

[LoRd_MuldeR]

Can i do with your programm 2pass encodes?

Sure. But you need to run both passes manually, each with the required parameters. There's no automated 2-Pass implemented, if you mean that...

[LoRd_MuldeR]

Updated x264 binaries to r1114 (builds taken from x264.nl).

[henryho_hk]

May I know what is the difference between pipebuf.exe and normal "|" piping?

I tried "|"'ing 32-bit mencoder's output to 64-bit x264.exe but it failed.

[LoRd_MuldeR]

May I know what is the difference between pipebuf.exe and normal "|" piping?

I tried "|"'ing 32-bit mencoder's output to 64-bit x264.exe but it failed.

The "|" operator will only work in the Windows Commandline Interpreter (aka "cmd.exe"), but it will not work in CreateProcess() or WinExec() natively.

So if you don't use my 'pipebuf.exe' tool, then you will need to use 'cmd.exe' instead and pass the commandline via "/c" option.

The advantage of 'pipebuf.exe' is that it has a nicer syntax (cmd.exe has a pretty bizarre way of handling quotes) and that you are able to specify the pipe buffer size.

Internally 'cmd.exe' will create the pipe in the very same way that 'pipebuf.exe' usese, I guess...

[LoRd_MuldeR]

Updated x264 binaries to r1120 (Skystrife builds).

[LoRd_MuldeR]

Updated x264 binaries to r1125 (builds taken from x264.nl).

[puffpio]

when doing the benchmark, i notice that the first benchmark (the 32 bit one) only uses 1 of my cpu's
while just hitting start calls the 64 bit version and it uses both cpu's...

thoughts? running windows 7 and your latest version w/ x264 1125

[puffpio]

update : nevermind
even though the process was listed using 50%, the total cpu usage was 100%..i think the task manager was not reporting it correctly

[puffpio]

Source: D:\temp\090306212759.avs
Params: --crf 22 --ref 5 --mixed-refs --bframes 3 --b-adapt 2 --b-pyramid --weightb --deblock -1:-1 --subme 8 --trellis 2 --partitions all --8x8dct --me umh --thread-input --no-psnr --no-ssim

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 1784 frames, 1.95 fps, 4160.33 kb/s
encoded 1784 frames, 2.18 fps, 4160.11 kb/s
encoded 1784 frames, 1.98 fps, 4160.33 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 1784 frames, 2.37 fps, 4160.11 kb/s
encoded 1784 frames, 2.32 fps, 4160.11 kb/s
encoded 1784 frames, 2.18 fps, 4160.11 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 1784 frames, 2.43 fps, 4160.11 kb/s
encoded 1784 frames, 2.35 fps, 4160.11 kb/s
encoded 1784 frames, 2.16 fps, 4160.11 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 1784 frames, 2.41 fps, 4160.11 kb/s
encoded 1784 frames, 2.42 fps, 4160.11 kb/s
encoded 1784 frames, 2.17 fps, 4160.11 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 1784 frames, 2.39 fps, 4160.11 kb/s
encoded 1784 frames, 2.42 fps, 4160.11 kb/s
encoded 1784 frames, 2.22 fps, 4160.11 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 1784 frames, 2.39 fps, 4160.11 kb/s
encoded 1784 frames, 2.48 fps, 4160.11 kb/s
encoded 1784 frames, 2.20 fps, 4160.11 kb/s

[LoRd_MuldeR]

when doing the benchmark, i notice that the first benchmark (the 32 bit one) only uses 1 of my cpu's
while just hitting start calls the 64 bit version and it uses both cpu's...

thoughts? running windows 7 and your latest version w/ x264 1125

I'm passing "--threads auto" to x264, so the problem (if there is one) shouldn't be on my side.

Anyway, if you are using a CPU with "Hyperthreading" (2 virtual cores per physical core), then 50% total load means that all physical cores are at 100% load, as Windows Taskmanager will only see virtual cores.

Of course it may also happen that your are bottlenecked by the input (decoder throughput, avisynth script) ...

[HymnToLife]

Not a tremendous speed boost here either.
Source is 1080p anime (creditless opening of Michiko e Hatchin), settings are the ones I use for my real-world encodes (except for the CRF 18, I normally use 2 pass bitrate mode and the final RF is usually something between 19-20).
CPU is Phenom II 940 @ 3.2 GHz, running Vista 64. I also updated x264 to r1127 from x264.nl.
I'm going to run another test with standard definition (DVD) anime soon-ish.

Source: C:\software\x264_x64.2009-03-08\michiko_op.avs
Params: --crf 18 --ref 8 --mixed-refs --no-fast-pskip --bframes 4 --b-adapt 2 --b-pyramid --weightb --direct auto --deblock -1:-1 --subme 7 --trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --merange 22 --psy-rd 0.8:0 --thread-input --no-dct-decimate --no-psnr --no-ssim

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 1944 frames, 5.02 fps, 7196.12 kb/s
encoded 1944 frames, 5.02 fps, 7196.12 kb/s
encoded 1944 frames, 5.03 fps, 7196.12 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 1944 frames, 5.13 fps, 7197.35 kb/s
encoded 1944 frames, 5.13 fps, 7197.35 kb/s
encoded 1944 frames, 5.16 fps, 7197.35 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 1944 frames, 5.16 fps, 7197.35 kb/s
encoded 1944 frames, 5.17 fps, 7197.35 kb/s
encoded 1944 frames, 5.19 fps, 7197.35 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 1944 frames, 5.21 fps, 7197.35 kb/s
encoded 1944 frames, 5.17 fps, 7197.35 kb/s
encoded 1944 frames, 5.16 fps, 7197.35 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 1944 frames, 5.18 fps, 7197.35 kb/s
encoded 1944 frames, 5.17 fps, 7197.35 kb/s
encoded 1944 frames, 5.15 fps, 7197.35 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 1944 frames, 5.18 fps, 7197.35 kb/s
encoded 1944 frames, 5.16 fps, 7197.35 kb/s
encoded 1944 frames, 5.15 fps, 7197.35 kb/s

[HymnToLife]

Creditless first ending of Sky Girls (DVD, IVTC and resizing to 848x480 were done beforehand).
Once again, real-world settings, and once again, a very minimal speed increase.
In both this case and the one above, a buffer size of 2 MB seems to give the "best" results (if I may say so, given the very minimal difference).

Source: C:\software\x264_x64.2009-03-08\skygirls.avs
Params: --crf 18 --level 4.1 --ref 8 --mixed-refs --no-fast-pskip --bframes 4 --b-adapt 2 --b-pyramid --weightb --direct auto --deblock -1:-1 --subme 7 --trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --merange 18 --thread-input --no-dct-decimate --no-psnr --no-ssim

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 2196 frames, 23.58 fps, 2848.26 kb/s
encoded 2196 frames, 23.76 fps, 2848.26 kb/s
encoded 2196 frames, 23.46 fps, 2848.26 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 2196 frames, 24.65 fps, 2848.26 kb/s
encoded 2196 frames, 24.71 fps, 2848.26 kb/s
encoded 2196 frames, 24.86 fps, 2848.26 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 2196 frames, 24.82 fps, 2848.26 kb/s
encoded 2196 frames, 25.49 fps, 2848.26 kb/s
encoded 2196 frames, 24.69 fps, 2848.26 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 2196 frames, 25.49 fps, 2848.26 kb/s
encoded 2196 frames, 25.26 fps, 2848.26 kb/s
encoded 2196 frames, 25.60 fps, 2848.26 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 2196 frames, 24.66 fps, 2848.26 kb/s
encoded 2196 frames, 25.46 fps, 2848.26 kb/s
encoded 2196 frames, 25.50 fps, 2848.26 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 2196 frames, 25.63 fps, 2848.26 kb/s
encoded 2196 frames, 25.17 fps, 2848.26 kb/s
encoded 2196 frames, 25.58 fps, 2848.26 kb/s

[LoRd_MuldeR]

Updated x264 binaries to r1128 (builds taken from x264.nl).

[Rodger]

Here is the new Result.
Source: D:\Temp\MTV - h264_576p.avs
Params: --crf 22

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 6820 frames, 101.04 fps, 1831.60 kb/s
encoded 6820 frames, 100.87 fps, 1831.60 kb/s
encoded 6820 frames, 100.73 fps, 1831.60 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 6820 frames, 102.31 fps, 1831.59 kb/s
encoded 6820 frames, 101.27 fps, 1831.59 kb/s
encoded 6820 frames, 101.46 fps, 1831.59 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 6820 frames, 104.79 fps, 1831.59 kb/s
encoded 6820 frames, 104.92 fps, 1831.59 kb/s
encoded 6820 frames, 104.79 fps, 1831.59 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 6820 frames, 104.49 fps, 1831.59 kb/s
encoded 6820 frames, 104.76 fps, 1831.59 kb/s
encoded 6820 frames, 104.12 fps, 1831.59 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 6820 frames, 104.14 fps, 1831.59 kb/s
encoded 6820 frames, 104.31 fps, 1831.59 kb/s
encoded 6820 frames, 103.21 fps, 1831.59 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 6820 frames, 102.05 fps, 1831.59 kb/s
encoded 6820 frames, 101.81 fps, 1831.59 kb/s
encoded 6820 frames, 101.84 fps, 1831.59 kb/s

[Amefurashi]

Some heavy testing on a 720p enc from Blu-Ray source:

Source: C:\LITTLE_MISS_SUNSHINE\little_miss_sunshine.avs
Params: --crf 18 --level 4.1 --keyint 240 --min-keyint 24 --ref 4 --mixed-refs
--bframes 5 --b-adapt 2 --b-pyramid --weightb --direct auto --deblock -2:-1
--subme 9 --trellis 2 --psy-rd 1.0:0 --partitions all --8x8dct --vbv-bufsize 40000
--vbv-maxrate 40000 --me umh --merange 24 --thread-input --aq-strength 1.0
--no-dct-decimate --no-psnr --no-ssim

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 501 frames, 1.43 fps, 10160.85 kb/s
encoded 501 frames, 1.43 fps, 10160.85 kb/s
encoded 501 frames, 1.44 fps, 10160.85 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 501 frames, 1.74 fps, 10160.85 kb/s
encoded 501 frames, 1.74 fps, 10160.85 kb/s
encoded 501 frames, 1.70 fps, 10160.85 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 501 frames, 1.65 fps, 10160.85 kb/s
encoded 501 frames, 1.69 fps, 10160.85 kb/s
encoded 501 frames, 1.58 fps, 10160.85 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 501 frames, 1.66 fps, 10160.85 kb/s
encoded 501 frames, 1.64 fps, 10160.85 kb/s
encoded 501 frames, 1.62 fps, 10160.85 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 501 frames, 1.72 fps, 10160.85 kb/s
encoded 501 frames, 1.74 fps, 10160.85 kb/s
encoded 501 frames, 1.59 fps, 10160.85 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 501 frames, 1.65 fps, 10160.85 kb/s
encoded 501 frames, 1.68 fps, 10160.85 kb/s
encoded 501 frames, 1.61 fps, 10160.85 kb/s

[LoRd_MuldeR]

Updated x264 binaries to r1137 (Skystrife builds).

[wiak]

this gui is epic simple one little thing am missing is some defoult high profiles and a bitrate calculator and it will be the best GUI for me =)
:stupid:

[HaraldBluetooth]

My PC spec.:

Q8200@2,33GHz
4 GB ram
Windows 7 Ultimate 64-bit

AviSynth script:
DirectShowSource("V:\Temp\Temp2\_Apocalypto.2006.720p.BluRay.x264-ESiR\Apocalypto.2006.720p.BluRay.x264-ESiR.mkv", fps=23.976, audio=false)
SelectRangeEvery
HQDN3D(1.9)
VagueDenoiser(threshold=1.7, method=3, nsteps=6, chromaT=0)
FFT3DGPU(bt=-1, sharpen=0.7)

Commandline:
Params: --crf 24.0 --ref 4 --mixed-refs --bframes 3 --b-adapt 2 --b-pyramid --weightb --deblock -3:-3 --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8

LoRd_MuldeR - I just wan't to give you big thanks for this marvelous GUI.

With your default settings I got a FPS at 7,60. With two encodes at the same time I got a total FPS at 9,94.

I did a normal encode with MeGui in my 32 bit Windows XP SP3 with a FPS 6,92.

So compared to this it's an increase at 9,83% with one encode and with two encodes at the same time an increase at 43,64%.:D

I don't think I could do two encodes at the same time in 32 bit XP with these filters and x264 settings.

[XadoX]

Intel Xeon E5420

Temp.avs:
DGDecode_mpeg2source("D:\Temp.d2v", info=3)
ColorMatrix(hints=true, threads=0)
crop( 10, 76, -6, -68)
Trim(13767, 16062)

Source: D:\Temp.avs
Params: --crf 22

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 2296 frames, 78.79 fps, 1127.03 kb/s
encoded 2296 frames, 79.27 fps, 1127.03 kb/s
encoded 2296 frames, 79.60 fps, 1127.03 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 2296 frames, 78.20 fps, 1126.99 kb/s
encoded 2296 frames, 77.46 fps, 1126.99 kb/s
encoded 2296 frames, 78.58 fps, 1126.99 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 2296 frames, 81.86 fps, 1126.99 kb/s
encoded 2296 frames, 82.09 fps, 1126.99 kb/s
encoded 2296 frames, 81.63 fps, 1126.99 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 2296 frames, 80.91 fps, 1126.99 kb/s
encoded 2296 frames, 84.73 fps, 1126.99 kb/s
encoded 2296 frames, 83.44 fps, 1126.99 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 2296 frames, 83.34 fps, 1126.99 kb/s
encoded 2296 frames, 81.77 fps, 1126.99 kb/s
encoded 2296 frames, 83.81 fps, 1126.99 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 2296 frames, 81.95 fps, 1126.99 kb/s
encoded 2296 frames, 81.63 fps, 1126.99 kb/s
encoded 2296 frames, 80.56 fps, 1126.99 kb/s

[wiak]

can someone with some better skills than me list the "encoding options" that is the closest to the MeGUI's DXVA-HD-HQ Profile and the DXVA-SD-HQ Profile? for this GUI please

btw you can also find latest x64 builds by techouse @ http://nwgat.net/x264/

[saint-francis]

@Lord
Any chance of batch encoding capabilities being incorporated into this fantastic tool?

[LoRd_MuldeR]

can someone with some better skills than me list the "encoding options" that is the closest to the MeGUI's DXVA-HD-HQ Profile and the DXVA-SD-HQ Profile? for this GUI please

MeGUI does show you the complete commandline for each profile. So you can simply copy&paste ;)

Anyway, if you want to use MeGUI profiles, why not simply use MeGUI?

Any chance of batch encoding capabilities being incorporated into this fantastic tool?

Not planned. But I have included the sources, so feel free to hack that in :D

[saint-francis]

Not planned. But I have included the sources, so feel free to hack that in :D

Sure thing! As soon as I retire I'll go back to school and learn how. :)
I'll just figure out how to do it the old fashioned way.

Thanks for the useful tool. I think it's helping to bring 64 bit awareness to the community.

[Buggle]

@Lord_Mulder
I was wondering whether you were planning on continuing support for this utility, or if this is only a proof-of-concept?
The reason I ask this is because to my knowledge, this tool is at this moment about the only option that has a high enough usability for moderately experienced users to allow x64 encodes.
The options we have are, as I understand it:
your pipebuf tool, avisynth64+MeGUI64 (not usable), avs2yuv
I would personally opt for the integration of piping (which one would you recommend; pipebuf or avs2yuv?) into MeGUI that would then also be able to run in x64 mode, but I guess your tool is as good as it gets till that moment arrives...

[LoRd_MuldeR]

@Lord_Mulder
I was wondering whether you were planning on continuing support for this utility, or if this is only a proof-of-concept?
The reason I ask this is because to my knowledge, this tool is at this moment about the only option that has a high enough usability for moderately experienced users to allow x64 encodes.
The options we have are, as I understand it:
your pipebuf tool, avisynth64+MeGUI64 (not usable), avs2yuv
I would personally opt for the integration of piping (which one would you recommend; pipebuf or avs2yuv?) into MeGUI that would then also be able to run in x64 mode, but I guess your tool is as good as it gets till that moment arrives...

You got it wrong. The "avs2yuv" tool reads an Avisynth script and writes the raw video data to STDOUT. This way the x264 process can read the data from STDIN. And this can happen from 32-Bit Avisynth/avs2yuv to 64-Bit x264, because they're running as two separate processes (just communicating through a pipe). Mixing 32-Bit and 64-Bit code within the same process is not possible! That's why we have to use the pipe method. The sole purpose of my "pipebuf" tool is to establish the pipe between avs2yuv and x264. The same could be done with cmd.exe, but cmd.exe doesn't allow to specify the pipe buffer size.

BTW: Yes, I will continue to give support for that tool. But I'm definitely not going to implement any new features. I don't want to maintain yet another x264 GUI...

[LoRd_MuldeR]

Updated x264 binaries to r1165 (JEEB builds).

[komisar]

LoRd_MuldeR, can you update benchmark to support lattest version of x264? (--progress option trouble)

[St Devious]

nice tool.

Would it be possible to make the x264 version user replaceable ? like MeGUI

[komisar]

St Devious, replace x264.exe or x264_x64.exe with your version.

[St Devious]

St Devious, replace x264.exe or x264_x64.exe with your version.

oh alright. I thought the x264 exe was included in the program exe like lame encoder i his LameXp software.

[JnZ]

Nice tool, I noticed from 30fps (x264 32bit) to 33fps (yourtool) speedup, can You update to the latest x264 build commandline (no --progress param), or put some option screen to configure hidden parameters?

Anyway :thanks: for nice GUI

[LoRd_MuldeR]

LoRd_MuldeR, can you update benchmark to support lattest version of x264? (--progress option trouble)

Done :cool:

The package has been updated to x264 r1181 (JEEB's builds) and the GUI reflects the new Preset/Tuning/Profile system now.
Also the GUI will work on 32-Bit OS now, but all 64-Bit features will be disabled for obvious reasons.
Last but not least there is a first attempt to implement automated 2-Pass. After some initial testing it seems to work as expected...

[EDIT]

A minor update is available now. Download link has been updated.

[LoRd_MuldeR]

Yet another small update. Fixed a few minor glitches and added a "help screen" for x264 parameters. Download link updated.

[St Devious]

any chance of adding horizontal scrolling in the window ?

and adding an option of using 32-bit or 64-bit x264 ?

and report the time taken to encode the first pass and second pass ?

[LoRd_MuldeR]

any chance of adding horizontal scrolling in the window ?

Nope.

and adding an option of using 32-bit or 64-bit x264 ?

Why would you want to use (the slower) 32-Bit x264 and a 64-Bit system, if you have a chance to use the 64-Bit one?

and report the time taken to encode the first pass and second pass ?

Well, a report could be displayed after 2-Pass, just like after the Benchmark...

[St Devious]

Nope.

Why would that be ?

Why would you want to use (the slower) 32-Bit x264 and a 64-Bit system, if you have a chance to use the 64-Bit one?


just for kicks to benchmark 32-bit against 64-bit

Well, a report could be displayed after 2-Pass, just like after the Benchmark...

that would be great. anyways, it displays


encoded 3179 frames, 37.69 fps, 5764.39 kb/s

at the end. So if i were to calculate time taken manually, frames/fps ?


also getting this

http://i32.tinypic.com/2zf2995.jpg

[LoRd_MuldeR]

Why would that be ?

The "List Box" control doesn't work like that and I don't intend to replace it.

(BTW: You can see the entire line simply by holding the mouse course above the line for a few seconds)

just for kicks to benchmark 32-bit against 64-bit

What do you think the "Benchmark" button does? :p

also getting this

http://i32.tinypic.com/2zf2995.jpg

...because "--8x8dct" doesn't exist any longer. Just as the message indicates ;)

8x8dct is enabled by default now! If you want to disable 8x8dct, then you must pass "--no-8x8dct".
Otherwise you don't need to do anything...

(BTW: Please click "Show Help Screen" for detailed information about x264 commandline parameters)

[LoRd_MuldeR]

Well, a report could be displayed after 2-Pass, just like after the Benchmark...
that would be great.

Done. Download link updated.

[St Devious]

...because "--8x8dct" doesn't exist any longer. Just as the message indicates ;)

8x8dct is enabled by default now! If you want to disable 8x8dct, then you must pass "--no-8x8dct".
Otherwise you don't need to do anything...

(BTW: Please click "Show Help Screen" for detailed information about x264 commandline parameters)

actually in my case, i was encoding with ultrafast preset which has --no-8x8dct. I wanted to enable that and it gave me this error message


also is it possible to type in the input and output file box instead of having to browse around the PC ?


Done. Download link updated.

was that only done for 2 pass ? i don't see it for ABR mode

http://i32.tinypic.com/et76vr.jpg

[LoRd_MuldeR]

actually in my case, i was encoding with ultrafast preset which has --no-8x8dct. I wanted to enable that and it gave me this error message

If you don't want ultra fast settings, don't use the "ultrafast" profile :p

was that only done for 2 pass ? i don't see it for ABR mode

We don't need a report for ABR, because ABR has only one single encoding pass and the info is in the encoding window.

(In contrast to 2-Pass the encoding window won't close automatically after an ABR encode)

[St Devious]

If you don't want ultra fast settings, don't use the "ultrafast" profile :p


I wanted to use that specific option with ultrafast presets.

Could you please leave the prompt in there, but let it be the user's choice to put the parameter in there after that or remove it ?

also, the x264 report in the end displays


encoded 3179 frames, 37.69 fps, 5764.39 kb/s


at the end. So if i were to calculate time taken manually, frames/fps ?

[LoRd_MuldeR]

I wanted to use that specific option with ultrafast presets.

Then instead of using "--preset ultrafast" you will have to specify every option manually.

You can specify all the option that the "ultrafast" preset includes, but simply leave out the "--no-8x8dct" parameter ;)

Could you please leave the prompt in there, but let it be the user's choice to put the parameter in there after that or remove it ?

I certainly won't allow the user to specify a parameter that doesn't exist in x264 r1177 (http://git.videolan.org/gitweb.cgi?p=x264.git;a=blobdiff;f=x264.c;h=e79f9acc2b3486adbc8b958b1df4f6044616215a;hp=9aafc357930dc3821cc45eec0480f2f6324e15ed;hb=af2a4ecd7bcefc97c8aa83913c9a2980206f9cd0;hpb=72534d466a6bd99b9cbf32c74e667bea608c6dee) and later :p

If I did, the results would be x264 aborting with "unknown option" error...

[St Devious]

Then instead of using "--preset ultrafast" you will have to specify every option manually.

You can specify all the option that the "ultrafast" preset includes, but simply leave out the "--no-8x8dct" parameter ;)


Alright, I'll do that. thanks

I certainly won't allow the user to specify a parameter that doesn't exist in x264 r1177 (http://git.videolan.org/gitweb.cgi?p=x264.git;a=blobdiff;f=x264.c;h=e79f9acc2b3486adbc8b958b1df4f6044616215a;hp=9aafc357930dc3821cc45eec0480f2f6324e15ed;hb=af2a4ecd7bcefc97c8aa83913c9a2980206f9cd0;hpb=72534d466a6bd99b9cbf32c74e667bea608c6dee) and later :p

If I did, the results would be x264 aborting with "unknown option" error...

isn't --8x8dct a default parameter in x264 now , http://forum.doom9.org/showthread.php?t=148148 ?

Also please answer the "calculate time taken manually, frames/fps ?"

[LoRd_MuldeR]

isn't --8x8dct a default parameter in x264 now , http://forum.doom9.org/showthread.php?t=148148 ?

That's exactly the reason why "--8x8dct" doesn't exist as an option anymore. There is no need for an option that just sets the default value ;)

You can only disable what is enabled by default. And that's what "--no-8x8dct" is good for.

In other words: Unless you explicitly set the "--no-8x8dct" parameter (or a preset that includes it), 8x8 vs. 4x4 Transform Adaptivity will be enabled.

Also please answer the "calculate time taken manually, frames/fps ?"

<frame count> / <average fps> = <encoding time>

[St Devious]

Would it be possible to add a "No preset" option in the presets drop down box, so that the program uses x264 default options.

[LoRd_MuldeR]

Would it be possible to add a "No preset" option in the presets drop down box, so that the program uses x264 default options.

It's already on the list :D

Please see:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=blobdiff;f=x264.c;h=e79f9acc2b3486adbc8b958b1df4f6044616215a;hp=9aafc357930dc3821cc45eec0480f2f6324e15ed;hb=af2a4ecd7bcefc97c8aa83913c9a2980206f9cd0;hpb=72534d466a6bd99b9cbf32c74e667bea608c6dee

[...]

else if( !strcasecmp( optarg, "medium" ) )
{
/* Default is medium */
}

[...]

[St Devious]

It's already on the list :D

Please see:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=blobdiff;f=x264.c;h=e79f9acc2b3486adbc8b958b1df4f6044616215a;hp=9aafc357930dc3821cc45eec0480f2f6324e15ed;hb=af2a4ecd7bcefc97c8aa83913c9a2980206f9cd0;hpb=72534d466a6bd99b9cbf32c74e667bea608c6dee

[...]

else if( !strcasecmp( optarg, "medium" ) )
{
/* Default is medium */
}

[...]

don't know what that is , looks like a c program.

What does "Default is medium" mean ?

[LoRd_MuldeR]

don't know what that is , looks like a c program.

What does "Default is medium" mean ?

It means that using "--preset medium" is like not using the "--preset" switch at all, because the "medium" preset is equal to the x264 defaults (and consequently will do nothing).

And if you take a look at the x264 commandline, you will notice that my x264 launcher tool won't even involve the "--preset" switch, if "Medium" is selected in the "Preset" combo box ;)

(BTW: In a C or C++ program /* and */ surround comments (http://en.wikipedia.org/wiki/C_syntax#Comments), so the code I quoted really doesn't do anything)

[St Devious]

It means that using "--preset medium" is like not using the "--preset" switch at all, because the "medium" preset is equal to the x264 defaults (and consequently will do nothing).

And if you take a look at the x264 commandline, you will notice that my x264 launcher tool won't even involve the "--preset" switch, if "Medium" is selected in the "Preset" combo box ;)

(BTW: In a C or C++ program /* and */ surround comments (http://en.wikipedia.org/wiki/C_syntax#Comments), so the code I quoted really doesn't do anything)

alrite that clears things up. thanks.

[LoRd_MuldeR]

Updated x264 to r1184 (JEEB's builds). Download link updated.

[LoRd_MuldeR]

Updated x264 to r1184 (JEEB's builds). Download link updated.

Previous JEEB builds had some strange error which caused x264 to crash with "short" commandline parameters (e.g. "-h").

Not sure whether there were other problems as well. Anyway, JEEB has fixed his built environment and provided fresh r1184 builds.

Download link in first post updated. I highly recommend to updated again, if you downloaded the update earlier this day!

[St Devious]

Previous JEEB builds had some strange error which caused x264 to crash with "short" commandline parameters.

Not sure whether there were other problems as well. Anyway, JEEB has fixed his built environment and provided fresh r1184 builds.

Download link in first post updated. I highly recommend to updated again, if you downloaded the update earlier this day!

thanks

[twist3d]

Core 2 Duo E7200 overclocked to 3.02GHz, 2GB DDR2, P43 Chipset, Windows 7 Ultimate RC1 X64

500 frame clip from "A Love Song for Bobby Long" PAL R2

avisynth:
DGDecode_mpeg2source("C:\work\bobbylong.d2v", info=3)
ColorMatrix(hints=true, threads=0)
crop( 2, 0, 0, 0)
LanczosResize(720,576)
trim(15500,16000)

Source: C:\work\bobbylong.avs
Preset: Fast
Tuning: None
Profile: High
Params:

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 501 frames, 51.95 fps, 936.46 kb/s
encoded 501 frames, 51.88 fps, 936.46 kb/s
encoded 501 frames, 51.93 fps, 936.46 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 501 frames, 52.54 fps, 936.46 kb/s
encoded 501 frames, 51.89 fps, 936.46 kb/s
encoded 501 frames, 52.64 fps, 936.46 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 501 frames, 52.80 fps, 936.46 kb/s
encoded 501 frames, 53.04 fps, 936.46 kb/s
encoded 501 frames, 52.98 fps, 936.46 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 501 frames, 52.85 fps, 936.46 kb/s
encoded 501 frames, 51.61 fps, 936.46 kb/s
encoded 501 frames, 52.94 fps, 936.46 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 501 frames, 51.70 fps, 936.46 kb/s
encoded 501 frames, 46.54 fps, 936.46 kb/s <- window auto-lost focus here
encoded 501 frames, 51.18 fps, 936.46 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 501 frames, 47.61 fps, 936.46 kb/s <- and here
encoded 501 frames, 51.55 fps, 936.46 kb/s
encoded 501 frames, 51.09 fps, 936.46 kb/s



also ran the same test with icc builds from http://imk.cx/pc/x264/, seems to lower fps on 32-bit but raise it with 64-bit... :

Source: C:\work\bobbylong.avs
Preset: Fast
Tuning: None
Profile: High
Params:

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 501 frames, 48.28 fps, 936.46 kb/s
encoded 501 frames, 47.73 fps, 936.46 kb/s
encoded 501 frames, 48.42 fps, 936.46 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 501 frames, 52.88 fps, 936.46 kb/s
encoded 501 frames, 53.65 fps, 936.46 kb/s
encoded 501 frames, 53.75 fps, 936.46 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 501 frames, 54.02 fps, 936.46 kb/s
encoded 501 frames, 54.34 fps, 936.46 kb/s
encoded 501 frames, 54.41 fps, 936.46 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 501 frames, 54.24 fps, 936.46 kb/s
encoded 501 frames, 54.31 fps, 936.46 kb/s
encoded 501 frames, 54.35 fps, 936.46 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 501 frames, 52.69 fps, 936.46 kb/s
encoded 501 frames, 53.74 fps, 936.46 kb/s
encoded 501 frames, 53.81 fps, 936.46 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 501 frames, 52.66 fps, 936.46 kb/s
encoded 501 frames, 52.64 fps, 936.46 kb/s
encoded 501 frames, 52.64 fps, 936.46 kb/s

[LoRd_MuldeR]

Updated x264 to r1189 (JEEB's builds). Also allow the Quantizer for CRF mode to be a Float. Download link updated.

[alwa]

Could you built in a benchmark case where the buffer size is frame oriented (e.g. buffer size = Framewidth x Frameheigth x 1.5 Bytes). It migth be interesting to see whether ther is a dependency.

Thanks anyway.

[LoRd_MuldeR]

Could you built in a benchmark case where the buffer size is frame oriented (e.g. buffer size = Framewidth x Frameheigth x 1.5 Bytes). It migth be interesting to see whether ther is a dependency.

I tried this once, but it didn't improve the results at all. So I dropped that idea.

[EDIT]

Updated x264 to r1190 (JEEB's builds). Download link in first post updated.

[LoRd_MuldeR]

Updated x264 to r1193 (JEEB's builds). Download link in first post updated.

[twist3d]

some fast tests again, now with akira r2 remastered special edition, jeeb's 1193 and imk.cx icc 1193.

- quick conclusion would be that icc builds are faster on x64
- 1mb/2mb/4mb buffers are the fastest


DGDecode_mpeg2source("C:\work\akira.d2v", info=3)
ColorMatrix(hints=true, threads=0)
crop( 2, 0, 0, 0)
BilinearResize(720,576)
trim(29000,29500)


jeeb's 1193:

Source: C:\work\test.avs
Preset: Veryfast
Tuning: Animation
Profile: High
Params:

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 501 frames, 80.81 fps, 1459.69 kb/s
encoded 501 frames, 80.82 fps, 1459.69 kb/s
encoded 501 frames, 79.33 fps, 1459.69 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 501 frames, 74.55 fps, 1459.69 kb/s
encoded 501 frames, 73.29 fps, 1459.69 kb/s
encoded 501 frames, 75.20 fps, 1459.69 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 501 frames, 79.32 fps, 1459.69 kb/s
encoded 501 frames, 78.93 fps, 1459.69 kb/s
encoded 501 frames, 78.72 fps, 1459.69 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 501 frames, 78.89 fps, 1459.69 kb/s
encoded 501 frames, 78.58 fps, 1459.69 kb/s
encoded 501 frames, 78.59 fps, 1459.69 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 501 frames, 76.33 fps, 1459.69 kb/s
encoded 501 frames, 78.84 fps, 1459.69 kb/s
encoded 501 frames, 78.10 fps, 1459.69 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 501 frames, 76.09 fps, 1459.69 kb/s
encoded 501 frames, 77.47 fps, 1459.69 kb/s
encoded 501 frames, 76.61 fps, 1459.69 kb/s


imk.cx icc:


Source: C:\work\test.avs
Preset: Veryfast
Tuning: Animation
Profile: High
Params:

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 501 frames, 66.30 fps, 1459.69 kb/s
encoded 501 frames, 67.84 fps, 1459.69 kb/s
encoded 501 frames, 67.15 fps, 1459.69 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 501 frames, 79.41 fps, 1459.69 kb/s
encoded 501 frames, 79.35 fps, 1459.69 kb/s
encoded 501 frames, 79.78 fps, 1459.69 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 501 frames, 80.90 fps, 1459.69 kb/s
encoded 501 frames, 81.16 fps, 1459.69 kb/s
encoded 501 frames, 80.95 fps, 1459.69 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 501 frames, 79.56 fps, 1459.69 kb/s
encoded 501 frames, 81.33 fps, 1459.69 kb/s
encoded 501 frames, 80.59 fps, 1459.69 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 501 frames, 80.51 fps, 1459.69 kb/s
encoded 501 frames, 80.42 fps, 1459.69 kb/s
encoded 501 frames, 80.68 fps, 1459.69 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 501 frames, 78.20 fps, 1459.69 kb/s
encoded 501 frames, 78.91 fps, 1459.69 kb/s
encoded 501 frames, 77.73 fps, 1459.69 kb/s

[LoRd_MuldeR]

Updated x264 to r1195 (Techouse builds). I recommend updating, QPRD was borked in previous builds. Download link in first post updated.

[juGGaKNot]

borked

What does that mean, you use it all the time ?

[LoRd_MuldeR]

What does that mean, you use it all the time ?

It means that if (and only if) you used QPRD (aka SubME=10), then your output wasn't as the developers had intended, because there was a bug in QPRD.

But by chance the GCC builds still gave "reasonable" output, while ICC builds would simply have crashed. The problem is fixed now ;)

http://forum.doom9.org/showthread.php?p=1309515#post1309515

[juGGaKNot]

No, i mean what does the word mean, i know about the bug :)

[LoRd_MuldeR]

No, i mean what does the word mean, i know about the bug :)

http://www.urbandictionary.com/define.php?term=borked ;)

[LoRd_MuldeR]

Updated x264 to r1203 (x264.nl builds). Also added support for the new presets. Download link in first post updated.

[LoRd_MuldeR]

Updated x264 to r1206 (Komisar's builds). Download link in first post updated.

[GZZ]

avs2yuv dosnt work with avs script that uses DGDecodeNV.dll (Nvidia version og DGIndex), it just hang without continue.

[LoRd_MuldeR]

avs2yuv dosnt work with avs script that uses DGDecodeNV.dll (Nvidia version og DGIndex), it just hang without continue.

This is the wrong place to report. I don't even have a license to test DGDecodeNV ;)

[LoRd_MuldeR]

Updated x264 to r1210 (JEEB's builds). Download link in first post updated.

[LoRd_MuldeR]

Updated x264 to r1214 (JEEB's builds). This fixes a bug in QPRD (SubME 10) and greatly improves 1-Pass VBV. Update to x264 r1214+ is highly recommended.

[nakTT]

Updated x264 to r1214 (JEEB's builds). This fixes a bug in QPRD (SubME 10) and greatly improves 1-Pass VBV. Update to x264 r1214+ is highly recommended.
Hi Lord,

I have one question regarding your software. Is the software only encode video without audio or it also encode audio for the movie (like Megui)?

[Wishbringer]

Is the software only encode video without audio or it also encode audio for the movie (like Megui)?

It's a launcher for x264 64bit version for AviSynth 32bit.
x264 is an AVC video encoder...

It's not an all-in-one-tool like MeGui, RipBot etc.

[nakTT]

It's a launcher for x264 64bit version for AviSynth 32bit.
x264 is an AVC video encoder...

It's not an all-in-one-tool like MeGui, RipBot etc.
Sorry if my question wasn't clear. I know x264 is an AVC VIDEO encoder. I'm just asking for a confirmation whether or not this Application made by Loard can encode a complete movies or or just a video part of it.

Since you have answered the question, I thank you very much.

:thanks:

[LoRd_MuldeR]

It's not an all-in-one-tool like MeGui, RipBot etc.

Correct. It's a very simple front-end to x264.exe, nothing else. And x264.exe doesn't process audio at all ;)

I recommend MKVToolnix or YAMB to mux in the audio after encoding, when needed...

[nakTT]

Correct. It's a very simple front-end to x264.exe, nothing else. And x264.exe doesn't process audio at all ;)

I recommend MKVToolnix or YAMB to mux in the audio after encoding, when needed...
Any suggestion for simple tools to make avs for the Launcher?

:thanks:

[LoRd_MuldeR]

Any suggestion for simple tools to make avs for the Launcher?

:thanks:

Notepad++ :p

Or maybe this one:
http://avisynth.org/qwerpoi/index.html

[LoRd_MuldeR]

Updated x264 to r1217 (JEEB's builds). Download link in first post updated.

[nakTT]

Notepad++ :p

Or maybe this one:
http://avisynth.org/qwerpoi/index.html
Thanks. But until now I still using MeGUI tools "AVS Script Creator" in the tools menu. Any other simple to use AVS creator like in MeGUI that you want to suggest.

:thanks:

[Teddl]

Hi there!
Benchmarks are fun! :)

AMDPhenom(tm 9950 Quad-Core Processor 2.60GHz; Windows Vista(tm) Ultimate 64bit SP2,
Source: DivX.Avi@17000kbits (Ingame Video); x264 JEEB's builds from your .7z archive


Source: H:\17000B&B.avs
Preset: Faster
Tuning: None
Profile: High
Params: (din't show but --crf 23.0 --output H:\17000B&B2.mp4)

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 10104 frames, 30.87 fps, 4849.01 kb/s
encoded 10104 frames, 31.22 fps, 4848.35 kb/s
encoded 10104 frames, 31.35 fps, 4847.00 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 10104 frames, 31.96 fps, 4850.68 kb/s
encoded 10104 frames, 31.95 fps, 4850.15 kb/s
encoded 10104 frames, 31.88 fps, 4847.02 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 10104 frames, 32.17 fps, 4843.76 kb/s
encoded 10104 frames, 32.13 fps, 4848.87 kb/s
encoded 10104 frames, 32.22 fps, 4851.95 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 10104 frames, 32.74 fps, 4849.16 kb/s
encoded 10104 frames, 32.77 fps, 4849.17 kb/s
encoded 10104 frames, 32.74 fps, 4844.90 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 10104 frames, 32.97 fps, 4847.00 kb/s
encoded 10104 frames, 32.93 fps, 4851.58 kb/s
encoded 10104 frames, 33.01 fps, 4846.86 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 10104 frames, 32.86 fps, 4847.44 kb/s
encoded 10104 frames, 32.95 fps, 4849.03 kb/s
encoded 10104 frames, 32.92 fps, 4849.81 kb/s

Resolution: 1280 x 720
Frame No. : 10104
Frame Rate: 25/1

x264 0.72.1217M 5e9ae4c
built on Aug 20 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
Revision: 1217

6 or 7% gain for 64-Bit 4MB to 32-Bit 0MB? Math is long time ago for me. :o

Source: YV12 640x360
Source: H:\17000B&B.avs
Preset: Faster
Tuning: None
Profile: High
Params:

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 10104 frames, 128.38 fps, 1441.13 kb/s
encoded 10104 frames, 117.09 fps, 1441.13 kb/s
encoded 10104 frames, 117.66 fps, 1441.13 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 10104 frames, 123.71 fps, 1441.13 kb/s
encoded 10104 frames, 125.47 fps, 1441.13 kb/s
encoded 10104 frames, 123.43 fps, 1441.13 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 10104 frames, 136.70 fps, 1441.13 kb/s
encoded 10104 frames, 134.54 fps, 1441.13 kb/s
encoded 10104 frames, 136.24 fps, 1441.13 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 10104 frames, 134.89 fps, 1441.13 kb/s
encoded 10104 frames, 142.73 fps, 1441.13 kb/s
encoded 10104 frames, 134.41 fps, 1441.13 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 10104 frames, 137.39 fps, 1441.13 kb/s
encoded 10104 frames, 137.96 fps, 1441.13 kb/s
encoded 10104 frames, 135.49 fps, 1441.13 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 10104 frames, 139.85 fps, 1441.13 kb/s
encoded 10104 frames, 139.96 fps, 1441.13 kb/s
encoded 10104 frames, 139.14 fps, 1441.13 kb/s



Don't know if you can use this:
DivX.Avi@17000kbits with JEEB's builds from your yesterday.. no big changes:

Source: H:\17000B&B.avs
Preset: Faster
Tuning: None
Profile: High
Params: (din't show.. but: --crf 23.0 --output H:\17000B&B2.mp4)

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 10104 frames, 31.01 fps, 4820.78 kb/s
encoded 10104 frames, 30.86 fps, 4820.53 kb/s
encoded 10104 frames, 31.17 fps, 4819.30 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 10104 frames, 31.68 fps, 4819.03 kb/s
encoded 10104 frames, 31.82 fps, 4817.60 kb/s
encoded 10104 frames, 31.79 fps, 4818.23 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 10104 frames, 32.07 fps, 4818.78 kb/s
encoded 10104 frames, 31.77 fps, 4818.48 kb/s
encoded 10104 frames, 32.19 fps, 4818.60 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 10104 frames, 32.69 fps, 4818.92 kb/s
encoded 10104 frames, 32.39 fps, 4819.50 kb/s
encoded 10104 frames, 32.92 fps, 4818.74 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 10104 frames, 33.03 fps, 4817.76 kb/s
encoded 10104 frames, 32.77 fps, 4820.07 kb/s
encoded 10104 frames, 33.23 fps, 4820.41 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 10104 frames, 33.20 fps, 4818.04 kb/s
encoded 10104 frames, 33.01 fps, 4818.66 kb/s
encoded 10104 frames, 32.49 fps, 4817.34 kb/s

x264 0.72.1235M 448b138
built on Aug 27 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
Revision: 1235


Want your GUI with Automatic 3pass :p

[nakTT]

Updated x264 to r1217 (JEEB's builds). Download link in first post updated.
Can it work with x264 from:

http://x264.nl/ ?

[LoRd_MuldeR]

Updated x264 to r1247 (JEEB's builds). Download link in first post updated!

Can it work with x264 from:

http://x264.nl/ ?

Sure, why not? :confused:

(Just be sure to save the 32-Bit build as "x264.exe" and the 64-Bit build as "x264_x64.exe" in the same folder as the "launcher.exe")

Want your GUI with Automatic 3pass :p

3-Pass is a placebo :sly:

[LoRd_MuldeR]

Updated x264 to r1251 (JEEB's builds (http://forum.doom9.org/showpost.php?p=1322616&postcount=2273)). Download link in first post updated!

I also fixed job control on Vista/Win7. This should make "abort" work on those OS. Before only 'pipebuf.exe' was terminated, but not 'x264.exe' and 'avs2yuv.exe' ;)

[nakTT]

Updated x264 to r1251 (JEEB's builds (http://forum.doom9.org/showpost.php?p=1322616&postcount=2273)). Download link in first post updated!

I also fixed job control on Vista/Win7. This should make "abort" work on those OS. Before only 'pipebuf.exe' was terminated, but not 'x264.exe' and 'avs2yuv.exe' ;)
When I mux my output video from the launcher with aac audio using Megui, the audio seems to be out of sync. I don't have this issue when I do the whole encoding job with Megui. Any idea? Please advice.

:thanks:

[LoRd_MuldeR]

When I mux my output video from the launcher with aac audio using Megui, the audio seems to be out of sync. I don't have this issue when I do the whole encoding job with Megui. Any idea? Please advice.

:thanks:

This is a GUI for x264.exe only! And x264 does not process audio at all.

The one and only thing that could effect the audio sync would be the framerate. My GUI will obtain the framerate from Avisynth and forward it to x264.

And that seems to work properly for me...

[nakTT]

This is a GUI for x264.exe only! And x264 does not process audio at all.

The one and only thing that could effect audio sync would be the framerate. But my GUI will obtain the framerate from Avisynth and forward it to x264. Seems to work properly for me.
Thanks for the reply. I do know that the launcher do not process audio (you already let me know sometime ago, remember? ;)). That is why I mux the video and audio using MeGUI instead. Anyway, any chance the total frame for the output is a bit different (more?) from Avisynth?

:thanks:

[LoRd_MuldeR]

That is why I mux the video and audio using MeGUI instead.

Why not use MKVToolnix ???

Anyway, any chance the total frame for the output is a bit different (more?) from Avisynth?

This shouldn't happen. The encoded file should always have exactly the same number of frames as the input Avisynth script! And in my experience that is the case ;)

So unless there is any indication that something is wrong with the video part, your muxing problem doesn't belong to this thread...

[nakTT]

Why not use MKVToolnix ???
Thanks for the suggestion. Will try to use it.

:thanks:

[LoRd_MuldeR]

Updated x264 r1251 with latest JEEB builds (http://forum.doom9.org/showpost.php?p=1323501&postcount=2294), including the fixed HRD patch (http://forum.doom9.org/showpost.php?p=1323313&postcount=2291). Download link in first post updated!

[m3mbran3]

megui just uses its on front-end for MKVToolnix so it should be the same thing.

I must say that this program really is useful and use it for all my encodes now. The only issue I have is if I'm trying to batch encode because there is no queue like in megui, anyway to overcome this? be it either by command line or batch file.

[LoRd_MuldeR]

The only issue I have is if I'm trying to batch encode because there is no queue like in megui, anyway to overcome this? be it either by command line or batch file.

Not implemented yet and not currently planned, because I'm busy with "real life" stuff. But feel free to hack that in, the sources are included...

[yesgrey]

LoRd_MuldeR,
In the dialog, group "Rate Control", I think it's missing a "t" in the word "Quanizer"...

[LoRd_MuldeR]

LoRd_MuldeR,
In the dialog, group "Rate Control", I think it's missing a "t" in the word "Quanizer"...

Well spotted. I will fix the typo for next release ;)

[yesgrey]

Well spotted.
It's easier when we're looking at it for the first time...:)
By the way, is it possible for you to add .264 file output?

Thanks.

[LoRd_MuldeR]

By the way, is it possible for you to add .264 file output?

Yes, that was easy and quick to do. Download link in first post updated!

[yesgrey]

Thanks!
I prefer to mux into mkv using eac3to.;)

[LoRd_MuldeR]

Updated x264 to r1259 (Komisar's builds). Download link in first post updated.

[click2]

Is sources.tar missing a few files? mulder_toolz.pas and unit_runprocess.pas for instance

[LoRd_MuldeR]

Is sources.tar missing a few files? mulder_toolz.pas and unit_runprocess.pas for instance

You are right. That is code shared with other project, so I forgot to include it :o

http://www.mediafire.com/file/cmkztvt4ynm/MuldeR_Toolz.2009-09-21.zip

[Widok]

[edit]

[LoRd_MuldeR]

Looks like some DirectShow problem, so this is not the right thread to complain. Anyway, it seems other people saw the same issue:
http://forum.doom9.org/showthread.php?p=1327378#post1327378

:search:


I can only recommend to try something that isn't DirectShowSource(), for example FFVideoSource() (http://code.google.com/p/ffmpegsource/) from FFmpegSource project ;)

[XadoX]

:thanks: for this nice GUI!

[LoRd_MuldeR]

Updated x264 to r1271 (Komisar's builds). Download link in first post updated!

[dstln]

Thanks for keeping this updated, looking forward to playing around with it on new OS.

Nice progress bar too :P

[ACrowley]

i like your gui, its exactly what i need..a simple x264 gui :)

Can you add 1 Pass Options please ? I want to use different lowered Settings in 1st Pass.

I know that new x264 should work autom "fast" in 1 Pass :
"For all encodes, regardless of preset or not, using --pass 1 will automatically trigger "turbo" settings....."

But for some reason i get only half FPS/Perfomance in 1 Pass when using your gui in 2 pass Mode ?
Its as slow as with --slow-firstpass but i havent set it to --slow-first pass.

[LoRd_MuldeR]

i like your Build :)

Can you add 1 Pass Options please ? I use different lowered Settings in 1st Pass.

What more than 1-Pass CRF and 1-Pass CQP do you need? For bitrate-based encodes you really should use 2-Pass mode!

[ACrowley]

What more than 1-Pass CRF and 1-Pass CQP do you need? For bitrate-based encodes you really should use 2-Pass mode!

im talking about 2pass VBR! And the 1st Pass is very slow

The gui sets x264 to use same Paramerets for both passes...so 1 pass is very slow

[LoRd_MuldeR]

im talking about 2pass VBR! And the 1st Pass is very slow

2-Pass is always VBR. It can be constrained via VBV though.

The gui sets x264 to use same Paramerets for both passes...so 1 pass is very slow

Wrong. Unless you explicitly pass "--slow-firstpass", which my GUI definitely does not do, x264 will automatically run the first pass with "turbo" settings.

So it's perfectly fine to pass the same settings for both passes and let x264 decide which settings can be lowered during the first one ;)

Of course it's up to you. You can always add the "--slow-firstpass" parameter to the "Advanced Options" edit box, if you really want a SLOW first pass.

[ACrowley]

2-Pass is always VBR. It can be constrained via VBV though.



Wrong. Unless you explicitly pass "--slow-firstpass", which my GUI definitely does not do, x264 will automatically run the first pass with "turbo" settings.

So it's perfectly fine to pass the same settings for both passes and let x264 decide which settings can be lowered during the first one ;)

Of course it's up to you. You can always add the "--slow-firstpass" parameter to the "Advanced Options" edit box, if you really want a SLOW first pass.
I understand. But why do i get only ~4,5fps in 1 pass with your Gui ?
With all other guis or via cmdline i get ~15fps with the same Settings/Source ?

Log : ( from 500 frames sample, but its the same Speed with the Full Source)

[First Pass]
encoded 501 frames, 4.79 fps, 14969.11 kb/s

[Second Pass]
encoded 501 frames, 2.40 fps, 15057.99 kb/s


-- [Detailed Report] --

Source: F:\test.avs
Output: F:\encode.mkv
Preset: Veryslow
Tuning: Grain
Profile: High
Params: --level 4.1 --deblock -3:-3 --ref 5 --vbv-bufsize 30000 --vbv-maxrate 40000 --no-dct-decimate --no-fast-pskip --partitions p8x8,b8x8,i4x4,i8x8 --me umh --subme 9

Analayzing source file:
F:\test.avs: 1920x816, 48000/2002 fps, 501 frames

Resolution: 1920 x 816
Frame No. : 501
Frame Rate: 24000/1001

x264 0.76.1271 496d79d
built by Komisar on Sep 25 2009, gcc: 4.4.1 (x86_64.core2.Komisar)
Revision: 1271

Commandline for x264:
"C:\AV Tools\x264 Launcher\pipebuf.exe" "C:\AV Tools\x264 Launcher\avs2yuv.exe" F:\test.avs -raw - : "C:\AV Tools\x264 Launcher\x264_x64.exe" --preset veryslow --tune grain --bitrate 14800 --pass 2 --stats F:\encode.mkv.x264-stats --level 4.1 --deblock -3:-3 --ref 5 --vbv-bufsize 30000 --vbv-maxrate 40000 --no-dct-decimate --no-fast-pskip --partitions p8x8,b8x8,i4x4,i8x8 --me umh --subme 9 --output F:\encode.mkv --frames 501 --fps 24000/1001 - 1920x816 : 4

x264 [info]: 1920x816 @ 23.98 fps
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 4.1
F:\test.avs: 1920x816, 48000/2002 fps, 501 frames

x264 [info]: frame I:9 Avg QP:16.48 size:141729
x264 [info]: frame P:106 Avg QP:16.03 size: 95216
x264 [info]: frame B:386 Avg QP:16.25 size: 72442
x264 [info]: consecutive B-frames: 1.4% 0.4% 20.7% 11.4% 5.1% 23.2% 32.7% 3.3% 1.8%
x264 [info]: mb I I16..4: 44.3% 50.4% 5.3%
x264 [info]: mb P I16..4: 10.8% 12.5% 2.8% P16..4: 47.8% 16.2% 9.8% 0.0% 0.0% skip: 0.1%
x264 [info]: mb B I16..4: 4.2% 3.1% 0.6% B16..8: 52.1% 2.1% 3.6% direct:23.6% skip:10.6% L0:42.3% L1:40.1% BI:17.6%
x264 [info]: 8x8 transform intra:44.1% inter:28.5%
x264 [info]: direct mvs spatial:79.0% temporal:21.0%
x264 [info]: coded y,uvDC,uvAC intra: 98.3% 80.3% 70.4% inter: 60.7% 49.3% 15.4%
x264 [info]: i16 v,h,dc,p: 1% 1% 61% 36%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 7% 6% 19% 10% 12% 11% 11% 11% 13%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 6% 5% 13% 11% 14% 12% 13% 12% 15%
x264 [info]: ref P L0: 47.2% 21.8% 15.2% 8.9% 7.0%
x264 [info]: ref B L0: 67.7% 16.9% 9.9% 5.4%
x264 [info]: kb/s:15057.99
encoded 501 frames, 2.40 fps, 15057.99 kb/s

[LoRd_MuldeR]

I understand. But why do i get only ~4,5fps in 1 pass with your Gui ?
With all other guis or via cmdline i get ~15fps with the same Settings/Source ?

It is technically impossible to get different speed with my GUI compared to other GUI's, unless you are either using a different x264 binary or passing other parameters to x264 ;)

But if you don't trust the GUI, copy the full command-line form the log window and run it manually from the command prompt...

[ACrowley]

It is technically impossible to get different speed with my GUI compared to other GUI's, unless you are either using a different x264 binary or passing other parameters to x264 ;)

But if you don't trust the GUI, copy the full command-line form the log window and run it manually from the command prompt...

As i say i use exactly the same Options!

But your gui use the x264 Build and other guis 32Bit rev 1281 thats the one and only difference

[LoRd_MuldeR]

As i say i use exactly the same Options!

Do you only select the same options in both GUI's or do both GUI's really pass identical parameters to x264? That's a difference!

But your gui use the x264 Build and other guis 32Bit rev 1281 thats the one and only difference

That's definitely something you should investigate. Exchange the builds and try again ;)

[ACrowley]

Do you only select the same options in both GUI's or do both GUI's really pass identical parameters to x264? That's a difference!
That's definitely something you should investigate. Exchange the builds and try again ;)
ofcourse..im not stupid.
--preset veryslow --tune grain --bitrate 14800 --level 4.1 --deblock -3:-3 --ref 5 --vbv-bufsize 30000 --vbv-maxrate 40000 --no-dct-decimate --no-fast-pskip --partitions p8x8,b8x8,i4x4,i8x8 --me umh --subme 9

obviously theres something wrong:)...but it works with all other x264 guis/cmdline.

I use x264 rev1281 32Bit (tested with megui/Staxrip/Ripbot,x264.exe) and rev1281 x64 in your gui

everytime 14,96fps in 1pass and 4,79fps with your gui

Can somebody reproduce it ?

[dstln]

Post the log from the other gui.

[Keiyakusha]

ACrowley
Note, that megui's "turbo" first pass probably uses different settings than 1st pass in x264. But I'm not using megui since I found Simple x264 Launcher so I'm not sure what settings MeGui uses now.

[LoRd_MuldeR]

Updated x264 to r1281 (JEEB's builds). Download link in first post updated!

[ACrowley]

ACrowley
Note, that megui's "turbo" first pass probably uses different settings than 1st pass in x264. But I'm not using megui since I found Simple x264 Launcher so I'm not sure what settings MeGui uses now.

as i say i use exactly the same cmdline everytime,also i dont use megui anymore!
Same 1 pass Perfomance with x264.exe via cmdline too since years.
But not with this launcher....i dont know why, strange. Theres something wrong

It looks like the placebo preset in 1pass where the turbo is disabled. I get 4-4fps with placebo in 1 pass too...

But i use the preset very slow ...and the launchers log shows the correct cmdline.

I really want to know Results from other Users. Please can someone test the 2 pass VBR Mode with the same cmdline with this gui ?

Preset: Veryslow
Tuning: Grain
Profile: High
Params: --level 4.1 --deblock -3:-3 --ref 5 --vbv-bufsize 30000 --vbv-maxrate 40000 --no-dct-decimate --no-fast-pskip --partitions p8x8,b8x8,i4x4,i8x8 --me umh --subme 9

Perhaps somebody can reproduce it...im sure its not my fault.

EDIT:
It works:) 1 pass fps are normal now. I changed nothing but x264 to latest rev1281 techhouse. Same cmdline/Source/AvS as above
However, its strange.In Fact i hade same Perfomance with the older Build via x264.exe. There was something confused here. But now its fine.

By the Way, a autom creation of the output logf Feature woule be nice ? Ofcourse i can manually copy it to clipboard, sure

[ACrowley]

Another Question :)

How can i delete all the old cmdline in the custom cmd scrooll down list ? The List is dozens of entrys long filled with every single cmdline ive used with the gui.

[LoRd_MuldeR]

AHow can i delete all the old cmdline in the custom cmd scrooll down list ? The List is dozens of entrys long filled with every single cmdline ive used with the gui.

Not exactly. It only shows the last eight parameters used and it only adds a new item to the list, if the current parameters are different from the previous ones!
This way you don't end up with a bunch of identical items in your history list, if you run several encodes with the very same parameters...

Anyway, you can simply delete all the "history_n" entries in your "%APPDATA%\x264_x64.ini" file or rename/move/delete the entire file, if that makes you feel better :p

[ACrowley]

Not exactly. It only shows the last eight parameters used and it only adds a new item to the list, if the current parameters are different from the previous ones!
This way you don't end up with a bunch of identical items in your history list, if you run several encodes with the very same parameters...

Anyway, you can simply delete all the "history_n" entries in your "%APPDATA%\x264_x64.ini" file or rename/move/delete the entire file, if that makes you feel better :p
THX :rolleyes:

[LoRd_MuldeR]

Updated x264 to r1292 (Komisar's builds). Download link in first post updated!

[ACrowley]

again a request

Cab you add a minimize Button please ?

[LoRd_MuldeR]

again a request

Cab you add a minimize Button please ?

Will look for a solution. The "tool window" doesn't have a minimize button. You can use "Minimze" from the taskbar icon for the moment...

[ACrowley]

Will look for a solution. The "tool window" doesn't have a minimize button. You can use "Minimze" from the taskbar icon for the moment...

Taskbar icon ..ok

Another Thing :)
A Time Overview/Hint would be nice.
Maybe the Time where you start the encoding and the elapsed Time in the Final Stats

Ofcourse i know its a "simple x264 launcher only" and there are enough frontends out there....

[LoRd_MuldeR]

Updated x264 to r1301 (Komisar's builds). Download link in first post updated!

[kypec]

LM: Maybe you could add and then regularly update info about which version of x264 is included with your launcher at the first post of this thread also?

[LoRd_MuldeR]

LM: Maybe you could add and then regularly update info about which version of x264 is included with your launcher at the first post of this thread also?

The info is here ;)

Last edited by LoRd_MuldeR; Today at 11:54. Reason: Update x264 binaries to r1301

Also you can update x264 yourself. I just update the package now and then, so less experienced users don't get/keep an outdated x264 binary...

[kypec]

Sorry, didn't notice that tiny edit notes below. Yeah, I know I can use whatever x264 build instead of packaged one. Just wanted to make it more clear for not so experienced users/visitors of this thread. ;)

[Yoshiyuki Blade]

Droppin by to say thanks for pointing me to this program. :)
I might switch over to 64-bit encoding finally!

[dstln]

And if anyone still cares about the benchmarks, I was burning in/testing a new cpu last night.

Source: C:\temp\test.avs
Preset: Medium
Tuning: None
Profile: High
Params: --level 4.1 --thread-input --deblock -2:-2 --bframes 7 --b-adapt 2 --direct auto --ref 10 --merange 24 --me umh --subme 10 --partitions all --trellis 2 --psy-rd 1.0:0.0 --no-dct-decimate --no-fast-pskip --psnr --ssim --sar 33:27

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 9750 frames, 7.53 fps, 2582.80 kb/s
encoded 9750 frames, 7.58 fps, 2582.80 kb/s
encoded 9750 frames, 7.50 fps, 2582.80 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 9750 frames, 8.68 fps, 2582.80 kb/s
encoded 9750 frames, 8.59 fps, 2582.80 kb/s
encoded 9750 frames, 8.68 fps, 2582.80 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 9750 frames, 8.76 fps, 2582.80 kb/s
encoded 9750 frames, 8.74 fps, 2582.80 kb/s
encoded 9750 frames, 8.53 fps, 2582.80 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 9750 frames, 8.80 fps, 2582.80 kb/s
encoded 9750 frames, 8.76 fps, 2582.80 kb/s
encoded 9750 frames, 8.72 fps, 2582.80 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 9750 frames, 8.64 fps, 2582.80 kb/s
encoded 9750 frames, 8.59 fps, 2582.80 kb/s
encoded 9750 frames, 8.66 fps, 2582.80 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 9750 frames, 8.63 fps, 2582.80 kb/s
encoded 9750 frames, 8.60 fps, 2582.80 kb/s
encoded 9750 frames, 8.69 fps, 2582.80 kb/s


further proof that 2m buffer seems to perform best, and with a nice ~1.16x speedboost over 32-bit x264

[LoRd_MuldeR]

Cab you add a minimize Button please ?

Done.

[Keiyakusha]

I just downloaded and re-downloaded latest ver but don't see minimize button... :confused:

[LoRd_MuldeR]

I just downloaded and re-downloaded latest ver but don't see minimize button... :confused:

http://img188.imageshack.us/img188/9380/minimize.png

:confused: :confused: :confused:

[Keiyakusha]

http://img188.imageshack.us/img188/9380/minimize.png

:confused: :confused: :confused:

Ahaa! I didn't think I need to start the encode, I expected to see it near the "close" button! :p
Thanks for this useful feature!

[LoRd_MuldeR]

Ahaa! I didn't think I need to start the encode, I expected to see it near the "close" button! :p

I think minimizing the window is only of interest for the user while encoding ;)

(BTW: Tool windows cannot have a "normal" minimize buttons)

[prOnorama]

Thanks for this LordMulder, I was looking for a MeGUI replacement just to do the encoding part, I just want to encode using the latest x264 32 bit (MeGUI is contantly out of date and sometimes buggy)

Did a test and it worked with the latest x264 32 bit (1310) using my own custom command line :)

I know this is not meant as a full GUI but it would be nice if you can store custom command lines under (a few) profiles and give them your own name (like "DXVA 720p HQ" or "DXVA 1080p SHQ").

An option to auto-save the log file would be nice too (especially for lazy people like me :p )

Cheers

PS: there's a small typo in the log-> "Analayzing Source File" ->
"Analyzing Source File"

[prOnorama]

Bummer, it doesn't let you set an exact bitrate (like 7238), just rounded to the nearest 100, if I enter it manually on the command line I get a "Please don't specify the "--bitrate parameter", I will do this for you, if required" warning.

[Darth Viorel]

You can set an exact bitrate, but the automatic correction will change wron values. So as 7 kbit/sec isn't allowed, it will make 100 out of it. If you just paste your desired bitrate into the box even 7238 is possible.

[egrimisu]

great too, a queue would be excelent. Thanks

[LoRd_MuldeR]

Bummer, it doesn't let you set an exact bitrate (like 7238), just rounded to the nearest 100, if I enter it manually on the command line I get a "Please don't specify the "--bitrate parameter", I will do this for you, if required" warning.

The behavior of the SpinEdit control to enforce the Min value isn't very convenient, I know.

However you can enter the desired bitrate manually using number-keys. But the intermediate value must not be too small.

So don't erase the complete number. Better change one digit at a time...

[Zarxrax]

Could I get a sample command line for how to use avs2yuv and pipebuf with x264? Thanks.

[LoRd_MuldeR]

I'd say look at my GUI. It prints out the full command-line to the log/progress window ;)

[Zarxrax]

Oh, ok :)

[Blue_MiSfit]

This is a great tool, Lord_Mulder!!!

I will be using this for all my x264 encoding needs for the time being!

~MiSfit

[LoRd_MuldeR]

Updated x264 to r1310 (Komisar's builds). Also made the "Bitrate" SpinEdit box easier to edit. Download link in first post updated!

[McArty]

Thank you LoRd_MuldeR for your continuous work.

P.S.That minimize button was very useful for me.

[turbojet]

Is there any chance of being able to type in the path\file boxes?

Also since I notice x86 x264 is faster then x64 on first pass or really fast settings is there any chance of adding an option to use x86 on first pass, x64 on second pass?

Also an option to use x86 x264 would be very useful for everyone that are still on x86 OS's and want to use a simple GUI.

[LoRd_MuldeR]

Is there any chance of being able to type in the path\file boxes?

Nope :p

Also since I notice x86 x264 is faster then x64 on first pass or really fast settings is there any chance of adding an option to use x86 on first pass, x64 on second pass?

Also an option to use x86 x264 would be very useful for everyone that are still on x86 OS's and want to use a simple GUI.

Runtime x86 -vs- x64 is already implemented :D

[sjakke]

Image in first post is broken.

[LoRd_MuldeR]

Blame ImagesHack. Will re-upload if it remains broken...

[turbojet]

Nope :p

Bummer, just a usual routine for me.

Runtime x86 -vs- x64 is already implemented :D

Ah wasn't aware of that never tried on an x86 OS. How an option in x64 mode an option to use x86 x264 for first pass and an option to use x86 for all encodes?

Also any chance of a process priority option and/or a pause/resume option through something like PsSuspend (http://technet.microsoft.com/en-us/sysinternals/bb897540.aspx)?

[Buggle]

Mulder, I'm having some issues here. First, launcher reports me it is using MMX and SSE2slow. As I'm on a X2 Brisbane 5000+, that doesn't make sense (it supports MMX, Extended 3DNow!, SSE, SSE2, SSE3).
Then, I was wondering if there is an option to select/set the buffer size to use for the encode, since there's no one-size-fits all. I've scrolled through this threat and looked for an ini/inf file in the package, but can't find one. Maybe I'm just blind, that could be the case.

[Buggle]

Some benchmarks from me. The clip is a trim() of Lord of War, with double DeGrainMedian, Spline36 resize (hardly, but it's in the filterlist) and some Undots. The x264 used is release 1318 from x264.nl
Source: D:\LORD_OF_WAR\VTS_01_1.avs
Preset: Slower
Tuning: Film
Profile: High
Params:

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 5001 frames, 5.50 fps, 1106.06 kb/s
encoded 5001 frames, 5.39 fps, 1106.06 kb/s
encoded 5001 frames, 5.39 fps, 1106.06 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 5001 frames, 5.91 fps, 1106.06 kb/s
encoded 5001 frames, 5.91 fps, 1106.06 kb/s
encoded 5001 frames, 5.38 fps, 1106.06 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 5001 frames, 4.98 fps, 1106.06 kb/s
encoded 5001 frames, 6.01 fps, 1106.06 kb/s
encoded 5001 frames, 5.96 fps, 1106.06 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 5001 frames, 5.97 fps, 1106.06 kb/s
encoded 5001 frames, 6.01 fps, 1106.06 kb/s
encoded 5001 frames, 6.18 fps, 1106.06 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 5001 frames, 6.18 fps, 1106.06 kb/s
encoded 5001 frames, 6.03 fps, 1106.06 kb/s
encoded 5001 frames, 6.06 fps, 1106.06 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 5001 frames, 6.15 fps, 1106.06 kb/s
encoded 5001 frames, 6.11 fps, 1106.06 kb/s
encoded 5001 frames, 6.08 fps, 1106.06 kb/s

[Dark Shikari]

Mulder, I'm having some issues here. First, launcher reports me it is using MMX and SSE2slow. As I'm on a X2 Brisbane 5000+, that doesn't make sense (it supports MMX, Extended 3DNow!, SSE, SSE2, SSE3).No, that's perfectly normal for an Athlon 64.

[Buggle]

No, that's perfectly normal for an Athlon 64.
How come? I thought x264 is using/can use SSE3 as well.

[Dark Shikari]

How come? I thought x264 is using/can use SSE3 as well.Only as a workaround for a weakness of the Pentium 4E.

[LoRd_MuldeR]

Ah wasn't aware of that never tried on an x86 OS. How an option in x64 mode an option to use x86 x264 for first pass and an option to use x86 for all encodes?

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

Also any chance of a process priority option and/or a pause/resume option through something like PsSuspend (http://technet.microsoft.com/en-us/sysinternals/bb897540.aspx)?

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

[Fr4nz]

Hi Lord, it seems that no one asked you this question in this thread: is it possible to implement a "shutdown" function (like the one present in MeGUI) in your launcher? :)

[LoRd_MuldeR]

Hi Lord, it seems that no one asked you this question in this thread: is it possible to implement a "shutdown" function (like the one present in MeGUI) in your launcher? :)

Possible indeed. But not currently planned...

[turbojet]

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

Fast x264 settings run faster with x86 x264. Including fast first passes which I see are ~5-10% faster. For example:

1280x720, preset medium, 2000 kbps, windows 7 x64, athlon ii 620

x86 from command line
pass 1: encoded 1277 frames, 48.40 fps, 1970.02 kb/s
pass 2: encoded 1277 frames, 28.44 fps, 2000.92 kb/s

x64 launcher
[First Pass]
encoded 1277 frames, 45.61 fps, 1969.83 kb/s
[Second Pass]
encoded 1277 frames, 29.02 fps, 2000.89 kb/s

Also I did a benchmark with the same CPU/source.

Preset: Ultrafast
Tuning: None
Profile: High
Params:

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 1277 frames, 51.93 fps, 1083.92 kb/s
encoded 1277 frames, 52.19 fps, 1083.92 kb/s
encoded 1277 frames, 51.82 fps, 1083.92 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 1277 frames, 47.30 fps, 1083.92 kb/s
encoded 1277 frames, 45.61 fps, 1083.92 kb/s
encoded 1277 frames, 47.30 fps, 1083.92 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 1277 frames, 47.30 fps, 1083.92 kb/s
encoded 1277 frames, 47.30 fps, 1083.92 kb/s
encoded 1277 frames, 47.30 fps, 1083.92 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 1277 frames, 47.30 fps, 1083.92 kb/s
encoded 1277 frames, 47.30 fps, 1083.92 kb/s
encoded 1277 frames, 47.30 fps, 1083.92 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 1277 frames, 47.30 fps, 1083.92 kb/s
encoded 1277 frames, 47.30 fps, 1083.92 kb/s
encoded 1277 frames, 45.61 fps, 1083.92 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 1277 frames, 45.61 fps, 1083.92 kb/s
encoded 1277 frames, 47.30 fps, 1083.92 kb/s
encoded 1277 frames, 47.30 fps, 1083.92 kb/s


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

Thanks that works.

[McArty]

And if you click the "X" button, the encoding will be paused. Click "No" to resume...
That is good to know, i thought wasn't implemented. Very useful for my slow cpu ;.)

p.d. Only that doing so is impossible minimize...

[psycoxl]

MeGUI does show you the complete commandline for each profile. So you can simply copy&paste ;)

Anyway, if you want to use MeGUI profiles, why not simply use MeGUI?



Not planned. But I have included the sources, so feel free to hack that in :D

you can't use it with the x264 x64 (or am i wrong)

[ACrowley]

That is good to know, i thought wasn't implemented. Very useful for my slow cpu ;.)

p.d. Only that doing so is impossible minimize...

mhh doesnt work here in 2nd Pass.

It was working before but only after 10-10sec until it suspends and cpu load goes down.

But in this Moment it doesnt work anymore in 2nd Pass here ?

[Buggle]

Seeing the attention went to the second part of my question about the SSIMs, I would like to ask the first part again to LordMulder: is it, or will it be, possible to select a custom buffer size? I've searched, but didn't find information about this.

[Darth Viorel]

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.

[LoRd_MuldeR]

You mean VBV Buffer or Pipe Buffer? The former can be adjusted with "--vbv-bufsize". The latter is hardcoded to 4 MB in "encode" (non-benchmark) mode.

[LoRd_MuldeR]

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.

Never seen anything like that :confused:

[Buggle]

You mean VBV Buffer or Pipe Buffer? The former can be adjusted with "--vbv-bufsize". The latter is hardcoded to 4 MB in "encode" (non-benchmark) mode.
I meant the pipe buffer. Would it be possible to implement a custom (drop down or so) option to select your own? Depending on the different uses (fast/slow settings and low/heavy filtering for instance) this could provide for some extra benefit speedwise.

[Buggle]

Never seen anything like that :confused:
I've experienced this as well, one time.

[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!

[JoeH]

Just a note to thank you for this tool. The interface is nice and I love being able to use the 64-bit for that extra bit of speed! :thanks:

One feature I'd love to see in future editions is the ability to do a 2-pass encode.

[LoRd_MuldeR]

One feature I'd love to see in future editions is the ability to do a 2-pass encode.

Automated 2-Pass already is implemented. Maybe you want batch processing?

[JoeH]

Automated 2-Pass already is implemented. Maybe you want batch processing?

Oooooooooooops! I actually originally wanted to do the the automated two pass with the benchmark and saw it wasn't yet implemented and just figured I couldn't do a simple encode either. But it works great. Batch processing would always be come in handy occasionaly but isn't as essential for me.

Honestly one thing I was thinking would be nice to see that I've never seen in any X264 GUI is some sort of a checkbox to activate / require the different options necessary to make an encoding compatible with a Blu-ray Standalone. I know for example that the --nad-hd (or whatever it's called) needs to be activated, but then there are a couple other things as well like max bitrate and such that are recommended / required.

I always used the MeGUI options for Standalone, but now that those presets are not working properly it is something I need to look into.

[LoRd_MuldeR]

Updated x264 to r1360 (Komisar's builds) and fixed one typo.

[XadoX]

Oops! (404). Can not download the file.

[LoRd_MuldeR]

Oops! (404). Can not download the file.

DropBox has disabled public downloads for my account. Too much traffic :rolleyes:

Will upload to another mirror, once I get back home...

[EDIT]

Re-uploaded. The download link in the first post has been updated accordingly.

[egrimisu]

avisource work jsut great with megui, i believe there is nothing wrong with it

my script look like this:
DGDecode_mpeg2source("d:\misu\nana22\VTS_01_1.d2v")
source1=DGDecode_mpeg2source("d:\misu\nana22\VTS_01_1.d2v").trim(0,38011)
source2=AviSource("D:\Misu\nana22\hfyu_1.avi")
a=source1.animeivtc(mode=1,aa=0,mt=true).assumefps(30000,1001)
b=source2
a+b

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

[LoRd_MuldeR]

avisource work jsut great with megui, i believe there is nothing wrong with it

my script look like this:
DGDecode_mpeg2source("d:\misu\nana22\VTS_01_1.d2v")
source1=DGDecode_mpeg2source("d:\misu\nana22\VTS_01_1.d2v").trim(0,38011)
source2=AviSource("D:\Misu\nana22\hfyu_1.avi")
a=source1.animeivtc(mode=1,aa=0,mt=true).assumefps(30000,1001)
b=source2
a+b

There really is no reason why AVISource should work only in MeGUI, but not in another GUI.

Given that you use the same version of Avisynth and the same source clip...

[Rodger]

I miss the call of the plugin itself in that script....may be the reason

[deets]

and odd situation, when i chose slower, my video stops after a few seconds. no encode error, it just freezes on the first few frame but the time carries on.

if i chose any lower preset, the video encodes just fine.

im using a script created by dgdecnv and a 1080i source from BBC HD.

just wondered if it could be anything obvious?

[LoRd_MuldeR]

What happens if you run x264 from the console with the exactly same command-line and the exactly same avisynth script?

[kool]

Thanks for this thread, I have few questions...

I moved to win 7 64bit for the first time, and i need help to get x264 work with Win 7 64bit. I usually use meGUI and some time RipBot. I still don't know if there is an other way to use x264 64bit work with 64bit OS.

guide me please if I need to use any other softs or avisynth 64bit.

Thanks in advance.

[LoRd_MuldeR]

You can use x264 on 64-Bit Windows just fine. Both, 32-Bit builds and 64-Bit builds of x264, will work perfectly fine. However the 64-Bit builds should give a nice speed boost!

But if you want to use 64-Bit x264, the you need 64-Bit Avisynth. Then all your Avisynth plugins must be 64-Bit too! And, if you use DirectShowSource() or AVISource(), all Codecs must be 64-Bit as well!

With my tool you can avoid this. It uses 64-Bit x264, but pipes the data in from a separate 32-Bit process. Hence you can continue using 32-Bit Avisynth/Plugins/Codecs, as you are used to...

[kool]

:o now I'm geting confuse, which way is recommended and stable to use avisynth 64bit or 32bit under 64bit OS?

if 64bit avisynth is stable under 64bit OS, could you please point me to link, to get avisynth 64bit and 64bit filters.

Thanks.

[LoRd_MuldeR]

:o now I'm geting confuse, which way is recommended and stable to use avisynth 64bit or 32bit under 64bit OS?

if 64bit avisynth is stable under 64bit OS, could you please point me to link, to get avisynth 64bit and 64bit filters.

Thanks.

There are no "official" builds of 64-Bit Avisynth, but you can find squid_80's builds here:
http://www.members.optusnet.com.au/squid_80/

Also you will find some 64-Bit plugins there. However you won't be able to use any 32-Bit Plugins with 64-Bit Avisynth, which is a limitation!

And as said before, you need 64-Bit Codecs, as 32-Bit Codecs won't work...

(BTW: Updated x264 to r1373. Using Komisar's builds)

[deets]

What happens if you run x264 from the console with the exactly same command-line and the exactly same avisynth script?

yeah same thing, weird. wonder why

[LoRd_MuldeR]

yeah same thing

Then it has absolutely nothing to with my GUI and this is the wrong place to complain...

[deets]

Then it has absolutely nothing to with my GUI and this is the wrong place to complain...

i wasn't complaining, just making a comment. and until we did the test, we didn't know if it was or not :)

maybe with your advanced knowledge you could have shed some light as to what options changed between presets to warrant a crash.

but i didnt expect you to devote any time to answering.

[kool]

Thanks alot LoRd_MuldeR for your help, Could you help me out, how to install Avisynth 64BiT, as there is no installer.
* Could you guide me, how to use your tool?
* can we use 32-Bit Plugins and 32bit avisynth under 64bit os? "at lose of some speed" just want to make sure.

[LoRd_MuldeR]

Thanks alot LoRd_MuldeR for your help, Could you help me out, how to install Avisynth 64BiT, as there is no installer.

Unzip.

* Could you guide me, how to use your tool?

Install 32-Bit Avisynth with the official installer - and then use the tool.

* can we use 32-Bit Plugins and 32bit avisynth under 64bit os? "at lose of some speed" just want to make sure.

Yes, of course! And there generally is no loss in speed! What I said is: 64-Bit x264 has some speed-up compared to 32-Bit x264.

It's not related to what Avisynth you use. However, as I said before, 64-Bit x264 requires 64-Bit Avisynth.

Or you use my tool (or a similar one), which allows you to use 64-Bit x264 with 32-Bit Avisynth by piping the data into x264 from a 32-Bit process.

That said, in theory, Avisynth plugins could gain some speed-up from 64-Bit too. But it depends on the individual plugin!

(Keep in mind that many Avisynth plugins don't even have a 64-Bit build available. So if you use 64-Bit Avisynth, the usable plugins are limited)

[LoRd_MuldeR]

i wasn't complaining, just making a comment. and until we did the test, we didn't know if it was or not :)

But now we know that's your problem isn't related to my GUI and therefore it has become clear that you are discussing your problem at the wrong place...

[kool]

(Keep in mind that many Avisynth plugins don't even have a 64-Bit build available. So if you use 64-Bit Avisynth, the usable plugins are limited)

OK...:) in theory I can use avisynth 32bit and it's plugins under 64bit OS with out any problem? but can't use 32bit avisynth and it's plugins under 64bit avisynth, as you mentioned there are few plugins for 64bit avisynth, and the usable plugins are limited for 64bit avisynth? "if yes" than I happyly move to 64bit.

Your suggestion i ask, I have total of 4GB Ram with 32bit OS, I can use about 3.25 GB, so when I move to 64bit OS I will get total of 4 GB Ram, and here...will the extra 0.35 GB make any speed differences when I move to 64 bit OS?

Thank you once again :)

[LoRd_MuldeR]

OK...:) in theory I can use avisynth 32bit and it's plugins under 64bit OS with out any problem?

Yes, you can. There is absolutely no problem.

but can't use 32bit avisynth and it's plugins under 64bit avisynth, as you mentioned there are few plugins for 64bit avisynth, and the usable plugins are limited for 64bit avisynth? "if yes" than I happyly move to 64bit.

32-Bit Avisynth can only use 32-Bit plugins, it cannot use 64-Bit plugins. 64-Bit Avisynth can only use 64-Bit plugins, it cannot use 32-Bit plugins.

Various plugins are already available as 64-Bit version (see squid80's site), but many are not...

Your suggestion i ask, I have total of 4GB Ram with 32bit OS, I can use about 3.25 GB, so when I move to 64bit OS I will get total of 4 GB Ram, and here...will the extra 0.35 GB make any speed differences when I move to 64 bit OS?

Probably there won't be much speed-up regarding the additional RAM. But you will run in "out of RAM" problems less frequently.

Be aware that 32-Bit applications are still limited to 2 GB of memory per process, even when running on a 64-Bit OS. That's often a problem with memory-intensive Avisynth scripts!

Only if you use 64-Bit applications (which of course requires a 64-Bit OS) the per-process 2 GB memory limit is gone!

With my tool Avisynth is still 32-Bit and still has the 2 GB limit. But as Avisynth and x264 are running in separate processes with my tool, the memory issue is eased a bit, at least ;)

[djesteban]

Hi,

I have a odd problem here
I am trying to encode this 1920x1080 h264 stream, but it won't encode if I add any option to my avs script.
For example, if my avs script looks like this:
LoadPlugin("<path>\DGDecodeNV.dll")
DGSource("D:\Hatsukoi\video.dga")
#deinterlace
#crop
#resize
#denoise

The encode starts and seems to continue without any issue (I aborted before the end since it's a fairly long movie)

...but if I change my script with a crop like the following:
LoadPlugin("<path>\DGDecodeNV.dll")
DGSource("D:\Hatsukoi\video.dga")
#deinterlace
crop( 0, 22, 0, -22)

#resize
#denoise

...then the launcher displays Creating encoder processes, please wait... forever and never starts the encode.

What am I doing wrong here?!?! When I test this AVS in MeGUI, it does start and encode. Please help!

Here's my .dga info log:
Stream Type: Elementary
Video Type: AVC
Profile: High
Level: 4.1
Coded Size: 1920x1088
SAR: 1:1
Display Size: 1920x1080
Frame Rate: 23.976024 fps
Colorimetry: BT.709 [1]
Frame Structure: Frame
Frame Type: I
Coded Number: 164219
Playback Number: 164219
Frame Repeats: 0
Field Repeats: 0
Bitrate: 0.888
Bitrate (Avg): 34.297
Bitrate (Max): 40.085
Elapsed: 0:09:54
Remain: 0:00:00
FPS:
Info: Finished!


Thanks in advance

[LoRd_MuldeR]

Is that problem specific to DGSource? Then please report it in the proper thread:
http://forum.doom9.org/showthread.php?t=147945

If that problem is specific to x264 itself, which means DGSource works perfectly fine in any other application, you will have to discuss that with the x264 developers.

The only case where I might be able to do something are problems that are specific to my GUI, which means x264 works 100% fine from console but doesn't inside my GUI.

BTW: When cropping, try to avoid Non-Mod16 resolutions. That means: If your source is Mod16, only crop multiples of 16 in each dimension.

[kool]

is this tool belongs to "C:\Program Files (86)?

[LoRd_MuldeR]

is this tool belongs to "C:\Program Files (86)?

You can put it to whatever place you like :p

However Microsoft's "C:\Program Files (86)" -vs- "C:\Program Files" folder concept doesn't fit here, as this software package incorporates 32-bit and 64-Bit binaries :D

But technically there is absolutely no reason to use the one or the other. Choose whatever you personally like more ;)

[rack04]

Hi,

I have a odd problem here
I am trying to encode this 1920x1080 h264 stream, but it won't encode if I add any option to my avs script.
For example, if my avs script looks like this:
LoadPlugin("<path>\DGDecodeNV.dll")
DGSource("D:\Hatsukoi\video.dga")
#deinterlace
#crop
#resize
#denoise

The encode starts and seems to continue without any issue (I aborted before the end since it's a fairly long movie)

...but if I change my script with a crop like the following:
LoadPlugin("<path>\DGDecodeNV.dll")
DGSource("D:\Hatsukoi\video.dga")
#deinterlace
crop( 0, 22, 0, -22)

#resize
#denoise

...then the launcher displays Creating encoder processes, please wait... forever and never starts the encode.

What am I doing wrong here?!?! When I test this AVS in MeGUI, it does start and encode. Please help!

Here's my .dga info log:
Stream Type: Elementary
Video Type: AVC
Profile: High
Level: 4.1
Coded Size: 1920x1088
SAR: 1:1
Display Size: 1920x1080
Frame Rate: 23.976024 fps
Colorimetry: BT.709 [1]
Frame Structure: Frame
Frame Type: I
Coded Number: 164219
Playback Number: 164219
Frame Repeats: 0
Field Repeats: 0
Bitrate: 0.888
Bitrate (Avg): 34.297
Bitrate (Max): 40.085
Elapsed: 0:09:54
Remain: 0:00:00
FPS:
Info: Finished!


Thanks in advance

Since you have DGDecNV tools you could use the DGIndexNV cropping feature and see if that solves anything.

[djesteban]

Is that problem specific to DGSource? Then please report it in the proper thread:
http://forum.doom9.org/showthread.php?t=147945

If that problem is specific to x264 itself, which means DGSource works perfectly fine in any other application, you will have to discuss that with the x264 developers.

The only case where I might be able to do something are problems that are specific to my GUI, which means x264 works 100% fine from console but doesn't inside my GUI.

BTW: When cropping, try to avoid Non-Mod16 resolutions. That means: If your source is Mod16, only crop multiples of 16 in each dimension.
Ok so I tested the following from the cli...
x264.exe --preset slower --tune film --pass 1 --bitrate 12000 --stats "encode.stats" --output NUL "D:\Hatsukoi\video.avs"
(here's the avs script; notice that I have change the crop size to make sure it is mod16):
LoadPlugin("<path>\DGDecodeNV.dll")
DGSource("D:\Hatsukoi\video.dga")
#deinterlace
crop( 0, 20, 0, -20)

#resize
#denoise

...and it works like a charm, encode starts (thanks to your help in another thread :p )

But now, when I try your tool, I input the same avs in launcher.exe, specify my output path with .264 extension and:
mode: 2-pass
target bitrate: 12000
preset: slower
tuning: film
profile: high
no advanced/custom options specified
...then I start the job, and it still stays at the Creating encoder processes, please wait... message forever and never actually starts the encode.

Now, the only way I am able to make it start, is by completely stripping my avs in the following way (notice there's no crop anymore):
LoadPlugin("<path>\DGDecodeNV.dll")
DGSource("D:\Hatsukoi\video.dga")
#deinterlace

#resize
#denoise
That will start the job and encode.
So mod16 or not, as soon as i add a crop, it just sleeps there without doing anything.

[djesteban]

Since you have DGDecNV tools you could use the DGIndexNV cropping feature and see if that solves anything.

Hmmm... that could be the issue, who knows... I'll try it... but still it doesn't explain why it works from the cli and not from this tool (with the same avs)

Let me try that and I'll tell you what happens :)

*EDIT*
By cropping through DGIndexNV the encode indeed starts! Though my avs script is still the stripped one because the crop info are stored in the .dga file now.
Still, the question remains as why it works through cli and not in this tool when cropping through the .avs script

[kool]

I have did the 1th test with 704x304 Win 7 64-bit.

Source: C:\Users\kool\Desktop\Test\test.avs
Preset: Medium
Tuning: None
Profile: High
Params:

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 922 frames, 74.81 fps, 1440.62 kb/s
encoded 922 frames, 75.48 fps, 1440.62 kb/s
encoded 922 frames, 74.25 fps, 1440.62 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 922 frames, 76.83 fps, 1440.62 kb/s
encoded 922 frames, 70.92 fps, 1440.62 kb/s
encoded 922 frames, 70.92 fps, 1440.62 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 922 frames, 76.83 fps, 1440.62 kb/s
encoded 922 frames, 70.92 fps, 1440.62 kb/s
encoded 922 frames, 76.83 fps, 1440.62 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 922 frames, 70.92 fps, 1440.62 kb/s
encoded 922 frames, 70.92 fps, 1440.62 kb/s
encoded 922 frames, 70.92 fps, 1440.62 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 922 frames, 70.92 fps, 1440.62 kb/s
encoded 922 frames, 70.92 fps, 1440.62 kb/s
encoded 922 frames, 70.92 fps, 1440.62 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 922 frames, 76.83 fps, 1440.62 kb/s
encoded 922 frames, 76.83 fps, 1440.62 kb/s
encoded 922 frames, 70.92 fps, 1440.62 kb/s

[LoRd_MuldeR]

Updated x264 to r1376, using Komisar's builds.

Also piping source into x264 as YUV4MPEG from now on, so we don't need to specify the video resolution and framerate in the command-line.

However we still need to detect the number of frames and pass it to x264 via command-line parameter explicitly...

[buzzqw]

However we still need to detect the number of frames and pass it to x264 via command-line parameter explicitly...

why ?

from my short test the encoding has always ended at right frame..

BHH

[LoRd_MuldeR]

why ?

from my short test the encoding has always ended at right frame..

BHH

If you pipe input into x264 from STDIN then it doesn't know the total number of frames!

With the YUV4MPEG format the width/height as well as the framerate are included in the stream (as opposed to "raw" YUV), so we don't need to pass those params explicitly.

However the total number of frames are not included in the YUV4MPEG stream, so we need to pass it manually via "--frames" parameter.

Otherwise x264 doesn't display the progress properly - and the GUI fails to parse the output. Well, how should x264 display progress, if the total number of frames isn't known?

But don't worry, the GUI will detect the number of frames for you and pass the "--frames" parameter to x264 ;)

(It's just that we cannot get rid of the "Analyze" step before the encoding starts. Anyway, the analyze isn't required to detect width/height/framerate anymore)

[buzzqw]

thanks for explanation LM!

BHH

[dstln]

http://img695.imageshack.us/img695/4153/errorwh.png

Been getting a bunch of these recently, at the end of encodes. Launcher keeps running and even working (during benchmark) until you press ok, then it crashes out.

[LoRd_MuldeR]

Unless you give me detailed information on how to reproduce this problem, I cannot help. I finished dozens of encodes and it never crashed for me...

[djesteban]

I am actually using this tool as my main x264 GUI front-end!
I am still having the crop issue when cropping from my .avs file, but since I am now cropping directly in my .dga file (now .dgi it seems), this works like a charm.
Thanks for keeping up the good work on this one LoRd_MuldeR :)

*EDIT*
Only thing that is missing from this tool IMO is a good bitrate calculator like in MeGUI. That would be awesome!

[LoRd_MuldeR]

I am actually using this tool as my main x264 GUI front-end!
I am still having the crop issue when cropping from my .avs file, but since I am now cropping directly in my .dga file (now .dgi it seems), this works like a charm.
Thanks for keeping up the good work on this one LoRd_MuldeR :)

I can't help you with the "cropping" issue, as there is no indication that this related to my GUI.

It's caused by x264, Avisynth or DGSource. Or more likely, a combination of those...

*EDIT*
Only thing that is missing from this tool IMO is a good bitrate calculator like in MeGUI. That would be awesome!

What's wrong with %WINDIR%\System32\calc.exe ??? :D

[yesgrey]

My test results with 1920x816p, Win7 RC1 64bit, E2160@2.7GHz:
Source: D:\Temp\test_jumper_x264.avs
Preset: Slow
Tuning: Grain
Profile: High
Params: CRF 18

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 202 frames, 1.86 fps, 14666.12 kb/s
encoded 202 frames, 1.92 fps, 14666.12 kb/s
encoded 202 frames, 1.93 fps, 14666.12 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 202 frames, 1.92 fps, 14666.12 kb/s
encoded 202 frames, 1.96 fps, 14666.12 kb/s
encoded 202 frames, 1.96 fps, 14666.12 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 202 frames, 1.98 fps, 14666.12 kb/s
encoded 202 frames, 1.94 fps, 14666.12 kb/s
encoded 202 frames, 1.98 fps, 14666.12 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 202 frames, 1.98 fps, 14666.12 kb/s
encoded 202 frames, 1.98 fps, 14666.12 kb/s
encoded 202 frames, 1.96 fps, 14666.12 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 202 frames, 1.98 fps, 14666.12 kb/s
encoded 202 frames, 1.98 fps, 14666.12 kb/s
encoded 202 frames, 1.98 fps, 14666.12 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 202 frames, 1.98 fps, 14666.12 kb/s
encoded 202 frames, 1.94 fps, 14666.12 kb/s
encoded 202 frames, 1.98 fps, 14666.12 kb/s

[aegisofrime]

Lord Mulder: Any chance of adding a queuing system?

[dstln]

Fairly certain that has been asked ~10 times in this topic and it's been more or less said that he doesn't want to. So unless you have a specific reason for doing sequential encodes, I'd just say open a bunch of launcher applications and run them if you'll be afk for a while and wish to do so.

[alwyn]

Ran a benchmark on my i7 920 Rig, 6 GB DDR3 RAM, the procesor chip is overclocked to 3.5 GHZ.
Here's the results:
Encode resolution : 640x272, simply resized a sample of one of my 720p encodes
Source: C:\Users\Alwyn's System\Desktop\touch me.avs
Preset: Fast
Tuning: Grain
Profile: Main
Params:

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 7734 frames, 87.53 fps, 5274.00 kb/s
encoded 7734 frames, 89.03 fps, 5274.00 kb/s
encoded 7734 frames, 88.95 fps, 5274.00 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 7734 frames, 100.44 fps, 5273.99 kb/s
encoded 7734 frames, 100.44 fps, 5274.00 kb/s
encoded 7734 frames, 100.44 fps, 5274.00 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 7734 frames, 100.44 fps, 5274.00 kb/s
encoded 7734 frames, 99.15 fps, 5274.00 kb/s
encoded 7734 frames, 97.90 fps, 5274.00 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 7734 frames, 99.15 fps, 5274.00 kb/s
encoded 7734 frames, 99.15 fps, 5274.00 kb/s
encoded 7734 frames, 97.90 fps, 5274.00 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 7734 frames, 100.44 fps, 5274.00 kb/s
encoded 7734 frames, 100.44 fps, 5274.00 kb/s
encoded 7734 frames, 99.15 fps, 5274.00 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 7734 frames, 97.90 fps, 5274.00 kb/s
encoded 7734 frames, 99.15 fps, 5274.01 kb/s
encoded 7734 frames, 99.15 fps, 5274.00 kb/s

[buzzqw]

Lord Mulder: Any chance of adding a queuing system?

MicroX264 (inspired by this great gui) has a queue system

BHH

[kool]

* The tuning option is set to none by default, can you please tell me in details what other 6 options means and when I can use it?
* I understand the two pass mod, but I'm unaware of other 3 mods, CRF, QP and ABR :confused:
* What is the relation between CRF > Quantizer and QP > Quantizer?
* The slower preset means " better quality" :rolleyes: ?
* Is it like higher profile means "high quality" ? Could you explain the profiles :)
* What are the recommended lower value for quantizer for high quality?

Thank you.

[LoRd_MuldeR]

* The tuning option is set to none by default, can you please tell me in details what other 6 options means and when I can use it?
* I understand the two pass mod, but I'm unaware of other 3 mods, CRF, QP and ABR :confused:
* What is the relation between CRF > Quantizer and QP > Quantizer?
* The slower preset means " better quality" :rolleyes: ?
* Is it like higher profile means "high quality" ? Could you explain the profiles :)
* What are the recommended lower value for quantizer for high quality?

Thank you very much.

These are very basic question about x264, not specific to this GUI. All the info can be found in this forum or in a basic x264 guide! So I won't answer it in this thread.

Please :search: and, if any questions remain, ask in the Newbies (http://forum.doom9.org/forumdisplay.php?f=6) forum. Also there is the "Show Help Screen" button in my GUI for a complete list of all options ;)

[MuLTiTaSK]

@kool

a little searching and reading can help take you a long ways here are some links to help:)
x264 settings (http://tinyurl.com/67y67w)
x264-encoding-options (http://tinyurl.com/y8coljh)
x264_options_page1 (http://tinyurl.com/2bmh56)
x264Options (http://tinyurl.com/ydr9lbk)
h264-profiles-and-levels (http://tinyurl.com/ybysezt)
x264 explained (http://tinyurl.com/3cp7bq) - LoRd_MuldeR's Sig can help

[kool]

Thank you very much MuLTiTaSK & LoRd_MuldeR for pointing me to right direction :p

[kypec]

Hi LoRd_MuldeR,

could you possibly enhance the information displayed in minimized state in taskbar?
I mean, currently it looks like this:
http://i48.tinypic.com/2uetohz.jpg
When using 2-pass mode I have to maximize window occasionally just to check which pass is really running at the moment. :(
It would be nice if that info was included in minimized window title and tooltip dialog as well.
Thank you very much for your superb tool and for hearing me out! ;)

[Rodger]

Totally different problem here:

how do I properly transcode a video-file that has this speciality:

SIZ 1920 x 1088
FPS 30000 / 1001
CODED 6246
PLAYBACK 7451
99.98% FILM


Whatever I do...the result is a out of sync file.

[rack04]

Totally different problem here:

how do I properly transcode a video-file that has this speciality:



Whatever I do...the result is a out of sync file.

Force film.

[Rodger]

care to elaborate?

[HaraldBluetooth]

When I try to download the latest update, it gives me:

"Oops! (404)
We can't find the page you're looking for. Check out our FAQ or forums for help. Or maybe you should try heading home. "

[twazerty]

When I try to download the latest update, it gives me:

"Oops! (404)
We can't find the page you're looking for. Check out our FAQ or forums for help. Or maybe you should try heading home. "

Can somebody give us a working link?

[rack04]

care to elaborate?

Your file appears to be film with 3:2 pulldown. Using DGDecNV you would need to use fieldop=1.

[LoRd_MuldeR]

When I try to download the latest update, it gives me:

"Oops! (404)
We can't find the page you're looking for. Check out our FAQ or forums for help. Or maybe you should try heading home. "

My Dropbox links have been disabled. Too much traffic they say. I don't know when they'll be back.

Will re-upload to another mirror soon...

[EDIT]

Here we go: http://www.mediafire.com/file/tqjoekjwmhm/x264_x64.2010-01-21.7z

[Rush_iam]

Here we go: http://www.mediafire.com/file/tqjoekjwmhm/x264_x64.2010-01-21.7z

I can't run 64-bit encoding on my Athlon II X2 CPU:
This program was not built to run on the processor in your system.
The allowed processors are: Intel(R) Core(TM) Duo processors and compatible Intel processors with supplemental Streaming SIMD Extensions 3 (SSSE3) instruction support

can you post Simple x264 Launcher that will not require SSSE3?

Thanks!

[LoRd_MuldeR]

I can't run 64-bit encoding on my Athlon II X2 CPU:


can you post Simple x264 Launcher that will not require SSSE3?

Thanks!

It's not an issue with my launcher, but with your build of x264 ;)

You must replace "x264_x64.exe" with a build that wasn't compiled with the Intel compiler and Intel-specific optimizations!

I'm including Komisar's "Core2" builds, but you can replace the build with whatever build you like...

You can try that one:
http://komisar.gin.by/old/1400/x264.1400kGIT.generic.x86_64.exe

[kypec]

LM, would you be so kind and post your comments on my small request (http://forum.doom9.org/showpost.php?p=1363584&postcount=299)?
TIA

[LoRd_MuldeR]

Done!

[kypec]

Done!
Much appreciated! :thanks:

[Motenai Yoda]

x264.nl/s build 1414 i7 920

script
MPEG2Source("C:\VTS_01_VOBID_001_CELLID_003_1.d2v", cpu=0,idct=3)
spline16resize(656,480)
removegrain(1,2,2)

Source: C:\Users\Casa\Desktop\VTS_01_VOBID_001_CELLID_003_1.avs
Preset: Fast
Tuning: Animation
Profile: High
Params:

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 17800 frames, 123.19 fps, 962.72 kb/s
encoded 17800 frames, 123.45 fps, 962.72 kb/s
encoded 17800 frames, 115.89 fps, 962.72 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 17800 frames, 129.93 fps, 962.72 kb/s
encoded 17800 frames, 130.88 fps, 962.72 kb/s
encoded 17800 frames, 131.85 fps, 962.72 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 17800 frames, 133.83 fps, 962.72 kb/s
encoded 17800 frames, 134.85 fps, 962.72 kb/s
encoded 17800 frames, 133.83 fps, 962.72 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 17800 frames, 134.85 fps, 962.72 kb/s
encoded 17800 frames, 135.88 fps, 962.72 kb/s
encoded 17800 frames, 134.85 fps, 962.72 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 17800 frames, 130.88 fps, 962.72 kb/s
encoded 17800 frames, 131.85 fps, 962.72 kb/s
encoded 17800 frames, 135.88 fps, 962.72 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 17800 frames, 134.85 fps, 962.72 kb/s
encoded 17800 frames, 133.83 fps, 962.72 kb/s
encoded 17800 frames, 134.85 fps, 962.72 kb/s

[LoRd_MuldeR]

Updated x264 to r1416 (Komisar's builds).

[egrimisu]

why are the executalbe that large? 6mb? any queue soon :) ?
Updated x264 to r1416 (Komisar's builds).

[XhmikosR]

They include ffms2+lavf input.

[Keiyakusha]

Is it possible to make sx264 GUI to run x264 without avs2yuv when input file is not avs script?

[rack04]

How does Simple x264 Launcher determine the number of frames from a avisynth script?

[MuLTiTaSK]

@rack04

--frames is used for x264 (http://forum.doom9.org/showpost.php?p=1354661&postcount=284)

[rack04]

@rack04

--frames is used for x264 (http://forum.doom9.org/showpost.php?p=1354661&postcount=284)

I understand that. What I was asking is how does the GUI determine the number of frames from the source, i.e. mediainfo, avisynth writefile, etc?

[MuLTiTaSK]

@rack04

thats actually something that i would like to know as-well;)

[LoRd_MuldeR]

I understand that. What I was asking is how does the GUI determine the number of frames from the source, i.e. mediainfo, avisynth writefile, etc?

avs2yuv does reveal that info. You just need to parse its STDOUT and capture the desired info :)

Is it possible to make sx264 GUI to run x264 without avs2yuv when input file is not avs script?

Possible indeed. And now that we have native FFMS2 input, it certainly would be a nice feature. However I'm too busy at the moment...

[buzzqw]

@Keiyakusha

(sorry for spam)

microx264 allow this
(using lavf/ffms2)

BHH

[kritip]

Windows 7 Home Premium
Dell XPS M1530 Laptop
Intel Mobile Core 2 T9300 @2.5GHz

Source: PAL DVD of Interview with a Vampire, black bars cropped mod16, no resize.

Crop(8,12,-8,-4)
trim(7000,7400)



Source: C:\RIPS\int vamp\MainMovie\INTERVIEW_WITH_A_VAMPIRE_PAL1\VIDEO_TS\tmp\k.avs
Preset: Veryslow
Tuning: Film
Profile: High
Params: --level 4 --ref 3 --bframes 3 --vbv-bufsize 25000 --vbv-maxrate 25000 --sar 16:11 --aud

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 401 frames, 4.69 fps, 1694.85 kb/s
encoded 401 frames, 4.75 fps, 1694.85 kb/s
encoded 401 frames, 4.82 fps, 1694.85 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 401 frames, 5.73 fps, 1694.85 kb/s
encoded 401 frames, 5.73 fps, 1694.85 kb/s
encoded 401 frames, 5.73 fps, 1694.85 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 401 frames, 5.65 fps, 1694.85 kb/s
encoded 401 frames, 5.73 fps, 1694.85 kb/s
encoded 401 frames, 5.73 fps, 1694.85 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 401 frames, 5.73 fps, 1694.85 kb/s
encoded 401 frames, 5.73 fps, 1694.85 kb/s
encoded 401 frames, 5.73 fps, 1694.85 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 401 frames, 5.65 fps, 1694.85 kb/s
encoded 401 frames, 5.65 fps, 1694.85 kb/s
encoded 401 frames, 5.65 fps, 1694.85 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 401 frames, 5.65 fps, 1694.85 kb/s
encoded 401 frames, 4.09 fps, 1694.85 kb/s
encoded 401 frames, 4.61 fps, 1694.85 kb/s


Nice improvment over 32bit x264. Could really do with a fater computer though :D


//EDIT

Just got x264 64 bit setup on the command line.

x264.exe r1416 from x264.nl
avisynth 2.5.8 64bit dll
dgdecode.dll 1.4.6 (couldn't find newer 64 bit version)

same clip and settings gave the following output. Note it's not bit identical though, so I may have messed up?


c:\RIPS\int vamp\MainMovie\INTERVIEW_WITH_A_VAMPIRE_PAL1\VIDEO_TS\tmp2>x26464.exe --preset veryslow --tune film --crf 18
--level 4 --ref 3 --bframes 3 --vbv-bufsize 25000 --vbv-maxrate 25000 --sar 16:11 --aud --output k.h264 k.av

avs [info]: 704x560p 16:11 @ 25/1 fps (cfr)
x264 [info]: using SAR=16/11
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
x264 [info]: profile High, level 4.0
x264 [info]: frame I:3 Avg QP:16.00 size: 32207
x264 [info]: frame P:122 Avg QP:17.60 size: 13658
x264 [info]: frame B:276 Avg QP:18.39 size: 5949
x264 [info]: consecutive B-frames: 0.3% 1.5% 61.1% 37.2%
x264 [info]: mb I I16..4: 9.7% 81.8% 8.5%
x264 [info]: mb P I16..4: 1.3% 10.1% 0.5% P16..4: 59.3% 21.5% 4.3% 0.1% 0.1% skip: 2.6%
x264 [info]: mb B I16..4: 0.1% 0.9% 0.0% B16..8: 40.3% 0.7% 1.5% direct:19.4% skip:37.1% L0:41.2% L1:45.6% BI:13.2%
x264 [info]: 8x8 transform intra:84.6% inter:53.7%
x264 [info]: direct mvs spatial:98.9% temporal:1.1%
x264 [info]: coded y,uvDC,uvAC intra: 87.6% 77.5% 47.1% inter: 36.3% 38.5% 2.1%
x264 [info]: i16 v,h,dc,p: 23% 8% 12% 58%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 7% 15% 9% 10% 12% 8% 13% 11%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 7% 5% 9% 13% 16% 10% 12% 10%
x264 [info]: Weighted P-Frames: Y:10.7%
x264 [info]: ref P L0: 54.8% 22.1% 8.4% 14.2% 0.5%
x264 [info]: ref B L0: 72.8% 27.2%
x264 [info]: kb/s:1698.15

encoded 401 frames, 5.81 fps, 1698.15 kb/s

[LoRd_MuldeR]

Updated x264 to r1442 (Komisar's builds).

[dstln]

Possible indeed. And now that we have native FFMS2 input, it certainly would be a nice feature. However I'm too busy at the moment...

Yes, I was thinking of this earlier. Would be great when you have the time.

[rack04]

Is it possible to make sx264 GUI to run x264 without avs2yuv when input file is not avs script?

These notes are probably a given:

If you're referring to 64-bit then the build will have to include 64-bit versions of ffmpeg and ffms2 and currently these input methods do not accept --nal-hrd <string> which may impact those who wish to encode to Blu-ray.

[Keiyakusha]

If you're referring to 64-bit then the build will have to include 64-bit versions of ffmpeg and ffms2 and currently these input methods do not accept --nal-hrd <string> which may impact those who wish to encode to Blu-ray.
x264 already contains ffms2 and/or lavc. There should be no problems with x64. Don't know anything about --nal-hrd but if currently it is possible to use it, then it should be also possible with proposed update.

[rack04]

x264 already contains ffms2 and/or lavc. There should be no problems with x64. Don't know anything about --nal-hrd but if currently it is possible to use it, then it should be also possible with proposed update.

What I was referring to is that x264 64-bit has to be compiled with 64-bit ffms and ffmpeg. AFAIK ffmpeg does not compile correctly in 64-bit due to fmpeg not properly following the win64 calling convention in its asm. nal-hrd does not currently work with x264 LAVF/FFMS input.

[Keiyakusha]

What I was referring to is that x264 64-bit has to be compiled with 64-bit ffms and ffmpeg. AFAIK ffmpeg does not compile correctly in 64-bit due to fmpeg not properly following the win64 calling convention in its asm. nal-hrd does not currently work with x264 LAVF/FFMS input.

Well, I don't know anything about this but current avs input should not be affected. If it works now, why it should not work after adding this new feature? Those who wants nal-hrd maybe will need to use another x264 build, but not a big problem I think.
Anyway thats up to LoRd_MuldeR.

[LoRd_MuldeR]

What I was referring to is that x264 64-bit has to be compiled with 64-bit ffms and ffmpeg. AFAIK ffmpeg does not compile correctly in 64-bit due to fmpeg not properly following the win64 calling convention in its asm. nal-hrd does not currently work with x264 LAVF/FFMS input.

We do have working 64-Bit builds of x264 with LAVF/FFMS enabled. This applies to the Komisar builds I have included ;)

There also are working 64-Bit Builds of MPlayer for Windows available. Conclusion: It definitely is possible to compile libavcodec/libavformat for Win64. But don't ask me how ^^

NAL-HRD will be working correctly again in latest x264 as soon as the patch has been updated or NAL-HRD is committed officially, I guess...

[rack04]

We do have working 64-Bit builds of x264 with LAVF/FFMS enabled. This applies to the Komisar builds I have included ;)

There also are working 64-Bit Builds of MPlayer for Windows available. Conclusion: It definitely is possible to compile libavcodec/libavformat for Win64. But don't ask me how ^^

NAL-HRD will be working correctly again in latest x264 as soon as the patch has been updated or NAL-HRD is committed officially, I guess...

Understood. I was just passing along information I received from Dark Shikari when I inquired about building 64-bit ffmpeg.

[Rodger]

A missing NAL-HRD Patch should be clearly stated with a realease since it has this huge impact on stand alone playability.

So I would sugguest to always keep a compatible release up, as long as the latest is the compatible one.

So I´m definitely waiting for a fitting release.

[LoRd_MuldeR]

A missing NAL-HRD Patch should be clearly stated with a realease since it has this huge impact on stand alone playability.

IMHO the presence (not the absence) of unofficial patches should be indicated. Also NAL-HRD is relevant for BluRay only.

Last but not least you can easily replace the x264.exe/x264_x64.exe with a different build...

[Rodger]

Just a different point of view, which I acknowledge but don´t accept.
I think since the playability outside of a computer is a MUST HAVE there is no way I would EVER give that up.
Times like the beginning of DivX when you only were able to play those files on a computer should definitely be over.
NAL-HRD should´nt be a patch. It´s something I still don´t get why it´s not implemented into the core of x264.

Of course I can replace it with a differenz build. But where is the need for me to update my files of "simple X264 launcher"?
Any striking improvement with the gui?
But I´ve already read that Rev.1442 is a huge step forward...sadly without SA compatibility.

[rack04]

But I´ve already read that Rev.1442 is a huge step forward...sadly without SA compatibility.

NAL HRD still works with avs input. So your argument about SA compatibility is incorrect.

[LoRd_MuldeR]

NAL-HRD should´nt be a patch. It´s something I still don´t get why it´s not implemented into the core of x264.

So did you do anything to help the development of x264 or NAL-HRD in particular ??? :sly:

NAL-HRD is still under development and the patch will be committed to the official x264 git repository once the developers are satisfied with it.

Until then you should be happy that there are people who actively work on NAL-HRD support, instead of complaining :rolleyes:

Of course I can replace it with a differenz build. But where is the need for me to update my files of "simple X264 launcher"?
Any striking improvement with the gui?
But I´ve already read that Rev.1442 is a huge step forward...sadly without SA compatibility.

You really should show a more positive attitude. So far I only see you complaining about software that was provided to you for free :mad:

But to answer your question: Nope, there were no changes to the GUI lately. Only the x264 builds have been updated to the latest revision.

[Rodger]

I´ve read that is currently broken?!
....And I just found out that you found out that there has been a change in the use of the string....

/EDIT:
No I didn´t?! But that shouldn´t prevent me on having a right to have my own opinion.
It´s proven to work properly. So I see no reason not to implement it.

[rack04]

I´ve read that is currently broken?!

Have YOU tested it? Does it work for YOU?

....And I just found out that you found out that there has been a change in the use of the string....

....And?

[Rodger]

If I got it right...instead of
--level 4.1 --nf --direct auto --vbv-bufsize 28000 --vbv-maxrate 28000 --subme 5 --no-mbtree --trellis 0 --me umh --nal-hrd --sar 1:1
with that new string I´ll have to say
--level 4.1 --nf --direct auto --subme 5 --no-mbtree --trellis 0 --me umh --nal-hrd 16000,16000 --sar 1:1

right?

[Rodger]

Have YOU tested it? Does it work for YOU?



....And?

IT WORKS!
Used the following build by komisar: http://komisar.gin.by/old/1442/x264.1442kGIT.core2.x86_64.exe

Played on...
...Samsung BD-P2500 Software V2.5
...Pioneer BDP-LX52 Software V3.41

/EDIT:
Damn they did a fantastic job. Faster, sharper and very keen on saving bitrate ;)

[rack04]

--nal-hrd 16000,16000

What is 16000,16000 for? According to full help:

--nal-hrd <string> Signal HRD information (needed e.g. for Blu-Ray compliance)
- vbr, cbr. (requires vbv-bufsize; cbr-hrd not allowed in .mp4)

So for Blu-ray compliance you would set --nal-hrd vbr. You would need to set --vbv-bufsize and --vbv-maxrate separately.

[Rodger]

I understood the new string as a replacement for the other two options.

Hmmh....I´m a bit confused....read the help myself now.

I now would have guessed to repeat the vbv-buffersize.
But when I read your hint....I now would set the used bitrate.

[anubhavrocker]

Is it not possible to make it completely use the command line function only, i mean a way in which it will not use the predefined settings values from mode, quant, b/w etc.

[Rodger]

That would´nt make it the "Simple" x264 Launcher.

[kool]

Hi, My goal is to achieve the highest quality, I don't know that there is something I don't know about or there is problem with GUI, I have been testing 1080p from Blu-Ray source the GUI is hanging I get text that
Analyzing source file:
Preparing for encode please wait... and this been toke me 6 hrs :)

I'm using very simple script
Resize
Tweak
Sharp

GUI setting
-- [Detailed Report] --

Source: C:\Users\kool\Desktop\test\test.avs
Output: C:\Users\kool\Desktop\test\test.mkv
Preset: Placebo
Tuning: Film
Profile: High
Params: (Empty)

Analyzing source file:

Aborted: Process was terminated prematurely!

[LoRd_MuldeR]

Hi, My goal is to achieve the highest quality, I don't know that there is something I don't know about or there is problem with GUI, I have been testing 1080p from Blu-Ray source the GUI is hanging I get text that
Analyzing source file:
Preparing for encode please wait... and this been toke me 6 hrs :)

I'm using very simple script
Resize
Tweak
Sharp

GUI setting
-- [Detailed Report] --

Source: C:\Users\kool\Desktop\test\test.avs
Output: C:\Users\kool\Desktop\test\test.mkv
Preset: Placebo
Tuning: Film
Profile: High
Params: (Empty)

Analyzing source file:

Aborted: Process was terminated prematurely!

There's probably something wrong with your input chain :rolleyes:

[LoRd_MuldeR]

Updated x264 to r1462 (Komisar's builds).

[Magix_995]

How to remove custom x264 lines from GUI ?

[LoRd_MuldeR]

How to remove custom x264 lines from GUI ?

:confused:

[Keiyakusha]

C:\Users\username\AppData\Roaming\x264_x64.ini -> history_1, history_2, history_3... this maybe?

[LoRd_MuldeR]

Why would you want to delete the history? The x264 launcher will only keep the eight most recent entries. And if you don't want to pick an entry from the history, simply don't do it...

[LoRd_MuldeR]

Updated x264 to r1471 (Komisar's builds). Support for FFMS2 input not yet, but under construction...

[LoRd_MuldeR]

Support for FFMS2 input has been added. Not tested very well yet. Feedback welcome :)

[LoRd_MuldeR]

Support for FFMS2 input has been added. Not tested very well yet. Feedback welcome :)

Minor update. Index files (created by FFMS2) will now be kept, so re-indexing the same source file can be avoided. Especially useful for 2-Pass encodes.

[egrimisu]

Minor update. Index files (created by FFMS2) will now be kept, so re-indexing the same source file can be avoided. Especially useful for 2-Pass encodes.

sorry for the dumb question, what is ffms2 and in what way can it help lets say end user. thanks.

[DarkZell666]

sorry for the dumb question, what is ffms2 and in what way can it help lets say end user. thanks.

Official infos :

http://doom10.org/index.php?topic=25.0
http://code.google.com/p/ffmpegsource

and the x264 commit that added ffms2 input support :

http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=380a201e8e8ba5a13022aeeeaf4b7501e1c79279

[LoRd_MuldeR]

sorry for the dumb question, what is ffms2 and in what way can it help lets say end user. thanks.

FFMS2 refers to "FFmpegSource2". It's a library that builds on top of libavcodec/libavformat from FFmpeg project. And it allows x264 to read all kinds of files (MPEG-PS, MPEG-TS, AVI, MKV, MP4, etc) directly and without Avisynth. Also no additional "Codecs" are needed, because all decoders/splitters are "built-in" already. For example the following is now possible:

x264.exe --crf 22 --output "C:\My Encodes\Output.mkv" "C:\My TV Captures\Some Movie.ts"

[deets]

another dumb question :) it cant resize or anything can it? only outputs the same as the input? so my 1440x1080 clips would still need avisynth to resize down to 720p?

[LoRd_MuldeR]

another dumb question :) it cant resize or anything can it? only outputs the same as the input? so my 1440x1080 clips would still need avisynth to resize down to 720p?

AFAIK you cannot apply any filters with FFMS2 input. At least not yet. It was discussed, but not added until now - or did I miss it?

So if you need to apply filters and if you can live without VFR (variable framerate) support, then Avisynth is still the way to go...

[DarkZell666]

AFAIK you cannot apply any filters with FFMS2 input. At least not yet. It was discussed, but not added until now - or did I miss it?

So if you need to apply filters and if you can live without VFR (variable framerate) support, then Avisynth is still the way to go...

Here's what the devs are up to right now : http://doom10.org/index.php?topic=177.0 ;)

[deets]

fascinating, thanks

[echohead]

this might be a pointless idea, but is there any chance you could add support for 2-pass encoding where the first pass uses crf?

[LoRd_MuldeR]

this might be a pointless idea, but is there any chance you could add support for 2-pass encoding where the first pass uses crf?

What would be the purpose of that ???

[buzzqw]

encode at bitrate given/obtained by a crf encoding
microx264 allow this, could be useful mainly for testing purpose
just do a 1 pass crf , then do a 2nd pass using the average bitrate from first pass

BHH

[LoRd_MuldeR]

encode at bitrate given/obtained by a crf encoding
microx264 allow this, could be useful mainly for testing purpose
just do a 1 pass crf , then do a 2nd pass using the average bitrate from first pass

BHH

Doing a 2-Pass encode at bitrate X and doing a CRF encode at the same bitrate X will give (almost) identical results - the only difference is that with CRF you don't know X in advance. The difference in quality will be so small, that you probably wouldn't be able to spot it. So if you need to hit a specific bitrate, then do a "plain" 2-Pass encode. If you want to preserve a certain level of quality (roughly), then use CRF mode at your favourite CRF value. First doing a CRF pass and then doing a second pass (2-Pass mode) based on the bitrate/stats from the CRF pass won't improve quality over the initial CRF pass. Since this GUI was written for simplicity and since it certainly doesn't try to be a "swiss army knife" for x264, I won't add an automated method for such "placebo" features. There is no real use for it (at least none has been presented to me) and it potentially confused people. Plus it unnecessarily complicates the code...

[buzzqw]

you just got a more bitrate variance with the insurance of "fixed" crf value

again, not for daily use, but fun for testing :)

BHH

[LoRd_MuldeR]

again, not for daily use, but fun for testing :)

And thus nothing we need in a "Keep It Simple Stupid" GUI :p

[buzzqw]

yea KISS rule! :D

BHH

[LoRd_MuldeR]

Updated x264 to r1510 (Komisar's builds). Now with full "BluRay" (NAL-HRD) support.

Please see the commit message for detailed info on how to produce BluRay-compliant streams:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=c6de86497cdd7b7f3cce7d8a95d723c7d0c9f505

[archaeo]

x264 [warning]: input appears to be interlaced, enabling interlaced mode.
If you want otherwise, use --no-interlaced
x264 [warning]: interlace + weightp is not implemented

Program indicated that it is enabling interlaced mode, but then warning states that it is not implemented. (It wasn't)
Why did it disable? How do I make sure it is enabled when interlaced is found?

thanks

[LoRd_MuldeR]

Program indicates that it is enabling interlaced mode, but then warning states that it is not implemented. (It wasn't)
Why did it disable? How do I make sure it is enabled when interlaced is found?

thanks

(1) If your source is interlaced, but you don't encode it as interlaced (i.e. "--interlaced" wasn't set), then x264 will switch to interlaced mode for you. And for good reason ;)
(2) If you really want to enforce progressive encoding of interlaced source, then you can specify "--no-interlaced". Probably not a good idea though!
(3) The warning about "interlace + weightp is not implemented" means that x264 cannot use both, weight-p and interlaced mode, at the same time. It is not implemented (yet).
(4) It is 100% safe to ignore the warning. Basically it just informs you that interlaced mode is used, and thus weight-p (weighted p-prediction) is not used.

[archaeo]

OK, thanks for the explanation...
By the way, I really like the program - it's simplicity and light footprint is something that works very well for me
:thanks:

[archaeo]

I had another question:
Is there a way to load two m2ts files and merge during encode?
At this point I'm merging them in tsmuxer and loading that file into x264. Could save a step, but not at the risk of complicating a nice program.

[LoRd_MuldeR]

I had another question:
Is there a way to load two m2ts files and merge during encode?
At this point I'm merging them in tsmuxer and loading that file into x264. Could save a step, but not at the risk of complicating a nice program.

Not directly. But if you write a custom Avisynth script, it's easy to do:

a = FFmpegSource("C:\Some Folder\File1.m2ts")
b = FFmpegSource("C:\Some Folder\File2.m2ts")
c = FFmpegSource("C:\Some Folder\File3.m2ts")
return a + b +c

Save that as "MySource.avs" and throw it on x264 ;)

[Vlarol]

1. Twelve Monkeys 1920x1040
2. Core i7 960@4.0GHz (HT disabled in BIOS)
3. Windows 7 Ultimate x64
4. Encoding with --crf 20.0

Medium preset

Source: D:\_FILM\Twelve Monkeys\Test.avs
Preset: Medium
Tuning: Film
Profile: High
Params: --sar 1:1

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 1000 frames, 11.66 fps, 9178.00 kb/s
encoded 1000 frames, 11.65 fps, 9178.00 kb/s
encoded 1000 frames, 11.66 fps, 9178.00 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 1000 frames, 12.35 fps, 9178.00 kb/s
encoded 1000 frames, 12.35 fps, 9178.00 kb/s
encoded 1000 frames, 12.35 fps, 9178.00 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 1000 frames, 12.20 fps, 9178.00 kb/s
encoded 1000 frames, 12.35 fps, 9178.00 kb/s
encoded 1000 frames, 12.35 fps, 9178.00 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 1000 frames, 12.20 fps, 9178.00 kb/s
encoded 1000 frames, 12.20 fps, 9178.00 kb/s
encoded 1000 frames, 12.20 fps, 9178.00 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 1000 frames, 12.35 fps, 9178.00 kb/s
encoded 1000 frames, 12.35 fps, 9178.00 kb/s
encoded 1000 frames, 12.35 fps, 9178.00 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 1000 frames, 12.20 fps, 9178.00 kb/s
encoded 1000 frames, 12.35 fps, 9178.00 kb/s
encoded 1000 frames, 12.20 fps, 9178.00 kb/s


Slower preset

Source: D:\_FILM\Twelve Monkeys\Test.avs
Preset: Slower
Tuning: Film
Profile: High
Params: --sar 1:1

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 1000 frames, 3.62 fps, 9160.56 kb/s
encoded 1000 frames, 3.61 fps, 9160.56 kb/s
encoded 1000 frames, 3.62 fps, 9160.56 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 1000 frames, 4.12 fps, 9160.56 kb/s
encoded 1000 frames, 4.08 fps, 9160.56 kb/s
encoded 1000 frames, 4.10 fps, 9160.56 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 1000 frames, 4.12 fps, 9160.56 kb/s
encoded 1000 frames, 4.15 fps, 9160.56 kb/s
encoded 1000 frames, 4.22 fps, 9160.56 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 1000 frames, 4.22 fps, 9160.56 kb/s
encoded 1000 frames, 4.20 fps, 9160.56 kb/s
encoded 1000 frames, 4.20 fps, 9160.56 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 1000 frames, 4.18 fps, 9160.56 kb/s
encoded 1000 frames, 4.18 fps, 9160.56 kb/s
encoded 1000 frames, 4.17 fps, 9160.56 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 1000 frames, 4.17 fps, 9160.56 kb/s
encoded 1000 frames, 4.20 fps, 9160.56 kb/s
encoded 1000 frames, 4.15 fps, 9160.56 kb/s

[mkv]

thx a bunch

[Rodger]

Hi there....how can I fix this:

When I feed the launcher with this avs-script:

AviSource("a.avi")
Lanczos4Resize(720,576)

It´s stuck at: "Preparing source for encode, please wait"

When I remove the resize-filter from the script...it does work properly.

Any ideas?

[LoRd_MuldeR]

Hi there....how can I fix this:

When I feed the launcher with this avs-script:

It´s stuck at: "Preparing source for encode, please wait"

When I remove the resize-filter from the script...it does work properly.

Any ideas?

Sounds like an Avisynth issue. Maybe an x264 issue. Most-likely not related to my GUI...

[Rodger]

But that script worked with megui, I can remember.

[LoRd_MuldeR]

But that script worked with megui, I can remember.

No matter what GUI front-end you use, your Avisynth script will always be handled by Avisynth, i.e. the GUI doesn't make a difference here.

Well, the only difference between MeGUI and my simple x264 launcher is that my launcher uses avs2yuv.exe instead of passing the script to x264.exe directly.

Try something like avs2yuv.exe "C:\Temp\Your Script.avs" -o "C:\Temp\Output.y4m" with your script and see what happens...

[Rodger]

Well...I guess I have to tell you, that you´re wrong!

I does work INSTANDLY within Megui.
Just updated it to the latest build and works like a charm with that little script.

/EDIT: Oversaw your hint at first.

It seems it is reasoned by avs2yuv. Since I get an error message like: "doesn´t look like an avisynth script". The same unchanged avs-file that CURRENTLY works within megui.

Here is the full script for reference:
#LoadCplugin("C:\Program Files (x86)\megui\tools\yadif\yadif.dll")
#Loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\DGDecodeNV.dll")
#DGSource("KNICK.dgi", deinterlace=1)
#DGSource("PLATSCH.dgi", deinterlace=1, resize_w=720, resize_h=576)
#DGSource("BLUBB.dgi", deinterlace=1)
#yadif(mode=0,order=-1,opt=-1)
#LeakKernelDeint(order=0)
#Crop(0,72,-0,-72)
#AddBorders(0,16,0,16)
AviSource("a.avi")
Lanczos4Resize(720,576)

[LoRd_MuldeR]

Well...I guess I have to tell you, that you´re wrong!

What I told you are simple facts.

It seems it is reasoned by avs2yuv. Since I get an error message like: "doesn´t look like an avisynth script". The same unchanged avs-file that CURRENTLY works within megui.

If the identical script is accepted by x264.exe, but rejected by avs2yuv.exe, this would indicate a potential bug in avs2yuv.

However you should try to track down the issue by reducing the script as much as possible. For example: Remove all the unneeded lines that are commented out.

Then try removing LanczosResize. If that doesn't make a difference, try a different source filter (i.e. FFVideoSource instead of AVISource).

(BTW: What version of Avisynth do you have installed ???)

EDIT:

And try replacing "a.avi" with the fully qualified path to your input file (such as "C:\Some Folder\a.avi"), just to be sure.

[Rodger]

AVISynth V2.58

Well....As I already said....it´s not related to the disabled lines.
As soon as I disable the lancos4resize line the script works.

You made a good sugguestion! I´ll try to change it "simple" lancosresize. But of course I wanted to use lanczos4resize because of the better upsizing.

/EDIT: Nah...doesn´t work too. Seems avs2yuv doesn´t like the resize filters of avisynth.

[LoRd_MuldeR]

You made a good sugguestion! I´ll try to change it "simple" lancosresize. But of course I wanted to use lanczos4resize because of the better upsizing.

Same issue with any resizer (e.g. BiCubicResize, Spline36Resize or PointResize), or is it just Lanczos4Resize ???

[Rodger]

I think more simple than "LanczosResize" isn´t neccesary to try.

[Rodger]

For all who can use it.

Here is a new Version of my "Excel-Bitrate-Calc".
Added new Media-Types and optimized the settings for newer revisions of x264 since I experienced x264 builds smaller files.

Still comments or Infos are welcome on this one.

[LoRd_MuldeR]

Updated x264 to r1564 (Komisar's builds).

[kypec]

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:

http://i43.tinypic.com/6htbm0.jpg

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?

[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:

http://i43.tinypic.com/6htbm0.jpg

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?

The context menu in the "report" window (as opposed to the "status" window) simply is the default one. In the "status" window I have implemented a custom one.

I can use the my custom context menu in the "report" window easily, if you like. But probably not before Sunday...

[kypec]

:thanks: and take your time! It's not a critical bug after all :p

[me7]

A great tool. Saves me some stupid grunt work I'd have to endure without it.
Thanks.

[CpT]

Nice tool.

http://vizmu.com/images/264-bench.jpg

Win7 32bit
Intel 980x Hyperthreading = on /12 threads.
Currently clocked at 4.2Ghz.
http://valid.canardpc.com/show_oc.php?id=1178119

I have to rebuild my 64bit raid array, it died on me uggg... When the drives come in stock I'll run it via 64bit win7.

If you toss in a auto resizer and NeroAac audio handling I would use this as my main encoder!

Source: C:\Chosen.mov
Output: C:\Output.mp4
Preset: Veryslow
Tuning: Film
Profile: High
Params: --keyint 750

x264 0.94.1583M 7608d73
built on May 9 2010, gcc: 4.4.4 (x86.core2.Komisar)
Revision: 1583

Commandline for x264:
C:\x264_x64.2010-04-25\x264.exe --preset veryslow --tune film --crf 22.0 --keyint 750 --output C:\Output.mp4 --demuxer ffms --index C:\Users\980\AppData\Local\Temp\~14FC3617328D3588A3CE6235F8E31A5F1AC64986.x264-index C:\Output.mp4

ffms [info]: 720x320p 1:1 @ 24/1 fps (vfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 3.1
x264 [info]: frame I:11 Avg QP:22.46 size: 18588
x264 [info]: frame P:305 Avg QP:25.17 size: 4697
x264 [info]: frame B:479 Avg QP:26.67 size: 2225
x264 [info]: consecutive B-frames: 15.3% 7.4% 9.2% 64.3% 3.8% 0.0% 0.0% 0.0% 0.0%
x264 [info]: mb I I16..4: 22.7% 58.4% 18.9%
x264 [info]: mb P I16..4: 14.7% 13.6% 4.5% P16..4: 21.9% 8.8% 1.6% 0.1% 0.0% skip:34.7%
x264 [info]: mb B I16..4: 2.3% 2.3% 0.4% B16..8: 31.3% 8.2% 1.6% direct: 6.3% skip:47.6% L0:41.7% L1:46.7% BI:11.6%
x264 [info]: 8x8 transform intra:43.5% inter:81.2%
x264 [info]: direct mvs spatial:97.9% temporal:2.1%
x264 [info]: coded y,uvDC,uvAC intra: 42.6% 50.0% 15.7% inter: 15.0% 16.9% 1.4%
x264 [info]: i16 v,h,dc,p: 42% 33% 7% 18%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 17% 13% 7% 9% 9% 12% 9% 14%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 17% 6% 7% 11% 10% 12% 9% 16%
x264 [info]: i8c dc,h,v,p: 44% 33% 13% 10%
x264 [info]: Weighted P-Frames: Y:23.6%
x264 [info]: ref P L0: 57.5% 13.2% 16.5% 5.5% 2.3% 1.2% 0.9% 0.5% 0.4% 0.3% 0.8% 0.3% 0.2% 0.1% 0.2% 0.1%
x264 [info]: ref B L0: 87.5% 6.8% 2.3% 0.8% 0.5% 0.4% 0.3% 0.2% 0.2% 0.2% 0.1% 0.2% 0.3% 0.1% 0.1%
x264 [info]: ref B L1: 96.7% 3.3%
x264 [info]: kb/s:652.76
encoded 795 frames, 42.76 fps, 652.93 kb/s

[LoRd_MuldeR]

If you toss in a auto resizer and NeroAac audio handling I would use this as my main encoder!

This is a x264 GUI, so can't offer any functionality that isn't supported by x264 ;)

Audio encoding support is on the "to do" list of x264, as far as I know. The same goes for video filters (e.g. resize).

Until then you'll have to use Avisynth input and do the resize in your AVS script...

[sebazvideo]

Lord Mulder, is there a way to set your program to make x264 to run in different priority modes, such as Low if I need to do other stuff while I'm encoding? Is that saved in a preference file or in the registry somewhere?

[livache]

Lord Mulder, is there a way to set your program to make x264 to run in different priority modes, such as Low if I need to do other stuff while I'm encoding? Is that saved in a preference file or in the registry somewhere?

Why would you need that? It currently starts x264 on below normal priority, which is enough to not slow down too much the processes that run on normal priority. You can even play games with no stuttering while x264 runs on below normal. If you really have a fixation with this, you can always use task manager to lower x264 priority to Low, but I find it pointless.

[LoRd_MuldeR]

Why would you need that? It currently starts x264 on below normal priority, which is enough to not slow down too much the processes that run on normal priority. You can even play games with no stuttering while x264 runs on below normal. If you really have a fixation with this, you can always use task manager to lower x264 priority to Low, but I find it pointless.

I agree.

[deets]

I agree.

I like the choice as i often leave the pc unattended for a long time, ie over night and want the confidence if my anti virus starts a search or whatever, x264 will always run at full speed.

ripbot has the option and changing it in the task bar is pain if it can be done simpler in software :)

[sebazvideo]

Why would you need that? It currently starts x264 on below normal priority, which is enough to not slow down too much the processes that run on normal priority. You can even play games with no stuttering while x264 runs on below normal. If you really have a fixation with this, you can always use task manager to lower x264 priority to Low, but I find it pointless.

I notice a difference when encoding between using below normal and low priority. Yes, I can change it from Task Manager, but it would be easier to change it from the program with a drop down list like in MeGUI, and also like with MeGUI, it would be nice to be able to set the default priority.

[LoRd_MuldeR]

I notice a difference when encoding between using below normal and low priority. Yes, I can change it from Task Manager, but it would be easier to change it from the program with a drop down list like in MeGUI, and also like with MeGUI, it would be nice to be able to set the default priority.

I really want to keep the GUI minimalistic.

And I assume 99% of all users will be happy with x264 running at below normal priority, as this way x264 will neither slow down other "foreground" applications nor will "background" tasks slow down x264.

Anyway, you can change the default priority by adjusting one single line of source code, if you really need to ;)

Process.Priority := ppBelowNormal;

(That's in the constructor of TEncode in "Unit_Encode.pas")

[Kuningas]

Thank you for this wonderful tool ) It's really make my life easier )
Just one question. I want to use crf + pass2 mode. But launcher rejects "--pass 1" parameter in crf mode. So no .stats I receive.
Could you fix it or what am I doing wrong?

[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

[stinman]

Of course I'm not planning to quit updating this tool anytime soon...
http://mewiki.project357.com/wiki/X264_Settings

Good I'm glad you will be here,as far as x264 wiki,I been there and still visit from time to time.I mainly got to learn how to write the commands and use cmd.I can use cmd when I see what other people write for commands.Thanks maybe I will try again,but who needs to when I got this tool :rolleyes:.I was looking at Komisar's link to his x264 builds,seems he is building a x264Gui also.Didn't look like it supports Bluray yet?Keep up the good work!!

Is there a program to help write the necessary avisynth script needed to use a raw h264 file for encoding with simple x264 launcher? I may have ask this before (or something like it).I was looking at your avsproxy gui,it will do this?

[LoRd_MuldeR]

Good I'm glad you will be here,as far as x264 wiki,I been there and still visit from time to time.I mainly got to learn how to write the commands and use cmd.I can use cmd when I see what other people write for commands.Thanks maybe I will try again,but who needs to when I got this tool :rolleyes:.

Well, my tool doesn't expose most x264 options in the GUI. Most non-standard options need to be written into the "custom x264 parameters" box, in CLI syntax!

I was looking at Komisar's link to his x264 builds,seems he is building a x264Gui also.Didn't look like it supports Bluray yet?Keep up the good work!!

You probably are referring to the x264 VFW encoder. That's something different!

You would use the x264 VFW encoder in VirtualDub and friends, but you can not use it as a "stand alone" application.

Is there a program to help write the necessary avisynth script needed to use a raw h264 file for encoding with simple x264 launcher? I may have ask this before (or something like it).I was looking at your avsproxy gui,it will do this?

"AVS Proxy GUI for Avidemux", as the name implies, is a GUI for Avidemux' AVS Proxy. If you don't use Avidemux, then the AVS Proxy GUI is not for you ;)

Nonetheless you should give Avidemux a try, if you didn't do so yet...

About loading H.264 stream in your Avisynth script: If you have a NVidia card and are willing to spend 15$, then DGDecodeNV (http://neuron2.net/dgdecnv/dgdecnv.html) would be the easiest choice.

Otherwise look at FFmpegSource2!

[click2]

Your program works well and is very helpful. : ) One very minor bug report: The tooltip text hasn't been updated since support for media files was added..?


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

[LoRd_MuldeR]

Your program works well and is very helpful. : ) One very minor bug report: The tooltip text hasn't been updated since support for media files was added..?


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

You are right. I will fix that with the next release.

[egrimisu]

Hi,
it seems that if the avs is avisource the encode freezes at the begining, will i lose quality if i use directshowsource (using ffdshow with no postprocesing or other filters), or basicly it's the same thing.
I'm using avisynth 2.58, win7 x64.thanks.

[Tatsukun]

Thanks for this tool, I just found out about it but it's really nice to have. Until now I had been using a bunch of .bat scripts.

I see that the advanced options saves some of your past entries. I was wondering if it would be possible to give these names so it's easier to distinguish and quickly recall them. For example, 480p, 720p, Bluray, Anime, etc.

[Rodger]

Thanks for this tool, I just found out about it but it's really nice to have. Until now I had been using a bunch of .bat scripts.

I see that the advanced options saves some of your past entries. I was wondering if it would be possible to give these names so it's easier to distinguish and quickly recall them. For example, 480p, 720p, Bluray, Anime, etc.

That is an interesting idea. But I don´t think mulder is into it.
My fellow-countryman is not into profiles. He wants to keep it easy as it is named "SIMPLE....."

My idea for you is to create a simple txt-file on the desktop.
Mine looks like this: 1080p Blu-Ray
--level 4.1 --nf --direct auto --subme 5 --no-mbtree --trellis 0 --me umh --vbv-bufsize 28000 --vbv-maxrate 28000 --nal-hrd "vbr" --sar 1:1

1080p AVCHD
--level 4.1 --nf --direct auto --subme 5 --no-mbtree --trellis 0 --me umh --vbv-bufsize 16500 --vbv-maxrate 16500 --nal-hrd "vbr" --sar 1:1

576p 16:9
--level 4.1 --nf --direct auto --subme 5 --no-mbtree --trellis 0 --me umh --vbv-bufsize 6000 --vbv-maxrate 6000 --nal-hrd "vbr" --sar 16:11

It´s the the easiest way to have "profiles" available at hand.

[stinman]

I wonder if we will get a update any time soon to the latest komisars x264.I tried to download the x264x64 from his web page but simple x264 launcher would not recognize it.I don't know how to make it.I hope you haven't quit on us Lord Mulder!

[komisar]

rename it from x264.1804.generic.x86_64.exe to x264_64.exe

[kypec]

rename it from x264.1804.generic.x86_64.exe to x264_64.exe

Small typo there ^^^
The proper filename should be x264_x64.exe
I would recommend to always update both x264 executables to same version (32-bit x264.exe & 64-bit x264_x64.exe) because
launcher uses 32-bit executable for printing help info whereas 64-bit for actual encoding on 64-bit Windows.

[stinman]

Thanks to both of you for your help,I did not update the 32-bit only the 64-bit the first time...Lord Muldor has them separated because the file size makes me think this anyway .So far no matter what it will not work.Tells me x264 is not in the home directory.I put both in the same folder,does the tar folder got to be changed also? I put these snips so you can see what I did.

[kypec]

Thanks to both of you for your help,I did not update the 32-bit only the 64-bit the first time...Lord Muldor has them separated because the file size makes me think this anyway .So far no matter what it will not work.Tells me x264 is not in the home directory.I put both in the same folder,does the tar folder got to be changed also? I put these snips so you can see what I did.
You must have done something wrong. Please follow my step-by-step instructions below and it will work:

I assume you have Simple x264 Launcher installed already. Your installation folder must contain these files:C:\Program Files (x86)\AVTools\Simple x264 Launcher
avs2yuv.exe 52736 4. 3. 2005
launcher.exe 373248 6. 9. 2010
pipebuf.exe 41984 10. 1. 2009
x264.exe 6487552 6. 9. 2010
x264_x64.exe 6798848 6. 9. 2010
sources.tar 395776 6. 9. 2010
GPL.txt 18321 29. 1. 2009

Download the latest x264 executables from Komisar:
32-bit executable r1804 (http://komisar.gin.by/old/1804/x264.1804.generic.x86.exe)
64-bit executable r1804 (http://komisar.gin.by/old/1804/x264.1804.generic.x86_64.exe)
Rename each downloaded file like this:
x264.1804.generic.x86.exe ---> x264.exe
x264.1804.generic.x86_64.exe ---> x264_x64.exe
Copy or move both renamed files to your installation folder so that they will replace the original x264 executables over there.
You can start launcher.exe now and enjoy the latest x264 revision doing its job!

[komisar]

64-bit executable r1804 (http://komisar.gin.by/old/1804/x264.1804.generic.x86_64.exe)

[stinman]

I will do this exactly as you stated and get back.You did see the snips I sent here, I don't know if the pipe buf is this- pipebuf.exe 41984 10. 1. 2009, but it is the one from his last update on 9-6-2010, but this is what I done last time.I will re-do it now and get back.Thanks for your help.

[LoRd_MuldeR]

I'm planning to put up a new package soon. Just busy with other projects and with real life stuff.

In the meantime: Replacing the x264 binaries manually should work just fine...

[stinman]

I'm planning to put up a new package soon. Just busy with other projects and with real life stuff.

In the meantime: Replacing the x264 binaries manually should work just fine...

I understand,your not getting paid or anything and you got things you must do.I always knew that a time would come,as it has.Why for me it will not read them.I just don't know.T really have followed the other guys instructions.

[kypec]

stinman, can you show us the content of your Simple Launcher directory? Start "cmd.exe" command line shell first. Then navigate to your Simple Launcher directory with cd command, for example:cd "C:\Program Files (x86)\AVTools\Simple x264 Launcher" When in that directory type dir command with its output redirected to some text file, like this:dir > mydir.txt Finally please post the contents of that file mydir.txt in this thread, preferrably embedded in the CODE tags.
I just can't believe that such simple process doesn't work for you...:eek:

EDIT:
I think I found the reason why the renamed x264 files fail for you ;)
After closer inspection of your screenshots I can see that you have configured your Windows Explorer to hide extensions of known file types.
This is a default setting and you can change it via Organize | Folder and search options | View tab > uncheck "Hide extensions for known file types".

http://i53.tinypic.com/30acoj4.jpg

You have clearly renamed the executable files to x264.exe.exe and x264_x64.exe.exe, just rename them again and leave out one redundant .exe part this time.:p

[stinman]

The thing you are failing to realize is,this tool does not install, it runs from a folder with all contents involved in that folder just like ripbot264 does,where ever it is.I chose to have mine in the Public documents folder,it works from there .The directory is this C:\Users\Public\Public Documents\Video Encoding tools\Simple x264 launcher. Last night I downloaded the new ripbot264 1.16.3.I copied both sets of x264 from that program's tools to this one and it worked.So now they are updated to r1732,but I don't know who's version Atak uses. I do know that Lord Mulder's, Komisars versions of x264 do not say x264.x86_64.exe they say x264.exe and x264_64.exe.
As far as the CMD,I couldn't do it with what you told me to do,I believe because it is not a installed program,installed to the program files.If I was real sharp with command line,I would just use the command line to encode with x264.:) I have Windows 7 Ultimate 64bit.
You can also get to the directory from the Libraries tab.This is what's in the directory folder,look at screen.
What do you mean by Start CMD.exe "command line shell first",I know about cmd and how to start it and with admin rights,but not command line shell first?

[stinman]

Finally got it to accept Komisars 1820 generic build,I did nothing different than before.It just worked this time.Thanks to you all for help!

[kypec]

What do you mean by Start CMD.exe "command line shell first",I know about cmd and how to start it and with admin rights,but not command line shell first?
Yes, by starting "cmd" I meant just what you did i.e. to run cmd.exe command line prompt where you can type all other operating system commands or launch other programs from (executables like .exe, .cmd, .bat).
No, I'm not failing to understand where or how did you install/unzipped Lord Mulder's Simple Launcher application. It doesn't really matter, the only thing important is that launcher.exe is looking for x264.exe & x264_x64.exe files which must be placed in the same directory as launcher.exe itself.
Did you read my notes below EDIT: in my previous post? I have clearly explained what was your problem -> HIDDEN FILE EXTENSIONS in your Windows Explorer window. When you was originally renaming x264.1804.generic.x86 to x264.exe you typed also the .exe extension explicitly but your Windows have appended also the original .exe there which lead to final filename being x264.exe.exe!
Finally got it to accept Komisars 1820 generic build,I did nothing different than before.It just worked this time.
You must have done something differently! I suppose you turned off HIDING EXTENSIONS FOR KNOWN FILE TYPES as I proposed and since that moment you can see full filenames properly and avoid such mistakes with doubled extensions when renaming or viewing directory contents.

[stinman]

I did do as you said,I just didn't come back and report everything I did.I all ready knew about the turning on and off file extensions.I never did name them with 2 .exe.exe at the end.I can say that the only thing I did different was to go back to the next release of x264,(can't remember which x264 release it was) after Lord Mulders Sept 6th and put it in the simple x264 launcher folder and it worked and then went to 1804 release and it also worked.I mean,not much to it but to take old out and put new in with the proper name.Everything is in the same folder so it should of worked.I'm glad it does now though!!

[LoRd_MuldeR]

Updated x264 binaries to r1834 (Komisar's builds) with FFmpgeSource v2.14.0.1.

[stinman]

Glad to see you back LoRd MuldeR,missed ya.I see a exe at the end of simple x264 launcher now.You changed it to a installed application now?

[kypec]

LM changed installer from ZIP/7Z to EXE back in September 2010 already. Anyway, that installer is actually just an unpacker, no registry or Windows configuration files are modified during the process. It just unpacks the files to (selectable) destination folder, that's all.

[LoRd_MuldeR]

Glad to see you back LoRd MuldeR,missed ya.I see a exe at the end of simple x264 launcher now.You changed it to a installed application now?

1. Didin't know I have been away :p

2. If you don't want to run the SFX (installer), then you can unzip the files manually with 7-Zip.

[me7]

I noticed that the GUI doesn't allow me to specify the --fps parameter myself. It says that it will do so itself if required. How safe is your method of detection and how can I know whether the framerate has been changed by the GUI?

[LoRd_MuldeR]

I noticed that the GUI doesn't allow me to specify the --fps parameter myself. It says that it will do so itself if required. How safe is your method of detection and how can I know whether the framerate has been changed by the GUI?

It will set the frame-rate reported by Avisynth/AVS2YUV. That is required, because when piping in the video as "raw" data, x264 can't know the FPS (and would always assume 25 fps, unless we specify explicitely). You can use AssumeFPS() or ChangeFPS() in your AVS script, if required.

[me7]

Since ffmpegsource is sometimes wrong about the framerate (current example: Watchmen Motion Comic from BluRay) and AssumeFPS() and ChangeFPS() have problems with non-integer values (they turn 24000/1001 into 23 AFAIK) I usually used x264 to correct the framerate. Maybe this warrants the option for the user to specify the framerate by himself?

[LoRd_MuldeR]

Since ffmpegsource is sometimes wrong about the framerate (current example: Watchmen Motion Comic from BluRay) and AssumeFPS() and ChangeFPS() have problems with non-integer values (they turn 24000/1001 into 23 AFAIK) I usually used x264 to correct the framerate. Maybe this warrants the option for the user to specify the framerate by himself?

Maybe the GUI could be changed in a future version to only insert "--fps <fps reported by AVS>" if the user has not specified "--fps" explicitely.

[Didée]

AssumeFPS() and ChangeFPS() have problems with non-integer values (they turn 24000/1001 into 23 AFAIK)
Sorry, but that's your fault, not that of those filters. :)
24000/1001 is [integer]/[integer], so the result is an integer, too. You must write at least one of those numbers as float, then the result will be float, too.

AssumeFPS( 24000/1001.0 ) # integer/float = [float]

or (preferred)

AssumeFPS( 24000, 1001 ) # numerator,denominator (division is handled internally)

[me7]

Sorry, but that's your fault, not that of those filters. :)
24000/1001 is [integer]/[integer], so the result is an integer, too. You must write at least one of those numbers as float, then the result will be float, too.

AssumeFPS( 24000/1001.0 ) # integer/float = [float]

or (preferred)

AssumeFPS( 24000, 1001 ) # numerator,denominator (division is handled internally)

I see, my bad. Thanks for the thorough explanation :)

[djesteban]

Hey LoRd_MuldeR,

Since we now have a 64bit build of Avisynth 2.5.8, are you planning to release a version of your x264 launcher that goes directly through avisynth x64, then to x264 x64??
Would be awesome!! I really like this simple GUI :)

Cheers

[LoRd_MuldeR]

Updated x264 binaries to r1900 (Komisar's builds) with FFmpgeSource v2.14.2.0.

[laserfan]

LM, I borrowed your command line for my own batchfile usage (I don't use yr GUI :o but thanks) and have been fiddling with W7's resmon.exe (Resource Monitor) which allows for Suspend of running tasks.

I notice that when your app Suspends, it does so for all of avs2yuv, x264_x64, and pipebuf. I've done (very limited) testing that suggests I can use resmon to suspend just the x264 process, and it seems to work.

Do you have experience/knowledge that suspending x264_x64 alone can get me into trouble? If you recommend suspending all 3, is there a sequence I should use to suspend them?

In case it's not clear, I don't know how these work together (only that they do, thanks again!). :)

[dansus]

Trying to force --fps 30000/1001 but the GUI says no..

Without this setting, output is ~ ffms [info]: 1440x1080i 0:1 @ 60030/1001 fps (vfr) ~ which is x2 the deinterlaced fps.

[LoRd_MuldeR]

LM, I borrowed your command line for my own batchfile usage (I don't use yr GUI :o but thanks) and have been fiddling with W7's resmon.exe (Resource Monitor) which allows for Suspend of running tasks.

I notice that when your app Suspends, it does so for all of avs2yuv, x264_x64, and pipebuf. I've done (very limited) testing that suggests I can use resmon to suspend just the x264 process, and it seems to work.

Do you have experience/knowledge that suspending x264_x64 alone can get me into trouble? If you recommend suspending all 3, is there a sequence I should use to suspend them?

In case it's not clear, I don't know how these work together (only that they do, thanks again!). :)

Sure, suspending only x264_x64.exe should work too.

As soon as x264 stops reading data from the pipe, the pipe buffer will run full very soon. Then the next write operation of avs2yuv.exe will block, which effectively suspends avs2yuv.exe too.

Finally when x264_64.exe resumes, it will start reading data from the pipe buffer again, so the OS can unblock/resume avs2yuv.exe at this moment and complete the pending write...


Trying to force --fps 30000/1001 but the GUI says no..

Without this setting, output is ~ ffms [info]: 1440x1080i 0:1 @ 60030/1001 fps (vfr) ~ which is x2 the deinterlaced fps.

This GUI was mainly designed to use 64-Bit x264 with 32-Bit Avisynth.

As this requires passing the input data to x264 through a pipe, the GUI has to set the "--fps" option. x264 can't know the FPS for input from STDIN, so it would always assume 25 fps.

Therefore the GUI will detect the proper frame rate from the input Avisynth script and then pass that frame rate to x264 via "--fps" option. Thus settings "--fps" manually isn't intended.

(However I see that is might be desirable, at least when using x264's "native" FFMS2 input. In Avisynth you could always use 'AssumeFPS()' instead)

[laserfan]

Sure, suspending only x264_x64.exe should work too...
Thank you kindly sir! Once again you've made a thorough explanation, and I appreciate it.
:thanks:

[stinman]

Thanks for the latest release!

[Lighto]

Any chance of adding a shutdown when done and batch/queue function?:p

[LoRd_MuldeR]

Any chance of adding a shutdown when done and batch/queue function?:p

Not currently planned.

[Temuthril]

I was low on free memory and wasn't really expecting the encoding to start, but is the following error message intended? After clicking yes (the left one) there was a malloc failed error message from x264.

http://dl.dropbox.com/u/13680560/launcherbug.jpg

x264 settings were preset veryslow, tune film, crf 21.

Avs file contents, if relevant:
LoadPlugin("C:\Plugins\rawsource_25_dll_20060728\rawsource.dll")
RawSource("G:\Video test\1080i25_stockholm_ter.yuv",1920,1080,"YV12")
Trim(1,250)
TDeint()
Crop(16,0,0,0)
FFT3DGPU(mode=1, precision=2)
Spline36Resize(1270,720)

[LoRd_MuldeR]

First of all: This error message does NOT originate from my GUI, but from Avisynth or the affected Avisynth Plugin.

Also the error message is quite clear: You obviously are out of memory! And therefore it's not surprising at all that the next malloc() in x264 will fail ;)

In contrast to many Avisynth plugins, all malloc's in x264 are checked. So if the malloc() in x264 fails, it will throw an error message...

(BTW: Limiting the memory used for caches by calling SetMemoryMax() in your AVS script might help to avoid 'out of memory' errors with Avsynth)

[Temuthril]

Thanks for the explanation, was just thinking if it could be the first case you mentioned.

[stinman]

will you be updating again to latest version of x264.I have tried like the last time to use komiars latest builds and no luck.I guess maybe ffmpeg or something else has to be updated also.

[LoRd_MuldeR]

will you be updating again to latest version of x264.I have tried like the last time to use komiars latest builds and no luck.I guess maybe ffmpeg or something else has to be updated also.

As explained earlier, you can update the 'x264.exe' or 'x264_x64.exe' file yourself. No change to the GUI will be required!

If you are using a build of x264 with FFMS2 (FFmpegSource) support enabled, then FFmpeg/libavcodec is already "built-in" in the EXE file.

And yes, Komisar's builds do have FFMS2 support enabled. Anyway, it's probably time to make an updated package, so here we go ;)

[dispatcher7007]

Testfile was a 1minute-extract of a BD which had the highest bitrate of the complete film.


Source: G:\Tests\hohe Komplexität\title00 (1)-134 (1) temp files\z nur für avs.avs
Preset: Medium
Tuning: None
Profile: High
Params:

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 1459 frames, 12.30 fps, 4124.29 kb/s
encoded 1459 frames, 12.34 fps, 4124.29 kb/s
encoded 1459 frames, 12.30 fps, 4124.29 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 1459 frames, 10.98 fps, 4124.29 kb/s
encoded 1459 frames, 11.32 fps, 4124.29 kb/s
encoded 1459 frames, 11.30 fps, 4124.29 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 1459 frames, 12.93 fps, 4124.29 kb/s
encoded 1459 frames, 11.40 fps, 4124.29 kb/s
encoded 1459 frames, 11.47 fps, 4124.29 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 1459 frames, 11.51 fps, 4124.29 kb/s
encoded 1459 frames, 13.01 fps, 4124.29 kb/s
encoded 1459 frames, 13.01 fps, 4124.29 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 1459 frames, 11.57 fps, 4124.29 kb/s
encoded 1459 frames, 13.09 fps, 4124.29 kb/s
encoded 1459 frames, 13.09 fps, 4124.29 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 1459 frames, 13.08 fps, 4124.29 kb/s
encoded 1459 frames, 13.09 fps, 4124.29 kb/s



The .avs was a script created by staxrip with all filters, but autocrop disabled. I haven't got used to writing avisynth-scripts manually, so this was the easiest way for me. I don't think it should have much of an impact on the results.

The script was:

LoadPlugin("E:\Software\DVD rippen\StaxRip\Applications\AviSynth plugins\ffms2\ffms2.dll")
FFVideoSource("G:\Tests\hohe Komplexität\title00 (1)-134 (1).mkv", cachefile="G:\Tests\hohe Komplexität\title00 (1)-134 (1) temp files\title00 (1)-134 (1).ffindex")
AssumeFPS(23.976)
Crop(0,0, -Width % 8,-Height % 8)
ConvertToYV12()
Crop(0,132,-0,-132)


I'm slightly disappointed about the 64bit performance, because I expected more than the 6,5% improvement.

Is it possible to speed it up further by having the complete process chain set up in 64 bit?

What parts are all needed for this? are ffdshow 64, avisynth 64 and x264 64 all, or did I miss anything?

[LoRd_MuldeR]

I'm slightly disappointed about the 64bit performance, because I expected more than the 6,5% improvement.

Is it possible to speed it up further by having the complete process chain set up in 64 bit?

What parts are all needed for this? are ffdshow 64, avisynth 64 and x264 64 all, or did I miss anything?

Essentially 64-Bit x264 is all you need. With its "built-in" FFMS2 support, x264 handles most input alone.

64-Bit Avisynth is required only, if you want to use Avisynth input with a 64-Bit build of x264 directly (i.e. not via avs2yuv).

64-Bit FFdshow would only be relevant, if you did use DirectShowSource() or DSS2() in your AVS script - under a 64-Bit Avisynth.

And of course with 64-Bit Avisynth all your Avisynth plug-in's must be 64-Bit. You can't use 32-Bit plug-in's with 64-Bit Avisyth.

[stinman]

yeaaa!! Thanks for update!!. It seems after the x264 codec gets a few updates ahead of your last update here, it will not recognize the newest Komisar's files.It always say's "x264_x64.exe not found in the directory". Maybe it's just my windows 7 ultimate, or me, but I can make it work a few updates ahead but not way ahead like the last one I tried r1900 to r2008 all from Komisar's because I figured it had to be this set of x264 because this is what you use.Sorry if I seem dumb to you LoRd_MuldeR,I'm not, I have followed the directions to the exact as laid out to me in this forum to do it.
I want to learn to use the command line for x264.I know basic in's and out of cmd. Could I look at the log files of simple x264 launcher and see the commands, then copy them to cmd? Thanks again for the update!!

[LoRd_MuldeR]

yeaaa!! Thanks for update!!. It seems after the x264 codec gets a few updates ahead of your last update here, it will not recognize the newest Komisar's files.

Definitely not ;)

I have no idea what was wrong, but you certainly can replace an older 'x264_x64.exe' with a newer version without modifying/updating the GUI program.

The GUI program would only need updates, if the x264 CLI syntax was changed in a way that breaks compatibility. But that did not happen...

[dispatcher7007]

what buffersize is it using, when you dont run the benchmark?

[LoRd_MuldeR]

what buffersize is it using, when you dont run the benchmark?

4 Megabyte

[Rodger]

I remember it was 1MB

[LoRd_MuldeR]

I remember it was 1MB

Then you remember wrong. Look at the source code! If my eyes don't fool me, then it's 4 MB ;)

[MajorX]

@LoRd_MuldeR
can u add a custom setting option so that we can change x264 parameters like ref, me_range, rc_lookahead, bframes etc.

[LoRd_MuldeR]

@LoRd_MuldeR
can u add a custom setting option so that we can change x264 parameters like ref, me_range, rc_lookahead, bframes etc.

No I can't. Because it is already there :p

http://img696.imageshack.us/img696/8918/customoptions.png

[MajorX]

No I can't. Because it is already there :p

http://img696.imageshack.us/img696/8918/customoptions.png
Oh yeah, now i can use custom parameters, thanks. :)

Edit:when i use --subme 10 it always encode with --subme 9 not 10 why?
(i use 10-bit x264)

[LoRd_MuldeR]

Oh yeah, now i can use custom parameters, thanks. :)

Edit:when i use --subme 10 it always encode with --subme 9 not 10 why?
(i use 10-bit x264)

SubME > 9 requires (Trellis == 2) && (AQ != 0). I guess that at least one of these conditions doesn't hold true for your settings.

I would recommend to NOT tweak such options manually (unless you have a very good reason to do so), but use the preset system instead!

SubME 10 is enabled in "veryslow" preset. Of course that presets contains all options required for SubME 10 to work...

[MajorX]

can it possible to use subme 10 with trellis= 2 & aq=2:0.60? i use slow preset.

[LoRd_MuldeR]

can it possible to use subme 10 with trellis=2 & aq=2:0.60?

Sure.

i use slow preset.

Time to upgrade to "veryslow", if you want SubME 10. If "veryslow" is too slow for you, then go with the SubME mode that "slow" uses.

[egrimisu]

hi lord,
can i use a 10bit x264 with the laucher as i use the 8bit one? does the 10bit preset profiles have the same config as the 8bit one? thanks.

[LoRd_MuldeR]

hi lord,
can i use a 10bit x264 with the laucher as i use the 8bit one? does the 10bit preset profiles have the same config as the 8bit one? thanks.

10-Bit is a compile-time option. So you will have to replace the x264 binary(ies) with 10-Bit build(s). That's all.

AFAIK there are no bitness-specific CLI options in x264...

[naoan]

any plan to have simple preset option? and uh, batch...

[LoRd_MuldeR]

any plan to have simple preset option?

Support for Presets (and Tunings) has already been implemented long ago :confused:

and uh, batch...

Not planned, sorry.

[MajorX]

Any Update?

[LoRd_MuldeR]

There's nothing that would require an update at the moment, I think. You can update your x264 independent from the GUI...

[the_weirdo]

There's nothing that would require an update at the moment, I think. You can update your x264 independent from the GUI...

Actually, I think you should update avs2yuv to this version (http://forum.doom9.org/showthread.php?p=1527698#post1527698). But users can also update it themself, of course.

[LoRd_MuldeR]

Actually, I think you should update avs2yuv to this version (http://forum.doom9.org/showthread.php?p=1527698#post1527698). But users can also update it themself, of course.

Will have a look at that one...

:thanks:

[LoRd_MuldeR]

I have uploaded a new package:

x264 has been updated to r2106 and avs2yuv has been updated v0.24bm2.

[kypec]

When I updated my x264 binaries to komisar's build revision 2120 Launcher refuses to show help screen dialog after Show Help Screen click. Only error message pops up "Sorry, failed to generate the help screen!"
I can't understand what could go wrong as I've been updating x264 binaries myself many times before without problems so I know what to do and how to do it (rename executable to x264.exe and x264_x64.exe respectively)...
Has anything changed in console output of x264 since r2106 recently? :confused:

[Nevilne]

I'm not sure, but even
"apps\x264komisar.exe" --fullhelp > x264.txt

crashes on 21kb :o

Haven't used his builds for long time tho so not sure if it's recent stuff.

[komisar]

first build is buggy... sorry. i'm update it with patch http://privatepaste.com/c943123095 ... this is ffmpeg fault

[kypec]

:thanks: a lot! You're the man, komisar :)

[LoRd_MuldeR]

komisar, any chance you update the "x264 libpack" on your site? Latest x264 doesn't like the FFMS2 included in your current pack.

:thanks:

[stinman]

What now? Last post is Dec 7th- are things fixed now? Can we add new x264 builds to the simple x264 launcher
May I ask what are the difference from komisar x264 and darkshikari x264 or jeeb... and why you choose komisar builds? Just wondering and learning. Thanks.

[LoRd_MuldeR]

You can always update x264.exe and x264_x64.exe with the build of your choice, as long as the CLI syntax hasn't changed - which did not happen recently.

Builds by different people mostly differ which GCC version was used to build and by the versions of the "third-party" libs (libavcodec, libavformat, FFMS2, etc) included.

Some builds may also include new/experimental patches. Usually this will be noted...

[aufkrawall]

Is there a way to manually define FPS?
When I try --fps command it tells me that *it* would define it if needed but it's doing something wrong. ;)
According to MediaInfo the output has 1.500 fps, but input file has 30.
I'd like to define an output file with 30 fps.

[LoRd_MuldeR]

This GUI was mainly written to allow encoding with 64-Bit x264 from a 32-Bit Avisynth.

For this reason we use a 32-Bit 'avs2yuv' instance to read the AVS script and then pipe over the "raw" data to the 64-Bit 'x264' process.

Of course x264 can't know the frame rate of the original source in this case. So the GUI will set the appropriate "--fps" for you.

(Now it should be obvious why we can't allow the user to specify "--fps" itself)

[aufkrawall]

(Now it should be obvious why we can't allow the user to specify "--fps" itself)
It is now, thank you. :)
But it's odd: The result is played with 30 fps but MediaInfo says 1.5.
I can remuxe it and define 30 fps, but I'd like to save this stepp.

The input is Fraps RGB, btw.

Is there really no way to force x264 via GUI to write 30 fps into the file info?
It's just a bureaucratic issue, not a technical one.

[LoRd_MuldeR]

If your input is from an Avisynth script, I would recommend to use AssumeFPS() or ChangeFPS(), whatever is the suitable one.

(The former just "overwrites" the FPS value, but does not add or remove any frames. The latter actually converts the FPS, by duplicating/skipping frames as needed)

If you don't use Avisynth input yet, make a simple text file (input.avs) and put the following content in:

FFVideoSource("C:\Path to your input\source.avi")
AssumeFPS(25.0) #could also put ChangeFPS(25.0) at this place

(Make sure you have Avisynth (http://sourceforge.net/projects/avisynth2/files/AviSynth%202.5/) and the FFMS2 (http://code.google.com/p/ffmpegsource/downloads/list) plug-in installed for this to work)

[aufkrawall]

Somehow it fails with "Analyzing the source video".
I just copied the ffms plug-in into the the plugins folder, is this correct?

But it's really not urgent. I have to use some merging tool anyway to merge the splitted Fraps avi files and while this I can specify FPS afterwards.

Btw: Your Simple x264 Launcher seems to be the only x264 converter with GUI that correctly encodes Fraps RGB videos to x264 I444/RGB. :thanks:
All other tools fail, colors aren't right etc.

Edit: One more question: Why is --tune forbidden?

[LoRd_MuldeR]

Somehow it fails with "Analyzing the source video".

Try to open your AVS script in VirtualDub and see what happens...

I just copied the ffms plug-in into the the plugins folder, is this correct?

If you mean the Avisynth plug-in folder, then you did right.[/QUOTE]

But it's really not urgent. I have to use some merging tool anyway to merge the splitted Fraps avi files and while this I can specify FPS afterwards.

Btw: Your Simple x264 Launcher seems to be the only x264 converter with GUI that correctly encodes Fraps RGB videos to x264 I444/RGB. :thanks:
All other tools fail, colors aren't right etc.

That's not a feature of the GUI. In fact it should work with any x264 GUI, given it is used with an up-to-date x264 binary that has FFMS2 enabled.

Edit: One more question: Why is --tune forbidden?

...because there is a combo box for this option in the GUI. Setting "--tune" twice would be pointless ;)

[aufkrawall]

Try to open your AVS script in VirtualDub and see what happens...

It gives unknown import filter error with code 80040154.


That's not a feature of the GUI. In fact it should work with any x264 GUI, given it is used with an up-to-date x264 binary that has FFMS2 enabled.

They always mess around with color spaces.
Either they allow only YUV12/I420, they change it without saying, they use only I420 or they mess it up in some other way.
Either I use a GUI because it makes things easier or I don't use it at all and learn x264 CLI or AviSynth.
Your program simply works, it decodes flawlessly in RGB mode and converts it to the chosen CS without mess.
I just wished there would be a GUI option for the 10bit x264 version. Would be very easy to implement. :)
Btw: The x264 version which is delivered by the current version of your program doesn't accept --range pc.


...because there is a combo box for this option in the GUI. Setting "--tune" twice would be pointless ;)
Oops.
Hm, when using --tune fastdecode it simply seems to be --no cabac, at least when using crf 0.
The problem with x264 RGB is its high CPU usage. Best compromise of decoding speed and compression seems to be placebo preset and no cabac.

[LoRd_MuldeR]

According to the x264 manpage, the "fastdecode" tuning does exactly the following:

--no-cabac --no-deblock --no-weightb --weightp 0

Though, AFAIK, the lossless mode doesn't use B-Frames anyway and Deblocking also is irrelevant in that case.

[aufkrawall]

Though, AFAIK, the lossless mode doesn't use B-Frames anyway and Deblocking also is irrelevant in that case.
That it must be, the file size doesn't even differ by one KB between festdecode and no cabac.

Uhm, the following may be a bit OT ;) , I hope it's ok though:
Do you know if/when compatibility for 10bit RGB of x264 could be realized?
It could dramatically help to reduce bitrate and so decoding power.

[LoRd_MuldeR]

Do you know if/when compatibility for 10bit RGB of x264 could be realized?

I don't understand this question. x264 does support RGB encoding as well as 10-Bit encoding.

It could dramatically help to reduce bitrate and so decoding power.

If you refer to 10-Bit encoding here, then 10-bit encoding indeed does improve the compression efficiency (i.e. the "quality per bit" ratio), compared to 8-Bit.

However 10-Bit is significant slower at both, encoding and decoding. After all using "only" 8-Bit is nothing but a speed-up trick ;)

(Also hardware support for 10-Bit H.264 is pretty much none-existing. Well, the same applies to H.264 RGB mode, i.e. "High 4:4:4" Profile)

[aufkrawall]

I don't understand this question. x264 does support RGB encoding as well as 10-Bit encoding.

But not both at a time, 10bit version supports only I444 colorspace (and lower).


If you refer to 10-Bit encoding here, then 10-bit encoding indeed does improve the compression efficiency (i.e. the "quality per bit" ratio), compared to 8-Bit.

However 10-Bit is significant slower at both, encoding and decoding. After all using "only" 8-Bit is nothing but a speed-up trick ;)

With some earlier tests I couldn't play I444 8bit crf 0 smoothly, but now it does (I must have made some mistakes in the past).
But CPU usage is not lower than with 10bit, must be because bitrate is 80mbit/s lower with 10bit.


(Also hardware support for 10-Bit H.264 is pretty much none-existing. Well, the same applies to H.264 RGB mode, i.e. "High 4:4:4" Profile)
Yey, it's only usable with PCs, and only with correctly configured ones.
And of course only with enough powerful ones. ;)
I wonder if x264 RGB crf 0 with preset placebo can be played smoothly on a 4.5Ghz Sandy Bridgy i7. :D

[honza567]

Hi,

firstly I want to say, that the Simple x264 luncher is the best x264 encoder tool I ever met, becouse of his easy update for a new x264 version and low requirments to RAM and last but not least open all x264 settings.


I know that my question is silly, but I spent too much to done it just by myself and without success.

I can´t change resolution of output file.

Even I tried to use "Show help screen."

resize:[width,height][,sar][,fittobox][,csp][,method] - This fine, but I still must put some mistakes into, when it didn´t work. Even when I thought that units are filled rigthly. ... Or can I miss any of those inner parameters?

Should be "--" before this.. or should I prezerve "[]" or commas?

Let´s say for example. We need to get:
width 320,
height 320
sar is: 1 here (I suppose)
fittobox... I don´t know. Let´s use some recommended
csp: again I don´t know which one. Let´s use some recommended
method: spline

Could you write me what exactly to write into CLI (Custom parameters x264) for change resolution?

Thanks a lot

[aufkrawall]

Could you write me what exactly to write into CLI (Custom parameters x264) for change resolution?

Try something like this:
"--video-filter resize:width=1920,height=1080"
Some more info:
http://mewiki.project357.com/wiki/X264_Settings#resize

[Temuthril]

--video-filter resize:320,320,1:1,method=spline

[honza567]

Ouch. It works even with modifications

Thanks a lot guys

... Another my IQ test fail. :D :p

[komisar]

komisar, any chance you update the "x264 libpack" on your site? Latest x264 doesn't like the FFMS2 included in your current pack.
Sorry for the delay... Libpacks updated 2012-01-19

[LoRd_MuldeR]

Sorry for the delay... Libpacks updated 2012-01-19

Great :thanks:

[donfrenchiano]

Has anyone been able to get the 64bit to work under wine in linux? If i do everything from the command line it seems to work fine but the gui gives me an error, something like it can't get normal handles. The gui works fine if i run it in a 32bit environment.

[LoRd_MuldeR]

Has anyone been able to get the 64bit to work under wine in linux? If i do everything from the command line it seems to work fine but the gui gives me an error, something like it can't get normal handles. The gui works fine if i run it in a 32bit environment.

This software was never written to run under Wine. It may work or not, I have no idea.

Anyway, running under Wine only makes sense, if you need Avisynth, because there is no native Avisynth port for Linux.

But then you should run only Avisynth/AVS2YUV under Wine. Pipe the output to a native Linux x264 from there!

(The simple x264 launcher cannot do this)

[darknoob]

First off thanks for the GUI lord it works great. My question is regarding the first pass log info. I use the two pass method with placebo preset, the first pass log does appear briefly before the second pass starts, but its for like 2 seconds, and I don't see it saved anywhere. I would like to see that final rate factor number to verify my compressibility on the first pass. Lord is there a cmd I can use to get this?

thanks

[LoRd_MuldeR]

My simple x264 launcher currently does not retain detailed information of the first of a 2-Pass encode. Sorry.

(The "2-Pass report" only includes a quick "one line" summary of the first pass)

[LoRd_MuldeR]

Here is an all new but experimental(!) version of the "Simple x264 Launcher" application:

http://img17.imageshack.us/img17/6384/simplex264launcher64bit.th.png (http://img17.imageshack.us/img17/6384/simplex264launcher64bit.png)

Be aware that this really is an early version! But I hope that this will develop into something useful ;)

[MajorX]

Thanks LoRd_MuldeR. :)
I will try this new version of x264 Launcher.

Edit: Please help i got this error when i try to open x264 Launcher.

http://img831.imageshack.us/img831/3561/errorwr.jpg

[LoRd_MuldeR]

Hmm, Google says the code 0xC0000409 refers to a STATUS_STACK_BUFFER_OVERRUN.

Smells like we have an infinite recursion somewhere :eek:

I need some more details. Does that crash happen before the main window becomes visible ???

Cannot reproduce on my Windows XP machine

[LoRd_MuldeR]

Here is a slightly updated version: 2-Pass encoding should now be working.

[MajorX]

Thanks new version works fine. :)

------------------------
------------------------
Can't Paste x264 Parameters in Custom x264 Parameters field.

It doesn't remember previous settings [Input/Output Folder + Encode Settings]

CRF encoding is not working...if i set CRF it automaticaly encode in CQ mode.

If i add 3+ jobs in queue....can u add some option in right click so we can disable a job, can remove completed jobs etc.

When open input file can please set File of Types as Supported Files.
-----------------------------
-----------------------------

[LoRd_MuldeR]

Thanks new version works fine. :)

That's a bit strange, because I haven't changed anything in the early initialization code that could/should have effected your problem :confused:

About your other remarks:

This is an unpolished "preview" version, so I will have a look at those feature requests once all the "core" stuff is working...

[LoRd_MuldeR]

This version should fix some of your issues.

[ganymede]

@LoRd_MuldeR : I just tried your new experimental version in CRF mode, and it just worked fine, thank you.

[LoRd_MuldeR]

Here is a new improved build:

http://img16.imageshack.us/img16/5655/addjob20120131223913.th.png (http://img16.imageshack.us/img16/5655/addjob20120131223913.png)

Most things should be working now ;)

[MajorX]

Thanks LoRd_MuldeR.

-----------------------
-----------------------
It doesn't remember previous settings [Input/Output Folder(When i close x264 Launcher, it reset Input/Output Folder to My Video Folder) + Encode Settings(like custom x264 Parameters)]

With job column can u add another column for showing the Mode type like 2-Pass or CRF while encoding + A numbering column for jobs.

In old version i can pause and resume my jobs...so can u add this feature in x264 Launcher v2.

-------------------------
-------------------------


Edit: Got this error,
Job started at 2012-02-01, 13:37:49.

Source file: C:/Documents and Settings/H/Desktop/Sample.avs
Output file: C:/Documents and Settings/H/Desktop/Sample.mkv

--- SETTINGS ---

RC Mode: 2-Pass
Preset: Veryslow
Tuning: Animation
Profile: High
Custom: --bframes 5 --ref 10 --me umh --scenecut 40 --nr 460 --level 5.1 --aq-mode 3 --aq-strength 0.5 --psy-rd 0.00 --rc-lookahead 50 --subme 10 --merange 24 --partitions all --keyint 300 --min-keyint 25 --no-fast-pskip

--- CHECK VERSION ---

Creating process:
"C:/Program Files/MuldeR/Simple x264 Launcher v2/toolset/x264.exe" --version

x264 0.120.2148+631+27 a892bde tMod [10-bit@all X86]
(libswscale 2.1.0)
(libavformat 53.19.0)
(ffmpegsource 2.16.4.0)
built on Jan 19 2012, gcc: 4.6.2
configuration: --bit-depth=10 --chroma-format=all
x264 license: Non-Free
libswscale/libavformat/ffmpegsource license: nonfree and unredistributable
WARNING: This binary is unredistributable!

FAILED TO DETERMINE X264 VERSION !!!

but perfectly work with old version x264 Launcher.

[LoRd_MuldeR]

It doesn't remember previous settings

You can choose "<Recently Used>" to use the last used settings (selected by default).

And you can save your settings to a custom template in order to keep them when the application is terminated.

Edit: Got this error
x264 0.120.2148+631+27 a892bde tMod [10-bit@all X86]

Seems like you use an x264 binary with custom modifications that prevent the version string from being parsed properly...

[LoRd_MuldeR]

The "Pause" button has returned:

http://img836.imageshack.us/img836/6384/simplex264launcher64bit.th.png (http://img836.imageshack.us/img836/6384/simplex264launcher64bit.png)

[reff24]

Hy nice program. Should there still be a feature where you can immediately add to the soundtrack?

[MajorX]

Thanks LoRd_MuldeR. :)

-----------------------
-----------------------
And you can save your settings to a custom template in order to keep them when the application is terminated.
It only remember my encoding setting but not Input/Output Folder(When i close x264 Launcher, it reset Input/Output Folder to My Video Folder)

With job column can u add another column for showing the Mode type like 2-Pass or CRF while encoding.

Any planning to add custom audio encoding feature.

Can i hide the debug console.
-------------------------
-------------------------

[naoan]

Finally batch and template support, thank you veru much LoRd_MuldeR! :D

And imo this is good enough for me, adding audio muxer or encoder wouldn't make this program "simple" or "x264 launcher" anymore, but that's up to LoRd_MuldeR to decide.

[LoRd_MuldeR]

This is a simple front-end to x264. And as x264 does not process audio (yet), there is no way to encode audio directly.

Adding "audio processing" support would mean we need to: Demux the source audio, encode the demuxed audio and finally mux together the encoded video+audio.

Obviously that would require much more tools to be involved and it would make everything a lot more complicated/nasty, so I probably won't add that soon (if at all ^^).

BTW: You can hide the console with "--no-console" switch. And you can simply add that switch to a shortcut, if you want to use it permanently.

Also, all encoding parameters are shown in the log file, at the very top...

[MajorX]

And you can save your settings to a custom template in order to keep them when the application is terminated.
It only remember my encoding setting but not Input/Output Folder(When i close x264 Launcher, it reset Input/Output Folder to My Video Folder)

pls can you tell me how can i fix this?

Is it possible to add another column for showing the Mode type like 2-Pass or CRF for each job while encoding?.. cuz when i add 20+ jobs with different setting, it's little bit difficult know the encoding mode of each file.

Thanks.

[LoRd_MuldeR]

It only remember my encoding setting but not Input/Output Folder(When i close x264 Launcher, it reset Input/Output Folder to My Video Folder)

pls can you tell me how can i fix this?

Write the code to save/restore the last folder yourself. Or be patient until I have done so :)

(Will probably be done soon)

Is it possible to add another column for showing the Mode type like 2-Pass or CRF for each job while encoding?.. cuz when i add 20+ jobs with different setting, it's little bit difficult know the encoding mode of each file.

Would be possible indeed. But I'm not quite sure it will aid the clearness of the UI...

BTW: You can already distinguish between 2-Pass and single-pass modes, because only 2-Pass will ever show "Running... (Pass 1/2)" as status.

[stranno]

I love the new design, great work. Keep it up :D

[icon]

Very nice job on the front end. I think I'm going to give this a try. Coming from using a simple all-in-one approach, line handbrake, what is your recommended steps/programs from going to bd rip to mkv? I would like to have x264 video with either dts or ac3 audio, non-encoded. I would guess to use tsmuxer??? for demux, eac3to for audio, this program for video :), and mkvmerge for muxing. Any thoughts? Thanks.

[LoRd_MuldeR]

If you don't need to re-encode the audio, you can simply mux-in the original audio stream with either MKVToolNix/MKVMergeGUI or MP4Box/Yamb, depending on what container format you have chosen.

[reff24]

I hope they think about it again and add the feature. As with AutoMKV and so on. That would make the program interesting for more users.

I'd like but now for the good and easy-to-use program with thank you. And I hope the development continues.

[LoRd_MuldeR]

Some improvements:
* Added Drag&Drop support
* Added menu entry to delete a job
* Added preferences dialog
* Will remember last source/output folders now
* Be less picky about x264 version string

[icon]

If you don't need to re-encode the audio, you can simply mux-in the original audio stream with either MKVToolNix/MKVMergeGUI or MP4Box/Yamb, depending on what container format you have chosen.

mkv
don't need to re-encode audio, but I do want to get rid of HD audio, i.e. dts-hd to dts
what is the best way to demux and convert audio (eac3to).

I created some good scripts to convert dts to ac3 using eac3to and mkvmerge to remux. Maybe I can do something similar to de/mux.

Trying your new version now, thanks!

[reff24]

thanks for the good work

[LoRd_MuldeR]

Added option to shutdown computer when the encode is done. Also added option to control the maximum number of jobs to run in parallel.

[MajorX]

Thanks LoRd_MuldeR :)
Can u add uninstall & create shortcut to desktop option in setup file?

Edit:
Can not use crf value like 23.5, 24 .8....it only take 23 or 24 but i can use value like 23.5 in old version..can plz fix this.

Thanks.

[iregados]

Hello Mulder,

First thanks for your work, this app is fantastic!

I want to know if you plan to put on GUI some option to add subtitle or we'll still have to use the avs file to do it?

Keep the good work man!

[LoRd_MuldeR]

Can u add uninstall & create shortcut to desktop option in setup file?

In order to run the Uninstaller, simply use right-click + "Delete" on the folder where you have extracted the files to. That's it :p

(After all, the "installer" is nothing but a dumb SFX archive. I "misused" NSIS' zip2exe scripts for that purpose)

Can not use crf value like 23.5, 24 .8....it only take 23 or 24 but i can use value like 23.5 in old version..can plz fix this.

Yes, that should be easy to do.

I want to know if you plan to put on GUI some option to add subtitle or we'll still have to use the avs file to do it?

That's out of the scope of x264. If you want "soft" subtitles, you have to mux them after the encode, just like the audio.

If you can accept "hard" subtitles, you may add these in your Avisynth script. But I generally wouldn't use "hard" subtitles these days...

[LoRd_MuldeR]

Here is an updated version that should support fractional CRF values.

[MajorX]

Thanks LoRd_MuldeR :)
I create a template...now i do some changes in x264 parameters and i want to save these changes in that template..so how can i overwrite an existing template.

[LoRd_MuldeR]

You can't "change" a template in the GUI yet. If you don't want to save to a new name, you will have to delete the old/existing one first.

Well, if you really have to, you could still modify the template by editing the INI file, which should be straight forward to do...

[UPDATE]

This updated version allows you to overwrite an existing template.

(Just save to the name of an existing template and you will be asked to overwrite the old template)

[icon]

Your'e on fire, thanks! Working very well.

Maybe one possible small suggestion - add a horizontal scroller to go along with the vertical one.

Another question - What avs gui would you guys recommend? I'm using MeGUI's avs editior mainly for the autocrop feature. Any suggestions? Thanks

[LoRd_MuldeR]

Maybe one possible small suggestion - add a horizontal scroller to go along with the verticle one.

I don't like that idea :p

But you can hover the mouse over a line that is too long to fit in horizontally. The "tooltip" will show the complete line.

Furthermore you can copy the complete to the clipboard by using the context-menu.

Another question - What avs gui would guys recomend? I'm using MeGUI's avs editior mainly for the autocrop feature. Any suggestions? Thanks

That question is off-topic here. You will find various Avisynth editors (GUI's) in the Avisynth section of this forum.

BTW: Perosnally I use Notepad++ ;)

[stranno]

I'm trying to change the output file (from mkv to 264) but it doesnt work. Lastest version

It only works if i manually add the extension .264 in the text box

[LoRd_MuldeR]

I'm trying to change the output file (from mkv to 264) but it doesnt work. Lastest version

It only works if i manually add the extension .264 in the text box

Confirmed and fixed.

[LoRd_MuldeR]

Added option to use 64-Bit Avisynth/Avs2YUV.

[stranno]

Yay!, thanks :-D

[LoRd_MuldeR]

Added a few GUI-side workarounds for the unfortunate lack of Unicode support in x264.

This is probably the best we can do, as long as my UTF-8 patch (or some better solution) doesn't get adopted into x264.

[reff24]

thanks for the good work.

Another feature will come to insert subtitle?

[iSeries]

Hi,

Trying this for the first time today, tried to enter the --qpfile switch in the command line but it wont let me, says 'invalid parameter entered'? Also can't seem to be able to input an m2ts file directly?

[LoRd_MuldeR]

Trying this for the first time today, tried to enter the --qpfile switch in the command line but it wont let me, says 'invalid parameter entered'?

Some parameters are forbidden, because the GUI will set them (if required). Though "--qpfile" is not one of those.

You probably have entered some other parameter that isn't allowed. Or you pasted a complete command-line that contained some forbidden parameter.



Sorry, the "--qpfile" option is blocked indeed. That's because it starts with "--qp", which is blocked intentionally ;)

I will try to implement a workaround for this situation...



Also can't seem to be able to input an m2ts file directly?

What exactly do you mean? Doesn't the GUI allow you to select the m2ts file or does the encode fail?

In the former case you simply have to change the file type filter to "All files" and you should be able to select a M2TS file just fine.

In the latter case I would recommend to use Avisynth+DGDecodeNV instead of built-in FFMS2 input.

(FFMS2 is able to deal with almost everything. Unfortunately MPEG Transport streams are one of the few exceptions...)

[LoRd_MuldeR]

Another feature will come to insert subtitle?

Nope. Unless x264 suddenly got a parameter to mux in subtitles "on the fly" this is not possible ;)

Either create "hard" subtitles in your input Avisynth script or mux in the "soft" subtitles (along with the audio) after the encode has completed.

See also:
http://avisynth.org.ru/docs/english/externalfilters/vsfilter.htm

[iSeries]

Hi,

I meant when browsing for a file to add, it doesn't 'see' m2ts files. I did change the file type filter to all files and added an m2ts but the encode did indeed fail. I thought x264 could handle m2ts files directly? At least it seems to be able to just fine straight from the command line.

[LoRd_MuldeR]

Hi,

I meant when browsing for a file to add, it doesn't 'see' m2ts files. I did change the file type filter to all files and added an m2ts but the encode did indeed fail. I thought x264 could handle m2ts files directly? At least it seems to be able to just fine straight from the command line.

Well, if you throw a video file at x264, it will try to open that file via FFmpegSoource2 (FFMS2) - at least if your x264 binary was built with FFMS2 enabled.

As explained before, FFMS2 handles almost every container/video format in existence, because it is based on libavformat and libavcodec.

Nevertheless MPEG TS streams (like M2TS) are one of the "problematic" formats that may cause FFMS2 to fail. That's what the developers say themselves...

See also:
http://forum.doom9.org/showpost.php?p=1529599&postcount=6
http://forum.doom9.org/showpost.php?p=1502224&postcount=1109

Anyway, if something works "on the command-line" it is supposed to work in the GUI as well. So please post the exact error message!

:logfile:

[LoRd_MuldeR]

Improved verification of custom parameters, so options like "--qpfile" will now be accepted. Also some minor fixes.

[Video Dude]

LoRd_MuldeR,

This looks like a great program and exactly what I was looking for.

Do you have plans to add another box in the rate control section that would let the user specify a desired file output size, and then have the program set the bitrate accordingly?

[LoRd_MuldeR]

LoRd_MuldeR,

This looks like a great program and exactly what I was looking for.

Do you have plans to add another box in the rate control section that would let the user specify a desired file output size, and then have the program set the bitrate accordingly?

That's not easily possible, because it would require the GUI to know the exact duration, i.e. frame no. + frame rate, of the input file beforehand.

(Yes, I probably could use MediaInfo for that purpose, but that would add complexity I want to avoid for now)

[LoRd_MuldeR]

Re-added support for the Windows 7 taskbar progress indicator.

[reff24]

Norton says that the program is a Trojan.
Norton is the Qtxml4.dll dangerous. You will download a single dll again to do it. Can that possibly fix? For the next update? Read in this forum (http://www.mom-community.to/forum/showthread.php?33795-Simple-x264-Launcher-V2)

[meshaun]

Hi, this program looks good. I would love to use this tool. But first, please answer for the following :
1-Can it resize video and auto remove black bars?
2-Encode audio into AAC? from auto detecting it from a .mkv file? the audio in mkv is mostly DTS or TrueHD

[LoRd_MuldeR]

Norton says that the program is a Trojan.

False Positive, obviously :rolleyes:

Never trust the result of a single A/V software. Especially not if that A/V software is well-known for False Positives!

If you scan the file with multiple engines, you'll see that file definitely is unsuspicious:
https://www.virustotal.com/file/03f45ae788a67c9c7303a6d195816707a46ffee26be3e07ceea2a724ec482b47/analysis/1328733605/

"Detection ratio: 0 / 43"


Norton is the Qtxml4.dll dangerous. You will download a single dll again to do it.

That file is part of the Qt Framework (http://qt.nokia.com/) and has been included ever since.

I did not even compile this DLL myself. I just redistribute the file from the official Qt 4.8.0 SDK.

So much about that :p


Can that possibly fix?

Yes. Report the problem to the Symantec support team and they might be able to fix the bug in their software:
https://submit.symantec.com/false_positive/

If they don't fix the problem in time, get you money back and buy a better A/V software. Preferably one that is less paranoid.

(Personally I can recommend to get MSSE. It's free and does a decent job, rather than scaring the user all the time)

[LoRd_MuldeR]

Hi, this program looks good. I would love to use this tool. But first, please answer for the following :
1-Can it resize video and auto remove black bars?

Sure. You can either do it in your Avisynth script with a combination of your favorite resize filzer, e.g. Spline36Resize() (http://avisynth.org/mediawiki/Resize), and the Crop() (http://avisynth.org/mediawiki/Crop) function.

If you don't use Avisynth input, you can use x264's built-in resize and crop filters. See the x264 Wiki (http://mewiki.project357.com/wiki/X264_Settings#video-filter) for details...

2-Encode audio into AAC? from auto detecting it from a .mkv file? the audio in mkv is mostly DTS or TrueHD

This is a GUI front-end for x264. At this time, x264 doesn't process audio at all. The answer follows :)

You can encode the audio with your favorite audio encoder (e.g. Nero AAC) and then mux it with the encoded video via MKVToolnix or MP4Box.

If you need an audio encoder GUI, you may want to have a look at LameXP (http://lamexp.sourceforge.net/) ;)

[shinchiro]

Thanks for this wonderful program! :D


This is a GUI front-end for x264. At this time, x264 doesn't process audio at all. The answer follows :)

I thought there is L-smash patch which can encode audio, right?


If you need an audio encoder GUI, you may want to have a look at LameXP (http://lamexp.sourceforge.net/) ;)
Did you plan to merge LameXp into this GUI? If yes, it would be awesome ;)

Can you add option to change priority of x264 & avsyuv processes if possible? The default priority is below normal

[LoRd_MuldeR]

I thought there is L-smash patch which can encode audio, right?

AFAIK, the "L-smash" project implements an alternative MP4 muxer. I don't think it is specifically for audio encoding :confused:

Anyway, I cannot make use of any features/patches that have not been adopted into mainline x264 yet.

The same goes for UTF-8 support, for example. You still may be able to make use of "unofficial" features through the "custom parameters" edit box.


Did you plan to merge LameXp into this GUI? If yes, it would be awesome ;)

Definitely not. I'm not trying to create an "egg-laying wool-milk-sow" that nobody can maintain...


Can you add option to change priority of x264 & avsyuv processes if possible? The default priority is below normal

What is wrong about that?

If you think that running a process at a higher priority would make it run any "faster", then you are wrong!

Priorities only make a difference when various processes are ready to execute at the same moment and thus compete for the CPU.

In that case the process with the higher priority is served first. And we generally want that to be the GUI (foreground) process.

Running x264 at "below normal" priority means: Use all the CPU time you can get, but don't thwart any of the "foreground" processes.

Thus, as long as you don't run other "CPU intensive" workload at the same time, a "below normal" priority won't slow down x264...

(Though it will noticeably improve the reactivity of the GUI front-end and other programs, e.g. web-browser and stuff)

[naoan]

Some improvements:
* Added Drag&Drop support


I'm probably doing something wrong, but the latest version I tried (x264_x64.2012-02-09) doesn't seems to accept drag&drop file. :confused:

[LoRd_MuldeR]

I'm probably doing something wrong, but the latest version I tried (x264_x64.2012-02-09) doesn't seems to accept drag&drop file. :confused:

Works just fine here. Also I did not change anything about Drag&Drop support since it was added :confused:

Sure you did not launch the application with elevated rights for whatever reason?

Applications running with elevated rights won't accept any drops from a non-elevated process...

(BTW: x264_x64.2012-02-09. That's not the latest version)

Are you sure you dropped the files on the "Main" window?

[naoan]

Are you sure you dropped the files on the "Main" window?

Ah this was my problem, I'm too used with the old behavior of dragging the file where the open button is. Sorry for the confusion. :D

[LoRd_MuldeR]

Ah this was my problem, I'm too used with the old behavior of dragging the file where the open button is. Sorry for the confusion. :D

I can add Drag&Drop support for the "Add Job" dialog too. Though dropping multiple files won't work there.

[naoan]

It's not working here, I probably need to update the launcher though.

[LoRd_MuldeR]

It's not working here, I probably need to update the launcher though.

What exactly? :confused:

[naoan]

The drag&drop on add job window, just tried the x264_x64.2012-02-10 version and it's still not working. I'm using windows 7 x64 sp1 if that could help anything.

Edit: And I'm running the app on the same right as explorer/my login.

[LoRd_MuldeR]

The drag&drop on add job window, just tried the x264_x64.2012-02-10 version and it's still not working. I'm using windows 7 x64 sp1 if that could help anything.

I just said that "I can add Drag&Drop support for the 'Add Job' dialog too", but I did not want to indicate that this is already supposed to be working ;)

[naoan]

Ah sorry about that, bad day (and eyesight) of me :p, please do if you can, that would be much appreciated. :D

Oh and also, retaining pending job even after closing the launcher would be nice. :D

Edit: one more thing to consider is to give user option of defaulting "Start Job Immediately" checkbox ticked or not. :)

[LoRd_MuldeR]

Edit: one more thing to consider is to give user option of defaulting "Start Job Immediately" checkbox ticked or not. :)

Whether that checkbox will be checked initially (or not) is controlled dynamically:

If the number of running jobs still is below the user-defined limit, then it will be checked initially. Otherwise it won't be.

[LoRd_MuldeR]

New version:

This version supports a "portable" mode (see ReadMe for details) and accepts Drag&Drop's in the Add Job dialog.

[naoan]

Thanks! :D

[Chumbo]

I just stumbled on this thread. A sweet little app I must say. :) I was hoping it would work with avisynth 32bit like suggested and encode with 64bit x264 but it doesn't work here at all. Basically the same thing happens on each of my systems when attempting any of the 32bit tools, i.e., they crash. I have 3 installations that are all Win7U64bit. Am I missing something to get the 32bit tools to work WITHOUT crashing? Those of you who have it working, was there something specific you did in your Win7 64bit install so the 32bit tools don't crash? I'm at a complete loss.

I get the typical "xxx has stopped working" message for avs2yuv.exe.

@MuldeR,
If I may request a feature please. Any chance of modifying the log area to just be a text box? It would be nice to be able to just copy specific text directly from there. A normal text field there would also still provide the standard context menu to allow to select all and copy. Right now we have to copy everything and open a text editor, paste and then grab a line or command to test. Thanks a lot for considering it.

[LoRd_MuldeR]

I was hoping it would work with avisynth 32bit like suggested and encode with 64bit x264 but it doesn't work here at all. Basically the same thing happens on each of my systems when attempting any of the 32bit tools, i.e., they crash.

That's obviously some local problem.

I have 3 installations that are all Win7U64bit. Am I missing something to get the 32bit tools to work WITHOUT crashing? Those of you who have it working, was there something specific you did in your Win7 64bit install so the 32bit tools don't crash? I'm at a complete loss.

Nope, works "out of the box". I am using 64-Bit Windows 7 on my main development machine too and have not encountered any problems so far.

I regularly use use 32-Bit DGDecodeNV (with 64-Bit x264), for example. As far as I know, it doesn't have a 64-Bit equivalent.

If I remember correctly, you have reported similar problems before. So your problem is probably not related to the Simple x264 Launcher at all...

You have a specific software, e.g. a specific Virus Scanner or Firewall, installed on all "problematic" systems? If so, get rid of it!

Also it certainly won't hurt to clean-up your Avisynth plug-in's folder. Throw out everything you don't really need. Or even load all plug-in's explicit.

I got all kinds of strange crashes with old/buggy/incompatible Avisynh plug-in DLL's in the past. Last but not least: Use Avisynth 2.5.8 stable.

I get the typical "xxx has stopped working" message for avs2yuv.exe.

Time to load up a debugger and find out what is wrong... Does the very same AVS file open and play fine with VirtualDub or MPlayer?

What if you run "avs2yuv.exe input.avs -o output.y4m" from the console manually ???

If I may request a feature please. Any chance of modifying the log area to just be a text box? It would be nice to be able to just copy specific text directly from there. A normal text field there would also still provide the standard context menu to allow to select all and copy. Right now we have to copy everything and open a text editor, paste and then grab a line or command to test. Thanks a lot for considering it.

Not easily possible, as I use a QListView there. AFAIK there is nothing like a QTextView.

Sure, I could use a simple QTextEdit widget, but then I had to keep the content manually in sync with the logging data :rolleyes:

Having the View atomically synchronize itself with the log Model is so much cleaner and nicer...

[Chumbo]

That's obviously some local problem.
I figured as much but have been unable to track it down since it happens exactly the same on 3 computers and a VM.
Nope, works "out of the box". I am using 64-Bit Windows 7 on my main development machine too and have not encountered any problems so far.

I regularly use use 32-Bit DGDecodeNV (with 64-Bit x264), for example. As far as I know, it doesn't have a 64-Bit equivalent.

If I remember correctly, you have reported similar problems before. So your problem is probably not related to the Simple x264 Launcher at all...
Lucky you. ;) This is why I did a clean install in a VM to see if that resolved anything and it did not. For me, "out of the box" still crashed the same dang way. And you are correct, I have reported the same problem specifically to try to fix it. I brought it up here because I wasn't sure if your app was doing something "internally" to link 32bit AVS to work with 64bit x264. I found out it does not. :(
You have a specific software, e.g. a specific Virus Scanner or Firewall, installed on all "problematic" systems? If so, get rid of it!

Also it certainly won't hurt to clean-up your Avisynth plug-in's folder. Throw out everything you don't really need. Or even load all plug-in's explicit.

I got all kinds of strange crashes with old/buggy/incompatible Avisynh plug-in DLL's in the past. Last but not least: Use Avisynth 2.5.8 stable.
I'd like to get the VM install working since it's new and "clean" and only has very few things installed on it, i.e., basic stuff like AviSynth 2.5.8 stable.
Time to load up a debugger and find out what is wrong... Does the very same AVS file open and play fine with VirtualDub or MPlayer?
Debugger time is right. Yes, I use VirtualDub and VirtualDub64 to test my AVS scripts and the script loads fine in VirtualDub. I use MPC-HC to play the AVS and it plays fine.
What if you run "avs2yuv.exe input.avs -o output.y4m" from the console manually ???
Actually that's what I did to see why it failed. The crash dialog does not come up when it fails from the UI so I ran it manually to see the source of the failure and voila.

Thanks for looking at the edit box possibility. Do you know if the current control you're using can add a "Copy Line" item on the context menu? That would be nice. Not a big deal honestly, just more of a convenience thing to not have to open another program. ;)

BTW, when a job fails, any chance of adding an option to reset it so it can be run again? Again, not a big deal, just a convenience thing. Thanks again.

[Chumbo]

...I got all kinds of strange crashes with old/buggy/incompatible Avisynh plug-in DLL's in the past. Last but not least: Use Avisynth 2.5.8 stable.

Time to load up a debugger and find out what is wrong...
...
You are indeed LoRd_MuldeR. :D After a year of being unable to resolve this damn issue, you said the right thing to put me on the right track. So I checked the event viewer and saw thisFaulting application name: avs2yuv.exe, version: 0.0.0.0, time stamp: 0x4e78e870
Faulting module name: bass_ape.dll_unloaded, version: 0.0.0.0, time stamp: 0x4383b3ab
Exception code: 0xc0000005
Fault offset: 0x003d2be0
Faulting process id: 0x19bc
Faulting application start time: 0x01cce9257a2ce816
Faulting application path: D:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\avs2yuv.exe
Faulting module path: bass_ape.dll
Report Id: b9a3e916-5518-11e1-b339-ef7a097f6cd3
Pointed directly the file causing the crash. I removed all the bass* files from the AviSynth plugins folder and voila! Unbelievable. I can't believe in all this time it didn't occur to me to check the event viewer. Sheesh. Anyhow, can't thank you enough. I hope this helps anyone else who may be running into the same issue.

The reason, obviously, why it's blowing up in the VM "clean" install is that I copied the plugins folder to make sure I had the files needed not realizing that I was copying outdated ones too.

I'll need to see if there are new versions of the Bass* files or if all I need is the BassAudio.dll. Either way, I'll restore them back one at a time to see if only bass_ape is the problem or the others as well.
:thanks:

[LoRd_MuldeR]

Debugger time is right. Yes, I use VirtualDub and VirtualDub64 to test my AVS scripts and the script loads fine in VirtualDub. I use MPC-HC to play the AVS and it plays fine.

That's really strange. So VirtualDub opens (and plays !?) your script just fine, but Avs2YUV does not? :scared:

What if you run "avs2yuv.exe input.avs -o output.y4m" from the console manually ???Actually that's what I did to see why it failed. The crash dialog does not come up when it fails from the UI so I ran it manually to see the source of the failure and voila.

And voila... what? :confused:

[Pat357]

Nice little tool you have ! Thanks a lot for creating it.
I have however 2 problems with it :

1. When I want to specify "--fps 24" as a custom parameter for x264_x64, I says it's invalid and deletes all other custom settings too.
If you check in the x264 help "--fps .." IS a valid parameter.
Any reason why this is blocked ?
I tried to encode a 24fps MKV file (remuxed .TS file), I got an encoded MKV file, but the header in mediainfo indicated a VFR instead of 24 fps for the framerate.
The input .mkv file had 24 fps in mediainfo and the whole file plays at 24 fps.
Some splitters rely on the FPS in the header, so I want 24fps there instead of VFR, because the file is not VFR !

2. My input file is native 4:2:2, but when I created an AVS-script (gives 4:2:2 output) and input this in your tool, I noticed AVS2YUV converted it to 4:2:0.
That's not what I want. I used profile High422 and used --csp-input i422 and --csp-output i422 as custom parameters for x264, but no avail : AVS2YUV always converted to 4:2:0.
I have no place in the tool to enter parameters for AVS2YUV, and as a matter fact, I would want that avs2yuv would not touch the color-space and just pass-through as it is.
Is this possible ?

Another solution could be that avs2yuv outputs the color-space based on the profile :
for "High422" (output i422 then) and in case of profile "High444", avs2yuv should output i444.
For all other profiles just output 4:2:0.
Is this more feasible to add to your nice tool ?

[LoRd_MuldeR]

1. When I want to specify "--fps 24" as a custom parameter for x264_x64, I says it's invalid and deletes all other custom settings too.
If you check in the x264 help "--fps .." IS a valid parameter.
Any reason why this is blocked ?

It's blocked as a "custom" parameter, because the GUI will set it for you.

When the input is piped into x264 via Avs2YUV, x264 can't know the original framerate. It just sees the "raw" image data it gets via STDIN.

That's why the GUI will detect the framerate from the original AVS and pass it to x264 via "--fps" parameter.


2. My input file is native 4:2:2, but when I created an AVS-script (gives 4:2:2 output) and input this in your tool, I noticed AVS2YUV converted it to 4:2:0.
That's not what I want. I used profile High422 and used --csp-input i422 and --csp-output i422 as custom parameters for x264, but no avail : AVS2YUV always converted to 4:2:0.
I have no place in the tool to enter parameters for AVS2YUV, and as a matter fact, I would want that avs2yuv would not touch the color-space and just pass-through as it is.
Is this possible ?

This would require to pass a custom "-csp" parameter to Avs2YUV, which is not currently possible. The default is "-csp I420", but you would need "-csp I422".

Also I think it will require experimental Avisynth 2.6, because Avisynth 2.5 cannot output YV16. And Avs2YUV apparently cannot pass through YUY2, only YV16.

Last but not least you would also need to pass "--csp-output I422" to x264, because by default x264 would convert the I422 input back to I420...

[Chumbo]

And voila... what? :confused:Since the UI did NOT really show what the failure was it could be anything. By running it manually, I was able to see exactly what was failing, i.e., the executable itself. So voila as in running it manually revealed the source of the crash. ;) Anyhow, that's all behind me now thank goodness.

[LoRd_MuldeR]

Added support for custom Avs2YUV parameters:

You can now encode 4:2:2 and 4:4:4 YUV data from Avisynth by passing "-csp I422" or "-csp I444" to Avs2YUV as a custom parameter.
Please remember that you also need to pass the proper "--output-csp" parameter to x264, if you want to encode in 4:2:2 or 4:4:4 YUV.

[Chumbo]

@MuldeR,
I noticed that when the app is already installed, running the setup for an updated version does not "see" the location of the current installation and updates it. I install my apps to drive D so D:\... is my path but the install came up pointing to C:\.... This may be out of your control depending on what setup packing software you use, but it would be nice if it came up and recognize an already installed copy and pointed to its current location.

[LoRd_MuldeR]

@MuldeR,
I noticed that when the app is already installed, running the setup for an updated version does not "see" the location of the current installation and updates it. I install my apps to drive D so D:\... is my path but the install came up pointing to C:\.... This may be out of your control depending on what setup packing software you use, but it would be nice if it came up and recognize an already installed copy and pointed to its current location.

Yes, the installer does not currently remember the install location from previous installations.

(Will add this in a future build, although the "portable" purist will complain)

[Pat357]

It's blocked as a "custom" parameter, because the GUI will set it for you.

When the input is piped into x264 via Avs2YUV, x264 can't know the original framerate. It just sees the "raw" image data it gets via STDIN.

That's why the GUI will detect the framerate from the original AVS and pass it to x264 via "--fps" parameter.

Lord Mulder,
If you read my first problem again, you'll notice that I was not trying to feed an .avs, but a normal 4:2:2 MKV file.
Does the guy in this case also adds the "--fps" parameter ?
I asked because even for MKV input, --fps is blocked.
This doesn't seem right to me, but I could be wrong....
Why is it still blocked for MKV input ?

[Pat357]

Added support for custom Avs2YUV parameters:
http://code.google.com/p/mulder/downloads/

Thanks a million !!
I'm gonna test it asap.

[LoRd_MuldeR]

Lord Mulder,
If you read my first problem again, you'll notice that I was not trying to feed an .avs, but a normal 4:2:2 MKV file.
Does the guy in this case also adds the "--fps" parameter ?
I asked because even for MKV input, --fps is blocked.
This doesn't seem right to me, but I could be wrong....
Why is it still blocked for MKV input ?

Well, I blocked it in general. That's because there are cases in which setting "--fps" manually would mess up things.

For native MKV input we don't really have to block it. But we also shouldn't need to set it.

If FFMS2 doesn't detect the frame rate of your MKV file correctly, then you should report the problem to FFMS2 guys.

You can still use a simple Avisynth script with FFVideoSource() followed by AssumeFPS() as workaround for now...

(Note that the "--force-cfr" option should not be blocked at all, if that is your concern)

Thanks a million !!
I'm gonna test it asap.

Please also note the instructions in the ReadMe file.

[LoRd_MuldeR]

Added a "Restart Job" button. Also added some info on audio encoding to the ReadMe file.

[nibus]

Excellent utility Lord Mulder!

I use a lot of custom --zones and as such my x264 command line gets pretty long. What do you think about adding a "--zones Parameters:" field in the Add Job box and appending it to the x264 command line?

[Chumbo]

Added a "Restart Job" button. Also added some info on audio encoding to the ReadMe file.

Download:
http://code.google.com/p/mulder/downloads/
Sweet! Thank you.

[LoRd_MuldeR]

Excellent utility Lord Mulder!

I use a lot of custom --zones and as such my x264 command line gets pretty long. What do you think about adding a "--zones Parameters:" field in the Add Job box and appending it to the x264 command line?

What would a "zones" parameters edit box do different than the general "custom" parameters box?

After all, both edit boxes would contain additional user-defined CLI parameter that will be passed to x264, right?

So basically we would have two edit boxes for the the same purpose.

If all your zones parameters don't fit into the "custom parameters" edit box, you can make the window wider.

And if they still don't fit in, you can prepare your command-line in your preferred text editor...

[nibus]

What would a "zones" parameters edit box do different than the general "custom" parameters box?

After all, both edit boxes would contain additional user-defined CLI parameter that will be passed to x264, right?

So basically we would have two edit boxes for the the same purpose.

If all your zones parameters don't fit into the "custom parameters" edit box, you can make the window wider.

And if they still don't fit in, you can prepare your command-line in your preferred text editor...

I see your point, it would be redundant. True, you can just make the window wider, but this is kind of a pain if you have a really long command line. What if the custom parameters box had 2-3 lines with word-wrap? That would make the command line more accessible without any redundant boxes.

[reff24]

Thank you for your work. is prorgam getting better and better! I hope it is not set like AutoMKV and co! So stay on the ball and keep going

[LoRd_MuldeR]

I see your point, it would be redundant. True, you can just make the window wider, but this is kind of a pain if you have a really long command line. What if the custom parameters box had 2-3 lines with word-wrap? That would make the command line more accessible without any redundant boxes.

Please try with the attached version. Right-click + "Open Editor" will open the multi-line editor.

[nibus]

Please try with the attached version. Right-click + "Open the Text-Editor" will open the multi-line editor.

Awesomesauce. :D Works perfectly!

[shinchiro]

What is wrong about that?

If you think that running a process at a higher priority would make it run any "faster", then you are wrong!

Priorities only make a difference when various processes are ready to execute at the same moment and thus compete for the CPU.

In that case the process with the higher priority is served first. And we generally want that to be the GUI (foreground) process.

Running x264 at "below normal" priority means: Use all the CPU time you can get, but don't thwart any of the "foreground" processes.

Thus, as long as you don't run other "CPU intensive" workload at the same time, a "below normal" priority won't slow down x264...

(Though it will noticeably improve the reactivity of the GUI front-end and other programs, e.g. web-browser and stuff)
I never know about that. btw, in my observation, x264 encode faster (maybe finished 2-5 minutes early when encoding 720p anime with duration 24 minutes) when I changed it to normal :rolleyes:

And I only do that when I want to leave my pc on for a night for encoding and nothing intensive program running along. Since megui has this option, I would like to see this feature in this tool too

[LoRd_MuldeR]

I never know about that. btw, in my observation, x264 encode faster (maybe finished 2-5 minutes early when encoding 720p anime with duration 24 minutes) when I changed it to normal :rolleyes:

If x264 encodes any faster* by raising the priority, then this means another process running on your system was competing with x264 for the CPU.

(*) And here we are talking about a speed-up that does NOT fall within the normal fluctuations!

[VideoFanatic]

Could you please explain this to me:

I encoded the same file at different speed settings and got the following sizes:

CRF 17 Medium: 49 MB
CRF 17 Super Fast: 59 MB

I thought the slows speeds are supposed to give the same file size but a better quality file? Medium should be better quality than Super Fast yet Medium has a much smaller file size. I looked at both files on my TV and I can't tell them apart.

[vdcrim]

I thought the slows speeds are supposed to give the same file size but a better quality file?
You really should check the available x264 documentation, as LoRd_MuldeR already showed you in your other thread. From http://mewiki.project357.com/wiki/X264_Settings#preset:
Change options to trade off compression efficiency against encoding speed.
Compression efficiency can be defined as quality/bitrate. Now, x264 allows you to encode with two different approaches:

Aim for a certain filesize: use '--bitrate' and a number of passes, usually 2.
Aim for a certain uniform quality: use '--CRF'. This only approximates to constant quality though.

Taking this to the efficiency definition, you'll have this:

For bitrate mode, 'preset' is a trade off between speed and perceptual quality. A slower preset gives better quality results.
For CRF mode, 'preset' is a trade off between speed and bitrate (assuming CRF were a perfect index of quality). A slower preset gives (generally) a smaller filesize.

[shinchiro]

Could you please explain this to me:

I encoded the same file at different speed settings and got the following sizes:

CRF 17 Medium: 49 MB
CRF 17 Super Fast: 59 MB

I thought the slows speeds are supposed to give the same file size but a better quality file? Medium should be better quality than Super Fast yet Medium has a much smaller file size. I looked at both files on my TV and I can't tell them apart.
Dude, you are using crf. Generally, when using crf, crf will try to get certain degree of quality based on the value you give in no matter what preset you use. Note that, the slower the preset, more compression can be attained so smaller the size. You are using same crf value for both test so expect negligible similar quality (since you are watching on tv)

I thought the slows speeds are supposed to give the same file size but a better quality file?
This only apply to 2pass. Open bitrate calculator in megui and calculate bitrate for 59mb. Take note that bitrate and use that for both test. Then you will say slower preset will give more quality than faster preset.

[sneaker_ger]

Also note that CRF does not guarantee constant quality for different settings. Especially not on medium vs superfast, as the latter does not use mb-tree while the former does.

[LoRd_MuldeR]

Could you please explain this to me:

I encoded the same file at different speed settings and got the following sizes:

CRF 17 Medium: 49 MB
CRF 17 Super Fast: 59 MB

I thought the slows speeds are supposed to give the same file size but a better quality file? Medium should be better quality than Super Fast yet Medium has a much smaller file size. I looked at both files on my TV and I can't tell them apart.

Using a "slower" preset does improve the compression efficiency. That is the "quality per bit" ratio.

However there is absolutely no guarantee that, in CRF (or CQ) mode, the total size of the file will still be the same after you switch the preset ;)

Consequently, if you want to compare the quality of "Superfast" and "Medium" presets, you need to ensure your files have an identical size.

So you need to use "2-Pass" mode (with identical target bitrate) for this kind of test. And be sure to pick a reasonable bitrate!

Once you have verified for yourself that "Medium" preset gives better results, you can go back to CRF mode and tweak your CRF value as needed.

Hint: The same CRF value will give "very similar" quality for different sources. But only as long as no other influential settings are changed...

[reff24]

You can add any configuration on a menu item? Loading template (Custom Matrix)?

[VideoFanatic]

Is there any way to force the aspect ratio to 4:3 with your program or avisynth? My MPEG2 is 4:3 when I view it on my PC. Mediainfo and Videoredo also say it's 4:3. However when I use your program my video is stretched to 1.50:1. With HC Encoder I just selected 4:3 to prevent that.

Is there any way to get your program to have the output selected as h264 by default? At the moment mkv is always selected first.

I have a dual core PC. At the moment it takes me 2 hours 45 minutes to encode a 1 hour 30 minute video on VeryFast CRF 17. How much faster would it be if I had more cores?

[kypec]

Is there any way to force the aspect ratio to 4:3 with your program or avisynth? My MPEG2 is 4:3 when I view it on my PC. Mediainfo and Videoredo also say it's 4:3. However when I use your program my video is stretched to 1.50:1. With HC Encoder I just selected 4:3 to prevent that.
That's because you didn't specify SAR explicitly for elementary stream descriptors and you didn't do it either in target container (MP4 or MKV).
Just add --sar 8:9 option to your command line and you'll get proper 4:3 display ratio for your 3:2 source clip (probably some 720 x 480 NTSC MPEG2). ;)

Is there any way to get your program to have the output selected as h264 by default? At the moment mkv is always selected first.This behaviour annoys me a bit as well because I use raw .264 output too for my encodes but I think unless LM rewrites the code there's no way we two would be satisfied 100%, MKV is likely more preferred output type for general audience. :p

[LoRd_MuldeR]

Is there any way to get your program to have the output selected as h264 by default? At the moment mkv is always selected first.

In my opinion MKV should be the standard output format. With a "raw" H.264 file you cannot do much. Most players won't even be able to play that! The only thing you can do (and probably will do) is muxing the "raw" stream to MKV (or MP4). And if you are going to mux the stream anyway (e.g. for adding the audio), you can mux from the MKV file just as well. MKVMergeGUI accepts MKV's as input just fine. You also have to be aware that 99% of all users believe that if a file does not play immediately on double-click in Windows Explorer, then that file is "broken" and the application who created the file is to blame! Thus by making MKV the default output format, I can save about ten angry e-mails per day. There could be some discussion whether the default format should be MKV or MP4. While MP4 would be "more standard", I believe that most people prefer MKV these days. And the people who don't care will probably get the best results with MKV too...

I have a dual core PC. At the moment it takes me 2 hours 45 minutes to encode a 1 hour 30 minute video on VeryFast CRF 17. How much faster would it be if I had more cores?

As x264 scales very well up to at least 16 cores, you can expect ~2x speed-up for a Quadcore and ~3x speed-up for a Hexacore.

That is for a CPU of the same generation. If you replace an older Dualcore processor with a modern Quadcore (or Hexacore), you can get even more speed-up, due to improved "per core" performance.

Of course you can only expect speed-up, if you aren't bottle-necked by "slow" input, such as a slow single-threaded Avisynth script. x264 can't encoder faster than the input gets delivered.

[VideoFanatic]

LoRd_MuldeR my video is 720 x 480 and I'll be viewing it on my TV. Could you please confirm that 8:9 is the correct aspect ratio setting to use on your program?

10:11 looks the same as as 8:9 but it's a slightly wider picture. I load both videos in Videoredo and it says both are 4:3 so how do I know which is correct? They both look in proportion.

[LoRd_MuldeR]

DAR = W:H x SAR = 720:480 x 8:9 = 1:1.33333 = 4:3

So, yes. For 720x480 video, a SAR (Sample Aspect Ratio, aka Pixel Aspect Ratio) of 8:9 will result in a DAR (Display Aspect Ratio) of 4:3.

Video captured from TV Broadcast is either 4:3 or 16:9. Nowadays mostly 16:9.

(BTW: Cropping never changes the SAR. But, as the SAR remains as-is while the Width and/or Height changes, the DAR might change.)

[VideoFanatic]

Thanks and what sar setting should I use for 16:9?

[LoRd_MuldeR]

Thanks and what sar setting should I use for 16:9?

Let's have a little math exercise:

720:480 x ? = 16:9

? = 16:9 / 720:480

? = 16:9 * 480:720

? = 32:27

[VideoFanatic]

I don't know what you mean! I didn't even understand the calculation you did before! I did some searching and all I found was people equally confused about this issue.

Wouldn't it be easier to just have a checkbox in your program to select 4:3 or 16:9?

[LoRd_MuldeR]

I don't know what you mean! I didn't even understand the calculation you did before! I did some searching and all I found was people equally confused about this issue.

Hit F5 and you'll see the result of the calculation. Hopefully you will be able to solve it yourself next time.

Wouldn't it be easier to just have a checkbox in your program to select 4:3 or 16:9?

Nope. Because we need to enter the SAR (Sample Aspect Ratio, aka Pixel Aspect Ratio), and not the DAR (Display Aspect Ratio).

For the same DAR (e.g. 4:3 or 16:9) a completely different SAR may be required. It depends on the resolution of the video.

For 720x480 (NTSC) video a SAR of 8:9 results in a DAR of 4:3, as desired. But for 720x576 (PAL) a different SAR would be required to get the same DAR of 4:3.

Also 4:3 and 16:9 are not the only DAR's in existence. These are commonly used in TV Broadcast, yes. But other DAR's may be used just as well.

Actually video intended to watch on a computer as well as all "HD" video (1080p, 720p, etc) usually uses a SAR of 1:1, aka "Square Pixels".

Non-Square Pixels, aka "Anamorphic Video", aka SAR ≠ 1:1, is only a reminiscent of the analogous TV era...

[VideoFanatic]

OK fair enough but why would HC Encoder have a 4:3 option if it didn't give the intended result on 720 x 480 NTSC and 720 x 576 PAL?

[LoRd_MuldeR]

OK fair enough but why would HC Encoder have a 4:3 option if it didn't give the intended result on 720 x 480 NTSC and 720 x 576 PAL?

It probably calculates the required SAR from the chosen DAR and the actual resolution of the input video.

Simple x264 Launcher is just a front-end to the x264 CLI encoder. It doesn't know the exact resolution of the input video beforehand.

And therefore it cannot calculate the required SAR (for the desired DAR) from the information it has available...

I'm still lost as to what setting I'm supposed to use to get 16:9. What am I supposed to type into my calculator and where do I get the values from?

The calculation is straight forward. And I even gave you a detailed example above.

But to say it again: For 720x480 video you'll have to enter a SAR of 32:27 in order to get a DAR of 16:9.

[VideoFanatic]

I'm still lost as to what setting I'm supposed to use to get 16:9. What am I supposed to type into my calculator and where do I get the values from?

[LoRd_MuldeR]

Well, we know that "Width:Height x SAR = DAR". Width, Height and DAR are known. SAR we want to know.

So you write on a piece of paper "720:480 x X = 16:9" and then you solve what X is, like you (hopefully) learned it back in elementary school.

You will see that "X = 16:9 x 480:720 = (16x480):(9x720)". So you can type that into your calculator, if you are too lazy to reduce the fraction to 32:27 by hand...

Or you let WolframAlpha do the work:
http://www.wolframalpha.com/input/?i=Solve+%28720%2F480%29+*+X+%3D+16%2F9

[reff24]

You can add any configuration on a menu item? Loading template (Custom Matrix)?

they have overlooked it in their discussion with holygamer perhaps. Is it possible to install it?

[SeeMoreDigital]

By any chance. Is there anybody here able to provide a Quicktime player friendly "Custom x264 Parameter" encode setting string?


Cheers all

[LoRd_MuldeR]

You can add any configuration on a menu item? Loading template (Custom Matrix)?they have overlooked it in their discussion with holygamer perhaps. Is it possible to install it?

What would that menu item be supposed to do? :confused:

You can already "load" templates easily. The template is loaded immediately when you select a template from the "Template" combobox.

Custom matrices are set via "--cqm" or "--cqmfile", which you can add to the custom parameters. So that is already covered by current template system.

I don't see much reason to add more support for custom matrices, as custom matrices are pretty much obsolete and 99% of all users don't need them.

[VideoFanatic]

LoRd_MuldeR. You said this about having mkv as the default option:

You also have to be aware that 99% of all users believe that if a file does not play immediately on double-click in Windows Explorer, then that file is "broken" and the application who created the file is to blame! Thus by making MKV the default output format, I can save about ten angry e-mails per day.

I just dragged an MPEG2 into your program and saved it as mkv. The file doesn't play when I double-click on it (it doens't seem to be associated with any program) so what were you talking about? Also I played it in VLC Media Player but it had no sound.

[LoRd_MuldeR]

LoRd_MuldeR. You said this about having mkv as the default option:

You also have to be aware that 99% of all users believe that if a file does not play immediately on double-click in Windows Explorer, then that file is "broken" and the application who created the file is to blame! Thus by making MKV the default output format, I can save about ten angry e-mails per day.

I just dragged an MPEG2 into your program and saved it as mkv. The file doesn't play when I double-click on it (it doens't seem to be associated with any program) so what were you talking about?

This is different on any computer, of course :rolleyes:

However the chance that the user has installed some playback software, which can playback H.264 streams stored in a Matroska container and which has registered itself as default program for .MKV files, is pretty high!

VLC Player, for example, does do this by default:
http://img31.imageshack.us/img31/9028/clipboard53.th.png (http://img31.imageshack.us/img31/9028/clipboard53.png)

At the same time the chance that the user has installed some software which can open and play "raw" H.264 streams is rather low...

Also I played it in VLC Media Player but it had no sound.

Please read the section about audio encoding:
https://github.com/lordmulder/Simple-x264-Launcher/blob/master/ReadMe.txt#L168

[nibus]

Hi Mulder, I had a few more feature suggestions -

1) Set (or have an option to) the default save directory to the same directory as the .avs source.
2) Refer to the last saved file type (mp4/mkv) when saving a new video.
3) Compute a file size estimate on CRF encodes (similar to MeGUI).

Once again thanks for the awesome gui.

[kypec]

3) Compute a file size estimate on CRF encodes (similar to MeGUI).
:eek: Filesize can't be predicted when using CRF encoding mode so what are you talking about?

[nibus]

:eek: Filesize can't be predicted when using CRF encoding mode so what are you talking about?

A rough estimate can be predicted, MeGUI does it and the longer the encode goes the more accurate the prediction is. I assume it averages out the bitrate of the encode from the beginning to the current position and multiplies that to the remaining frames.

[reff24]

what's new in the versione from 21.02?

[LoRd_MuldeR]

1) Set (or have an option to) the default save directory to the same directory as the .avs source.

The program already remembers the last "open from" and "save to" directory. Output file paths are generated for the current (last used) "save to" directory.

2) Refer to the last saved file type (mp4/mkv) when saving a new video.

This should be working too. Actually it did not always work as expected, due to a bug. Should be fixed with the next build.

3) Compute a file size estimate on CRF encodes (similar to MeGUI).

As kypec said, this could only be done as an "educated guess". Also I don't want to encourage people to use rate-control modes in ways they are not intended to be used. If you use CRF mode with a certain CRF value, then you should be doing so, because that CRF values retains the desired level of quality. But not because that CRF value coincidentally happens to hit the desired target file size for one particular source. We have 2-Pass mode to hit a specific file size...

what's new in the versione from 21.02?

Handling of multiple instances.

[nibus]

The program already remembers the last "open from" and "save to" directory. Output file paths are generated for the current (last used) "save to" directory.

Right - what I meant was, automatically changing (or having an option to change) the save directory to the same directory as the AVS script being encoded, rather than the previously selected directory. So each script will have it's respective encode in the same directory.



This should be working too. Actually it did not always work as expected, due to a bug. Should be fixed with the next build.


:thanks:


As kypec said, this could only be done as an "educated guess". Also I don't want to encourage people to use rate-control modes in ways they are not intended to be used. If you use CRF mode with a certain CRF value, then you should be doing so, because that CRF values retains the desired level of quality. But not because that CRF value coincidentally happens to hit the desired target file size for one particular source. We have 2-Pass mode to hit a specific file size...

I don't encode for file size, but it is nice to see a rough estimate of a project. Some sources are simply too grainy to re-encode, so half way through the project it's nice to see if by chance the estimated file size is larger than the source. :eek:

[LoRd_MuldeR]

I don't encode for file size, but it is nice to see a rough estimate of a project. Some sources are simply too grainy to re-encode, so half way through the project it's nice to see if by chance the estimated file size is larger than the source. :eek:

So you want a "live" estimate of the final size during the encode, based on "what has been encoded so far" ?

Well, that might be possible to do...

[LoRd_MuldeR]

Nibus, please try with this TEST build.

[nibus]

Nibus, please try with this TEST build.

Works perfectly! Exactly what I was requesting.

I'll run some longer encodes through it tonight and see how it does, but from some shorter tests it seems to be quite accurate.

[kypec]

Right - what I meant was, automatically changing (or having an option to change) the save directory to the same directory as the AVS script being encoded, rather than the previously selected directory. So each script will have it's respective encode in the same directory.
I didn't try myself any of the latest versions (2.x) of Simple Launcher but the last branch behaves exactly like you want it to - you just need to drag&drop AVS file onto it instead of manual browse/open button.

[nibus]

I didn't try myself any of the latest versions (2.x) of Simple Launcher but the last branch behaves exactly like you want it to - you just need to drag&drop AVS file onto it instead of manual browse/open button.

Ahh ok, I'd never tried drag and drop. Thanks.

[MajorX]

need help when i try to encode with avs script the fps changes.
here my avs script,
FFVideoSource("F:\Video012.mkv")
Undot()

Input Video Frame rate: 29.970 fps
Output Frame rate: 24.326 fps

Help?

[LoRd_MuldeR]

need help when i try to encode with avs script the fps changes.
here my avs script,

Input Video Frame rate: 29.970 fps
Output Frame rate: 24.326 fps

Help?

If you want your AVS script to output 29.97 fps, but it doesn't, simply append "AssumeFPS(30000, 1001) to your script.

I'll run some longer encodes through it tonight and see how it does, but from some shorter tests it seems to be quite accurate.

It's as "accurate" as it can be. It's only a very rough estimate. And fluctuations are to be expected, especially at the beginning...

(Though if the "complexity" of the source varies a lot, big fluctuations may even happen towards the end)

[SeeMoreDigital]

If I input a video source which has a resolution of 1024x576 pixels. What "Custom x264 Parameter" string do I need to enter to resize the output to 720x576?


Cheers

[LoRd_MuldeR]

If I input a video source which has a resolution of 1024x576 pixels. What "Custom x264 Parameter" string do I need to enter to resize the output to 720x576?

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

[SeeMoreDigital]

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

I think I must be missing something. I placed the following code in the "Custom x264 Parameter" box: --resize:width=720,height=432,method=lanczos --sar 64:45

But all I got was: Process Exited with Error Code: -1

[LoRd_MuldeR]

Seems like you didn' read properly ;)

--video-filter <filter1>/<filter2>
You can 'chain' as many filter operations as you like together.
The available filters are:

[...]resize:[width,height][,sar][,fittobox][,csp][,method]

[nibus]

It's as "accurate" as it can be. It's only a very rough estimate. And fluctuations are to be expected, especially at the beginning...

(Though if the "complexity" of the source varies a lot, big fluctuations may even happen towards the end)

Done a couple 6+ hour encodes and haven't run into any issues. Thanks again for the feature implementation. :thanks:

[darkio]

works very well with aviutl fake avi too (vfapi codec). I prefer edit in aviutl instead avisynth, and then encode with simple 264 gui.
I think more x264 cli option (like vfw version) are welcome for future :)
However, thanks a lot !

[LoRd_MuldeR]

I think more x264 cli option (like vfw version) are welcome for future :)


You can enter any CLI option that you like into the "custom parameters" edit box - except for those that are reserved for the GUI.
https://gitorious.org/simple-x264-launcher/simple-x264-launcher/blobs/9a7ddf16c422ec23c8451d1313ddf7d9484e271a/ReadMe.txt#line123

[darkio]

I've a little question for you about gui. I've very old version x264 cli specified and compiled to use with firecoder blu card (toshiba's spursengine). it use some external libs to for hardware. The sdk are free but I'm not competent to recompile it with new x264 to use with simplegui. check version and then stop to work because is old. There is a ffmpeg encoder for spurs engine into sdk. I've read license, I know ask support for old version, but i wish to ask you if possible.

[LoRd_MuldeR]

I've a little question for you about gui. I've very old version x264 cli specified and compiled to use with firecoder blu card (toshiba's spursengine). it use some external libs to for hardware. The sdk are free but I'm not competent to recompile it with new x264 to use with simplegui. check version and then stop to work because is old. There is a ffmpeg encoder for spurs engine into sdk. I've read license, I know ask support for old version, but i wish to ask you if possible.

Please read here:
https://gitorious.org/simple-x264-launcher/simple-x264-launcher/blobs/9a7ddf16c422ec23c8451d1313ddf7d9484e271a/ReadMe.txt#line88

[icon]

I didn't try myself any of the latest versions (2.x) of Simple Launcher but the last branch behaves exactly like you want it to - you just need to drag&drop AVS file onto it instead of manual browse/open button.

This doesn't work for me with either the last stable or the experimental build. It still defaulted to the last save location.

I also tried to remove the settings files that are saved, but that didn't work either. I do agree though, that having the save location defaulting to the avs source location is a good idea.

[LoRd_MuldeR]

The program will remember the last directory where you saved a file.

If you open another input file later (e.g. via Drag&Drop), the default output file name will be generated in the last "save to" directory.

Thus it will not necessarily generate the default output name in the same folder where the source file is located, but of course this is still may happen.

(And I don't like to change the current behavior, because I usually keep my source files and my output files in different directories)

[icon]

Thanks for the explanation.

Another thought, any way to tweak the stats of the encode after resuming from pausing? It appears that the stats don't get reset based upon when the encode resumes, but are based upon when the initial encoding started, therefore given fps and etas that are not reliable. Unlike many I suppose, I use the pause and resume function a lot. Thanks for sharing such a great program.

[LoRd_MuldeR]

Another thought, any way to tweak the stats of the encode after resuming from pausing? It appears that the stats don't get reset based upon when the encode resumes, but are based upon when the initial encoding started, therefore given fps and etas that are not reliable. Unlike many I suppose, I use the pause and resume function a lot. Thanks for sharing such a great program.

The FPS and ETA values are calculated by x264. The GUI program just displays what x264 outputs to STDOUT. So you will have to ask the x264 devs about this ;)

(Though I think this issue was discussed before)

[SeeMoreDigital]

I know it might be a bit of a cheek... But is there any chance you could add some more encoding options to the "Add Job" GUI?

Perhaps something like this: -

http://img813.imageshack.us/img813/7989/guiproposal.png


Cheers

[LoRd_MuldeR]

It's impossible to add a GUI option for each CLI parameter that x264 supports, unless you want to create a bloated mess.

Adding only the "most important" ones also impossible, because every user has his/her own optionon on which options should be on the GUI and which not.

Consequently I want to keep the GUI as simple as possible and leave everything else for the "Custom Parameters" box ;)

[SeeMoreDigital]

That's a shame...

[darkio]

I know it might be a bit of a cheek... But is there any chance you could add some more encoding options to the "Add Job" GUI?

Perhaps something like this: -

http://img813.imageshack.us/img813/7989/guiproposal.png


Cheers

Can be a good idea very basic encoding options, but if you wan't use avisynth, I suggest (like me) to edit your clip/movie in aviutl with your personal settings like output resolution or resize, framerate, sharpness, crop, denoise, deinterlace or IVTC and many other settings, then save project to frame serve via vfapi codec into mulder's gui. Aviutl is like virtualdub with external plugin's system. You can set colorimetry too. Very usefull. VFAPIConv.exe must be used to convert aviutl project (.aup) into uncompressed fake avi.

[darkio]

possible save and load queues and up/down jobs in the future ? I can't see version history...

[LoRd_MuldeR]

possible save and load queues and up/down jobs in the future ?

If at all, we could only save jobs that are in the "enqueued" state. But I don't see much use for it.

The relevant properties of a job object would be the input/output paths and the encoder settings. But the encoder settings are already covered by the "template" system.

So instead of loading a job, you can simply "load" (re-add) the same source file again and choose the suitable template.

I can't see version history...

I do not really maintain a version history :o

But you can look at the Git repository commit log, if you like:
https://gitorious.org/simple-x264-launcher/simple-x264-launcher/commits/master

[Abyssal]

I would also like to see more basic stuff added to the Add Job GUI like resizing and stuff like that, just like SeeMoreDigital posted. Only adding a few things doesn't equal a bloated mess.

Anyway, is there any chance for 10bit x264 support? I tried replacing the 8bit x264 that's in the tools folder but got errors that made the program close itself.

Either way, been trying your program a few times and I think it's pretty good - looking forward to future updates. :-)

[Marin85]

@LoRd_MuldeR: Awesome little tool you have written there! I very much like it for keeping the interface so clean! IMHO, it is soo much cooler than MeGUI and much more responsive.

I hope you would not mind me making a few little suggestions:

S1) Bundle the 10-bit x264 in your application with a switch for 8-bit and 10-bit mode :p

S2) An option to apply a given encoding profile to all jobs automatically, i.e. without having to confirm with "yes" for every job (for instance useful when encoding anime or tv show series where using same encoding profile seems reasonable idea).

S3) An ability to multi-select jobs from the list and/or to clear all jobs. Plus it would be nice to be able to remove a job via "Del" or some other keyboard shortcut.

S4) An option to set the process priority for x264.

I also have two questions:

Q1) Would it be possible to include an auto-update function for the latest builds of x264?

Q2) How safe is the pause function? In other words, is there any danger of introducing glitches in the H.264 stream by pausing and then resuming the job?


Now, regarding adding additional GUI elements for the various x264 settings, here is my opinion for what it's worth: given that most of the x264 parameters have been well-established for some time now, I think the options worth tweaking can be reduced to a small number. Whoever wants to tweak what's not supposed to be tweaked can be assumed to have deeper knowledge in x264 settings and hence be familiar with the command line :rolleyes: People will finally stop f*cking with the i-p and p-b ratios :p Here is my suggestion to what could be added to the GUI:
- Levels, partitions and decimate;
- me range, me algorithm, subme;
- MV prediction and Trellis;
- psy-rd;
- qcomp and AQ;
- b-frames, b-adapt and b-pyramid;
- scenecut, ref frames, weight-p
- deblock

On the other hand, when I think about it, these are still quite many additional options and will probably overbloat the clean GUI. Plus, people tend to overlook "hidden" options when they see lots of GUI options, thinking that is all they need, but there are exceptions, of course. So, it might turn confusing for some.

Well, anyways, thanks again for the great utility!

PS: I have been lately thinkering something like this myself, but your utility is so much prettier. It just made my day as I discovered it tonight quite by accident. :o

[darkio]

Replace button for saving template configuration (boring typing every time for a single change) and full quote Marin85 for S1, S2S3 and S4 suggestion steps. Internal ARS calculator like this (http://forum.doom9.org/showthread.php?t=107039) can be very very usefull usefull !
There are many peoples can't use avisynth script, so we ask you to help us with some very very basic settings, like resize, deinterlace or detelecine, output resolution, framerate and other small stuff.
This is great gui for x264, and can be improved :)

[LoRd_MuldeR]

I would also like to see more basic stuff added to the Add Job GUI like resizing and stuff like that, just like SeeMoreDigital posted. Only adding a few things doesn't equal a bloated mess.

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)

Anyway, is there any chance for 10bit x264 support? I tried replacing the 8bit x264 that's in the tools folder but got errors that made the program close itself.

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

[LoRd_MuldeR]

S1) Bundle the 10-bit x264 in your application with a switch for 8-bit and 10-bit mode :p

I won't include 10-Bit builds in the distribution package, because it would make the package even bigger.

Also most people don't need 10-Bit, because h/w support for 10-Bit does not exist and it doesn't seem like the situation will change anytime soon.

The people who need 10-Bit encoding can simply replace the 8-Bit binaries with 10-Bit binaries. Should be straight forward...

(I consider 10-Bit H.264 a "niche" product, really!)

S2) An option to apply a given encoding profile to all jobs automatically, i.e. without having to confirm with "yes" for every job (for instance useful when encoding anime or tv show series where using same encoding profile seems reasonable idea).

I may think of a way to do that.

S3) An ability to multi-select jobs from the list and/or to clear all jobs. Plus it would be nice to be able to remove a job via "Del" or some other keyboard shortcut.

Selecting more than one job at a time is not possible, because the details will be shown for the currently selected job. What to show if multiple jobs are selected?

Adding some keyboard shortcuts may be possible though.

S4) An option to set the process priority for x264.

What's wrong with "below normal" priority?

Would it be possible to include an auto-update function for the latest builds of x264?

Sure. But somebody has to code it. And somebody would have to provide and maintain the update server.

I have no plans to do that at the moment...

How safe is the pause function? In other words, is there any danger of introducing glitches in the H.264 stream by pausing and then resuming the job?

As safe as it can be.

Pause will suspend the main thread in the x264 process. Unpause will resume that thread.

If that triggered a deadlock (or other unexpected behavior) in x264, the responsible "race condition" would have to be fixed in x264...

(Note: I have not encountered any problems so far)

- Levels, partitions and decimate;
- me range, me algorithm, subme;
- MV prediction and Trellis;
- psy-rd;
- qcomp and AQ;
- b-frames, b-adapt and b-pyramid;
- scenecut, ref frames, weight-p
- deblock

These all are covered by the x264 Preset/Tuning system, so 99.9% of all users should never have to mess with these settings manually!

The few users who really have a good reason to overwrite any of these settings, can add the required option to the custom parameters easily...

(If a user doesn't know how to deal with CLI parameters, that is a clear indication the user should stick with the Preset/Tuning system ^^)

[kypec]

I won't include 10-Bit builds in the distribution package, because it would make the package even bigger.

The people who need 10-Bit encoding can simply replace the 8-Bit binaries with 10-Bit binaries. Should be straight forward...

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

[LoRd_MuldeR]

@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 sounds like a feasible solution, if you really need to switch between 8-Bit and 10-Bit frequently.

Though be aware that you won't be able to launch two instances (e.g. the "8-Bit copy" and the "10-Bit copy") at the same time.

[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 :)

[guccimane]

Please tell me the x264 log is autosaved in v2 :|

[LoRd_MuldeR]

Please tell me the x264 log is autosaved in v2 :|

Nope, the log's won't be autosaved.

But each job will remain on the list after it has finished until you either delete it or exit the program. So you can go back to the log at any time.

It should be straight forward to copy&past the log into Notepad, if you really need to save it...

[guccimane]

Nope, the log's won't be autosaved.

But each job will remain on the list after it has finished until you either delete it or exit the program. So you can go back to the log at any time.

It should be straight forward to copy&past the log into Notepad, if you really need to save it...

I really needed it and exited the program on accident thinking I'd be able to find the log in %appdata% like V1, but after looking through the code in the repo I realized i was out of luck. :c

[LoRd_MuldeR]

I may add an option to auto-save the logs to the preferences dialog in a future version.

[kypec]

I may add an option to auto-save the logs to the preferences dialog in a future version.
That would be much welcome, TIA!

[lansing]

can you extend the process killing countdown? I've running a heavy script on a 1080 source, and it took quite some time to even start, and then the "warning: x264 did not respond for 60 seconds..." comes up, some time it just kills the whole thing at the start. This last two days I was trying to do it again, both tries the process were timeout on the 10% mark, it's very frustrating.

[LoRd_MuldeR]

Are you using FFmpegSource as your source filter?

[lansing]

Are you using FFmpegSource as your source filter?

i'm using FFmpegSource2

[LoRd_MuldeR]

i'm using FFmpegSource2

FFmpegSource(2) will create an index file first when it opens the source file. This can result in your Avisynth script taking extremely long to initialize for "big" source files :eek:

I highly recommend to create the index file beforehand with the help of ffmsindex.exe. Then pass the path to the index file in your call to FFVideoSource or FFAudioSource.

[lansing]

FFmpegSource(2) will create an index file first when it opens the source file. This can result in your Avisynth script taking extremely long to initialize for "big" source files :eek:

I highly recommend to create the index file beforehand with the help of ffmsindex.exe. Then pass the path to the index file in your call to FFVideoSource or FFAudioSource.

i already has the .ffindex file created in the same folder. Or do you mean I should use FFVideoSource to load the video instead of FFmpegSource2?

[LoRd_MuldeR]

FFmpegSource2 is the name of the project/plugin. The functions provided by FFmpegSource2 are called FFVideoSource() and FFAudioSource().

I mean that you should create you index file beforehand with ffmsindex.exe and then use FFVideoSource() or FFAudioSource() in a way like this:

FFVideoSource("C:\Path to Source\source.mkv", cachefile="C:\Path to Source\source.ffindex")

At the moment when your Avsiynth script is loaded, the index file "C:\Path to Source\source.ffindex" should already exist.

[lansing]

FFmpegSource2 is the name of the project/plugin. The functions provided by FFmpegSource2 are called FFVideoSource() and FFAudioSource().

I mean that you should create you index file beforehand with ffmsindex.exe and then use FFVideoSource() or FFAudioSource() in a way like this:

FFVideoSource("C:\Path to Source\source.mkv", cachefile="C:\Path to Source\source.ffindex")

At the moment when your Avsiynth script is loaded, the index file "C:\Path to Source\source.ffindex" should already exist.

oh, i always thought that the index file will be auto loaded with the video file whenever the source filter was called.:eek:

I try and see what happen, thanks.

[LoRd_MuldeR]

Well, I think the cachefile defaults to the path of the source file + ".ffindex", but that file normally won't exist before you load your Avisynth script for the first time.

If the index file does not exist yet, then FFMS2 will generate the index file during the initialization of your Avisynth script. This can take very long (for big source file) and thus may cause your script to trigger a timeout.

By generating the index file beforehand with the ffmsindex.exe application you can avoid this kind of problem...

[lansing]

updating my problem, i just encoded for 4 hours to 10% done, and this time i was there to see the error. It was avs2yuv_x86.exe crashing that was causing the timeout, and it was one of my virtualdub plugin i used that was causing the crash.:(

[LoRd_MuldeR]

updating my problem, i just encoded for 4 hours to 10% done, and this time i was there to see the error. It was avs2yuv_x86.exe crashing that was causing the timeout, and it was one of my virtualdub plugin i used that was causing the crash.:(

If avs2yuv_x86.exe crashes, you obviously have another problem.

It's a problem with Avisynth or, more likely, one of the Avisynth plug-in's involved. Crash has nothing to do with a timeout!

(Any message about a "timeout" would only be an incidental symptom of the crash that has occurred)

[shinchiro]

updating my problem, i just encoded for 4 hours to 10% done, and this time i was there to see the error. It was avs2yuv_x86.exe crashing that was causing the timeout, and it was one of my virtualdub plugin i used that was causing the crash.:(
It might be possible that the source was corrupt. Try checking its crc32

[hunter_aran]

Wow. This tool is awesome! Is doesn't crash all the time like MeGUI and the speed up is very helpful!

Sorry if this has already been mentioned (tried reading through then searching again), but I'm having a problem with the aspect ratio as far as what is being reported in Mediainfo.

I generate a file (h264 or Mp4, doesn't matter) and then set the same DAR in the container when muxing. The PAR/SAR and DAR are the same and Mediainfo keeps showing two lines, one for "original aspect ratio" and another for "display aspect ratio". Now I've been told that when both lines are present and contain the same ratio (ie 4:3), this means that the aspect ratio in the stream and container vary, even if it is a small percent.

I have tried setting the SAR/PAR in x264 at 8:9, which is the correct AR and looks perfect and I have tried NOT setting it in x264 and instead writing it to the stream in YAMB/MP4box and it doesn't matter! Mediainfo always lists two lines for the AR. This is the same workflow I was using for stuff in MeGUI, so I am pretty sure the muxing programs (MP4Box and Subler) are not to blame. But no matter what I do, I can't get the files output by this program to match up the container and stream AR.

Any ideas? I really really want to switch over to this and dump Megui completely... :)

[LoRd_MuldeR]

You can use the "--sar" option to set the desired Sample (Pixel) Aspect Ratio.

[richeerichhh]

Just updated to version 2 of A Simple x264 Launcher. For some reason I keep getting these two messages when I start the program.
http://dl.dropbox.com/u/1045428/aviSerror01.PNG
followed by
http://dl.dropbox.com/u/1045428/aviSerror02.PNG

I have AviSynth (32-bit) installed. I know it works because I use it with AvsP and it works fine with the old A Simple x264 Launcher.

The wierd thing is that when I'm transcoding my BluRay's it plays well with AviSynth, despite the warning. But if I'm trancoding a DVD, using DGDecode, it won't work.
Now mind you it does work quite nicely in the old x264 launcher. Any solutions as to what could be causing this?

Thanks in advance.

[LoRd_MuldeR]

Well, the program will load the Avisynth.dll (the 32-Bit one!) and, if the DLL could be loaded, check the Avisynth version number.

So the warning indicates that either the Avisynth.dll could not be loaded or that the version number could not be detected or that the version number was smaller than 2.5.

Note that you might be able to get more detailed info on what the problem is by launching the program with the "--console" parameter.

[richeerichhh]

Thanks for your response, I'm running AviSynth version 2.58.

http://dl.dropbox.com/u/1045428/aviVersion.PNG

however this is what I got when I ran the launcher with the "--console" parameter.

http://dl.dropbox.com/u/1045428/launcher-debug.PNG

[hunter_aran]

You can use the "--sar" option to set the desired Sample (Pixel) Aspect Ratio.

Yes when I do this and set --sar 8:9 and then set the same thing when muxed, mediainfo still displays the two lines indicating that there is a discrepancy.

[richeerichhh]

What muxing program are you using? MKVToolnix/MKVMerge? What kind of file container are you encoding too. I would suggest encoding to a MKV file and see if that helps. Also don't set the DAR while muxing, let the x264 launcher set it for you.

[LoRd_MuldeR]

however this is what I got when I ran the launcher with the "--console" parameter.

This means that Avisynth triggered a crash (exception) while the version number is queried.

According to your screenshot, however, you are using the official 2.58 release of Avisynth, which is the latest "official" release and the version that I use too.

Are you 100% sure there aren't several Avisynth DLL's floating around on your system? AvsP might actaully be using a different DLL...

It might also be worth a try to clean-up your Avisynth plug-in's directory. Wouldn't be the first time that some buggy/deprecated plug-in DLL causes trouble!

[richeerichhh]

Thanks for your help. Where about should I go looking for AviSynth.dll? System32 folder? Or what .dll file am I looking for specifically? I'll also clean out my AviSynth plug-in folder to see if that helps any.

The thing that gets me though, is that your original "Simple x264 Launcher" work without errors with my current configuration. Any idea why that would be?

[LoRd_MuldeR]

Thanks for your help. Where about should I go looking for AviSynth.dll? System32 folder? Or what .dll file am I looking for specifically? I'll also clean out my AviSynth plug-in folder to see if that helps any.

The DLL search order on Windows is as follows:

The directory from which the application loaded, i.e. where the EXE file is located.
The system directory. Use the GetSystemDirectory() function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory() function to get the path of this directory.
The current directory. This can be anything depending on how the application was launched!
The directories that are listed in the PATH environment variable.


The application will load the first "Avisynth.dll" that it will find in any of these directories - in DLL search order.

The thing that gets me though, is that your original "Simple x264 Launcher" work without errors with my current configuration. Any idea why that would be?

The old version didn't even check for Avisynth :rolleyes:

[richeerichhh]

BTW I'm running Win 7 Ultimate x64.

Okay so I uninstalled and reinstalled AviSynth. It is currently in its default settings. Even the plugin directory contains only the default plugins. While it was installing I snapped a screenshot of where it put it's dll's.
http://dl.dropbox.com/u/1045428/AVSinstall.PNG
Looks correct right? Except where did it really install those two files? Here!
http://dl.dropbox.com/u/1045428/here.it.is.PNG

Strangely enough, I used those two functions you suggested to find my System Directory. This is what it gave me.

http://dl.dropbox.com/u/1045428/getsysinfo.PNG
The information makes sense to me. It also makes sense that SysWOW64 would be the 64 bit System directory. However I didn't or wouldn't install AviSynth 64 bit. Another weird thing is that if I move the two files (avisynth.dll & devil.dll) to the System32 directory AviSynth fails to work on both AvsP and your original version of "A Simple x264 Launcher" I tried to move one and both files to the "Simple x264 Launcher" directory but it failed to load.

http://dl.dropbox.com/u/1045428/doesnt.wrk.in.dir.PNG

So if the launcher is searching the System Directory which in my case is System32, but AviSynth installed the .dll's in SysWOW64 then it would make sense that it couldn't find them. However it still doesn't make sense that it doesn't find AviSynth when I put both .dll's into the launcher's .exe directory, especially if it searches it first.

I also tried putting the .dlls in the 16-bit directory which is C:\Windows\System, but that didn't work, or did placing them in any of the folders in my PATH. Thoughts?

[LoRd_MuldeR]

The information makes sense to me. It also makes sense that SysWOW64 would be the 64 bit System directory. However I didn't or wouldn't install AviSynth 64 bit. Another weird thing is that if I move the two files (avisynth.dll & devil.dll) to the System32 directory AviSynth fails to work on both AvsP and your original version of "A Simple x264 Launcher" I tried to move one and both files to the "Simple x264 Launcher" directory but it failed to load.

On 64-Bit Windows the "system" directory for 32-Bit applications (the one that would be relevant here) is located at:
C:\Windows\Syswow64

At the same time the "system" directory for 64-Bit applications is located at:
C:\Windows\System32

But to make things even more complex, a 32-Bit application will see "Syswow64" as "System32", unless File System Redirection is disabled.


Anyway, your error message means that the Avisynth DLL was loaded. It only crashed in the code that determines the version number.

That's why I though there might be different DLL's on your computer, e.g. one in the "system" folder and another one in the AvsP directory.

In that case AvsP would use its own DLL, while Simple x264 Launcher would fall back to the DLL from the "system" folder.

It was just an idea! Still you may give the Dependency Walker (http://www.dependencywalker.com/) a try, which will show you the DLL that is used. Just be sure to press F7.

I also tried putting the .dlls in the 16-bit directory which is C:\Windows\System, but that didn't work, or did placing them in any of the folders in my PATH. Thoughts?

Normally you put the Avisynth.DLL into the "System32" folder (or "Syswow64" on 64-Bit Windows) and that's it.

That's also where the installer will install the DLL.

(If the installer says it installed the DLL to "System32", this actually means "Syswow64" on 64-Bit Windows, due to the File System Redirection)

[hunter_aran]

What muxing program are you using? MKVToolnix/MKVMerge? What kind of file container are you encoding too. I would suggest encoding to a MKV file and see if that helps. Also don't set the DAR while muxing, let the x264 launcher set it for you.

I made sure there was nothing in the script to signal DAR, only --sar in the x264 options. If there is another way to set it in the program, I don't know it. If I do not set --sar and instead add it later using mp4box it does the same thing. In the past mp4box was able to overwrite any wrong aspect info in the stream so i am confised why it doesn't work now. I'll try mkv and see if it makes a difference...

I am primarily using Subler to add the aspect in the container for correct quicktime display (this was the only guaranteed way I've found to do this) and for apple devices. Subler works with other files created by Megui and Handbrake as we speak, so I don't think it's broken. Maybe it's a mediainfo problem?

[hunter_aran]

When I try creating an mkv, mediainfo reports one line, "display aspect ratio" only but when I remux to mp4 it still creates two lines. Could x264 be rounding some numbers here to create an sar that's a small percent off? That's what MeGUI was doing until I realized there was a setting for acceptable aspect error and it was at 2%. After changing to 0%, the files were perfect with the aspect ratios matching. I am at a loss still why mp4box can't correct this after the fact, since it was able to before.

The funny thing is that there is no cropping on these files, they are 640x480 so this was supposed to be easier...

Any help is appreciated. Thanks.

[laserfan]

The DLL search order on Windows is as follows:

The directory from which the application loaded, i.e. where the EXE file is located.
The system directory. Use the GetSystemDirectory() function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory() function to get the path of this directory.
The current directory. This can be anything depending on how the application was launched!
The directories that are listed in the PATH environment variable.

The application will load the first "Avisynth.dll" that it will find in any of these directories - in DLL search order.

On 64-Bit Windows the "system" directory for 32-Bit applications (the one that would be relevant here) is located at:
C:\Windows\Syswow64

At the same time the "system" directory for 64-Bit applications is located at:
C:\Windows\System32

But to make things even more complex, a 32-Bit application will see "Syswow64" as "System32", unless File System Redirection is disabled...

...Still you may give the Dependency Walker (http://www.dependencywalker.com/) a try, which will show you the DLL that is used. Just be sure to press F7.

Normally you put the Avisynth.DLL into the "System32" folder (or "Syswow64" on 64-Bit Windows) and that's it.

That's also where the installer will install the DLL.

(If the installer says it installed the DLL to "System32", this actually means "Syswow64" on 64-Bit Windows, due to the File System Redirection)

LM you are a treasure-trove of good information today. I have added the above to my "tips" file, thank you very much. :)

[dado023]

hiya,

are there any templates for download, for example template for youtube HD.....you hope you know what i mean :)

[LoRd_MuldeR]

No, there are no "pre-built" templates available for download. And you shouldn't need any!

Since x264 has added the Preset/Tuning system, configuring x264 has become straight forward. There are no "secret" options or "magic" values you need to know ;)

If at all, configuring x264 to create a BluRay-compatible stream requires some additional knowledge. But x264bluray (http://sites.google.com/site/x264bluray/) has all the info you need for that...

[dado023]

thanks for the fast response :)

since i need to upscale some videos to 1080p, i will have to use avs script, so i have done a bit googling around and found this http://goo.gl/296HY
I wonder what version of avisynth build, for this task, do you prefer on 32bit system on quadcore CPU?

[LoRd_MuldeR]

thanks for the fast response :)

since i need to upscale some videos to 1080p, i will have to use avs script, so i have done a bit googling around and found this http://goo.gl/296HY
I wonder what version of avisynth build, for this task, do you prefer on 32bit system on quadcore CPU?

There is no need to go the Avisynth route, just for resizing. It's possible to use Avisynth, for the task, of course. And the stable Avisynth v2.58 is fine.

But x264's internal resize filter should work just as well here. You can simply add "--video-filter resize:width=1280,height=720,method=spline" to the advanced options!

BTW: Why do you need to upsize at all? Upsizing some SD source video to HD resolution doesn't magically make it "HD quality" ;)

[dado023]

hey, thanks for the x264 resize info, i didn't know it was built in...now i see in wiki it even has crop :)

y, i am aware there is no gain in quality when upsizing, but i use it for youtube upload 1080p, so when youtube re-compresses it it gives more bitrate to video, at least that is what i have read in few youtube related threads....

[hunter_aran]

Just an update, I found out by trial and error that certain files are creating the aspect problem so it's nothing to do with this program or the version of x264. I don't understand why some episodes on this dvd have a par of 8:9 while others do not even though they display the same at 4:3. Might be that ITU thing which I don't completely understand yet. Kinda stupid if the dvd uses different PAR on different videos. Anyway, carry on. :rolleyes:

[r0lZ]

Hi Lord! I have exactly the same problem as richeerichhh, after a fresh install of Avisynth 2.5.8 (Dec 22, 2008).

Previously, I had two different avisynth.dll files: the one installed with the normal Avisynth installer (I don't remember the exact version number, but it was a v2.5), and another version installed by Format Factory, in its own directory. That second version was registered in my registry, and I think it was used by my scripts. Your program worked very well.

I've decided to uninstall FF and Avisynth, and re-install the latest Avisynth version, to get rid of the multiple avisynth dlls floating around. Since the new install, I have the same error message "Exception in Avisynth initialization code!". As far as I know, there is now only one avisynth.dll on my system. Could it be a bug in the dll?

BTW, can I suggest to print the path of the dll that is being checked to the console?

I'm running Win7 x64.

BTW, I have also another suggestion. Could you add a "Use input folder" checkbox near the output field? Currently, I have to change the path of the output file each time I drop an AVS script on the program's window, and it's a pain (especially when I forget to change the path and I close the window after the encoding process, as I don't know where the 264 file has been saved). Thanks in advance!

[LoRd_MuldeR]

First of all, there is no registry entry that tells applications where the Avisynth DLL is located, when using the "native" interface.

The DLL will be located (and loaded) according to the DLL search order:
http://forum.doom9.org/showpost.php?p=1572343&postcount=776

(Things would be different if we were talking about a COM/ActiveX DLL, like DirectShow filters. But that's not the case here!)

However there is a registry entry to indicate the path of the Avisynth Plugin's directory! And this one indeed might have changed on your system recently.

If Avisynth causes an unhandled exception during initialization, it means that Avisynth (or more likely one of the various Plugin DLL's!) has a bug.

Either that, or my application is calling the Avisynth DLL in an invalid way that triggers the crash. But it works fine for me. With Avisynth 2.58, on Windows 7 (x64).

Also my code to load the Avisynth DLL and check the version number (that's all I do!) was borrowed from x264's Avisynth input module ;)

I suspect it's some buggy Plugin DLL (or some DLL loaded by one of the Plugin DLL's) that causes the trouble! Certainly wouldn't be the first time...

[r0lZ]

I suspect it's some buggy Plugin DLL (or some DLL loaded by one of the Plugin DLL's) that causes the trouble! Certainly wouldn't be the first time...
Right! I've found the culprit: ffavisynth (http://avisynth.org.ru/docs/english/externalfilters/ffavisynth.htm). More precisely, if I remove ffavisynth.avsi, there is no crash any more. That script contains only:Load_Stdcall_Plugin("ffavisynth.dll")
I still don't know if it's the ffavisynth.dll that causes the crash, or the way it is loaded by the avsi, but the problem is solved. Thanks for your tips!

BTW, will you consider my suggestion to add the "Use input folder" checkbox?

[LoRd_MuldeR]

Right! I've found the culprit: ffavisynth.

Why I am not surprised? :)

BTW, will you consider my suggestion to add the "Use input folder" checkbox?

Normally the x264 Launcher will remember the last "save to" directory. I think that should work fine for most users!

But I see that it won't work if you encode from AVS files located in different directories each time and always want to save the output file in the same directory as the corresponding source.

Will consider adding an option for this purpose...

[r0lZ]

But I see that it won't work if you encode from AVS files located in different directories each time and always want to save the output file in the same directory as the corresponding source.

Will consider adding an option for this purpose...It's exactly what I am doing.

Thanks!

[LoRd_MuldeR]

r0lZ, please try with the new build.

[r0lZ]

Hum, I see no differences. What change should I test?

[LoRd_MuldeR]

Hum, I see no differences. What change should I test?

I added an option "Save output to the same folder where the source is located", which should be exactly what you requested ;)

(If you can't see that option, make sure you have downloaded build #340)

[r0lZ]

Oh, yes, sorry! I've looked for that option in the Add Job dialog. :rolleyes:
Anyway, it does exactly what I wanted. Thanks again!

[wiak]

holy monkeys you update this?, thx a million i kinda liked this one

[r0lZ]

Another suggestion: can you add an option to fall back to Avisynth 32bit when an avisynth script cannot be rendered with avisynth x64? I have sometimes several encodes in the queue. Most of them are compatible with avisynth x64, but some are not, because they use a 32bit plugin. It is a pity to have to wait for the 64bit batch to complete to launch another batch in x32 mode. (Another way to solve that problem would be to put the x64 option in the New Job dialog, to allow the user to specify it on a per script basis, but personally I think it is better to try the x64 mode anyway. However, I'm not sure you can do it, as currently, when a script fails, the avisynth error is correctly printed to the log, but the launcher concludes that the rendering was successful.)

Also, maybe I haven't looked at the right place, but after having enabled the option to save the log automatically when the job is finished, I can't find it in the destination directory. Is it a bug?

[LoRd_MuldeR]

Another suggestion: can you add an option to fall back to Avisynth 32bit when an avisynth script cannot be rendered with avisynth x64? I have sometimes several encodes in the queue. Most of them are compatible with avisynth x64, but some are not, because they use a 32bit plugin. It is a pity to have to wait for the 64bit batch to complete to launch another batch in x32 mode.

No, that's not possible. If x264 or AVS2YUV fails to open the input, e.g. because the Avisynth script failed to initialize, the GUI cannot know why it failed. In that case it's up to the user to read the error message (from the log) and correct his mistake. In theory the GUI could parse the error message and try to guess the reason for the problem. But a missing plugin will probably result in a "Script error: there is no function named Foobar" message. There are several reasons why a such error could appear. A missing plugin (or 64-Bit Avisynth being unable to load the 32-Bit plugin) is only one possibility out of many. In most cases a simple typo will be the cause of this kind of error...

Also, maybe I haven't looked at the right place, but after having enabled the option to save the log automatically when the job is finished, I can't find it in the destination directory. Is it a bug?

Should be located at:
%LOCALAPPDATA%\LoRd_MuldeR\Simple x264 Launcher\logs

[r0lZ]

No, that's not possible. If x264 or AVS2YUV fails to open the input, e.g. because the Avisynth script failed to initialize, the GUI cannot know why it failed. In that case it's up to the user to read the error message (from the log) and correct his mistake. In theory the GUI could parse the error message and try to guess the reason for the problem. But a missing plugin will probably result in a "Script error: there is no function named Foobar" message. There are several reasons why a such error could appear. A missing plugin (or 64-Bit Avisynth being unable to load the 32-Bit plugin) is only one possibility out of many. In most cases a simple typo will be the cause of this kind of error...
I understand. But I suggested that feature as an option, so that, if the x64 version fails, the program could try the x32 version anyway. Of course, that second try may fail too, but it will probably succeed if it's just a x32 plugin problem. Of course, if it fails twice, the user will have to fix the typo normally. At least, it should be possible to render most scripts. (Anyway, I test all my scripts in AvsPmod and with a player before launching the encoding.)

Should be located at:
%LOCALAPPDATA%\LoRd_MuldeR\Simple x264 Launcher\logs
Thanks!

[wiak]

hey lord, please add basic audio demux/muxing support and it will be perfectly simple :)
no need for any encoding like MeGUI, just demux the original audio and mux it into mkv with the time delay if there is any
keep up the good work, its seems stable on my computer

[LoRd_MuldeR]

hey lord, please add basic audio demux/muxing support and it will be perfectly simple :)
no need for any encoding like MeGUI, just demux the original audio and mux it into mkv with the time delay if there is any
keep up the good work, its seems stable on my computer

Please read the section about audio encoding from the Readme file!

[docholliday]

Hi Dude
How To use (Simple x264 Launcher) software...?
Can you Help me ?
Example : I want to encode m720p and how to setup software
Thanks Mate
---------------
I want this command-line to enter simple x264 software

x264-- 1280*544 -- bitrate 2600 -- ac3 5.1 48000 448 Kbps -- mkv -- 23.976 fps

what is the command-line ?

Thanks mate

[LoRd_MuldeR]

Hi Dude
How To use (Simple x264 Launcher) software...?
Can you Help me ?
Example : I want to encode m720p and how to setup software
Thanks Mate
---------------
I want this command-line to enter simple x264 software

x264-- 1280*544 -- bitrate 2600 -- ac3 5.1 48000 448 Kbps -- mkv -- 23.976 fps

what is the command-line ?

Thanks mate

This is a GUI program. The program itself does not use or need a command-line.

Moreover it will generate the command-line that is needed to call the encoder for you. And, as this is a front-end to x264, audio encoding is not currently possible.

...with the exceptions mentioned in the README file.

[michaelusa]

...with the exceptions mentioned in the README file.

Is the Readme file up to date? or am I missing something?
I pulled down the latest (I think..) JEEB x264 revision 2184 from http://x264.nl/, tested the --acodec option and it worked fine. Copying that version to the Launcher/toolset folder invokes an out-of date message. "Your revision of x264 is too old. Minimum required revision is 2189"
Please help, Regards Michael.

[LoRd_MuldeR]

Is the Readme file up to date? or am I missing something?
I pulled down the latest (I think..) JEEB x264 revision 2184 from http://x264.nl/, tested the --acodec option and it worked fine. Copying that version to the Launcher/toolset folder invokes an out-of date message. "Your revision of x264 is too old. Minimum required revision is 2189"
Please help, Regards Michael.

I don't think the builds from http://x264.nl/ (although built by JEEB too now) include the audio support patch!

The builds from JEEB's web-site do include that patch. But, as you have noticed, JEEB has't updated these builds for a while. They're still at r2184.

You either have to wait for JEEB to update his patched builds or you must decrease the minimum required x264 version manually.

(The Simple x264 Launcher contains that check to prevent people from encoding with outdated x264 versions - as many people tend to do)

[michaelusa]

Thanks for the quick response. I sent JEEB a question regarding an upgrade, Lets see what comes back.

[shinchiro]

I think option to minimize to system tray when close might become handy too

[LoRd_MuldeR]

I think option to minimize to system tray when close might become handy too

I will look for a way to implement this.

[VideoFanatic]

Hi, I have a 4:3 720 x 576 video. Is the following the correct SAR to use?: 12:11

[LoRd_MuldeR]

720/576 * 12/11 = 1,363 ≈ 4/3

[dado023]

isnt --fps valid x264 parameter? why do i get this error:
http://i48.tinypic.com/2j3h7yf.jpg

[stinman]

Haven't been here in awhile, once again this gets better and better. I know audio is important but most will just re-mux the same audio back in, I would think, or just use the dts core. I love "Simple" x264 launcher and don't want it bloated up. Thanks again LoRd MuldeR!

[dado023]

how can i force it to encode in 24fps?

[Kaiser Bill]

Hi LoRd_MuldeR. Want to thank you for this great app, which has now become the only one I use for converting from Avisynth scripts.

Would it be possible to add an option to hibernate after finishing any jobs rather than just shutdown? I very rarely use shutdown on my PC any more so hibernate would be a welcomed option, and the only addition I would really like to see.

[VideoFanatic]

OK here's another one. I have a 352 x 576 PAL video. I would like an aspect ratio of 2.39:1. What calculation would I do in Wolfram Alpha to find out the SAR to use?

[kypec]

OK here's another one. I have a 352 x 576 PAL video. I would like an aspect ratio of 2.39:1. What calculation would I do in Wolfram Alpha to find out the SAR to use?
I'd use --sar 43:11 which yields to 2.3888888888888888888888888888889 display aspect ratio. If you wanted to have 2.39:1 DAR precisely, the resulting SAR would be 2151:550 and I'm not sure if x264 (or H.264 specs) allow for such big numbers :(
The final error from 43:11 is negligible anyway, less than a pixel in horizontal resolution so no one cares about anyway.:)

[SeeMoreDigital]

OK here's another one. I have a 352 x 576 PAL video. I would like an aspect ratio of 2.39:1. What calculation would I do in Wolfram Alpha to find out the SAR to use?Here you go: -

http://i45.tinypic.com/2zdu9hj.png

[VideoFanatic]

Awesome tool. Thanks I will use that from now on. Just a question though. Mulder said for a 720 x 576 clip I should use 12:11 however your tool says 16:15. Which is correct? I tried both methods and both videos look the same as each other.

[SeeMoreDigital]

Awesome tool. Thanks I will use that from now on. Just a question though. Mulder said for a 720 x 576 clip I should use 12:11 however your tool says 16:15. Which is correct? I tried both methods and both videos look the same as each other.12:11 conforms to the ITU (International Telecommunication Union) standard. And is the method used for correcting the shape of non-square pixel standard-definition media.

16:15 is mathematically correct. And is the method used for correcting the shape of non-square pixel high-definition media.

[VideoFanatic]

So is it OK to use either method? I want the video to look the same no matter what device it's played on.

[Keiyakusha]

Can someone give me some tips how should I run avs2yuv to encode 10bit YV16 interleaved avisynth_x86 input into 10bit high422 profile? What should I add in commandline with or without Simple x264 Launcher?
For example with avs4x264mod this works for me:
avs4x264mod.exe --x264-binary "x264_10bit_x64.exe" --output-csp i422 --input-depth 10 --output "out.mkv" "xx.avs"
But with avs2yuv I always end up with corrupted video...

[icon]

I have a question about performance. Normally I use an avs script for the input. Simple script with mostly cropping. I seem to be able to utilize my 8 virtual cores, nearly 100% utilization.

Now I am using an avs script to resize using this filter command:

LanczosResize(480,272) # Lanczos (Sharp)

and it seems that my cpu utilization is around 20%. What gives? Is it cause this resize filter is not multithreaded? Any way to fix it? I know when I tried similar settings within Handbrake, it seemed to utilize my cpu 100%. Thanks for any help and great job with this program.

[dado023]

cant you use inbuilt x264 filter to do this?

[LoRd_MuldeR]

AFAIK, there is no multi-threading implemented in the Avisynth built-in resize filters. At least in the "official" (non-MT) version of Avisynth. With Avisynth-MT your may be able to use multi-threading.

Nonetheless I doubt a simple LanczosResize() alone can be the bottleneck. Compared to the CPU time spent in x264 (even with rather "fast" settings), the CPU time spent for the resize filter should be negligible!

So I suspect there is more than this going on in your Avisynth script or the bottleneck is not Avisynth. Anyway, dropping Avisynth and using x264's built-in FFMS2 and built-in filters is definitely worth a try...

[VideoFanatic]

Where do I find the log file for Simple x264 Launcher? There doesn't seem to be an option in the program to display the log.

[LoRd_MuldeR]

Where do I find the log file for Simple x264 Launcher? There doesn't seem to be an option in the program to display the log.

The lower pane is showing the log, when you select a job from the upper pane ;)

If you are looking for the location where the log's are achieved, when the "automatically save log" option is enabled, look at:
%LOCALAPPDATA%\LoRd_MuldeR\Simple x264 Launcher\logs

[VideoFanatic]

The lower pane is showing the log, when you select a job from the upper pane ;)

If you are looking for the location where the log's are achieved, when the "automatically save log" option is enabled, look at:
%LOCALAPPDATA%\LoRd_MuldeR\Simple x264 Launcher\logs

Where is the "automatically save log" option as I don't see it. I'm using version 2.04.295 of your program. I also can't see any log files in that location! Is this the correct location?

C:\Users\Dave\AppData\Local\LoRd_MuldeR\Simple x264 Launcher

My problem is I'm using the MT version of Avisynth and I've replaced the avisynth.dll in the System 32 folder with the file from MT. However when I try to encode the video in Simple x264 Launcher it crashes and I get the following message "avs2yux_x86.exe has stopped working". Yet if I encode with HC Encoder I don't get any problems.

[LoRd_MuldeR]

Where is the "automatically save log" option as I don't see it.

Look at preferences dialog ;)

I'm using version 2.04.295 of your program. I also can't see any log files in that location! Is this the correct location?
C:\Users\Dave\AppData\Local\LoRd_MuldeR\Simple x264 Launcher

Time to update. Also log's won't be saved unless you enable that option.

My problem is I'm using the MT version of Avisynth and I've replaced the avisynth.dll in the System 32 folder with the file from MT. However when I try to encode the video in Simple x264 Launcher it crashes and I get the following message "avs2yux_x86.exe has stopped working". Yet if I encode with HC Encoder I don't get any problems.

I can't tell you why Avisynth MT is crashing with your script. Also I can't tell you why the crash isn't triggered with HC Encoder.

But the "MT" branch of Avisynth is known to be an unstable mess. And there are various Avisynth MT builds of quite varying "quality" floating around.

So I guess you'll have to ask SEt or whoever is currently working on this, if you want that crash fixed...

[VideoFanatic]

I want to install the new version of your program . Should I uninstall the old version first? Also I can't see any option to uninstall it from the start menu. How do I uninstall it?

[LoRd_MuldeR]

I want to install the new version of your program . Should I uninstall the old version first? Also I can't see any option to uninstall it from the start menu. How do I uninstall it?

The application does not "install" anything (the setup program simply extracts the required program files to the selected directory), so there is no need to "uinstall" it.

You can simply delete the folder containing the program files, if you don't need it any longer. And of course you can simply "install" a newer version into the same folder, replacing the older version.

[icon]

cant you use inbuilt x264 filter to do this?

What would be the extra command to do this in x264?

I want the width to be 480 and the height to be whatever is necessary to keep the same sar as the original source. I can't quite get my arms around the syntax.

Edit - I figured out the syntax. Works pretty well. Actually like it better than using avisynth scripts. It gives me about a 25% boost on encoding performance, but still under utilizing my cpu. It looks like when I resize with avisynth, it uses 4 cores and when I resize with x264 it uses 6 cores. When I don't resize at all it uses 8 cores. - weird.

[LoRd_MuldeR]

Given that you haven't screwed up the "--threads" option, if x264 doesn't produce 100% CPU load, this usually has one of the following two reasons: Either you are bottlenecked by slow input (slow decoder, slow pre-processing filters, etc) or you are using very "fast" x264 settings. In the latter case it can happen that the non-parallelizable parts of x264 become more dominant. By using "slower" settings, you may be able to increase the CPU load in that case...

[icon]

Simple tests show it must be something to do with the resize filters. Resizing in Avisynth script or directly through x264 gives a low cpu utilization. No resizing, not changing anything else, gives me 100% cpu utilization. If that's the way it is, then that's the way it is.

On a separate note, could you consider putting the container format as an option that can get saved with the profile? I seem to be making 1/2 encodes in mkv format and 1/2 in mp4 format. Unfortunately, I seem to forget a lot to switch between the 2 formats manually, causing a lot of extra demuxing. Thanks.

[LoRd_MuldeR]

I still believe you must be using very "fast" encoder settings, if the resize filter becomes the bottleneck.

Try to use a lower x264 preset. Of course this won't be improve the encoding speed, but you may at least be able to squish out better quality at the same speed - by utilizing the CPU time that your CPU cores are idling at the moment...

[icon]

I always use 'slow'. I have never resized before, so I have no benchmarks really besides my recent observations. But I agree something doesn't make sense.

[VideoFanatic]

If my video is interlaced I was using the following: --tff

If the video is progressive do I simply delete that text?

[LoRd_MuldeR]

If my video is interlaced I was using the following: --tff

If you interlaced source is "top-field first" and you want to keep it interlaced, then that is the right option to set.

If the video is progressive do I simply delete that text?

Correct. Progressive video isn't field-based, thus you don't need interlaced encoding mode (and of course setting a field-order makes no sense either).

[mini-moose]

I was just told about this app and trying it now. It's very useful.

A couple things I wanted to ask/suggest

1) --level setting seems to not be added. Sure I can add it to custom parms and save it as a profile but in my opinion it's something important enough to be part of the main settings as it contributes a lot to compatibility.

2) 2-pass option - doesn't offer adding custom parms for each pass. For example I think it's not really necessary to use -o on first pass if you're using 2-pass.

3) the main difference between the builds is the x264 revision I assume? In which case I can just replace the exe when a new one is out. Unless the avs2yuv builds are often updated too?

thanks

[LoRd_MuldeR]

1) --level setting seems to not be added. Sure I can add it to custom parms and save it as a profile but in my opinion it's something important enough to be part of the main settings as it contributes a lot to compatibility.

There is no need to to use "--level", because x264 will automatically set the proper H.264 Level, based on the properties of your video and based on your encoding settings.

You would only need to set "--level" manually, if you want to enforce a different Level than x264 would set normally. But there is no guarantee that enforcing a lower Level will work!

For example, the minimum required Level depends (not only) on the resolution and frame-rate of the video - there is nothing x264 could do about that...

See also:
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels

2) 2-pass option - doesn't offer adding custom parms for each pass. For example I think it's not really necessary to use -o on first pass if you're using 2-pass.

The identical parameters should be used for both passes of a 2-Pass encode!

Note that x264 will automatically "speed up" some of the encoder settings in the first pass of a 2-Pass encode, unless "--slow-firstpass" is added explicitly.

Also you don't need to set "-o" at all. The Simple x264 Launcher will set that option for you and thus it won't allow you to enter it for a second time.

3) the main difference between the builds is the x264 revision I assume? In which case I can just replace the exe when a new one is out. Unless the avs2yuv builds are often updated too?

The difference, of course, is not only the revision number ;)

The difference is whatever has changed in the x264 code between those revisions - see the x264 changelog (http://mirror01.x264.nl/x264/changelog.txt) for details! The revision numbers are only used to distinguish the different revisions.

Furthermore different x264 builds created by different people may also differ in which "unofficial" patches have been included (if any) or in which compiler has been used to make the build.


Generally you can replace the x264 binary that ships with Simple x264 Launcher with some newer revision. Replacing it with an older revision is not supported.

Nonetheless if the x264 "core" version has changed, the binary may not be compatible anymore. Therefore Simple x264 Launcher will throw a warning, if an unknown "core" version is encountered.

Also there should be no need to replace the avs2yuv binary. Stick with the one that ships with Simple x264 Launcher and that's it!

[VideoFanatic]

I currently have a Dual Core PC with 32-bit Windows Vista. I use Avisynth (with Set's MT mode) with Simple x264 Launcher to encode a 1 hour 30 minute standard definition video to h264:

Here is my script:

setmtmode(5,2)
Mpeg2Source("H:\New\Raw 1996 March 11 new.d2v", CPU=6)
setmtmode(2,0)
Load_Stdcall_plugin("C:\Program Files\AviSynth 2.5\plugins\yadif.dll")
QTGMC(Preset="Ultra Fast")
Vinverse()
TTempSmoothF(maxr=3, lthresh=8, cthresh=5, strength=4, interlaced=true)

It takes 8 hours to encode at around 10 FPS. How much faster would a quad core be with Vista 64-bit?

How much faster would an 8 core be?

Does having a better graphics card speed up encoding? Should I get a graphics card with CUDA if that will speed up encoding?

[LoRd_MuldeR]

Switching from a Dualcore to an Octocore processor of the same processor generation (same microarchitecture) will roughly multiply your throughput by four :)

That's because the x264 encoding speed scales almost linearly with the number of CPU cores. At least up to something like ~16 cores.

Of course the above only applies if x264 itself is your performance bottleneck! If your Avisynth script is the bottleneck, then it highly depends on what filters/plugins your are using.

Some Avisynth plug-in's are multi-threaded nicely, while others are not multi-threaded at all. Also note that the Avisynth core itself is not multi-threaded at all.

(There is an "MT" branch of Avisynth available, but it is known to be an unstable mess. Feel free to experiment with Avisynth-MT tough!)


As for CUDA: x264 currently does not use/need/support CUDA or any other form of GPGPU (such as OpenCL or DirectCompute) at all. Thus a faster graphics card won't speed up x264 encoding at all!

If you have followed the discussion on this forum, then you should know that the hype around "GPU accelerated" video encoders is nothing but a marketing hoax :rolleyes:

Company xyz will tell you "our GPU-based encoder is 10x faster than x264", but they won't tell you that they compared the "crap quality" setting of their encoder to x264 running with "very slow" settings :p

If GPU's really were as suitable for video encoding as the GPU vendors try to make you believe, then somebody would already have developed a GPU-based encoder that can keep up with x264 in a fair comparison.

We are still waiting to see this happen! This all doesn't mean that you can't use a GPU-based decoder (e.g. DGDecodeNV) to feed x264. But you really don't need a "high end" graphics card for that...

[mini-moose]

There is no need to to use "--level", because x264 will automatically set the proper H.264 Level, based on the properties of your video and based on your encoding settings.

well, if you encode 1920x1080 with --profile high --preset slower, the ref will be set to 8 which exceeds the max ref h264 specs allows for that resolution. if you use --level 4.1 it will be set to 4 as it needs to be. That's mainly what I'm talking about. Try encoding a short clip with and without --level 4.1, mediainfo it and see.
Blu-Rays of course use those h264 specs - High@L4.1 and ref 4.

Here are the results from a quick test I just did (both on the same source of course):

1920x1080 using --preset slow --profile high --level 4.1 :
mediainfo : High@L4.1, ref=4

1920x1080 using --preset slow --profile high :
mediainfo : High@L5.0, ref=5


The identical parameters should be used for both passes of a 2-Pass encode!
unless "--slow-firstpass" is added explicitly.


First pass doesn't use the same parms as 2nd. As you said it's it reduces certain parms to speedup by using profile main.
personally I sometimes change certain elements that are lower on first pass (and of course much higher on 2nd pass) that my differ from --slow-firstpass, which is why I would have liked to be able to make my own modifications for first pass as well.

Also you don't need to set "-o" at all. The Simple x264 Launcher will set that option for you and thus it won't allow you to enter it for a second time.

that's not what I meant. The way it is now, first pass uses -o as well, which means it writes a video file to hdd for first pass and then overwrites it on 2nd. IMO there is no need to for that on 1st pass.
so first pass can be set to use -o NUL.

from the log file (I modified the paths):

"x264_8bit_x64.exe" --bitrate 5212 --pass 1 --stats test.stats --preset slow --profile high --output test.mkv --frames 401 --demuxer y4m --stdin y4m -


The difference, of course, is not only the revision number ;)

Fair enough, I wanted to be clear on that.
I don't think however that the various tweaks/changes/fixes made on each revision really effect the main settings available on the launcher. the presets/profiles/psy tunes are still the same as far as the cmd goes (unless there is some major change which happens once in a long time). They may have internal changes but that shouldn't effect the cmds themselves.
If I'm wrong with my assumptions I apologize in advance :) I'm perfectly fine with getting new versions and just wanted to be be clarify that subject.

Anyway, I'm happy I found out about your launcher it seems to be very useful.

[VideoFanatic]

Switching from a Dualcore to an Octocore processor of the same processor generation (same microarchitecture) will roughly multiply your throughput by four :)

As for CUDA: x264 currently does not use/need/support CUDA or any other form of GPGPU (such as OpenCL or DirectCompute) at all. Thus a faster graphics card won't speed up x264 encoding at all!

This all doesn't mean that you can't use a GPU-based decoder (e.g. DGDecodeNV) to feed x264. But you really don't need a "high end" graphics card for that...


http://www.videohelp.com/tools/DGAVCDec. That page says The DGDecNV version (costs money) is similar to the DGAVCDec program but it uses your Nvidia card to decode video much faster using CUDA video decoding.

So are you still saying that there's no need to buy a CUDA supported card because it won't speed up x264 encoding? If CUDA is useless then do I only need a basic £30 graphics card?

Any idea why the "DGVC1DecNV" link doesn't work. Where do I go to get that program?

[mini-moose]

So are you still saying that there's no need to buy a CUDA supported card because it won't speed up x264 encoding? If CUDA is useless then do I only need a basic £30 graphics card?

Any idea why the "DGVC1DecNV" link doesn't work. Where do I go to get that program?

I'm not an expert but from what I've experienced and read, using dgavcnv will make decoding your video faster (serve the frames faster to your encoder) depending on what pure video engline your cuda card has. for it to drastically effect the encoding speeds you'll need a kick ass cpu too as at the end the bottle neck is how fast your cpu can handle encoding under high 264 settings. You do not need a high end card to get faster decoding, what you need is one with the latest vp engine. the vp engine doesn't change. i.e if you buy a $50 card with vp5 or a $500 card with vp5, it will still do the same job as it's the same vp on both.
http://neuron2.net/dgdecnv/dgdecnv.html is the software's webpage.

[LoRd_MuldeR]

http://www.videohelp.com/tools/DGAVCDec. That page says The DGDecNV version (costs money) is similar to the DGAVCDec program but it uses your Nvidia card to decode video much faster using CUDA video decoding.

DGAVCDec is a "dead" project. It has a lot of problems that are never going to be fixed, as the developer dropped that project. Also it only handled AVC/H.264.

DGDecNV supports H.264/AVC, VC-1 and MPEG-2 via "hardware" decoding. And it's under active development. It does not neccesarrily decode "faster" (a decent CPU can actually decode faster than the graphic card's built-in video decoder unit), but it does keep the CPU free for other work...

So are you still saying that there's no need to buy a CUDA supported card because it won't speed up x264 encoding? If CUDA is useless then do I only need a basic £30 graphics card?

For DGDecNV you need a supported NVidia card. There is a list of supported cards on the web-site. You do not need a "high end" model though. For video decoding the actual GPU is not used! Instead a dedicated decoder unit (NVidia calls it "Pure Video") integrated on the graphic's card is used. The video decoder unit is pretty much identical between "high end" and "low end" cards. A cheap one will do the job just as well...

And, as explaind before, x264 itself doesn't use the graphic's card. It doesn't even notoice what graphics card you have. You could be running x264 on a server machine without any graphics card ^^

[LoRd_MuldeR]

well, if you encode 1920x1080 with --profile high --preset slower, the ref will be set to 8 which exceeds the max ref h264 specs allows for that resolution. if you use --level 4.1 it will be set to 4 as it needs to be. That's mainly what I'm talking about. Try encoding a short clip with and without --level 4.1, mediainfo it and see.

Each H.264 Level defines a "Decoded Picture Buffer" (DPB) size. It is the DPB size and the resolution of the video that defines the maximum number of references. Now if you feed x264 with 1080p video and set 8 referfences (either explicitely or implicitely via Preset), then x264 will of course pick the Level that can support 8 referneces for 1080p. The result will perfectly comply to the H.264 specifictions! It may not come out as Level 4.1 though, because x264 cannot magically know that you are expecting Level 4.1. It selects the Level that is suitable for your input video and for your settings! If you need Level 4.1 for whatever reason, then you may enforce this by setting "--level 4.1". But generally this won't be needed...

First pass doesn't use the same parms as 2nd. As you said it's it reduces certain parms to speedup by using profile main.
personally I sometimes change certain elements that are lower on first pass (and of course much higher on 2nd pass) that my differ from --slow-firstpass, which is why I would have liked to be able to make my own modifications for first pass as well.

What I mean is that x264 is designed to use the exactly same command-line parameters for both passes. It will automatically lower certain settings in the first pass (those that are "safe" to be lowered in a first pass), even when you use the identical parameters (except for "--pass" of course) in both passes. Thus there is no need to enter different parameters for pass1/pass2. Using different parameters can even be dangerous, because there are many options that are NOT supposed to be changed between the passes...

that's not what I meant. The way it is now, first pass uses -o as well, which means it writes a video file to hdd for first pass and then overwrites it on 2nd. IMO there is no need to for that on 1st pass.
so first pass can be set to use -o NUL.

It could be done, yes. But it doesn't have to. The way it currently is, we can inspect the temporary file while the first pass is still running...

Fair enough, I wanted to be clear on that.
I don't think however that the various tweaks/changes/fixes made on each revision really effect the main settings available on the launcher. the presets/profiles/psy tunes are still the same as far as the cmd goes (unless there is some major change which happens once in a long time). They may have internal changes but that shouldn't effect the cmds themselves.
If I'm wrong with my assumptions I apologize in advance :) I'm perfectly fine with getting new versions and just wanted to be be clarify that subject.

Most of the time the command-line interface of x264 doesn't change, so we can update the x264 binary without modifying the GUI. Nevertheless changes to the command-line interface may happen and may break compatibility. Also keep in mind that the GUI needs to read x264's console output. If the console output changes, it may (and probably will) also break the compatibility.

[mini-moose]

It may not come out as Level 4.1 though, because x264 cannot magically know that you are expecting Level 4.1. It selects the Level that is suitable for your input video and for your settings!
I'm well aware that the level is auto chosen in relevance to presets etc. The thing I'm saying that using anything over level 4.1 might cause compatibility issues with certain hardwares. Sure you can set it to whatever you want but if you spent several hours making your video and your hardware chokes on it you end up with wasting your time.
http://mewiki.project357.com/wiki/X264_Settings#level :
"Level 4.1 is often considered the highest level you can rely on desktop consumer hardware to support. Blu-ray Discs only support level 4.1, and many non-mobile devices like the Xbox 360 specify level 4.1 as the highest they officially support"

[LoRd_MuldeR]

Well, not everybody is encoding for consumer hardware decoders. A lot of people encode to watch the result on a PC and there Levels are pretty much irrelevant (for software decoders). If you need to hit a specific Level, well, go ahead an add "--level x.y" to the custom parameters. It will even be included in your template! But I don't think we should enforce a specific Level by default. Especially because enforcing, e.g. Level 4.1, can be far too high - depending on the source. I can't remember what x264 does when the request Level is higher than needed. But we either get a video with a "wrong" (too high) Level flag or we get a video whose Level will be different from what the user has selected. And you know, user will be confused if selected Level is 4.1, but the video comes out at Level 3.0, for example...

[mini-moose]

Well, not everybody is encoding for consumer hardware decoders.
fair enough. I didn't suggest forcing a certain level just adding a lever selector next to tune/preset/profile.
Every one of the main settings can cause some confusion.
All such confusions can be resolved after some trial and error and spending some time reading mans (or do a bit of research).

[WasF]

Why does the GUI enforce the use of a preset ? Where is the "none" entry in the drop menu ?

[LoRd_MuldeR]

The "Medium" preset is identical to x264's default.

Actually x264 first sets its defaults, then applies the selected preset and finally applies all other user options, if any.

(The "Medium" preset is implemented as changing nothing)

[WasF]

That was fast ! Thanks.
Would help (psychologically that is) if you added a "none" entry that secretly applies "Medium".

Now this launcher is looking close to perfection !
One concern though: can it really pause the encode ? I remember this as a hot topic few years ago, and artifacts were feared and all..
I guess you just suspend the process. To your knowledge, does x264 tolerate this with no effect on the output ?
(really, this feature should be implemented in x264 itself - like through a signal)

[VideoFanatic]

I'm not an expert but from what I've experienced and read, using dgavcnv will make decoding your video faster (serve the frames faster to your encoder) depending on what pure video engline your cuda card has.You do not need a high end card to get faster decoding, what you need is one with the latest vp engine. the vp engine doesn't change. i.e if you buy a $50 card with vp5 or a $500 card with vp5, it will still do the same job as it's the same vp on both.
http://neuron2.net/dgdecnv/dgdecnv.html is the software's webpage.

Thanks. I know about that webpage already but I was just wondering why the link on the following page to DGVC1DecNV doesn't work. Does that program no longer exist?:

http://www.videohelp.com/tools/DGAVCDec

Also on the http://neuron2.net/dgdecnv/dgdecnv.html page I don't see anything that mentions VP engine. Could you please show me a page from that software documentation that mentions VP engines?

Any idea what the cheapest VP5 supported graphics card is?

[mini-moose]

I was just wondering why the link on the following page to DGVC1DecNV doesn't work. Does that program no longer exist?:

DGVC1DecNV link I guess doesn't work cause that's an old version of what is now DGDecNV, for VC1 streams only. It was migrated into DGDecNV which supports also h264 and mpeg2 in addition to VC1 (all in one).
It costs a little but you get tons of licenses. I believe DGVC1DecNV was a payware as well.
I don't see anything that mentions VP engine. Could you please show me a page from that software documentation that mentions VP engines?
Any idea what the cheapest VP5 supported graphics card is?

I will need to search for it but you can have a look through the dgavcnv support forum. It should be discussed there. for example:
http://neuron2.net/board/viewtopic.php?f=8&t=199
http://neuron2.net/board/viewtopic.php?f=8&t=167

When you download the software package it comes with some html documentations. Might have more info there.

see also what op wrote earlier:
http://forum.doom9.org/showpost.php?p=1582382&postcount=846

I think GT 520 is one of the cheaper ones.
you can look here at a list of gpus, find the ones that say vp5 and compare prices:
http://en.wikipedia.org/wiki/Nvidia_PureVideo#Table_of_PureVideo_.28HD.29_GPUs

edit:

look at the DGDecodeNVManual.html and DGIndexNVManual.html that come with the application package:
"The "NV" in the name "DGDecodeNV" indicates that this version of the program is designed for use with the VP2 (or greater) GPU decoder on some Nvidia video cards...."

[VideoFanatic]

OK now I'm confused. I saw a post that said "DGDecNV has allowed us to decode video using CUDA, as well as the option we have always had to decode using VP". How do I know which to use? CUDA or VP?

[mini-moose]

OK now I'm confused.

you seem to be overthinking it. I don't know a whole lot on how something works just what it does for my needs:)

DGAVCNV decodes streams using the purevideo (vp) engine on nvidia cuda cards. You load your video on this tool, save it to a project file. Serve the project file on your .avs script and encode. Simple :)

[LoRd_MuldeR]

OK now I'm confused. I saw a post that said "DGDecNV has allowed us to decode video using CUDA, as well as the option we have always had to decode using VP". How do I know which to use? CUDA or VP?

CUDA is an interface to access the graphic's processor (GPU) for running "arbitrary" calculations. OpenCL and DirectCompute basically do the same. However nobody would implement a video decoder on the GPU using CUDA (or OpenCL or DirectCompute). That's because all graphic's cards from the last ~8 years have dedicated video decoding units! NVidia calls it "PureVideo HD" while AMD/ATI calls it "Unified Video Decoder" (UVD). Once again, several interfaces to access the graphic card's hardware video decoder unit exist, such as DirectX Video Acceleration (DXVA). Another one, created by NVidia and supported exclusively by NVidia cards, is CUVID (the "CUDA Video API"). Don't confuse CUVID with CUDA itself! Applications using CUDA are using the actual GPU and they have to upload their own program code (called a "kernel") into the GPU. At the same time, applications using CUVID are simply using the hardwired video decoder unit, which is not programmable at all.

As for DGDecNV: It is based on CUVID and thus the minimum hardware requirement is an NVidia card with VP2 (i.e. the second generation of "PureVideo HD") or newer. Look at the table (http://en.wikipedia.org/wiki/PureVideo#Table_of_PureVideo_.28HD.29_GPUs) to see which cards are suitable...

[LoRd_MuldeR]

That was fast ! Thanks.
Would help (psychologically that is) if you added a "none" entry that secretly applies "Medium".

I prefer to stick with the same names that x264 itself uses.

One concern though: can it really pause the encode ? I remember this as a hot topic few years ago, and artifacts were feared and all..
I guess you just suspend the process. To your knowledge, does x264 tolerate this with no effect on the output ?
(really, this feature should be implemented in x264 itself - like through a signal)

Interestingly the Win32 API doesn't provide a function to suspend a complete process. Instead we have to enumerate all threads of the process and suspend them one-by-one. Later we will enumerate the process' threads again and resume them one-by-one. In case of x264, however, it is sufficient to just suspend/resume the "main" thread ;)

And yes, this should be perfectly safe. Actually the operating system's scheduler suspends and resumes the processes/threads running on your computer all the time. This is called "preemptive multi-tasking" and it is the way how multi-tasking is implemented on all modern operating systems - including Microsoft Windows. Please see here (http://en.wikipedia.org/wiki/Preemption_%28computing%29#Preemptive_multitasking) for details!

In other words: Operating systems, except for special "real time" operating systems, never give any timing guarantees. Thus a program requiring that it never gets suspended (for longer than x seconds) is bound to fail in the first place...

(BTW: The only "side effect" of suspending the x264 process I ever noticed is that the "fps" and "eta" progress indicators will get confused)

[WasF]

I prefer to stick with the same names that x264 itself uses.

That was.. not so fast this time :p But hey: worth the wait, though ! :D
Don't worry, my suggestion was of "psychological" order, to remove the false impression that the GUI was imposing something it shouldn't impose..
Funny to see how "open sourcers" keep having allergies to this kind of stuff ! (dirty codename: usability :devil:).

The only "side effect".. is that the "fps" and "eta" progress indicators will get confused
That rings a bell ! I seem to remember this as "slow restart", when it's actually the indicators that get crooked. I guess the fps and eta values are computed using absolute time, not "actually running time", so it's normal. This is why this should be supported by x264 itself: the process can't know it got suspended, and could receive this info through a signal and subtract the "pause time" from absolute time.
(I remember now: the "hot topic" I mentioned was actually about complete stop/resume, not just pause, which, I guess, is not even on x264 people's radar, given that they don't even support pause/resume. Would be a huge convenience though, but, hey, it's open source, so, remember, dirty codename again !)

Alright, Simple x264 Launcher::Pesky_users++ (how is this good news for you ?! :sly:)

[LoRd_MuldeR]

It should be obvious that the average "fps" (and thus the "eta") is approixmated as follows:
FPS = frames_processed_so_far / ( time(right_now) - time(start_of_encode) )

In therory it would be possible to use the time that the process has actually been active on the CPU, referred to as the process' "virtual time". But it would be neccesarry to use platform-specific functions to determine this info, making the code less portable. Also the "eta" would then be expressed in "virtual" time rather than "real" time, which is confusing for the user! Imagine two instances of x264 are running in parallel and each instance uses ~50% of the CPU time. In that case the "virtual" time of each process would be running at 0.5x speed of the "real" time. Thus, in this case and if we calculated the "eta" based on "virtual" time, then an "eta" auf 1 hour would mean the user still has to wait ~2 hours for the encode to finish. Not very obvious...

[WasF]

Yes: when the system scheduler is involved, it's hard to deduce the real run time.
That's why I was talking about an external information telling the process explicitly: now, you nap. Or: now, you wake up.
This would be trivial to use : just subtract the difference from your timeline : time(right_now) - time(start_of_encode) - cumulated_naps
No guessing involved.
P.S.: and less portable is fine by me, if it gets me this convenience ! It can be made a patch, to preserve the main codebase.:rolleyes:

[bugmen0t]

hai, mulder :D

can you make a tutorial how to use this app

i can find how to resize ouput video :(

thnks for reply

[LoRd_MuldeR]

hai, mulder :D

can you make a tutorial how to use this app

i can find how to resize ouput video :(

thnks for reply

This is just a simple GUI for the x264 encoder.

However there are different ways to resize the input video. If you use an Avisynth script as your source, simply use one of Avisynth' resize functions in your script:
http://avisynth.org/mediawiki/Resize

If you use FFMS2/LAVF input, you can use x264' built-in resize filter, by adding "--video-filter resize:640,480" to the custom x264 options. (replace the numbers as needed!)

[r0lZ]

If you use FFMS2/LAVF input, ...Why? It is not possible to resize any input video type with x264?

[LoRd_MuldeR]

Why? It is not possible to resize any input video type with x264?

Sure it is. But with FFMS2/LAVF input the built-in filters are your only option, while with With Avisynth input you can apply filters on the Avisynth side as well.

Also I'm assuming that in case bugmen0t is using Avisynth input, he should be familiar with Avisynth scripting and thus should be able to add the Resize() filter to his script easily.

An surprisingly large number of users seem to have problems with figuring out the correct syntax for x264's built-in filters ;)

[r0lZ]

Ah, OK. I did not understand your reply correctly. I thought you said that with avisynth, your only option is to use the avisynth resize.

BTW, I'm still wondering what is the fastest resize (with equivalent filter quality). Avisynth or x264?
And it is better to let avisynth do the resize to leave more processor time to x264 for the h264 encoding stricto-sensu?

[LoRd_MuldeR]

Why should letting Avisynth do the resize leave more processor time to x264? They are running on the same CPU! And, unless you put Avisynth into its own process (e.g. via avs2yuv), they even run in the context of the same process! So whether you spend those CPU cycles required for the resize in x264's resize code or in Avisynth' resize code doesn't matter at all - as long as we assume neither code is faster. Whether the resize code in Avisynth or the resize code in libswscale (that's what x264 uses) is better optimized for speed, I have no idea. The resize algorithms they implement mostly are the same (Bilinear, Bicubic, Lanczos, Spline resize). Nonetheless I think using Avisynth input causes at least some performance overhead, compared to the built-in decoders. On the other hand, most Avisynth users use FFVideoSource() from FFMS2 nowadays, which is exactly the same library that x264's built-in decoder uses by default. So it shouldn't make much difference. For me there are three main reasons to use Avisynth: Complex filter scripts that x264 can't do (QTGMC is the best example here!), sources that x264 can't read by itself (e.g. something that needs Avisynth' AVISource or DirectShowSource) and GPU-based decoding via DGDecodeNV - the latter indeed does free some CPU cycles for x264, because it leaves the decoding to the hardware decoder. In all other cases I wouldn't use Avisynth input...

[r0lZ]

Thanks for the extended and clear reply.

When I'll have some time, I will try to compare the performances of the avisynth and x264 resize filters...

[bugmen0t]

thnks for advice mulder :D

"--video-filter resize:640,480"
seems good for me :p
http://photoserver.ws/images/7aDd4e059ddc241d9.gif

[lansing]

hi I'm trying to encode my bluray video with 10bit encoding, so I checked the "use 10-bit" setting, but i keep getting random "warning: avisynth process exited with error code: -1073741819" during the encoding, and then the whole process just stopped and was labeled completed.

What is wrong?

[LoRd_MuldeR]

hi I'm trying to encode my bluray video with 10bit encoding, so I checked the "use 10-bit" setting, but i keep getting random "warning: avisynth process exited with error code: -1073741819" during the encoding, and then the whole process just stopped and was labeled completed.

What is wrong?

Obviously Avisyth (or one of the plug-in's involved) has crashed, i.e. your problem is not related to Simple x264 Launcher.

(As always in this situation, try to open the exact same script in VirtualDub and check if it plays all the way from start to finish)

[lansing]

Obviously Avisyth (or one of the plug-in's involved) has crashed, i.e. your problem is not related to Simple x264 Launcher.

(As always in this situation, try to open the exact same script in VirtualDub and check if it plays all the way from start to finish)

ok, thanks. I was loading a virtualdub plugin in my script, and just tested with a preroll of 1, and everything seems alright now.

[mini-moose]

I know you were all against my suggestion to include a separate cmd option for 1st pass on 2-pass option but the new x264 feature kind of requires it, in fact it even requires using a different avs (if one is using avs). Of course since it's a "simple" launcher maybe it's not meant to support this feature.

[LoRd_MuldeR]

I know you were all against my suggestion to include a separate cmd option for 1st pass on 2-pass option but the new x264 feature kind of requires it, in fact it even requires using a different avs (if one is using avs). Of course since it's a "simple" launcher maybe it's not meant to support this feature.

What feature should that be ???

[mini-moose]

What feature should that be ???

"Support changing resolutions between passes with macroblock-tree
Implement a basic separable bilinear filter to rescale the quantizer offsets.
Structure inspired by swscale, but floating-point instead of fixed-point.
Not as optimized as it could be, but it's quite fast already.

Example compression penalties on a 720p video game recording:
First pass with 720p and second as 480p: ~-1.5% (vs. same res)
First pass with 480p and second as 720p: ~-3% (vs. same res)"

[LoRd_MuldeR]

This commit allows x264 to change the resolution between passes - now also with MB-Tree rate-control enabled. The commit message also shows some examples of the expected compression penalty for doing so.

It certainly does not say that it is recommended to change the resolution between passes. Actually the expected compression penalty means that you do not want to change the resolution between passes, unless you absolutely have to...

(There may be specific use-cases for changing the resolution between passes, but that's certainly not what a regular user should be doing. Thus I see no reason to encourage people to do it, just because "it can be done")

[mini-moose]

This commit allows x264 to change the resolution between passes - with MB-Tree rate-control enabled.

yes, I'm aware of what it is.
As I said maybe it's not the place for app called "simple" to mess about with "advanced". Mentioned it cause it's a new feature which require some changes between passes.
However since you already have an option to add custom x264 parameters, simple can become advanced for non-default users, so I thought it's worth mentioning.

[mini-moose]

I tried using .avs for load/crop/fps but resize via x264. With the x264 version that comes with the app I get considerably slower encodes than using the x264.nl one (both supposed to be Komisar's but seem different).

Much slower on 1st pass and just slightly less on second.
I tested the same encode with the app and with a batch file using app x264 and x264.nl one and the results correspond with what I described above.

App x264:
1st - encoded 10001 frames, 39.66 fps, 5354.61 kb/s
2nd - encoded 10001 frames, 24.81 fps, 5374.17 kb/s

x264.nl x264:
1st - encoded 10001 frames, 65.23 fps, 5354.61 kb/s
2nd - encoded 10001 frames, 26.60 fps, 5374.17 kb/s

x264 resize was: --vf resize:width=1280,height=696,method=spline,sar=1:1

resizing in .avs produces same speeds for both x264.exe versions.

[kypec]

can I ask what builds of x264 you are using? self compiled? the logs suggest it may be the same one available on x264.nl but I noticed the ones coming with the application are slightly smaller in size (same for avs2yuv).
Looking closely into the log output will tell you who has built it: x264 0.125.2200 999b753
(libswscale 2.1.100)
(libavformat 54.6.100)
(ffmpegsource 2.17.1.3)
built by Komisar on May 23 2012, gcc: 4.7.0 (multilib.generic.Komisar) (http://komisar.gin.by/)
configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

x264 revision: 2200 (core #125)

[mini-moose]

Looking closely into the log output will tell you who has built it

yes, I have checked the logs. It's a little confusing.
Though both x264.nl and the one that comes with the launcher are said to be komisar's, the one downloadable is 10.1mb and the launcher one is 8.5mb. I guess the build with launcher is different.

I replaced the one in toolset with the one from the website and ran it. It doesn't show a compiler name and has some other differences. I wouldn't care too much if they didn't behave differently with the parms described before.

launcher (8.5mb):
x264 0.125.2208 d9d2288
(libswscale 2.1.100)
(libavformat 54.17.100)
(ffmpegsource 2.17.2.1)
built by Komisar on Jul 19 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

x264.nl (10.1mb):
x264 0.125.2208 d9d2288
(libswscale 2.1.0)
(libavformat 54.9.0)
(ffmpegsource 2.17.2.1)
built on Jul 18 2012, gcc: 4.7.1
configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: LGPL version 2.1 or later

both are r2208 x64 of course.

[LoRd_MuldeR]

I took the builds that are bundled with Simple x264 Launcher directly from Komisar's web-site (http://komisar.gin.by/).

They have been built with GCC 4.7.1, while the builds on x264.nl (http://x264.nl/) apparently have been built with GCC 4.5.3 - assuming the info on the web-site is correct.

If I understand you correctly, the Komisar web-site build is slower, but only when the "built-in" resize filte is used? - I assume you verified this with multiple runs to rule out the usual fluctuations.

Well, this may be caused by a different version of libswsclae - the library used by x264's built-in resize filter. Or by the different GCC version. Or by a combination of both.

BTW: Other people have complained about "unusal" slow resizing before, so there indeed might be a problem with Komisar's GCC 4.7 build and the "resize" filter. I don't resize a lot ;)

[mini-moose]

If I understand you correctly, the Komisar web-site build is slower, but only when the "built-in" resize filte is used? - I assume you verified this with multiple runs to rule out the usual fluctuations.


correct. I did a few runs using the build you use - with and without the launcher.

[r0lZ]

And when you use the AviSynth resize, is it faster or slower (with a similar resize filter giving proximately the same quality)?

[mini-moose]

And when you use the AviSynth resize, is it faster or slower

avisynth resizing is same for both x264 builds from what I remember. Certainly nothing that seemed out of the ordinary different.

[r0lZ]

Yes, I understand that. But what I would like to know is if the avisynth resize is faster or slower than the x264 resize. It is difficult to compare them, as we can't be sure that they offer exactly the same quality, but an approximation of the speed difference would be an interesting information anyway.

[mini-moose]

I would like to know is if the avisynth resize is faster or slower than the x264 resize.

x264 seems to be faster. I can't tell you if it's as good but it has the same type of resizers avisynth does : fastbilinear, bilinear, bicubic, experimental, point, area, bicublin, gauss, sinc, lanczos, spline (method names copied from the x264 help). Though I think it doesn't make a big difference when you are using single pass encodes unless you use faster presets. It's more evident in fast passes (like 1st pass in 2-pass).

[r0lZ]

OK, thanks for the info.
BTW, do you know what the "experimental" resize is? Is it reliable?

[mini-moose]

BTW, do you know what the "experimental" resize is? Is it reliable?

no idea. I stick the ones I know from avisynth.

[DaRkBoZ]

Hey :)

Thanks a lot for this excellent tool.

I've read in your documentation that you don't want to make it compatible with x264 binaries others than the one you packed with it.

Would it be possible to make an exception about that ? I use a special compilation of x264 with many patches and until then it was working with it, but now i dunno why it can't obtain the version from the --version switch, but it work perfectly when i call it myself from cmdline.

That would be awesome if you could make it work with it (or maybe just add an option so that the x264 version is ignored or/and forced :) )

The version i use are from here : http://astrataro.wordpress.com/category/encode/x264/

Theses custom builds are great especially the 8bit one with the AQ modding, and the 10 bits one i use for the FGO patch aside from others (i know jeebs build have the FGO patch, but i find them to be less fast and crashed on me on many occasions, and he didn't updated to 2208 yet (only 2200).

Thanks a lot in advance for your reply about that, i would really like to continue using your GUI :)

[Keiyakusha]

I use these builds with no problems so far Oo
Maybe you didn't renamed them correctly?
On x264.nl these are JEEB's builds too. At least that's what they say in parentheses.

P.S.
These AQ patches are no good imho. The only thing they can - make everything flat. They are probably good for encoding flash vector animation. Perhaps that's why they forever "patches" and not official.

[DaRkBoZ]

Oh it was working before the latest x264 launcher (v2.05.346) now with this version and the Taro x264 v2208, i get this error.

--- CHECK VERSION ---

Creating process:
D:/ENCODES/sx264launcher/toolset/x264_10bit_x64.exe --version
FAILED TO DETERMINE X264 VERSION !!!

when i do it by hand with the cmdline i obtain

(Taro v2208)

x264 0.125.2208+677+32 26f090e tMod [10-bit@4:2:0 X86_64]
(libswscale 2.1.100)
(libavformat 54.18.100)
(ffmpegsource 2.17.2.1)
built on Jul 20 2012, gcc: 4.7.1
configuration: --bit-depth=10 --chroma-format=420
x264 license: Non-Free
libswscale/libavformat/ffmpegsource license: nonfree and unredistributable
WARNING: This binary is unredistributable!

(Taro v2200)

x264 0.125.2200+666+30 20c70fc tMod [10-bit@4:2:0 X86_64]
(libswscale 2.1.0)
(libavformat 54.3.0)
(ffmpegsource 2.17.1.3)
built on May 25 2012, gcc: 4.7.0
configuration: --bit-depth=10 --chroma-format=420
x264 license: Non-Free
libswscale/libavformat/ffmpegsource license: nonfree and unredistributable
WARNING: This binary is unredistributable!

So i guess the launcher can't parse the version number correctly and it make it crash :)

PS : I agree with you for the AQmode patch mod 1 & mod2 but the 8 bits patch with MixAQ and OreAQ yield interesting result when you want 8 bits, but yeah i'am in it especially for the FGO patch since jeebs didn't updated his, and they're a bit less fast and stable :)

[Keiyakusha]

Hmm, let me make it clear.... when you try to add --version in custom commandline in GUI and run this job - it fails? If so, I never tried this. Why would anyone want to do it?
For normal encoding without specifying weird commandline options latest Launcher with 2208 taro's builds worked for me just about yesterday... And I remember I tried every his build including "light" package. Unfortunately can't verify this mystery right now.

[DaRkBoZ]

i don't add --version as a custom command line in the launcher.

The launcher do it itself to determine the version, if you use a too old x264 version the launcher will tell you and will not launch the encode (that's what i had when i used jeebs 2200 it tell you the launcher can't work with version under 2201)

Why would i add myself the --version to the custom cmd line ^^

EDIT : Ok lol since you told me it was working well for you, i kinda begun searching for alternative issues/solutions, i finally found what was the issue after using a process spy, i use a passive protection program, and this dumb silly apps was blocking the new x264 binary, now i added it to the trusted files and it work ! damn i'am feeling dumb now haha. Well moving along then, thanks for the info Keiya, and sorry about taking your time.

Well at least now i can enjoy again this nice launcher

[LoRd_MuldeR]

I've read in your documentation that you don't want to make it compatible with x264 binaries others than the one you packed with it.

Hello, DaRkBoZ.

I just want to make clear that my intention certainly is not to make the Simple x264 Launcher "incompatible" with other x264 binaries. The program is written to work with the latest "official" x264 version. The binaries included in the package are just "vanilla" builds and they have been tested to work with the GUI properly, so for most users it is recommended to stick with these binaries. Nonetheless other x264 binaries will work just as well - as long as they don't break compatibility with the "standard" x264 CLI syntax or the "standard" x264 console output format.

BTW: The program has to parse the version number, because it will refuse to run with outdated x264 versions. This is required to ensure that the user doesn't use some "archaic" x264 version which is lacking support for some of the CLI options used by the GUI. Furthermore people tend to be lazy with keeping their software up-to-date. As x264 is constantly improving and fixing bugs, it certainly doesn't hurt to enforce an update now and then! I know that this can be annoying, if you depend on a "special" build that contains certain patches you want to use. However, if these patches haven't been ported to up-to-date x264 or nobody is building with these patches anymore, then this shows that those patches either have become obsolete or whatever approach they tried to implement turned out to be the wrong way...

Anyway, glad to hear that you solved your problem ;)

[DaRkBoZ]

Hey, thanks ;)

Oh yeah sorry about that, i didn't wished to say it like this, not that you didn't wanted to make it incompatible with other x264 releases, more like you prefered to keep your launcher as close as standard and not code special feature for everything out there (and on this point i agree, and understand :) )

Anyway yeah i'am happy to be able to use my fav launcher again, thx again :cool:

Oh btw when i'am here, i wished to ask, would it be possible in the future to be able to modify a profile you created beforehand and save it directly instead of only having the "save as" ? :)

thanks :)

[wcwman18]

Any plans to provide audio support at all?

[LoRd_MuldeR]

Simple x264 Launcher is a GUI for x264. As long as x264 doesn't support audio encoding, the answer is no ;)

Having said that, there is an "unofficial" x264 audio support branch, which you can use for audio encoding via x264. Such builds will work with the Simple x264 Launcher.

There even is some information in the Readme file. If you haven't read that file yet, you may want to have a look now...

[Atak_Snajpera]

if you need audio support then you should just use ffmpeg. x264 with audio encoding is just silly.

[LoRd_MuldeR]

if you need audio support then you should just use ffmpeg. x264 with audio encoding is just silly.

...or one of the various "Swiss army knife" GUI's that use x264 plus some AAC/Vorbis encoder plus some MP4/MKV muxer to handle video encoding, audio encoding and muxing all at once.

Simple x264 Launcher was never created to be yet another MeGUI clone ;)

[wcwman18]

Simple x264 Launcher is a GUI for x264. As long as x264 doesn't support audio encoding, the answer is no ;)

Having said that, there is an "unofficial" x264 audio support branch, which you can use for audio encoding via x264. Such builds will work with the Simple x264 Launcher.

There even is some information in the Readme file. If you haven't read that file yet, you may want to have a look now...

thanks

[wcwman18]

So, if I wanted to resize and deinterlace my TS file that I put in to the program would I add these to the custom avs field?

Yadif(0,1)
Lanczos4Resize(1280,720,6,6,-6,-6)

[LoRd_MuldeR]

There is no such thing as a "custom avs" field in Simple x264 Launcher.

There is a "custom" edit box for custom command-line parameters for x264 as well as one for custom command-line parameters for avs2yuv. That's it.

If you want to apply any Avisynth filters, you necessarily have to use an AVS script as input. And you would put the Avisynth filters into that script file.

Still, you may be able to get away without Avisynth and instead use x264's built-in filters. You can control these via custom command-line parameters.

Note, however, that while x264 has a built-in resize filters, it does not have a built-in deinterlace filter...

[wcwman18]

There is no such thing as a "custom avs" filed in Simple x264 Launcher.

There is a "custom" edit box for custom command-line parameters for x264 as well as one for custom command-line parameters for avs2yuv. That's it.

If you want to apply any Avisynth filters, you necessarily have to use an AVS script as input. And you would put the Avisynth filters into that script file.

Still, you may be able to get away without Avisynth and instead use x264's built-in filters. You can control these via custom command-line parameters.

Can I just add my edited TS file and add commands to resize and deinterlace? Not sure what they are though.

[LoRd_MuldeR]

Did you read my previous post ???

Yes, you can use x264's built-in video filters, such as the resize filter. And no, it does not have a built-in deinterlace filter at this time.

For the CLI syntax to control x264's built-in video filters, please see:
http://mewiki.project357.com/wiki/X264_Settings#Filtering

A simple example would be: --video-filter resize:width=1280,height=720,method=spline

[wcwman18]

Did you read my previous post ???

Yes, you can use x264's built-in video filters, such as the resize filter. And no, it does not have a built-in deinterlace filter at this time.

For the CLI syntax to control x264's built-in video filters, please see:
http://mewiki.project357.com/wiki/X264_Settings#Filtering

A simple example would be: --video-filter resize:width=1280,height=720,method=spline

So to resize if I read that right would be resize:width=1280,height=720,method=spline

To deinterlace within the software their is not a current way to do so, or can I add --tff and that will do that?

[LoRd_MuldeR]

So to resize if I read that right would be resize:width=1280,height=720,method=spline

That is the part you would put after the --video-filter command.

To deinterlace within the software their is not a current way to do so, or can I add --tff and that will do that?

With "--tff" you set the field order to top field first and you tell x264 to encode the video as interlaced.

Keeping the video interlaced (given the source actually is interlaced) and encoding it as interlaced is a feasible option, of course.

However if your goal is to de-interlace, then it's the exact opposite of what you want to do ;)

[sneaker_ger]

While vanilla x264cli does not have deinterlacing, the same builds that have audio (from JEEB) should also have yadif:
yadif:[mode][,order]
Deinterlaces the picture using MPlayer's yadif
mode: sets the deinterlacing mode
0 - single-rate deinterlacing (default)
1 - double-rate deinterlacing (bob)
2 - single-rate deinterlacing without spacial interlacing check
3 - double-rate deinterlacing without spacial interlacing check
order: forces the field order
tff - top-field first
bff - bottom-field first

Do not use resizing without prior deinterlacing.
-tff and -bff will use interlaced encoding - do not mix them with deinterlacing.

/edit:
too slow...

[wcwman18]

That is the part you would put after the --video-filter command.



With "--tff" you set the field order to top field first and you tell x264 to encode the video as interlaced.

Keeping the video interlaced (given the source actually is interlaced) and encoding it as interlaced is a feasible option, of course.

However if your goal is to de-interlace, then it's the exact opposite of what you want to do ;)

In the custom x264 per. --video-filter Lanczos4Resize 1280,720?

[LoRd_MuldeR]

In the custom x264 per. --video-filter Lanczos4Resize 1280,720?

The correct syntax has already been explained in the previous posts. I won't post it again, in the hope you start reading the answers you get ;)

[wcwman18]

The correct syntax has already been explained in the previous posts. I won't post it again, in the hope you start reading the answers you get ;)

It is not that I do not read what I am told but when you are not use to working with command line or where things go it makes things difficult.

The two things that I need to know step by step is what and where would I put de-interlacing and re sizing in your software.

Getting this error ffms [info]: 1920x1080i 1:1 @ 60001/1001 fps (vfr)
resize [error]: swscale is not compatible with interlaced vertical resizing

PROCESS EXITED WITH ERROR CODE: -1

[LoRd_MuldeR]

As has been explained before, resizing interlaced video is not possible. Resizing the interlaced video as if it was progressive (non-interlaced), will destroy the content! :eek:

Actually you have luck that swscale refused to resize the interlaced input (that's the error message you got), instead of silently destroying the content.

If you have interlaced footage and you want to resize it, then you have to de-interlace first. Exactly as you did in your Avisynth script: First apply Yadif() then LanczosResize().


Simple x264 Launcher is a GUI for x264, so it can only do what x264 can do. And, as original x264 does not have a built-in deinterlace filter, what you want is not possible with x264 alone.

You basically have two options here: Use an Avisynth script (AVS file) as input and do the deinterlacing+resizing (or at least the deinterlacing) in the Avisynth script.

Second option would be using the modified (patched) x264 with built-in Yadif filter, which sneaker_ger has mentioned (http://forum.doom9.org/showthread.php?p=1587580#post1587580). But don't ask me where to get an x264 binary with that patch...

(And of course yet another option would be: Keep the video interlaced, do not resize and encode it as interlaced - might not be what you want though)

[Atak_Snajpera]

if you need more advanced options use something more versatile like ripbot264

[Ru13en]

Hi, thanks for that Gui.
I want to give a suggestion to make that gui more attractive...
Like i've seen on that program, the possibility to pause and resume the encode is very cool...
So, to put that with more interest, you could add the option to set the hour to pause and shutdown the PC... That will be good for the person who want to encode in certain time, because of bucks of energetic cost that will be more cheaper on that hour.
So, the functionality of pause and resume will be more versatile... XD

Thanks for the attention
Regards

[LoRd_MuldeR]

Well, it is possible to "suspend" and "resume" a running encode, simply by suspending the x264 process (actually we have to suspend all threads separately due to limitations of the Win32 API). But the x264 process will still continue to exist while it is in "suspended" state (although it won't use any CPU time), so it has to remain in memory! It is NOT currently possible to terminate the x264 process and resume it at a later time. This also means we can NOT "pause" the process, shutdown the computer and resume the process after the next boot up. x264 does NOT provide such functionality and thus there isn't much what we could do on the GUI-side. But there is an easy solution: Hibernation. Simply send your computer to hibernation at whatever time you want and continue at a different time. No special support for this is needed in Simple x264 Launcher or in x264 itself, as Windows supports hibernation "out of the box".

[r154]

A simple example would be:
--video-filter resize:width=1280,height=720,method=spline
or
"... --vf resize:1280,544,1:1,,,spline64 ..."

[coocooc]

"--frames" is flagged as invalid. See attached screenshot.

Otherwise thanks for the program, saves quite some hassle. :)

[LoRd_MuldeR]

Yes, and that's intentionally! The GUI will set that option for you ;)

If we use x264 via pipe, which we do here, we need to set "--frames" explicitly, because otherwise x264 can't know the total number of frames and thus cannot display progress information. So the GUI will detect the number of frames from your input AVS script and forward that info to x264 by setting "--frames" accordingly. Setting that option twice, i.e. once by the GUI and once by the user, is a bad idea! So we prevent that the user sets it.

(I assume you tried to trim the video. For trimming, please use Trim() in your AVS script.)

[coocooc]

O.k., I understand. And the same argument will apply to --fps, that the GUI also suppresses, as I learnt yesterday.
But your launcher does not always use avisynth->pipe->x264. I tried a simple conversion that did not need avisynth (just cropping, which x264 can handle itself). To test if the output will be fine, I wanted to use the x264 --frames option. That was prohibited then by the GUI. In this case the behaviour of the GUI is counter-productive. I assume this use-case was just not on your radar, when you made your design decisions. For me it seemed natural to start all jobs from the same program (i.e. your launcher) independent of using avisynth or not. Main reason: to have the same job control for all conversions. Maybe your suppression should only be activated, if you actually use avisynth?

Ah, and the need to use the --fps option was: Without it x264 created output with borked frame rate (for some movies as low as 1.2, for others high as 18000). But that should be discussed in some other place (what would be the correct forum here on doom9 for this ?).

For the record: Input for my tests was a movie recorded from ARTE in 720p/50fps. Leading and trailing parts were first cut with TSDoctor. The log of the launcher looks like this:

Simple x264 Launcher (Build #346), built 2012-07-22

Job started at 2012-09-20, 04:53:23.

Source file: D:/Temp/TSDoctor/Gefahr und Begierde.ts
Output file: D:/Temp/TSDoctor/Gefahr und Begierde.264

--- SETTINGS ---

RC Mode: CRF
Preset: Medium
Tuning: Film
Profile: Auto
Custom: --video-filter crop:0,14,0,14

--- CHECK VERSION ---

Creating process:
"D:/Program Files (x86)/x264-Launcher/toolset/x264_8bit_x64.exe" --version

x264 0.125.2208 d9d2288
(libswscale 2.1.100)
(libavformat 54.17.100)
(ffmpegsource 2.17.2.1)
built by Komisar on Jul 19 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

x264 revision: 2208 (core #125)

--- ENCODING ---

Creating x264 process:
"D:/Program Files (x86)/x264-Launcher/toolset/x264_8bit_x64.exe" --crf 23.0 --preset medium
--tune film --video-filter crop:0,14,0,14
--output "D:\Temp\TSDoctor\Gefahr und Begierde.264"
--index D:\Temp\index.ffindex
"D:\Temp\TSDoctor\Gefahr und Begierde.ts"

ffms [info]: 1280x720p 1:1 @ 50/1 fps (vfr)
crop [info]: cropping to 1280x692
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
x264 [info]: profile High, level 3.2
x264 [info]: frame I:3104 Avg QP:21.33 size: 32009
x264 [info]: frame P:193230 Avg QP:24.65 size: 5475
x264 [info]: frame B:256793 Avg QP:26.22 size: 1180
x264 [info]: consecutive B-frames: 12.2% 32.2% 13.5% 42.1%
x264 [info]: mb I I16..4: 31.6% 56.7% 11.7%
x264 [info]: mb P I16..4: 2.9% 2.7% 0.2% P16..4: 32.5% 4.0% 3.2% 0.0% 0.0% skip:54.6%
x264 [info]: mb B I16..4: 0.1% 0.0% 0.0% B16..8: 25.9% 0.3% 0.0% direct: 0.4% skip:73.2% L0:42.8% L1:56.4% BI: 0.7%
x264 [info]: 8x8 transform intra:48.2% inter:88.7%
x264 [info]: coded y,uvDC,uvAC intra: 27.7% 41.1% 10.4% inter: 4.5% 9.9% 0.1%
x264 [info]: i16 v,h,dc,p: 52% 24% 8% 16%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 12% 43% 4% 5% 5% 5% 5% 4%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 37% 19% 14% 4% 6% 6% 5% 5% 3%
x264 [info]: i8c dc,h,v,p: 63% 16% 18% 3%
x264 [info]: Weighted P-Frames: Y:0.7% UV:0.2%
x264 [info]: ref P L0: 62.5% 13.0% 17.7% 6.8% 0.0%
x264 [info]: ref B L0: 87.4% 11.1% 1.6%
x264 [info]: ref B L1: 96.5% 3.5%
x264 [info]: kb/s:1289.06
encoded 453127 frames, 25.35 fps, 1289.06 kb/s
Final file size is 1,460,274,295 bytes.

--- DONE ---

Job finished at 2012-09-20, 09:53:53. Process took 300 minutes, 30 seconds.

[LoRd_MuldeR]

O.k., I understand. And the same argument will apply to --fps, that the GUI also suppresses, as I learnt yesterday.
But your launcher does not always use avisynth->pipe->x264. I tried a simple conversion that did not need avisynth (just cropping, which x264 can handle itself). To test if the output will be fine, I wanted to use the x264 --frames option. That was prohibited then by the GUI. In this case the behaviour of the GUI is counter-productive. I assume this use-case was just not on your radar, when you made your design decisions. For me it seemed natural to start all jobs from the same program (i.e. your launcher) independent of using avisynth or not. Main reason: to have the same job control for all conversions. Maybe your suppression should only be activated, if you actually use avisynth?

The GUI was created, mostly, long before x264 got native FFMS2 support, so we had to use Avisynth for everything (except for uncompressed YUV). I see that it may be desirable to use "--frames" or "--fps" when native FFMS2 input instead of Avisynth is used. Unfortunately the decision whether we use Avisynth or not is made much later in the process and the configuration dialog, where you enter your custom parameters, doesn't know yet. I will think about a solution though...

Ah, and the need to use the --fps option was: Without it x264 created output with borked frame rate (for some movies as low as 1.2, for others high as 18000). But that should be discussed in some other place (what would be the correct forum here on doom9 for this ?).

Well, that's probably because FFMS2 "detected" the framerate wrong. TS files are known to be problematic for FFMS2, so muxing the source into MKV first may already solve the issue. The correct place to discuss this issue would be the FFMS2 thread, I guess. That or the x264 development thread. But don't expect much "love" for TS files from the FFMS2 guys ^^

[coocooc]

Unfortunately the decision whether we use Avisynth or not is made much later in the process and the configuration dialog, where you enter your custom parameters, doesn't know yet. I will think about a solution though...
Seems you need to accept the user input first and then later give a warning, if it clashes with avisynth. What would happen, if the user really wanted to change the fps? His duty to do this in the .avs-script then?


Well, that's probably because FFMS2 "detected" the framerate wrong. TS files are known to be problematic for FFMS2, so muxing the source into MKV first may already solve the issue. The correct place to discuss this issue would be the FFMS2 thread, I guess. That or the x264 development thread. But don't expect much "love" for TS files from the FFMS2 guys ^^

I try to mux it first into MKV. I think I tried once to extract the AVC-part with tsmuxer first and it failed nevertheless. But I can't say for sure, didn't protocol all my failing attempts of the last day. But here (http://ffmpegsource.googlecode.com/svn/trunk/doc/ffms2-avisynth.html) is written:
Because of LAVF's demuxer, most raw streams (such as elementary h264 and other mpeg video streams) will fail to work properly.
So might be that raw files fail as well as .ts files. :(

x264 developer forum is on doom10 here (http://doom10.org/index.php?board=5.0), correct?
Is ffms2 development covered here (http://doom10.org/index.php?topic=25.0) despite being a subfolder of "avisynth development"?

[LoRd_MuldeR]

Seems you need to accept the user input first and then later give a warning, if it clashes with avisynth. What would happen, if the user really wanted to change the fps? His duty to do this in the .avs-script then?

Yes. Don't forget that the "--fps" option of x264 only specifies what the FPS of the input is. AFAIK, it doesn't allow to change the FPS. If, for example, the input video is actually 30 fps and I tell x264 via "--fps" that it's 60 fps, x264 will simply assume that the input is 60 fps rather than upconverting the 30 fps to 60 fps - resulting in a a/v desync. Avisynth, on the other hand, has filters that can do FPS conversion and keep the sync...

I try to mux it first into MKV. I think I tried once to extract the AVC-part with tsmuxer first and it failed nevertheless. But I can't say for sure, didn't protocol all my failing attempts of the last day. But here (http://ffmpegsource.googlecode.com/svn/trunk/doc/ffms2-avisynth.html) is written:

So might be that raw files fail as well as .ts files. :(

That's why I suggested MKV. Use MKVToolnix to wrap "raw" H.264 streams into MKV. You need to extract it from the TS first (e.g. via TSRemux or tsMuxeR).

x264 developer forum is on doom10 here (http://doom10.org/index.php?board=5.0), correct?
Is ffms2 development covered here (http://doom10.org/index.php?topic=25.0) despite being a subfolder of "avisynth development"?

There also is an x264 development thread right here:
http://forum.doom9.org/showthread.php?t=80910

Also note that FFMS2 is an Avisynth (source) filter. I think it was born to make libavcodec/libavformat available as a native Avisynth source filter, instead of having to go the DirectShowSource()+ffdshow route. But the "core" of FFMS2 is also available as a library that can be used on its own, without the Avisyth interface. That's what x264 does.

[coocooc]

Yes. Don't forget that the "--fps" option of x264 only specifies what the FPS of the input is. AFAIK, it doesn't allow to change the FPS. If, for example, the input video is actually 30 fps and I tell x264 via "--fps" that it's 60 fps, x264 will assume the input is 60 fps rather than upconverting the 30 fps to 60 fps. Avisynth, on the other hand, has filters that can do FPS conversion...


Thanks for the piece of information. Didn't know yet --fps defined the input only.


There also is an x264 development thread right here:
http://forum.doom9.org/showthread.php?t=80910


Seems to be dead since 2006, you probably meant that one (http://forum.doom9.org/showthread.php?t=108570&highlight=x264+development&page=91).

They state there is a separate CLI bug report thread here (http://forum.doom9.org/showthread.php?t=108571&page=13). Will post there, if I have substantial findings.


Also note that FFMS2 is an Avisynth (source) filter. I think it was born to make libavcodec/libavformat available as a native Avisynth source filter, instead of having to go the DirectShowSource()+ffdshow route. But the "core" of FFMS2 is also available as a library that can be used on its own, without the Avisyth interface. That's what x264 does.
Another thing that was not clear to me. Thanks! The thread category makes more sense then. :)

[LoRd_MuldeR]

Okay, I uploaded a new version. The CLI options "--fps" and "--frames" are now allowed as custom parameters.

If piped input (i.e. Avisynth/Avs2YUV) is used, we will kick out those parameters later and throw a warning. But you should be able to use them with FFMS2/LAVF input now.

Also, as usual, the x264 binaries have been updated to the current revision.

[GodRealm]

because does not work the function drag and drop in the window of the new version?

when dragging the avs script for the program window, automatically opening the new job. In the previous version.


sorry I use google translate, I'm Brazilian! ^^

[LoRd_MuldeR]

because does not work the function drag and drop in the window of the new version?

when dragging the avs script for the program window, automatically opening the new job. In the previous version.

sorry I use google translate, I'm Brazilian! ^^

Hi, GodRealm.

If I get you right, you are asking why "Drag & Drop" doesn't work with the latest build. Well, I can confirm that problem.

But I don't know why that this. Further investigation will be required, please stay tuned...

[GodRealm]

Hi, GodRealm.

If I get you right, you are asking why "Drag & Drop" doesn't work with the latest build. Well, I can confirm that problem.

But I don't know why that this. Further investigation will be required, please stay tuned...

I'll be waiting for some resolution of this bug.

Thank you!:)

[LoRd_MuldeR]

It appears this is a bug in Qt 4.8.3:
https://bugreports.qt-project.org/browse/QTBUG-27265

Seems like a fix is already on the way:
https://codereview.qt-project.org/#change,35297

All I can do is reverting back to Qt 4.8.2 until the issue has been fixed in Qt...

[EDIT]

Now that is strange: If I build with the static Qt 4.8.3 libraries that I compiled myself, Drag&Drop seems to be alright.

With the pre-compiled Qt 4.8.3 DLL's it definitely is broken :confused:

[LoRd_MuldeR]

I have put up a new build, that is using Qt 4.8.2 again. Should fix the Drag&Drop issue. Otherwise unchanged.

[GodRealm]

I have put up a new build, that is using Qt 4.8.2 again. Should fix the Drag&Drop issue. Otherwise unchanged.

This working perfectly.

Thank you!:D

[LoRd_MuldeR]

Just for the notes:

My first diagnosis that the static Qt 4.8.3 libraries do work alright was wrong, kind of. I only tested those with my LameXP project and Drag&Drop seemed to work, at first glance. But after some more testing I noticed that Drag&Drop did not work reliably. Since I don't want to revert my static Qt libraries to v4.8.2, I re-compiled Qt 4.8.3 with the suggested fix. Download link is below. Also note that this does not effect the Simple x264 Launcher, which uses the pre-compiled DLL's.

http://sourceforge.net/projects/lamexp/files/Miscellaneous/Qt%20Libraries/4.8.3/DrangAndDrop-Fix/

[GodRealm]

Hi LoRd_MuldeR!

I wonder if you could make a Britate Calculator for x264?

I tried to extract the MeGUI but could not.

It would be nice a newer version, separate from MeGUI.

If possible. Thank you!

[LoRd_MuldeR]

To start the (bitrate) calculator, go "Start" -> "Run" -> "calc.exe" :p

(Really, file size is defined as "Size = Bitrate x Duration" and thus we get "Bitrate = Size / Duration", which doesn't need any fancy tools to do the required math)

[SeeMoreDigital]

Hi LoRd_MuldeR,

Would it be possible for you to add a 'Lossless' option to your drop-down 'Profile' list please?

[LoRd_MuldeR]

Why would you need that? What is it supposed to do? :confused:

The "Profile" option really is only used to enforce a specific H.264 Profile. It maps 1:1 to x264's "--profile" parameter. But there is no such thing as a "lossless" Profile in the H.264 specs and I don't think x264 accepts "--profile lossless".

You can trigger the "lossless" mode of x264 simply via "CQ=0" or "CRF=0". It will use the "High 4:4:4" Profile, which is selectable from the "Profile" box. But of course "Auto" (the default) will work just fine.

[coocooc]

Okay, I uploaded a new version. The CLI options "--fps" and "--frames" are now allowed as custom parameters.

Thanks for the quick change! :)

[GZZ]

Hey lord. Nice little app. Will it be possible to load/save queues or just have the queue saved on exit and loaded on start?

[LoRd_MuldeR]

Hey lord. Nice little app. Will it be possible to load/save queues or just have the queue saved on exit and loaded on start?

Possible? Indeed. But I currently have no plans to implement it. Maybe at a later time...

[GZZ]

I also issue. When I load a AVS script (for making 3D SBS) (unchecking use 64 bit x264 on 64 bit machine, as some of the avs script is only 32 bit). When I have added my avs script and starts the job I get the following error

Simple x264 Launcher (Build #360), built 2012-09-26

Job started at 2012-10-01, 22:11:05.

Source file: E:/Temp2/script.avs
Output file: E:/Temp2/script.mkv

--- SETTINGS ---

RC Mode: CRF
Preset: Medium
Tuning: Animation
Profile: High
Custom: --level 4.1 --ref 4 --me umh

--- CHECK VERSION ---

Creating process:
"C:/ChromeDownload/x264mulder/Simple x264 Launcher v2/toolset/x264_8bit_x64.exe" --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

Creating process:
"C:/ChromeDownload/x264mulder/Simple x264 Launcher v2/toolset/avs2yuv_x86.exe"

Avs2YUV 0.24bm2

x264 revision: 2216 (core #128)
Avs2YUV version: 0.24.2

--- AVS INFO ---

Creating process:
"C:/ChromeDownload/x264mulder/Simple x264 Launcher v2/toolset/avs2yuv_x86.exe" -frames 1 E:\Temp2\script.avs NUL

E:\Temp2\script.avs: 1920x1080, 24000/1001 fps, 127766 frames

Resolution: 1920x1080
Frame Rate: 24000/1001
No. Frames: 127766

--- ENCODING ---

Creating Avisynth process:
"C:/ChromeDownload/x264mulder/Simple x264 Launcher v2/toolset/avs2yuv_x86.exe" E:\Temp2\script.avs -

Creating x264 process:
"C:/ChromeDownload/x264mulder/Simple x264 Launcher v2/toolset/x264_8bit_x64.exe" --crf 20.0 --preset medium --tune animation --profile high --level 4.1 --ref 4 --me umh --output E:\Temp2\script.mkv --frames 127766 --demuxer y4m --stdin y4m -

x264 [error]: could not open input file `-'
av2y [info]: E:\Temp2\script.avs: 1920x1080, 24000/1001 fps, 127766 frames
av2y [info]: error: wrote only 3085668 of 3110400 bytes

WARNING: Avisynth process exited with error code: 1

PROCESS EXITED WITH ERROR CODE: -1

from what I can see its missing something. Both jobs ends with -

[LoRd_MuldeR]

No, the commandline is correct. The data is passed via pipe! So the pseudo filename "-" is used to tell x264 to read from the STDIN (and AVS2Yuv to write to the STDOUT).

Does the very same .AVS file open correctly in VirtualDub and play all the way to the end?

[samtroy]

Quick (and possibly stupid) question for the pros:

If I encode a movie with CRF 18 and "Medium" preset and then the same movie with CRF 18 and "Slow" preset:

Will the quality be exactly the same and only the filesize will be a little larger?

I'm asking because "Slow" preset is much, much slower on my machine compared to "Medium" and I could easily live with a filesize increase of 1 or 2 gb (if the quality would be the same of course).

[LoRd_MuldeR]

Quick (and possibly stupid) question for the pros:

If I encode a movie with CRF 18 and "Medium" preset and then the same movie with CRF 18 and "Slow" preset:

Will the quality be exactly the same[?]

No. A specific CRF value gives the same quality (roughly!) for different sources, but only as long as no other influential options are changed :eek:

After switching from "Medium" to "Slow" preset (or vice versa) the same CRF value X may not give the same quality anymore, so you can't compare the file sizes!

In other words: You'll have to re-adjust your CRF value after switching the preset...

... and only the filesize will be a little larger?

When switching to a slower preset, one would expect the file size (i.e. average bitrate) to become smaller, not larger. Right? ;)

And indeed, switching to a slower preset will improve the compression, that is the "quality per bit" ratio. So you can get the same quality at a smaller file size.

In CRF mode, however, also the quality (for a specific CRF value X) may change when switching presets - as said before.

So again: In CRF mode you can't compare the file sizes after switching the preset. You would be comparing files of different size and (very likely) different quality.

Thus you'd learn nothing! Instead, use 2-Pass mode with a fixed target bitrate and compare quality...

[samtroy]

OK, thanks alot for all the info. I guess I'm sticking to "Slow", CRF 18 and High/Level 4.1 for now...

One more question: Do I have any quality disadvantage when I use x264's internal LAVF/FFMS video decoding and *not* use AVISynth?

[kypec]

One more question: Do I have any quality disadvantage when I use x264's internal LAVF/FFMS video decoding and *not* use AVISynth?
Unless that particular source filter contains some bugs that could possibly deliver broken/corrupted frames or produce missing/dropped/out-of-order frames then no, there is absolutely no difference in quality. Assuming any source filter works 100% correctly with your source material you should get identical output of all of them = 100% identical sequence of source decoded frames. There might be performance differences though so you better test each input source filter and decide which one suits you best.

[LoRd_MuldeR]

Actually I believe there is much more that can go wrong on the Avisynth side, especially when such "unpredictable" things as DirectShowSource() or AVISource() are involved.

Nowadays most people use FFVideoSource() from the FFMS2 package in their AVS script anyway. Output should then be identical to x264's built-in FFMS2, except that the latter avoids the Avisynth layer.

For me, primary reason to use Avisynth, if at all, is: Special input filters like DGDecodeNV that you can't have otherwise. That plus "complex" filters, e.g. QTGMC, not available otherwise.

(Some people also claim that the built-in "Resize" filter of x264 is significant slower than the Avisynth one. But I think this might very well a build issue with the specific x264 binary. Wouldn't generalize it!)

[GZZ]

Sorry for the slow reply... But I made some more testing and still cant get it working. So will explain what I do. But first.

No, the commandline is correct. The data is passed via pipe! So the pseudo filename "-" is used to tell x264 to read from the STDIN (and AVS2Yuv to write to the STDOUT).

Does the very same .AVS file open correctly in VirtualDub and play all the way to the end?

Virtualdub (32 bit version) crash when I try to load my AVS file.

My LionKing3D.avs script is for 3D SBS video:


LoadPlugin("e:\Encoding\SBS_Script\ffms2.dll")
LoadPlugin("e:\Encoding\SBS_Script\H264StereoSource.dll")
FFIndex("e:\Encoding\LionKing3D\LionKing_Left_Video.mkv", cachefile="e:\Encoding\LionKing3D\LionKing_Left_Video.mkv.ffindex", indexmask=0, demuxer="lavf")
Left_Video = FFVideoSource("e:\Encoding\LionKing3D\LionKing_Left_Video.mkv", cachefile="e:\Encoding\LionKing3D\LionKing_Left_Video.ffindex", seekmode=0).AssumeFPS(24000,1001)
Right_Video = H264StereoSource("e:\Encoding\LionKing3D\decoder.cfg", 127815).AssumeFPS(24000,1001)
return StackHorizontal(HorizontalReduceBy2(Left_Video), HorizontalReduceBy2(Right_Video)).Trim(0, 127765)


My x264 line, I just tested it and it works just fine if I send this to x264 (32 bit version). So I know my avs script is working.


"C:/ChromeDownload/x264mulder/Simple x264 Launcher v2/toolset/x264_8bit_x86.exe" --crf 20.0 --preset medium --tune animation --profile high --level 4.1 --ref 4 --me umh --frame-packing 3 --sar 1:1 --output "E:\Encoding\LionKing3D\LionKing3D.mkv" "E:\Encoding\LionKing3D\LionKing3D.avs"


If I load the above avs file into simple x264 launcher and uncheck "use 64 bit x264 for 64 bit machines" then I get this error


Simple x264 Launcher (Build #360), built 2012-09-26

Job started at 2012-10-04, 22:28:15.

Source file: E:/Encoding/LionKing3D/LionKing3D.avs
Output file: E:/Encoding/LionKing3D/LionKing3D.mkv

--- SETTINGS ---

RC Mode: CRF
Preset: Medium
Tuning: Film
Profile: High
Custom: --level 4.1 --ref 4 --me umh

--- CHECK VERSION ---

Creating process:
"C:/ChromeDownload/x264mulder/Simple x264 Launcher v2/toolset/x264_8bit_x64.exe" --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

Creating process:
"C:/ChromeDownload/x264mulder/Simple x264 Launcher v2/toolset/avs2yuv_x86.exe"

Avs2YUV 0.24bm2

x264 revision: 2216 (core #128)
Avs2YUV version: 0.24.2

--- AVS INFO ---

Creating process:
"C:/ChromeDownload/x264mulder/Simple x264 Launcher v2/toolset/avs2yuv_x86.exe" -frames 1 E:\Encoding\LionKing3D\LionKing3D.avs NUL

E:\Encoding\LionKing3D\LionKing3D.avs: 1920x1080, 24000/1001 fps, 127766 frames

Resolution: 1920x1080
Frame Rate: 24000/1001
No. Frames: 127766

--- ENCODING ---

Creating Avisynth process:
"C:/ChromeDownload/x264mulder/Simple x264 Launcher v2/toolset/avs2yuv_x86.exe" E:\Encoding\LionKing3D\LionKing3D.avs -

Creating x264 process:
"C:/ChromeDownload/x264mulder/Simple x264 Launcher v2/toolset/x264_8bit_x64.exe" --crf 20.0 --preset medium --tune film --profile high --level 4.1 --ref 4 --me umh --output E:\Encoding\LionKing3D\LionKing3D.mkv --frames 127766 --demuxer y4m --stdin y4m -

x264 [error]: could not open input file `-'
av2y [info]: E:\Encoding\LionKing3D\LionKing3D.avs: 1920x1080, 24000/1001 fps, 127766 frames
av2y [info]: error: wrote only 3085668 of 3110400 bytes

WARNING: Avisynth process exited with error code: 1

PROCESS EXITED WITH ERROR CODE: -1


Please let my know if you need more info.

[LoRd_MuldeR]

Virtualdub (32 bit version) crash when I try to load my AVS file.My x264 line, I just tested it and it works just fine if I send this to x264 (32 bit version). So I know my avs script is working.

How does this go together? If it crashed, it can't be working! :confused:

If your script crashes VirtualDub, then obviously something is seriously wrong with that script. It also means that your problem is not related to Simple x264 Launcher at all and this is the wrong thread to discuss it (we have an Avisynth forum (http://forum.doom9.org/forumdisplay.php?f=33)). So please try to get your script fixed first! I can only recommend to cut your script down and try to figure out what exactly causes the crash. If you use the experimental "x64" or "MT" branch of Avisynth, try stable Avisynth 2.58 (32-Bit) instead...

[GZZ]

How does this go together? If it crashed, it can't be working! :confused:

If your script crashes VirtualDub, then obviously something is seriously wrong with that script. It also means that your problem is not related to Simple x264 Launcher at all and this is the wrong thread to discuss it (we have an Avisynth forum (http://forum.doom9.org/forumdisplay.php?f=33)). So please try to get your script fixed first! I can only recommend to cut your script down and try to figure out what exactly causes the crash. If you use the experimental "x64" or "MT" branch of Avisynth, try stable Avisynth 2.58 (32-Bit) instead...

I really dont know. My avs script is identical to that BDtoAVCHD produce and I just manual encoded using the above script in x264 using the very same command as above and the video looks perfect. So cant be my avisynth version. But I have the 2.58 version 32 bit (used the link in your app to download).

But I will try see if I can get it working. Maybe its just a combination of piping to x264 64 bit that dosnt work with this avs script. Do you have any 3D movies you can test it on ?

[LoRd_MuldeR]

I really dont know. My avs script is identical to that BDtoAVCHD produce and I just manual encoded using the above script in x264 using the very same command as above and the video looks perfect. So cant be my avisynth version.

Just because the problem isn't triggered under condition "A" (using x264) it doesn't mean the problem doesn't exist. The fact that the problem is triggered under conditions "B" and "C" (using Avs2YUV or VirtualDub) shows that it is very real! Why the crash isn't triggered when you let x264 open the AVS file directly while the other applications will crash is difficult to say. Might be sheer luck. Or the phase of the moon.

Probably the crash is caused by a bug in Avisynth or (more likely) a bug in one of the plug-in's involved. Still my suggestion: Try to strip down the script as much as possible. Then identify which filter or plug-in exactly causes the crash....

(And another advice: Clean up your Avisynth plug-ins folder. In the past I had strange crashes that, apparently, were cause by buggy plug-in DLL's that weren't even used in the script!)

But I will try see if I can get it working. Maybe its just a combination of piping to x264 64 bit that dosnt work with this avs script.

For Avisynth it doesn't matter what the application which requested the frames will do with those frames. Whether the application encodes those frames in the same process, pipes those frames to another process or discards the frames right away - Avisynth doesn't know or care. The fact that VirtualDub crashes too verifies that this has nothing to with piping or with 64-Bit x264.

Do you have any 3D movies you can test it on ?

Nope. But piping 3840x2160 video (e.g. "Crowdrun") into x264 via Avs2YUV works fine for me. So very large frames (and "side-by-side" stereoscopic video is nothing else but large frames) aren't a problem.

Also it's not my job to debug Avisynth or third-party Avisynth plug-ins ;)

[GZZ]

I did some more testing and got my avisynth script working in Virtualdub.

LoadPlugin("e:\Encoding\SBS_Script\ffms2.dll")
LoadPlugin("e:\Encoding\SBS_Script\H264StereoSource.dll")
FFIndex("e:\Encoding\LionKing3D\LionKing_Left_Video.mkv", cachefile="e:\Encoding\LionKing3D\LionKing_Left_Video.mkv.ffindex", indexmask=0, demuxer="lavf")
Left_Video = FFVideoSource("e:\Encoding\LionKing3D\LionKing_Left_Video.mkv", cachefile="e:\Encoding\LionKing3D\LionKing_Left_Video.ffindex", seekmode=0).AssumeFPS(24000,1001)
Right_Video = H264StereoSource("e:\Encoding\LionKing3D\decoder.cfg", 127815).AssumeFPS(24000,1001)
return StackHorizontal(HorizontalReduceBy2(Left_Video), HorizontalReduceBy2(Right_Video)).Trim(0, 127765)

Number of frames (red) didnt match number of frames in the above line (blue). This made Virtualdub crash on load.

But I still get the same error when using your tool. But I tried to run the command lines manual from your log.

If I take this

"C:/ChromeDownload/x264mulder/Simple x264 Launcher v2/toolset/avs2yuv_x86.exe" E:\Encoding\LionKing3D\LionKing3D.avs -


and replace the - with an output file like this. Then I get a y4m file.


"C:/ChromeDownload/x264mulder/Simple x264 Launcher v2/toolset/avs2yuv_x86.exe" E:\Encoding\LionKing3D\LionKing3D.avs "e:\Encoding\LionKing3D\avs2yuvOutput.y4m"

I can then load the *.y4m file into x264 using this line (replaced the - with the above *.y4m file)


"C:/ChromeDownload/x264mulder/Simple x264 Launcher v2/toolset/x264_8bit_x64.exe" --crf 20.0 --preset medium --tune film --profile high --level 4.1 --ref 4 --me umh --output "E:\Encoding\LionKing3D\LionKing3D (2).mkv" --frames 127815 --demuxer y4m "e:\Encoding\LionKing3D\avs2yuvOutput.y4m"


then its encoding just fine without any errors.


I'm not sure it proves anything. But I suspect that the - options has a flaw and avs2yuv dosnt send any data to stdout as expected and therefor x264 fails.

[LoRd_MuldeR]

Now that doesn't make much sense at all. Whether you write the output to the STDOUT or to some "physical" file must not make any difference! :eek:

So I assume the bug in Avisynth (or more likely in one of the Avisynth plug-ins involved) is one of those nasty bugs that create "corrupted" memory and/or try to access "uninitialized" memory.

In this case, whether you actually get a crash or whether the bug remains unnoticed (which doesn't guarantee that the output will be correct !!!) is sheer luck ;)

And in this situation, small changes, even such that, at first glance, seem to be completely unrelated (like writing to a physical file or to the STDOUT), are only rolling the dice again...

At this point the only promising way to track the problem down: Compile a debug version of the "problematic" plugin and get debugging! Or, if you can't do it yourself, bother the plugin author.


Just out of curiosity: What happens if run exactly this command from the console:
"C:/ChromeDownload/x264mulder/Simple x264 Launcher v2/toolset/avs2yuv_x86.exe" E:\Encoding\LionKing3D\LionKing3D.avs - > foobar.y4m

[GZZ]

"C:/ChromeDownload/x264mulder/Simple x264 Launcher v2/toolset/avs2yuv_x86.exe" E:\Encoding\LionKing3D\LionKing3D.avs - > foobar.y4m

It then start writing a foobar.y4m file, just like if I did

"C:/ChromeDownload/x264mulder/Simple x264 Launcher v2/toolset/avs2yuv_x86.exe" E:\Encoding\LionKing3D\LionKing3D.avs "e:\Encoding\LionKing3D\avs2yuvOutput.y4m"


But the output foobar.y4m file dosnt work. I cant play it in vlc like i can with the avs2yuvOutput.y4m file. x264 dont want to load the file either, giving the error x264 [error]: could not open input file `e:\Encoding\LionKing3D\foobar.y4m'

[LoRd_MuldeR]

It then start writing a foobar.y4m file, just like if I did"C:/ChromeDownload/x264mulder/Simple x264 Launcher v2/toolset/avs2yuv_x86.exe" E:\Encoding\LionKing3D\LionKing3D.avs "e:\Encoding\LionKing3D\avs2yuvOutput.y4m"

Which only proves that using a pipe (alone) does not reliably reproduce the issue.

(That's because with the command I told you to try, you are telling Avs2YUV to write the output to STDOUT, just like when we are piping to the x264 process. Only difference is that this time the pipe will go to the CMD.EXE itself, instead of x264, and that CMD.EXE will dump all the data to a file right away. That's what the ">" operator does)


But the output foobar.y4m file dosnt work. I cant play it in vlc like i can with the avs2yuvOutput.y4m file. x264 dont want to load the file either, giving the error x264 [error]: could not open input file `e:\Encoding\LionKing3D\foobar.y4m'

Well, do the files come out at the same size? And did you compare the content, e.g. in a Hex Editor?

[GZZ]

Well, do the files come out at the same size? And did you compare the content, e.g. in a Hex Editor?

I didnt let it run til the end. The output files are huge. But I will let it run and compare the files and get back to you.

[LoRd_MuldeR]

Well, just add a "trim(0, 100)" at the end of your script for the test. Or does that make the original problem go away?

[GZZ]

Well, just add a "trim(0, 100)" at the end of your script for the test. Or does that make the original problem go away?

I added -frames 100 to the avs2yuv script and then I get 2 files which is only 2 bytes in difference.

The one with "...\foobar.y4m" output works and the other with > "...\foobar2.y4m" dosnt work. After comparing the files. It seams like a line break is inserted in the beginning of foobar2.y4m (Hex 0D 0A). #13#10 (delphi language).

Using a hex editor I can delete those 2 bytes from the beginning of the file and then both foobar2.y4m and foobar.y4m are identical when compared and both plays in vlc player.

So maybe the reason x264 is complaining is because of these 2 bytes when reading std from avs2yuv ?

[LoRd_MuldeR]

Those "wrong" bytes that slipped in most likely are one of those random "corruptions" I was talking about before.

This is one of the funny "effects" that can be caused by a bug, even if it doesn't crash the application altogether. Actually you are lucky if it does crash, because then you at least know that there is a bug somewhere.

...rather then getting corrupted output, which you might not even notice until it's too late ;)


Just for the notes: With a "working" Avisynth script (just FFmpegSoure and no fancy stuff), I get two 100% bit-identical output files:
F:\DeLpHi\x264_x64_launcher\res\toolset>avs2yuv_x86.exe D:\x264\sample.avs test1.y4m
D:\x264\sample.avs: 704x576, 60 fps, 500 frames

F:\DeLpHi\x264_x64_launcher\res\toolset>avs2yuv_x86.exe D:\x264\sample.avs - > test2.y4m
D:\x264\sample.avs: 704x576, 60 fps, 500 frames

F:\DeLpHi\x264_x64_launcher\res\toolset>sha1.exe < test1.y4m
f3a8b521d94d4a3bd0a71d03642a94adea6dc443

F:\DeLpHi\x264_x64_launcher\res\toolset>sha1.exe < test2.y4m
f3a8b521d94d4a3bd0a71d03642a94adea6dc443

F:\DeLpHi\x264_x64_launcher\res\toolset>

[GZZ]

is it something that can be fixed, like deleting the first 2 bytes before writing data to stdout ?

[LoRd_MuldeR]

If it can be fixed, then not by trying to workaround haphazard symptoms of the bug, but by tracking down the cause of the bug - and repairing it.

[samtroy]

@LoRd_MuldeR:

May I ask what exact settings + parameters you personally use for encoding a normal 2h 1080p movie?

Cheers, S.

[LoRd_MuldeR]

@LoRd_MuldeR:

May I ask what exact settings + parameters you personally use for encoding a normal 2h 1080p movie?

Cheers, S.

--crf 20 --preset veryslow

[samtroy]

--crf 20 --preset veryslow

OK.. and no extra parameters at all? Like --level 4.1 for compatability reasons maybe?

[LoRd_MuldeR]

OK.. and no extra parameters at all? Like --level 4.1 for compatability reasons maybe?

Nope.

[egrimisu]

how to use 10bit encode? i select high10 profile but stil x264 x86 8 bit is used.

[LoRd_MuldeR]

8-Bit vs. 10-Bit is a compile-time decision. It's nothing you can change at runtime via option ;)

The "--profile" option of x264 only restricts your other option to (at most) the selected H.264 Profile. It does not enforce the selected Profile, if a lower Profile is sufficient for your file.

In other words: Using 10-Bit H.264 implies the "High 10" Profile, but selecting the "High 10" Profile (alone) does NOT trigger or imply 10-Bit encoding!

You can enable "10-Bit encoding" in the preferences dialog. This will use the 10-Bit x264 binary for subsequent encodes, instead of the 8-Bit x264 binary that is used by default.

[egrimisu]

8-Bit vs. 10-Bit is a compile-time decision. It's nothing you can change at runtime via option ;)

The "--profile" option of x264 only restricts your other option to (at most) the selected H.264 Profile. It does not enforce the selected Profile, if a lower Profile is sufficient for your file.

In other words: Using 10-Bit H.264 implies the "High 10" Profile, but selecting the "High 10" Profile (alone) does NOT trigger or imply 10-Bit encoding!

You can enable "10-Bit encoding" in the preferences dialog. This will use the 10-Bit x264 binary for subsequent encodes, instead of the 8-Bit x264 binary that is used by default.

Fair enough, still what to enter in dialog there nothing in the help related to 10bit?

[LoRd_MuldeR]

Fair enough, still what to enter in dialog there nothing in the help related to 10bit?

:confused:

If you ask how to enable 10-Bit encoding in Simple x264 Launcher, just go to "File" -> "Preferences" and enable "Use 10-Bit version of x264".

It will show a warning. Read that warning and, if you have understood the consequences, click "Continue".

[egrimisu]

:confused:

If you ask how to enable 10-Bit encoding in Simple x264 Launcher, just go to "File" -> "Preferences" and enable "Use 10-Bit version of x264".

It will show a warning. Read that warning and, if you have understood the consequences, click "Continue".

Iddiot me, thanks, nice that you had implemented queue ;)

[darknoob]

Just wanted to say thank you Lord for making the new version with batch process, so much easier now queuing up test encodes. Also now I can see my RF after first pass, good stuff mate!

[nibus]

After upgrading to the newest version I'm getting constant crashes from avs2yuv:


Problem signature:
Problem Event Name: APPCRASH
Application Name: avs2yuv_x86.exe
Application Version: 0.0.0.0
Application Timestamp: 4e78e870
Fault Module Name: avisynth.DLL
Fault Module Version: 2.6.0.3
Fault Module Timestamp: 4f7b27cf
Exception Code: c0000005
Exception Offset: 00066e34
OS Version: 6.1.7601.2.1.0.256.4
Locale ID: 1033
Additional Information 1: 9bb2
Additional Information 2: 9bb2af9eb5b5e3c312278cd2f1aa9dbe
Additional Information 3: 9af5
Additional Information 4: 9af54169938890e76fe9ec03370a170d


This is on a Sandy Bridge 2600K, 8gb Ram, running at 4.0ghz. I didn't have any problems with the previous version. However it appears to run fine on my non-overclocked i7 930.

Is x264_x64.2012-07-22.exe the previous build? I will try it with that version and make sure it still runs stable.

[LoRd_MuldeR]

All previous versions can be found here:
http://code.google.com/p/mulder/downloads/list?can=1&q=simple&sort=-uploaded&colspec=Filename+Summary+Type+Uploaded+Size+DownloadCount

But Avs2YUV neither is my work nor did I change the included Avs2YUV binaries lately...

I've always been using the latest version from here:
http://komisar.gin.by/tools/avs2yuv/

What you are experiencing is probably a crash in Avisynth or (more likely) in one of the Avisynth plug-in's involved.

Does the very same Avisynth script open in VirtualDub and play through all the way to the end?

[nibus]

What you are experiencing is probably a crash in Avisynth or (more likely) in one of the Avisynth plug-in's involved.

Does the very same Avisynth script open in VirtualDub and play through all the way to the end?

It appears to play fine in VirtualDub, though I haven't had time to run through the entire video.

After reverting to x264_x64.2012-07-22.exe I still have the crash, though without the avs2yuv notice. The application just reports that x264 is not responding. Each time it appears to be in a different portion of the video.

The only other thing that has changed was a small mvtools2.dll update (http://forum.doom9.org/showthread.php?p=1386559#post1386559). That is probably the cause of the crash, though it's strange that it only happens on my newer i7 box.

I'm trying the encode again without filters; will report back.

[LoRd_MuldeR]

That's the problem with software testing: The fact that you didn't get a crash, doesn't prove the absence of bugs ;)

Depending on the nature of the bug, it may only be triggered under specific conditions. The conditions may even not be deterministic, which is especially true for "race conditions" errors!

And with memory corruption bugs, like "buffer overruns" or "dangling pointers", it's sheer luck whether you get an instant crash or "only" corrupted output (or no effect at all).

[nibus]

The encode runs fine without filters so it's probably an issue with mvtools2 or MT. Thanks for your help Mulder.

[GZZ]

in preferences I have checked "Automatically save output to log file when job has finished" - Where can I locate this log file, its not among my movie source files and I have tried look in the temp folder where the .ffindex file are saved. Can you give me a hint on where to find it ?

[r0lZ]

C:\Users\<YOU>\AppData\Local\LoRd_MuldeR\Simple x264 Launcher\logs\

[RockTheBass]

Hey!

Thaks for this great x264 encoder software! :) I love it!
I want to ask something. I downloaded the newest version (v2.06), I installed and I checked the version of x264 encoders:
toolset\x264_8bit_x64.exe

x264 core:128 r2216 198a7ea

I downloaded the newest x64 8bit version EXE from there: http://x264.nl/ and I checked this version also:

x264 core:128 r2216 198a7ea

The versions are same, but I noticed there are difference between the file sizes.
\Simple x264 Launcher v2\toolset\x264_8bit_x64.exe 9,034,240 Bytes

x264.nl_x64_8bit\x264.exe 10,607,616 Bytes.

Can someone explain why is difference these file sizes? I thought, x264 Simple Launcher uses the original x264 files. May I should replace the original files that located in \toolset\ folder with the www.x264.nl files?

Thank you! :)

[LoRd_MuldeR]

There is no such thing as "original" x264 files. x264 is OpenSource software and released as source code (http://en.wikipedia.org/wiki/Source_code). There are no "official" binaries (http://en.wikipedia.org/wiki/Software_build) ;)

Everybody can make his/her own builds. And the resulting file size will depend on many things, like the compiler version that was used, the compiler settings that were used, the libraries included in the build (or not), the versions of the included libraries, the debug symbols being stripped (or not), and so on. The binaries might even have been compressed with an "exe packer" like UPX...

I didn't compile x264 myself this time. The binaries I included in the Simple x264 Launcher download are those provided by Komisar (http://komisar.gin.by/) and the differences to JEEB's binaries (http://x264.nl/) should be negligible.

[RockTheBass]

Ohh, I understand. Thank you very much for quick answer! Please keep up this great software, and continue your work as you always do :) :cool:


There is no such thing as "original" x264 files. x264 is OpenSource software and released as source code (http://en.wikipedia.org/wiki/Source_code). There are no "official" binaries (http://en.wikipedia.org/wiki/Software_build) ;)

Everybody can make his/her own builds. And the resulting file size will depend on many things, like the compiler version that was used, the compiler settings that were used, the libraries included in the build (or not), the versions of the included libraries, the debug symbols being stripped (or not), and so on. The binaries might even have been compressed with an "exe packer" like UPX...

I didn't compile x264 myself this time. The binaries I included in the Simple x264 Launcher download are those provided by Komisar (http://komisar.gin.by/) and the differences to JEEB's binaries (http://x264.nl/) should be negligible.

[VideoFanatic]

I've installed the latest version of your program (2.06) on a new Windows 7 64-bit installation. I can't drag and avs files into your program. Even if I open the job window and drag it into the source file box, it doesn't work. The only way I can open a file is to manually select the file in the directory.

On my Vista 32-bit PC I had the 22nd July 2012 version and I could drag and drop an AVS file into main window and it would automatically populate the job source file.

[LoRd_MuldeR]

Are you sure you really have the latest version?

Qt v4.8.3 broke Drag&Drop on the Window platform. After I knew about that issue, I reverted to Qt v4.8.2 and uploaded a new build.

So please make sure you got build #360 and you also updated all the DLL's, i.e. do not copy over the EXE file only!

(BTW: The Drag&Drop issue is already fixed for the next Qt version and I will update to Qt 4.8.4 as soon as it becomes available)

[VideoFanatic]

I downloaded your program from here (http://forum.doom9.org/showpost.php?p=1234822&postcount=1) under "Download new version with queuing support". That page gave me this: x264_x64.2012-09-26.exe

I've no idea what you're talking about in regards to updating all the DLL's. I just double-clicked on the exe file to install the program as I did in the past. What else do I need to do?

I loaded the About page in your program and it says it's version 2.06.360. If the drag and drop feature is supposed to work in the 2012-09-26 version then how do I make it work because it doesn't work for me!

[LoRd_MuldeR]

Build #360 (https://mulder.googlecode.com/files/x264_x64.2012-09-26.exe) (2012-09-26) is the latest version, indeed.

That version ships with Qt 4.8.2, which you can check in the "About" dialog too. There is nothing special you need to do to get Drag&Drop working, it is supposed to work "out of the box".

For me it definitely does work using build #360 (2012-09-26). I'm using Windows 7 and never tested Vista, but that really shouldn't make a difference :confused:

Anyway, if there ware some problem with Drag&Drop already in Qt 4.8.2, then there isn't much I can do. The problem would have to be reported to the Qt bugtracker, so the Qt guys can fix it.

BTW: You are not running Simple x264 Launcher with "elevated" rights, do you? Drag&Drop from a none-elevated application (e.g. Explorer) into an elevated one doesn't work...

BTW2: You might want to give my LameXP program a try. It is being built with Qt 4.8.3, but incorporates a Qt patch that is supposed to fix the Drag&Drop issue introduced in Qt 4.8.3.

[VideoFanatic]

My apologies. It was Explorer++ that was causing the problem. That program doesn't seem to allow drag and drop.

[VideoFanatic]

The program is portable, nothing is installed, it just copies the folders onto your PC. To uninstall it, just delete the "installation" folder.

[LoRd_MuldeR]

Hello,

nice app!

Some suggestions/requests though:

(1) You can easily add "--level" to the advanced options, if you really need to enforce a specific Level. Most of the time it is recommended to simply let x264 set the most suitable Level for your footage.

(2) You can easily update the x264 binaries. Unless the new x264 build broke compatibility with the command-line interface (which usually doesn't happen), the GUI doesn't need to be updated. I upload new packages from time to time, but I can't create a new package for each x264 revision number.

(3) What about allowing additional "--tune" entries in the advanced options? I don't really like adding more controls to the configurations dialog. Especially because those two tunes that you might want to add additionally are not useful and not recommended for the great majority of the users (both, "zerolatency" and "fastdecode", strongly cripple the encoder settings for a highly specific purpose).

(4) Avisynth is considered a prerequisite for Simple x264 Launcher. After all this app was primarily written to use 32-Bit Avisynth with 64-Bit x264. So I won't remove the warning message, because a missing Avisynth means that a major feature of Simple x264 Launcher will be broken. But I'm planning to add VapourSynth support soon ;)

(5) holygamer said it all. The "installer" is pretty much an SFX archive. To uninstall, use Ctrl+Del on the install folder :)

[Kisa_AG]

(2) You can easily update the x264 binaries.

Hello LoRd_MuldeR.

Thanks for this GREAT tool!

Please can you describe which x264 binaries is possible to use? If I remember correctly, in the past you've recommend Generic binaries from Komisar (komisar.gin.by). But Komisar don't update binaries since x264 r2216.
Is it possible to use generic binaries from x264.nl? Is there any the difference?
Thanks!

[kypec]

Please can you describe which x264 binaries is possible to use? If I remember correctly, in the past you've recommend Generic binaries from Komisar (komisar.gin.by). But Komisar don't update binaries since x264 r2216.
Is it possible to use generic binaries from x264.nl? Is there any the difference?
Thanks!
I believe replacing x264 binaries with JEEB's builds from x264.nl should be just fine. I did it in the past too when komisar's builds were "delayed" ;)

[LoRd_MuldeR]

You can pick whatever builds you prefer, as long as they aren't broken and have been build with all the libs you need - which should apply to all builds from the "usual" sources ;)

Yet another source is the MeGUI update server:
http://megui.org/auto/

[VideoFanatic]

In VideoRedo I move through my video 1 second at a time. MPEG2s are fast to navigate but h264 is slow and at worst it's realtime.

See the 2nd post here: http://www.videoredo.net/msgBoard/showthread.php?t=29834


He basically says to use shorter GOPs and try to set it to insert an I/IDR frame every second or so.

How do I do that in Simple x264 Launcher?

[LoRd_MuldeR]

MPEG-2 is much(!) simpler than H.264, so decoding MPEG-2 is much faster than H.264. Not very surprising ;)

Furthermore, the longer your GOP's are, the slower seeking (navigation) will be. That's because decoding can only start at an key-frame. If you seek to a certain frame number and that frame doesn't happen to be a key-frame, then decoding has to start at the key-frame that precedes the desired frame. Then all the frames, from the key-frame up to the desired frame, have to be decoded (maybe skipping the B-Frames). Consequently, the larger the distance between the key-frames is, the more frames will have to be decoded on each seek operation (in average case). And thus a larger key-frame distance results in "slower" seeking. That's pretty much the same with MPEG-2 and H.264.

So if you want to ensure that seeking is "fast", you will have to limit the key-frame (IDR-Frame, in H.264) distance. Simply add "--keyint x" to the advanced options and replace x with the desired number. Default is 250. If you want one key-frame per second, you would set "--keyint 25", given that your footage is 25 fps. Needless to mention that setting a shorter key-frame distance will hurt compression efficiency...

[VideoFanatic]

Setting it to 50 makes navigation much faster but slower than MPEG2. I only lose 72 MB per 1 hour 30 minute file instead of 300 MB if I set it to 0! When you fill a Bluray disc that's only a loss of 504 MB compared to 2.1 GB. Zero gives navigation speeds as fast as MPEG2.

Just wondering if other programs have fast navigation by default (low keyframe distance) such as handbrake because I haven't heard of other people having slow navigation after using other programs to encode to h264?

I take it that the keyframe distance setting is the only way to speed up navigation?

[LoRd_MuldeR]

Setting it to 50 makes navigation much faster but slower than MPEG2.

...as expected ;)

If you make a video compression scheme more complex (H.264), it cannot decode as fast as its much simpler predecessor (MPEG-2). Better compression costs more CPU cycles. As always in life, nothing's for free.

I only lose 72 MB per 1 hour 30 minute file instead of 300 MB if I set it to 0! When you fill a Bluray disc that's only a loss of 504 MB compared to 2.1 GB. Zero gives navigation speeds as fast as MPEG2.

If you compare file sizes, I guess you encoded in CRF mode. As has been explained about one million times in this forum, the same CRF value does not give the same quality, as soon as you change other options - such as the key frame interval (or anything else). So you are comparing apples to bananas, i.e. your numbers don't say anything.

BTW: Setting "--keyint 0" means unrestricted, which means the key-frame interval will be infinite. That's the worst case for seeking! The encoder will still put key-frames at scene changes though, which mitigates things a bit.

Oups, "--keyint 0" means auto, not infinite. If you wanted an infinite key-frame interval (which you obviously don't want here!), you'd have to use "--keyint infinite".

Just wondering if other programs have fast navigation by default (low keyframe distance) such as handbrake because I haven't heard of other people having slow navigation after using other programs to encode to h264?

Pretty much ALL applications that you can download/use (legally) for free and that output H.264 video are based on x264. And x264 uses 250 as the default key-frame distance. Of course front-ends like Handbrake or whatever might set their own defaults, overwriting x264's defaults. Using lower key-frame distance by default would mean faster seeking but worse compression. As for Simple x264 Launcher, it doesn't mess with x264's defaults, so you get what x264's uses by default (and what the select Preset/Tuning applies!) unless you overwrite the setting explicitly...

I take it that the keyframe distance setting is the only way to speed up navigation?

Yes! That and how navigation is implemented in the application which navigates through the H.264 stream. DGIndexNV, for example, creates an index file first. Creating the index file takes some time, indeed, because the whole file needs to parsed once. But once you have the index, seeking is fast and accurate (at least as fast as it can possibly be). Other apps might seek through the H.264 more or less "blindly" until the desired frame is found. This doesn't need an index file, but obviously will be much slower (in average case).

[docholliday]

How can i use it,cant use comand line,,,I want use 2pass and High L4.1 and Audio AC3 448 5.1,Can u help me?

[LoRd_MuldeR]

How can i use it,cant use comand line,,,I want use 2pass and High L4.1 and Audio AC3 448 5.1,Can u help me?

No need to scream!

If you want 2-Pass rate-control and "High" Profile, then I would suggest to select those from the GUI ;)

http://img24.imageshack.us/img24/3603/clipboard05p.png

Level 4.1 can be enforced by adding --level 4.1 to the advanced options. And, as x264 is a video encoder, it doesn't encode audio.

[docholliday]

Tnx mate,but how can i resize for example i want 720p Resize,How can i do that ?

[LoRd_MuldeR]

You can (a) use an Avisynth script as input and then invoke one of the various Avisynth Resize-Filters (http://avisynth.org/mediawiki/Resize) in your script or (b) use x264's internal/built-in resize filter.

For the latter, simply add --video-filter resize:width=1280,height=720,method=lanczos to the advanced options. For details have a look here (http://mewiki.project357.com/wiki/X264_Settings#video-filter).

[VideoFanatic]

I sometimes get this error code: WARNING: Avisynth process exited with error code: 1. Usually I get a popup saying what plugin is at fault but these last few times I didn't. How can I find out what plugin is at fault?

It's weird, I got that message yet the encoding says it was 100% completed yet it obviously isn't as it only encoded a part of the file.

[LoRd_MuldeR]

This usually indicates Avisynth (or more likely one of the Avisynth plug-in's involved) has crashed!

You may try to open the identical script in VirtualDub and then try to play all the way through the end of the clip...

[VideoFanatic]

I don't really use VirtualDub. Do I just drag the script into VirtualDub then click on the play button? So if there's an error will VirtualDub give a popup showing what plugin is at fault?