Current Patches, Where to get them, How they affect speed/output

[rack04]

Toolchain:
cross-mingw.gcc443.core2.20100124
gpac-cvs-0.4.6-DEV-01272010.core2
coreutils-5.97-2-msys-1.0.11-ext
pkg-config_0.23-3
glib_2.22.3-1
yasm-0.8.0.2289
msys-1.0.11
x264_x86_r1442M (http://www.multiupload.com/CHD4ORVC0J)

Patch:
x264_NAL-HRD.1.30 (http://pastebin.com/m11b319d9)
x264_AQ_experiments_v4 (http://komisar.gin.by/test/x264_AQ_experiments_v4.diff)

./configure --extra-cflags="-march=core2"
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=parkrun.1280x720.yuv
x264_x86_r1442M (http://www.multiupload.com/6TB6UZ2THO)

Patch:
x264_filtering_04_r1442 (http://users.telenet.be/darnley/x264/x264_filtering_04_r1442.diff)
x264_AQ_experiments_v4 (http://komisar.gin.by/test/x264_AQ_experiments_v4.diff)

./configure --extra-cflags="-march=core2"
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
filters: resize select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=parkrun.1280x720.yuv
LAVF/FFMS:
ffmpeg r21893 and libswscale r30654 (http://www.multiupload.com/SO876G7G8J)
ffms2 r292 (http://www.multiupload.com/XPAMAV3B7Y)

[jpsdr]

@rack04 : How work your download links ?
When i click on them i have a french web page, but absolutely no download of any kind...

[rack04]

@rack04 : How work your download links ?
When i click on them i have a french web page, but absolutely no download of any kind...

The links are Multiupload.com links and they work fine for me.

http://i11.photobucket.com/albums/a199/rack04/multiupload.jpg

[jpsdr]

Well... That's absolutely NOT what i was getting !
And... now it's working...
I don't understand at all... Mysteries of Internet...

[olapanekala]

techhouse
we haven't seen any of your excellent builds for some time.

If it is no trouble pls make some icc qx ss3.
Thnx again for your time

:thanks:

[VincAlastor]

i have seen on komisar's website that autoVAQ is better than standard AQ. but i haven't understand what parameters i have to set for best quality? can someone say me short what i have to use for tune film? --aq-mode 2 --psy-rd 1.0:0.15 or --aq-mode 2 --psy-rd 0:0 or the patch --aq-mode 3 --psy-rd ??:??
my english isn't good enough to understand such things.

thank you guys for your great builds an patches and yes [rex] or techhouse intel ss3 patches are missing for a while :)

[rack04]

i have seen on komisar's website that autoVAQ is better than standard AQ. but i haven't understand what parameters i have to set for best quality? can someone say me short what i have to use for tune film? --aq-mode 2 --psy-rd 1.0:0.15 or --aq-mode 2 --psy-rd 0:0 or the patch --aq-mode 3 --psy-rd ??:??
my english isn't good enough to understand such things.

thank you guys for your great builds an patches and yes [rex] or techhouse intel ss3 patches are missing for a while :)

Best is whatever is best for you. Please see this post for an explanation of the modes.

http://forum.doom9.org/showthread.php?p=1357555#post1357555

[VincAlastor]

Best is whatever is best for you. Please see this post for an explanation of the modes.

http://forum.doom9.org/showthread.php?p=1357555#post1357555

i do compress very strong together with strong denoising and some sharpening (fft3d). the best is for me a setting with much less artefacts, like banding.

[rack04]

Toolchain:
cross-mingw.gcc443.core2.20100124
gpac-cvs-0.4.6-DEV-01272010.core2
coreutils-5.97-2-msys-1.0.11-ext
pkg-config_0.23-3
glib_2.22.3-1
yasm-r2291
msys-1.0.11
x86:

x264_x86_r1442M (http://www.multiupload.com/YYQ6Y7TUHW)

Patch:
x264_NAL-HRD.1.31 (http://pastebin.com/m7c87355c)
x264_AQ_experiments_v4 (http://komisar.gin.by/test/x264_AQ_experiments_v4.diff)

./configure --extra-cflags="-march=core2"
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=pedestrian_1920x1080.yuv
LAVF/FFMS:
ffmpeg r21955 and libswscale r30694 (http://www.multiupload.com/ICPI7LO9H0)
ffms2 r292 (http://www.multiupload.com/LXHQ3SXB1D)
x264_x86_r1442M (http://www.multiupload.com/UQ9M97S72A)

Patch:
x264_filtering_05_r1442 (http://users.telenet.be/darnley/x264/x264_filtering_05_r1442.diff)
x264_AQ_experiments_v4 (http://komisar.gin.by/test/x264_AQ_experiments_v4.diff)

./configure --extra-cflags="-march=core2"
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
filters: resize select_every crop
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=parkrun.1280x720.yuv
LAVF/FFMS:
ffmpeg r21961 and libswscale r30697 (http://www.multiupload.com/CVRUC2KJ90)
ffms2 r292 (http://www.multiupload.com/P39WYMAIB8)
x64:

x264_x64_r1442M (http://www.multiupload.com/1N8AS0YQU1)

Patch:
x264_NAL-HRD.1.31 (http://pastebin.com/m7c87355c)
x264_AQ_experiments_v4 (http://komisar.gin.by/test/x264_AQ_experiments_v4.diff)

./configure --extra-cflags="-march=core2" --host="x86_64-pc-mingw32" --cross-prefix="x86_64-pc-mingw32-"
Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: no
ffms input: no
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=pedestrian_1920x1080.yuv

[rack04]

Toolchain:
cross-mingw.gcc443.core2.20100124
gpac-cvs-0.4.6-DEV.core2.01272010
coreutils-5.97-2-msys-1.0.11-ext
pkg-config_0.23-3
glib_2.22.3-1
yasm-r2291
msys-1.0.11
x86:

x264_x86_r1460M (http://www.multiupload.com/0KA37E7WVX)

./configure --extra-cflags="-march=core2"
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=parkrun.1280x720.yuv
LAVF/FFMS:
ffmpeg r21997 and libswscale r30720 (http://www.multiupload.com/BIE13B7J2T)
ffms2 r292 (http://www.multiupload.com/2PVUU91O1F)

[jpsdr]

From what it seems, the autoVAQ 4 is now implemented, the new --aqmode 2 is the same than old/patched --aqmode 4.
But, can someone please make a build with the last NAL_HRD ?
Thanks.

[rack04]

From what it seems, the autoVAQ 4 is now implemented, the new --aqmode 2 is the same than old/patched --aqmode 4.
But, can someone please make a build with the last NAL_HRD ?
Thanks.

The patch will have to be updated the patch the latest git.

[jpsdr]

@rack04
Here the result of the --fullhelp of your last build.
There is apparently some troubles...

x264 core:88 r1460 9e35bd0
Syntax: x264 [options] -o outfile infile [widthxheight]

Options:

-h, --help List basic options
--longhelp List more options
--fullhelp List all options


Frame-type options:

-I, --keyint <integer> Maximum GOP size [2089877979]
-i, --min-keyint <integer> Minimum GOP size [0]
--no-scenecut Disable adaptive I-frame decision
--scenecut <integer> How aggressively to insert extra I-frames [12]
--intra-refresh Use Periodic Intra Refresh instead of IDR frames
-b, --bframes <integer> Number of B-frames between I and P [2368272]
--b-adapt <integer> Adaptive B-frame decision method [2367120]
Higher values may lower threading efficiency.
- 0: Disabled
- 1: Fast
- 2: Optimal (slow with high --bframes)
--b-bias <integer> Influences how often B-frames are used [2292916]
--b-pyramid <string> Keep some B-frames as references [???]
- none: Disabled
- strict: Strictly hierarchical pyramid
- normal: Non-strict (not Blu-ray compatible)
--no-cabac Disable CABAC
-r, --ref <integer> Number of reference frames [2089881734]
--no-deblock Disable loop filter
-f, --deblock <alpha:beta> Loop filter parameters [2293064:2371200]
--slices <integer> Number of slices per frame; forces rectangular
slices and is overridden by other slicing options
--slice-max-size <integer> Limit the size of each slice in bytes
--slice-max-mbs <integer> Limit the size of each slice in macroblocks
--interlaced Enable pure-interlaced mode
--constrained-intra Enable constrained intra prediction.

Ratecontrol:

-q, --qp <integer> Force constant QP (0-51, 0=lossless)
-B, --bitrate <integer> Set bitrate (kbit/s)
--crf <float> Quality-based VBR (0-51, 0=lossless) [0.0]
--rc-lookahead <integer> Number of frames for frametype lookahead [10513352]
--vbv-maxrate <integer> Max local bitrate (kbit/s) [9762748]
--vbv-bufsize <integer> Set size of the VBV buffer (kbit) [9830000]
--vbv-init <float> Initial VBV buffer occupancy [0.0]
--qpmin <integer> Set min QP [6]
--qpmax <integer> Set max QP [0]
--qpstep <integer> Set max QP step [6]
--ratetol <float> Tolerance of ABR ratecontrol and VBV [0.0]
--ipratio <float> QP factor between I and P [0.00]
--pbratio <float> QP factor between P and B [0.00]
--chroma-qp-offset <integer> QP difference between chroma and luma [10511436]
--aq-mode <integer> AQ method [9274580]
- 0: Disabled
- 1: Variance AQ (complexity mask)
- 2: Auto-variance AQ (experimental)
--aq-strength <float> Reduces blocking and blurring in flat and
textured areas. [0.0]

-p, --pass <integer> Enable multipass ratecontrol
- 1: First pass, creates stats file
- 2: Last pass, does not overwrite stats file
- 3: Nth pass, overwrites stats file
--stats <string> Filename for 2 pass stats [""]
--no-mbtree Disable mb-tree ratecontrol.
--qcomp <float> QP curve compression [0.00]
--cplxblur <float> Reduce fluctuations in QP (before curve compression) [0.0]
--qblur <float> Reduce fluctuations in QP (after curve compression) [0.0]
--zones <zone0>/<zone1>/... Tweak the bitrate of regions of the video
Each zone is of the form
<start frame>,<end frame>,<option>
where <option> is either
q=<integer> (force QP)
or b=<float> (bitrate multiplier)
--qpfile <string> Force frametypes and QPs for some or all frames
Format of each line: framenumber frametype QP
QP of -1 lets x264 choose. Frametypes: I,i,P,B,b.
QPs are restricted by qpmin/qpmax.

Analysis:

-A, --partitions <string> Partitions to consider ["p8x8,b8x8,i8x8,i4x4"]
- p8x8, p4x4, b8x8, i8x8, i4x4
- none, all
(p4x4 requires p8x8. i8x8 requires --8x8dct.)
--direct <string> Direct MV prediction mode ["???"]
- none, spatial, temporal, auto
--no-weightb Disable weighted prediction for B-frames
--weightp <integer> Weighted prediction for P-frames [9827368]
- 0: Disabled
- 1: Blind offset
- 2: Smart analysis
--me <string> Integer pixel motion estimation method ["???"]
- dia: diamond search, radius 1 (fast)
- hex: hexagonal search, radius 2
- umh: uneven multi-hexagon search
- esa: exhaustive search
- tesa: hadamard exhaustive search (slow)
--merange <integer> Maximum motion vector search range [9291360]
--mvrange <integer> Maximum motion vector length [-1 (auto)]
--mvrange-thread <int> Minimum buffer between threads [-1 (auto)]
-m, --subme <integer> Subpixel motion estimation and mode decision [0]
- 0: fullpel only (not recommended)
- 1: SAD mode decision, one qpel iteration
- 2: SATD mode decision
- 3-5: Progressively more qpel
- 6: RD mode decision for I/P-frames
- 7: RD mode decision for all frames
- 8: RD refinement for I/P-frames
- 9: RD refinement for all frames
- 10: QP-RD - requires trellis=2, aq-mode>0
--psy-rd Strength of psychovisual optimization ["0.0:0.0"]
#1: RD (requires subme>=6)
#2: Trellis (requires trellis, experimental)
--no-psy Disable all visual optimizations that worsen
both PSNR and SSIM.
--no-mixed-refs Don't decide references on a per partition basis
--no-chroma-me Ignore chroma in motion estimation
--no-8x8dct Disable adaptive spatial transform size
-t, --trellis <integer> Trellis RD quantization. Requires CABAC. [9291201]
- 0: disabled
- 1: enabled only on the final encode of a MB
- 2: enabled on all mode decisions
--no-fast-pskip Disables early SKIP detection on P-frames
--no-dct-decimate Disables coefficient thresholding on P-frames
--nr <integer> Noise reduction [6]

--deadzone-inter <int> Set the size of the inter luma quantization deadzone [9827368]
--deadzone-intra <int> Set the size of the intra luma quantization deadzone [2293292]
Deadzones should be in the range 0 - 32.
--cqm <string> Preset quant matrices ["flat"]
- jvt, flat
--cqmfile <string> Read custom quant matrices from a JM-compatible file
Overrides any other --cqm* options.
--cqm4 <list> Set all 4x4 quant matrices
Takes a comma-separated list of 16 integers.
--cqm8 <list> Set all 8x8 quant matrices
Takes a comma-separated list of 64 integers.
--cqm4i, --cqm4p, --cqm8i, --cqm8p
Set both luma and chroma quant matrices
--cqm4iy, --cqm4ic, --cqm4py, --cqm4pc
Set individual quant matrices

Video Usability Info (Annex E):
The VUI settings are not used by the encoder but are merely suggestions to
the playback equipment. See doc/vui.txt for details. Use at your own risk.

--overscan <string> Specify crop overscan setting ["???"]
- undef, show, crop
--videoformat <string> Specify video format ["component"]
- component, pal, ntsc, secam, mac, undef
--fullrange <string> Specify full range samples setting ["???"]
- off, on
--colorprim <string> Specify color primaries ["???"]
- undef, bt709, bt470m, bt470bg
smpte170m, smpte240m, film
--transfer <string> Specify transfer characteristics ["???"]
- undef, bt709, bt470m, bt470bg, linear,
log100, log316, smpte170m, smpte240m
--colormatrix <string> Specify color matrix setting ["???"]
- undef, bt709, fcc, bt470bg
smpte170m, smpte240m, GBR, YCgCo
--chromaloc <integer> Specify chroma sample location (0 to 5) [2089878056]

Input/Output:

-o, --output Specify output file
--muxer <string> Specify output container format ["auto"]
- auto, raw, mkv, flv, mp4
--demuxer <string> Specify input container format ["auto"]
- auto, yuv, y4m, avs, lavf, ffms
--index <string> Filename for input index file
--sar width:height Specify Sample Aspect Ratio
--fps <float|rational> Specify framerate
--seek <integer> First frame to encode
--frames <integer> Maximum number of frames to encode
--level <string> Specify level (as defined by Annex A)

-v, --verbose Print stats for each frame
--no-progress Don't show the progress indicator while encoding
--quiet Quiet Mode
--psnr Enable PSNR computation
--ssim Enable SSIM computation
--threads <integer> Force a specific number of threads
--sliced-threads Low-latency but lower-efficiency threading
--thread-input Run Avisynth in its own thread
--sync-lookahead <integer> Number of buffer frames for threaded lookahead
--non-deterministic Slightly improve quality of SMP, at the cost of repeatability
--asm <integer> Override CPU detection
--no-asm Disable all CPU optimizations
--visualize Show MB types overlayed on the encoded video
--dump-yuv <string> Save reconstructed frames
--sps-id <integer> Set SPS and PPS id numbers [8746976]
--aud Use access unit delimiters
--force-cfr Force constant framerate timestamp generation

[rack04]

@rack04
Here the result of the --fullhelp of your last build.
There is apparently some troubles...

Yeah I noticed that. :confused:

[komisar]

rack04, check #x264dev channel...

[rack04]

rack04, check #x264dev channel...

Toolchain:
cross-mingw.gcc443.core2.20100124
gpac-cvs-0.4.6-DEV.core2.01272010
coreutils-5.97-2-msys-1.0.11-ext
pkg-config_0.23-3
glib_2.22.3-1
yasm-r2291
msys-1.0.11
x86:

x264_x86_r1460M (http://www.multiupload.com/QJUAPWZD3F)

Patch:
x264_NAL-HRD.1.31.r1460 (http://komisar.gin.by/x.patch/last.used/x264_NAL-HRD.1.31.r1460.diff)
http://pastebin.com/GEGvfb89
http://pastebin.com/iv7W7mUH
http://pastebin.com/NdGLftsw
Build:
./configure --extra-cflags="-march=core2"
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=parkrun.1280x720.yuv
LAVF/FFMS:
ffmpeg r21997 and libswscale r30720 (http://www.multiupload.com/BIE13B7J2T)
ffms2 r292 (http://www.multiupload.com/2PVUU91O1F)

[Dark Shikari]

Fixed, dumb typo/error. Didn't affect encoding, just help display.

[shon3i]

@rack04, can you do x64 :) pls :D

[rack04]

@rack04, can you do x64 :) pls :D

Not until I have access to my home computer.

[Dark Shikari]

Sorry to make you keep rebuilding, but I just committed another fix for a stupid mistake that broke fast firstpass.

[shon3i]

Ok thanks, i will wait.

@Dark Shikari, what you think about adding nal-hrd as Experimental and call Experimental Blu-Ray support, i think more people will try and post feedback.

[Dark Shikari]

Crash with win64 caused by pengvado's patch fixed. Re-pull your trees.

[rack04]

Toolchain:
cross-mingw.gcc443.core2.20100124
gpac-cvs-0.4.6-DEV.core2.01272010
coreutils-5.97-2-msys-1.0.11-ext
pkg-config_0.23-3
glib_2.22.3-1
yasm-r2291
msys-1.0.11
x264_x86_r1463M (http://www.multiupload.com/7OQWL4SUCG)

Patch:
x264_NAL-HRD.1.31.r1460 (http://komisar.gin.by/x.patch/last.used/x264_NAL-HRD.1.31.r1460.diff)
Build:
./configure --extra-cflags="-march=core2"
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=parkrun.1280x720.yuv
LAVF/FFMS:
ffmpeg r21997 and libswscale r30720 (http://www.multiupload.com/BIE13B7J2T)
ffms2 r292 (http://www.multiupload.com/2PVUU91O1F)

[Dark Shikari]

Should probably note that we killed r1463 because of a bug that only occurred with some resolutions. The patch wasn't well tested enough, so it'll go into the next release.

The current latest version is r1462. r1463 will generate corrupt output for some resolutions, like CIF.

[rack04]

Toolchain:
cross-mingw.gcc443.core2.20100124
gpac-cvs-0.4.6-DEV.core2.01272010
coreutils-5.97-2-msys-1.0.11-ext
pkg-config_0.23-3
glib_2.22.3-1
yasm-r2291
msys-1.0.11
x264_x86_r1462M (http://www.multiupload.com/714WG8KAKK)

Patch:
x264_NAL-HRD.1.31.r1460 (http://komisar.gin.by/x.patch/last.used/x264_NAL-HRD.1.31.r1460.diff)
Build:
./configure --extra-cflags="-march=core2"
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=parkrun.1280x720.yuv
LAVF/FFMS:
ffmpeg r22008 and libswscale r30722 (http://www.multiupload.com/Y2W03LV66G)
ffms2 r292 (http://www.multiupload.com/UTBTQKSOS5)

[Fr4nz]

Rack, could you make also 64-bit builds? Thank you :D

[rack04]

Rack, could you make also 64-bit builds? Thank you :D

http://forum.doom9.org/showthread.php?p=1376972#post1376972

[outlaw.78]

x264 64bit (http://www.mediafire.com/?mixnjvhyinv)
x264 64bit NAL-HRD patch (http://www.mediafire.com/?m3wxzayyqez) (x264_NAL-HRD.1.31.r1460.diff) (http://komisar.gin.by/x.patch/last.used/x264_NAL-HRD.1.31.r1460.diff)

gcc 4.5.0 20100211 (experimental)
ffmpeg svn 22010
ffms2 svn 292
pthreads 2.9.0.0 shared
x264 0.88.1462 x86_64,amdfam10,fprofiled

[rack04]

Toolchain:
cross-mingw.gcc443.core2.20100124
gpac-cvs-0.4.6-DEV.core2.01272010
coreutils-5.97-2-msys-1.0.11-ext
pkg-config_0.23-3
glib_2.22.3-1
yasm-r2291
msys-1.0.11
x64:

x264_x64_r1462M (http://www.multiupload.com/W3D9IHR9WY)

Patch:
x264_NAL-HRD.1.31.r1460 (http://komisar.gin.by/x.patch/last.used/x264_NAL-HRD.1.31.r1460.diff)
Build:
./configure --extra-cflags="-march=core2" --host="x86_64-pc-mingw32" --cross-prefix="x86_64-pc-mingw32-"
Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: no
ffms input: no
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=pedestrian_1920x1080.yuv

[tormento]

@komisar

I am positively addicted to your builds. PLEASE release 1462/3 on your site ;)

[komisar]

tormento, in progress... ;) (also vfw builds updating...)

edit: CLI ready (kMod-build with .avi output support)

[UPD] Patch x264_avi_output.v2.diff (http://komisar.gin.by/x.patch/last.used/x264_avi_output.v2.diff) by BugMaster...

[Fr4nz]

Aaaah, great Komisarrrr... :D

[tormento]

tormento, in progress... ;)
Great! Already encoding with your new core2_x64 build!

P.S: Do you think is better to use avs4x264 or vfw4x264 to wrap 64bit to 32bit only encoder gui?

[aegisofrime]

komisar, I'm wondering if you could give a little help to outlaw78 applying the AQ4 patch? So that he could give a little goodness to us AMD users :)

hmmmm i am getting an error trying to apply this patch to latest source code, using git it says patch does not apply...

any help?

[komisar]

komisar, I'm wondering if you could give a little help to outlaw78 applying the AQ4 patch? So that he could give a little goodness to us AMD users :)
aq:4 == aq:2 in x264.rev1462
aq4 commit as aq2 in git

http://forum.doom9.org/showthread.php?p=1376873#post1376873

[outlaw.78]

aq:4 == aq:2 in x264.rev1462
aq4 commit as aq2 in git

http://forum.doom9.org/showthread.php?p=1376873#post1376873


nice :) less work for me :P

[RainyDog]

nice :) less work for me :P

Outlaw, will you be doing a 1471 AMD x64 build? Cheers.

[desta]

I don't know if it was just my settings, but I did an encode using 1462 and even though b-pyramid defaults to normal (2) in the fullhelp and changelog, the end result of the encode gave me b-pyramid 1 (according to avinaptic).

My encode settings were: --level 4.1 --preset veryslow --crf 18.5 --deblock -2:-1 --psy-rd 1.00:0.20 --qcomp 0.65 --aq-mode 2 --no-mbtree --intra-refresh

[kemuri-_9]

I don't know if it was just my settings, but I did an encode using 1462 and even though b-pyramid defaults to normal (2) in the fullhelp and changelog, the end result of the encode gave me b-pyramid 1 (according to avinaptic).

My encode settings were: --level 4.1 --preset veryslow --crf 18.5 --deblock -2:-1 --psy-rd 1.00:0.20 --qcomp 0.65 --aq-mode 2 --no-mbtree --intra-refresh

you seem to have conveniently ignored the warnings x264 issues here:

x264 [warning]: b-pyramid normal + intra-refresh is not supported
x264 [warning]: ref > 1 + intra-refresh is not supported

[desta]

you seem to have conveniently ignored the warnings x264 issues here:

x264 [warning]: b-pyramid normal + intra-refresh is not supported
x264 [warning]: ref > 1 + intra-refresh is not supported

Just checked the log and I conveniently didn't get any warnings. Thanks for the heads up though.

[outlaw.78]

x264 64bit (http://www.mediafire.com/?y12twafmqm4)

gcc 4.5.0 20100225 (experimental)
ffmpeg git 22094
ffms2 svn 298
pthreads 2.9.0.0 shared
x264 0.88.1471 x86_64,amdfam10,fprofiled

[captnes]

x264 64bit (http://www.mediafire.com/?y12twafmqm4)

gcc 4.5.0 20100225 (experimental)
ffmpeg svn 22094
ffms2 svn 298
pthreads 2.9.0.0 shared
x264 0.88.1471 x86_64,amdfam10,fprofiled

Ok, I'm at a loss. I haven't been able to extract a single one of your builds Outlaw. Tried both 7zip and WinRar and get an unsupported compression method on everyone you've posted.

[InsulinJunkie]

Ok, I'm at a loss. I haven't been able to extract a single one of your builds Outlaw. Tried both 7zip and WinRar and get an unsupported compression method on everyone you've posted.

WinRar pukes on them, but the 7zip 9.10 beta (64-bit version) seems to work.

[LoRd_MuldeR]

WinRar pukes on them, but the 7zip 9.10 beta (64-bit version) seems to work.

It seems he used LZMA2 compression, which is not widely supported yet. An up-to-date 7-Zip will handle it fine though!

(Overall LZMA2 compresses slightly worse than LZMA, but is more suitable for multi-threading ;) )

[XhmikosR]

Latest WinRAR handles LZMA2 7z archives just fine. IIRC v3.91 added support for this.

[captnes]

Thank you much gentlemen. The 7zip beta did the trick.

[outlaw.78]

It seems he used LZMA2 compression, which is not widely supported yet. An up-to-date 7-Zip will handle it fine though!

(Overall LZMA2 compresses slightly worse than LZMA, but is more suitable for multi-threading ;) )

y was using lzma2 cause it handles 4 threads fine...
ofc for this tiny archive there is no reason but its just left there on default.. i will try to to use normal lzma next time i post guys....

[RainyDog]

y was using lzma2 cause it handles 4 threads fine...
ofc for this tiny archive there is no reason but its just left there on default.. i will try to to use normal lzma next time i post guys....

Thanks, I had the winrar problem too so was having to use 7-zip. Cheers yet again for the latest build, too :)

[captnes]

Indeed, now that I've actually been able to test it I've been very pleased with the results. Thanks Outlaw.

[outlaw.78]

Indeed, now that I've actually been able to test it I've been very pleased with the results. Thanks Outlaw.

thanks guys :)

i would love to see some comparison results on AMD vs Intel
builds, if someone have the time to do it...

[aegisofrime]

thanks guys :)

i would love to see some comparison results on AMD vs Intel
builds, if someone have the time to do it...

I will do it. Although if something would to advise me on recommended testing methodologies to isolate the variables down to only AMD builds vs Generic/Intel builds, that will be helpful...

[captnes]

thanks guys :)

i would love to see some comparison results on AMD vs Intel
builds, if someone have the time to do it...

Real rough from memory last night I was getting about 2fps faster on an 8 minute 640x480 avs animation @ crf 18, everything else default with my X2 5600 Win7. I think it was about 13fps x32, 16fps x64 and 18fps AMD.

[Maccara]

I will do it. Although if something would to advise me on recommended testing methodologies to isolate the variables down to only AMD builds vs Generic/Intel builds, that will be helpful...

I'll be a bit surprised if you can get statistically significant differences.

Proper methodology would be to test various sources with various parameters to get results that would apply generally. That is still not counting, that you would need to test on multiple difference machines to get results that would apply for "everyone", but at least it would tell if there's any significant difference on at least some platform.

Maybe then analyzing the results with some mixed effects model (treating sources+params as random effects) would reveal the source of variability. Haven't used R much, but have been recommended lme4 package for mixed effects modeling. Standard anova probably would be masked/aliased by the difference between params/sources making it impossible to detect difference between exes only.

That was just from the top of my head to give some possible ideas. You need to also determine how many tests you need to have an adequate power for null hypothesis testing.

Edit: That being said, I've still compiled my own versions with -march=k8-sse3 "just to get the warm fuzzy feeling", even though I realize it probably doesn't make any significant difference. :) Will be nice if someone indeed will have the will and time to do proper testing.

[rack04]

Toolchain:
cross-mingw.gcc443.core2.20100124
gpac-cvs-0.4.6-DEV.core2.01272010
coreutils-5.97-2-msys-1.0.11-ext
pkg-config_0.23-3
glib_2.22.3-1
yasm-0.8.0
msys-1.0.11
x264_x86_r1471M (http://www.multiupload.com/S8MOYPYITT)

Patch:
x264_NAL-HRD.1.31.r1460_next.diff (http://komisar.gin.by/x.patch/last.used/x264_NAL-HRD.1.31.r1460_next.diff)
Build:
./configure --extra-cflags="-march=core2"
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=parkrun.1280x720.yuv
LAVF/FFMS:
ffmpeg svn22127 and libswscale svn30800 (http://www.multiupload.com/998KMKC8SW)
ffms2 svn300 (http://www.multiupload.com/O8HRE25RN8)

[bob0r]

rack04, everyone:
Maybe you guys should mention you use SVN or GIT for ffmpeg. The revision numbers aren't the same for SVN or GIT.
x264.nl uses GIT for example, notice the completely different numbers! :devil:

[rack04]

Toolchain:
cross mingw gcc 4.4.3
gpac 0.4.6 DEV 01272010
pthreads GC static 20091019-1
yasm 0.8.0
x86:

x264_x86_r1471M (http://www.multiupload.com/MZUE0ROXTS)

FFmpeg Patch:
ffmpeg_static_pthreads (http://pastebin.ca/1822141)
x264 Patch:
x264_NAL-HRD.1.32 (http://pastebin.ca/1819862)
Build:
./configure --extra-cflags=-march=core2
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=pedestrian_1920x1080.yuv
x64:

x264_x64_r1471M (http://www.multiupload.com/NKJIANJOQA)

FFmpeg Patch:
ffmpeg_static_pthreads (http://pastebin.ca/1822141)
sws_x64_fix (http://pastebin.ca/1822143)
x264 Patch:
x264_NAL-HRD.1.32 (http://pastebin.ca/1819862)
Build:
./configure --extra-cflags=-march=core2 --host=x86_64-pc-mingw32 --cross-prefix=x86_64-pc-mingw32-
Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=pedestrian_1920x1080.yuv
LAVF/FFMS:
ffmpeg svn22191 and libswscale svn30826 (http://www.multiupload.com/BR1Q4YS8S2)
ffms2 svn300 (http://www.multiupload.com/4I4Z1Z5C8O)

[outlaw.78]

x264 32bit & 64bit (http://www.mediafire.com/?wnaolhmotz5)

gcc 4.5.0 20100225 (experimental)
ffmpeg svn 22413
swscale svn 30879
ffms2 svn 305
pthreads 2.9.0.0 shared
x264 0.88.1471 amdfam10,fprofiled

[outlaw.78]

if u guys with 32bit windows have any problems with pthreads dll say so, i cant test the 32bit version.....

[Snowknight26]

Why's that?

[mara-]

Can anybody explain me what parameter --nal-hrd does? I can't find anywhere on the forum this explanation. I noticed that encoding is much slower with this parameter but, what it does? Thanks

Cheers ;)

[txporter]

Can anybody explain me what parameter --nal-hrd does? I can't find anywhere on the forum this explanation. I noticed that encoding is much slower with this parameter but, what it does? Thanks

Cheers ;)

It is for Blu-Ray compliance. See this thread (http://forum.doom9.org/showthread.php?t=152127).

[mara-]

OK, thanks. I sow the thread, but there is not explanation what for is the patch.

Cheers ;)

[rack04]

OK, thanks. I sow the thread, but there is not explanation what for is the patch.

Cheers ;)

Add NAL HRD parameters to the output stream; used for HD-DVD and Blu-ray compliancy. Depends on vbv-bufsize and vbv-maxrate to be set to be active.

[mara-]

Got it, thanks.

Cheers ;)

[rack04]

Toolchain:
cross-mingw.gcc443.core2.20100124
gpac-cvs-0.4.6-DEV.gc-static.core2.01272010
pthreads-2.9.0.0.gc-static.core2.20091019
glib_2.22.4-1
pkg-config_0.23-2
yasm-0.8.0
MSYS-1.0.11
msysDTK-1.0.1
msysCORE-1.0.14-1
bash-3.1.17-2
coreutils-5.97-2
m4-1.4.13-1
autoconf2.5-2.64-1
automake-1.11-1
libtool-2.2.7a-1
Builds:

x264_x64_r1510 (http://www.multiupload.com/DFDJPGR664)

./configure --prefix=/c/x264/x86_64-pc-mingw32 --extra-cflags=-march=core2 --host=x86_64-pc-mingw32 --cross-prefix=x86_64-pc-mingw32-

Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=/f/x264/pedestrian_1920x1080.yuv

x264_x86_r1510 (http://www.multiupload.com/XAVPR0Z0XX)

./configure --prefix=/c/x264/i686-pc-mingw32 --extra-cflags=-march=core2

Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=/f/x264/pedestrian_1920x1080.yuv

LAVF/FFMS:
ffmpeg svn22710 and libswscale svn30972 (http://www.multiupload.com/HNMHSTZR72)
ffms2 svn309 (http://www.multiupload.com/HHMUCYC23K)

[burfadel]

32 bit x264 r1510 anyone? x264.nl doesn't seem to be updating?... (its been a few hours)

[MatLz]

Here:
http://x264.fushizen.eu/

[burfadel]

Thanks for the link :)

[outlaw.78]

x264 x86 & x64 (http://www.mediafire.com/?nlliuzztzlt)

gcc 4.5.0 20100319 (experimental)
ffmpeg git 22712
ffms2 svn 309
pthreads 2.9.0.0 shared
x264 0.92.1510 x86,x64,amdfam10,fprofiled

[dev84]

Hi

Encoding with x264 r1510 from x264.nl in StaxRip i get:

------------------------------------------------------------
Error
------------------------------------------------------------

x264 failed with exit code -1

avs [info]: 1280x528p 0:0 @ 10000000/417083 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT
x264 [info]: profile High, level 4.0
x264 [error]: x264_encoder_encode failed
avs [info]: 1280x528p 0:0 @ 10000000/417083 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT
x264 [info]: profile High, level 4.0
avs [info]: 1280x528p 0:0 @ 10000000/417083 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT
x264 [info]: profile High, level 4.0
x264 [error]: x264_encoder_encode failed


thx

[alexins]

Hi

Encoding with x264 r1510 from x264.nl in StaxRip i get:

thx

Processor AMD?
If so, look at my site, there is a builds for Phenom X3/X4, Phenom II, Athlon II, Athlon X2 7x50.

[olapanekala]

techouse we miss your excellent builds....

[dev84]

Processor AMD?
If so, look at my site, there is a builds for Phenom X3/X4, Phenom II, Athlon II, Athlon X2 7x50.

Same thing, 1510 from http://x264.fushizen.eu/ says "looks like we run out of mem" but on all three encoders; x264.nl, x264.fushizen.eu, xvidvideo.ru - build for PhenomII encoding stops almost in the same place except there is free memory, than why?

Settings:

--preset placebo --tune film --crf 20 --ref 8 --rc-lookahead 250 --merange 64

Screenshot shows error message and memory usage at crash.

http://img52.imageshack.us/img52/6199/x264.jpg

[tph]

Same thing, 1510 from http://x264.fushizen.eu/ says "looks like we run out of mem" but on all three encoders; x264.nl, x264.fushizen.eu, xvidvideo.ru - build for PhenomII encoding stops almost in the same place except there is free memory, than why?
32-bit processes can only allocate 2 GiB of memory which is not enough for high resolution encoding with really slow settings. Use a 64-bit version of x264.

[Warpman]

Same thing, 1510 from http://x264.fushizen.eu/ says "looks like we run out of mem" but on all three encoders; x264.nl, x264.fushizen.eu, xvidvideo.ru - build for PhenomII encoding stops almost in the same place except there is free memory, than why?

Settings:



Screenshot shows error message and memory usage at crash.


Lookahead 250 is insane! Of cause you will, as tph stated, exhaust the 2Gb limit per process.

Even placebo preset uses only 60 frames!
Don't touch any options if you don't know what are you doing... :/

[dev84]

I wosn`t aware there is 2GB limit per process in 32 bit M@OS, thx for help i sattle for 8 bframes not to exceed 2GB limit.
Lookahead 250 maby it is insane but if it is possible and one does have time; why not!

Thx again

[lexor]

Lookahead 250 maby it is insane but if it is possible and one does have time; why not!

Thx again

If one does have time, use 2-pass.

[Rumbah]

The 250 frames lookahead makes x264 exceed the 2 GB in your encode, not the number of b-frames.

[Dark Shikari]

The 250 frames lookahead makes x264 exceed the 2 GB in your encode, not the number of b-frames.It's a combination of the two, actually.

[dev84]

It's a combination of the two, actually.

Indeed, 8 bframes with lookahead 250 does not exceed 2GB

[Snowknight26]

You can't make a judgment as to whether it does or doesn't without additional information (such as resolution).

[dev84]

You can't make a judgment as to whether it does or doesn't without additional information (such as resolution).

Everything is in order, i stated the problem giving res + encoder cfg, problem was resolved, it works, there is no need for debate what is wise thing to do or not to do.

Thx.

[jpsdr]

Among the most common builds (that i know) : rack04, Jeeb or x264.nl.
Is there great differences ? Is one of them more efficient on XP64 (i7@965) ?
Or are they globaly the same ?

[JEEB]

Among the most common builds (that i know) : rack04, Jeeb or x264.nl.
Is there great differences ? Is one of them more efficient on XP64 (i7@965) ?
Or are they globaly the same ?

x264.nl is currently using my builds (if we're talking about 64bit, automatizing 32bit is rather easy and jarod has been doing that by himself all the time IIRC). If there is any difference between rack's and mine, it'd probably end up being rather small :) (I would guess GCC's march settings + other optimizations, and/or intel's C compiler might give some speedup, but personally I've been just fine with standard GCC builds -- esp. because with GCC you never know when it might actually do the opposite from what you'd think).

My builds are nowadays generally without -march settings, with just standard configure (those builds that went onto x264.nl were always without -march=core2).

[CpT]

I've been using your build Jeeb with no issues on windows 7 64bit and the new I7980x @ 4.1ghz ;)

I would love to test out an x264 intel C build though using the latest x264 and this new cpu. They were faster for me, but only slightly.

[rack04]

Toolchain:
cross-mingw.gcc443.core2.20100124
gpac-cvs-0.4.6-DEV.rev5
pthreads-2.9.0.0.gc-static.core2.20091019
glib_2.24.0-1
pkg-config_0.23-3
yasm-r2310
MSYS-1.0.11
bash-3.1.17-2
coreutils-5.97-2
m4-1.4.13-1
autoconf2.5-2.64-1
automake-1.11-1
libtool-2.2.7a-1
LAVF/FFMS Builds:

ffmpeg svn22811 and libswscale svn31026 (http://www.multiupload.com/SDSTJEBHAT)
ffms2 svn309 (http://www.multiupload.com/FDNQ3NGGUV)
FFmpeg Patches:
ffmpeg_static_pthreads_v2 (http://pastebin.com/NTPxc4c5)
sws_x64_fix_v2 (http://pastebin.com/aUHckFQF)
x264 Builds:

x264_x86_r1523 (http://www.multiupload.com/NH7PEFHACQ)

./configure --prefix=/c/x264/i686-pc-mingw32 --extra-cflags=-march=core2

Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=/c/x264/pedestrian_1920x1080.yuv
x264_x64_r1523 (http://www.multiupload.com/WYEG2M1SJY)

./configure --prefix=/c/x264/x86_64-pc-mingw32 --extra-cflags=-march=core2 --host=x86_64-pc-mingw32 --cross-prefix=x86_64-pc-mingw32-

Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=/c/x264/pedestrian_1920x1080.yuv

[outlaw.78]

x264 0.92.1523 x64 & x86 (http://www.mediafire.com/?ntimk4widoo)

gcc 4.5.0 20100406 (pre-release)
ffmpeg svn 22815
ffms2 svn 309
pthreads 2.9.0.0 static (thanks to rack04 for providing the patches)
x264 0.92.1523 x86,x64,amdfam10,fprofiled

[burfadel]

x264 0.92.1523 x64 & x86 (http://www.mediafire.com/?ntimk4widoo)

gcc 4.5.0 20100406 (pre-release)
ffmpeg svn 22815
ffms2 svn 309
pthreads 2.9.0.0 static (thanks to rack04 for providing the patches)
x264 0.92.1523 x86,x64,amdfam10,fprofiled

With the x86 version, the quality of the output is really quite bad - its extremely noticeable, and the filesize is much smaller than it should be. I only tried CRF mode, since this is the one I typically use. I traced the issue back to mb-tree, with mb-tree on (default) the output is bunged, with mb-tree off its fine! Your previous r1310 build also had the same issue. Other builds work fine with mb-tree on, so I'm not sure what part of your compile chain breaks mb-tree.

This is on an Intel Q9400.

[burfadel]

In regards to build r1323 (the working builds) I've noticed a slight increase in speed, PSNR and SSIM (did a test with r1310 and r1323 out of interest).

[outlaw.78]

With the x86 version, the quality of the output is really quite bad - its extremely noticeable, and the filesize is much smaller than it should be. I only tried CRF mode, since this is the one I typically use. I traced the issue back to mb-tree, with mb-tree on (default) the output is bunged, with mb-tree off its fine! Your previous r1310 build also had the same issue. Other builds work fine with mb-tree on, so I'm not sure what part of your compile chain breaks mb-tree.

This is on an Intel Q9400.

i compile for amd only, so you should not run it on intel cpus, use rack04 builds instead....

[burfadel]

Ah ok :) at least it does show that there is a difference between compiling for AMD or Intel!

[LoRd_MuldeR]

Ah ok :) at least it does show that there is a difference between compiling for AMD or Intel!

But that doesn't explain why you got different output! As long as VBV isn't involved and as long as "--non-deterministic" isn't specified, all builds should give identical output for identical input/settings. If the build was compiled for a different type of CPU than yours, then two things happen: First of all, CPU instructions may be used in the compiled C code that aren't supported by your CPU. I don't think this applies here, but even if it did, you would simply encounter a crash ("illegal instruction"), but not borked output. The second thing is that the "cycles per instruction" that the compiler assumed for the target CPU don't match your CPU, which will result in code that won't run optimally (i.e. not at the full speed that it could run at) on your CPU, but the code still will (or at least should) run correctly! Therefore I rather suspect a miscompilation by GCC, than a CPU-type related issue. Consequently I'd suggest to outlaw.78 to check the output from his build against a reference build...

[laserfan]

My builds...Wondering JEEB why r1523 build of yours is suddenly 8,500KB where before was 1,200KB???

[LoRd_MuldeR]

Wondering JEEB why r1523 build of yours is suddenly 8,500KB where before was 1,200KB???

FFM2 + libavcodec + libavformat !?

[burfadel]

I tried lots of different settings, and in each case I got borked output in CRF mode with mb-tree on. I just tried the amdfam10 build of x264 r1323 from xvidvideo.ru and that has the exact same problem as outlaw.78's build, borked output with mb-tree on, whereas with the core2 build from xvidvideo.ru it works fine.

Edit:
On a short clip, here's the output from x264. I enabled PSNR and SSIM just for the comparison.

All builds except for those compiled for amdfam10 by Outlaw.78 and xvidvideo.ru:
x264 [info]: frame I:6 Avg QP:22.07 size: 23195 PSNR Mean Y:44.37 U:49.50 V:49.18 Avg:45.49 Global:45.38
x264 [info]: frame P:318 Avg QP:24.05 size: 6223 PSNR Mean Y:40.30 U:47.38 V:47.10 Avg:41.64 Global:41.53
x264 [info]: frame B:977 Avg QP:29.84 size: 1198 PSNR Mean Y:39.96 U:47.12 V:46.85 Avg:41.31 Global:41.17
x264 [info]: consecutive B-frames: 0.3% 2.2% 35.2% 11.4% 2.7% 48.2% 0.0% 0.0%
x264 [info]: mb I I16..4: 1.7% 85.1% 13.2%
x264 [info]: mb P I16..4: 0.4% 8.3% 1.1% P16..4: 48.0% 23.9% 8.6% 0.6% 0.8% skip: 8.4%
x264 [info]: mb B I16..4: 0.0% 0.4% 0.0% B16..8: 37.6% 5.6% 1.3% direct: 2.2% skip:52.9% L0:29.6% L1:54.0% BI:16.4%
x264 [info]: 8x8 transform intra:85.4% inter:60.2%
x264 [info]: direct mvs spatial:99.6% temporal:0.4%
x264 [info]: coded y,uvDC,uvAC intra: 88.2% 83.8% 50.1% inter: 13.9% 15.0% 2.4%
x264 [info]: i16 v,h,dc,p: 31% 17% 4% 48%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 25% 17% 8% 5% 7% 9% 8% 11% 11%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 21% 14% 4% 7% 11% 13% 11% 10% 10%
x264 [info]: Weighted P-Frames: Y:0.0%
x264 [info]: ref P L0: 56.4% 17.9% 18.5% 2.8% 3.1% 1.4%
x264 [info]: ref B L0: 92.1% 6.6% 0.9% 0.3%
x264 [info]: ref B L1: 96.9% 3.1%
x264 [info]: SSIM Mean Y:0.9812923
x264 [info]: PSNR Mean Y:40.066 U:47.194 V:46.920 Avg:41.408 Global:41.271 kb/s:606.06
encoded 1301 frames, 27.85 fps, 606.06 kb/s

Results for the amdfam10 builds by Outlaw.78 and xvidvideo.ru. Same settings as Intel builds:
x264 [info]: frame I:6 Avg QP:31.86 size: 9254 PSNR Mean Y:36.56 U:43.90 V:43.33 Avg:37.91 Global:37.46
x264 [info]: frame P:318 Avg QP:33.68 size: 2079 PSNR Mean Y:34.78 U:42.73 V:42.01 Avg:36.17 Global:36.00
x264 [info]: frame B:977 Avg QP:30.32 size: 2005 PSNR Mean Y:36.80 U:43.81 V:43.16 Avg:38.11 Global:37.98
x264 [info]: consecutive B-frames: 0.3% 2.2% 35.2% 11.4% 2.7% 48.2% 0.0% 0.0%
x264 [info]: mb I I16..4: 5.7% 87.0% 7.3%
x264 [info]: mb P I16..4: 0.7% 5.4% 0.3% P16..4: 40.5% 9.3% 3.9% 0.0% 0.0% skip:39.9%
x264 [info]: mb B I16..4: 0.1% 0.4% 0.0% B16..8: 43.1% 9.1% 1.5% direct: 5.6% skip:40.2% L0:41.1% L1:49.1% BI: 9.7%
x264 [info]: 8x8 transform intra:84.3% inter:79.7%
x264 [info]: direct mvs spatial:99.3% temporal:0.7%
x264 [info]: coded y,uvDC,uvAC intra: 69.5% 62.8% 22.2% inter: 15.5% 15.4% 0.6%
x264 [info]: i16 v,h,dc,p: 37% 24% 5% 34%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 21% 12% 6% 7% 8% 12% 10% 12% 12%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 12% 5% 6% 10% 12% 11% 10% 10%
x264 [info]: Weighted P-Frames: Y:0.0%
x264 [info]: ref P L0: 39.5% 40.4% 13.9% 2.2% 3.1% 1.0%
x264 [info]: ref B L0: 64.3% 31.4% 3.0% 1.3%
x264 [info]: ref B L1: 97.6% 2.4%
x264 [info]: SSIM Mean Y:0.9602218
x264 [info]: PSNR Mean Y:36.305 U:43.546 V:42.882 Avg:37.639 Global:37.405 kb/s:493.15
encoded 1301 frames, 37.53 fps, 493.15 kb/s

The PSNR and SSIM are lower, but by no means show how bad the output actually is.

Edit 2: Resolution used was 512,384 for the comparison.

[LoRd_MuldeR]

I tried lots of different settings, and in each case I got borked output in CRF mode with mb-tree on. I just tried the amdfam10 build of x264 r1323 from xvidvideo.ru and that has the exact same problem as outlaw.78's build, borked output with mb-tree on, whereas with the core2 build from xvidvideo.ru it works fine.

Still, this most likely indicates a bug in GCC 4.5.0 with respect to "-march=amdfam10", instead of an incompatibility between "AMD-optimized" builds any your Intel CPU.

Using "optimizations" that break compatibility to certain CPU types, although these CPU types support all the required instruction sets, is something that I'd expect from ICC only :D

[burfadel]

I'm suspecting a GCC error too, I wonder if on AMD systems the same output problem occurs?

[Midzuki]

Wondering JEEB why r1523 build of yours is suddenly 8,500KB where before was 1,200KB???

BTW, Komisar's x264 Mod == 6.12MB,
whereas "the most official" :) x264 build == 6.08MB.
And of course, Komisar's x264 includes AVI output :D

Anyway: it seems ppl have forgotten what 7-zip exists for. :devil:

[LoRd_MuldeR]

I'm suspecting a GCC error too, I wonder if on AMD systems the same output problem occurs?

I would assume so! Will check this on my AMD machine when I return home...

[rack04]

Toolchain:
cross-mingw.gcc443.core2.20100124
gpac-cvs-0.4.6-DEV.rev5
pthreads-2.9.0.0.gc-static.core2.20091019
glib_2.24.0-1
pkg-config_0.23-3
yasm-r2310
MSYS-1.0.11
bash-3.1.17-2
coreutils-5.97-2
m4-1.4.13-1
autoconf2.5-2.64-1
automake-1.11-1
libtool-2.2.7a-1
LAVF/FFMS Builds:

ffmpeg SVN-r22822M and libswscale SVN-r31027M (http://www.multiupload.com/5TDLNKAQZJ)
ffms2 SVN-r309M (http://www.multiupload.com/NQCK47BH7S)
LAVF/FFMS Patches:
ffmpeg_static_pthreads_v2 (http://pastebin.com/NTPxc4c5) <angustia>
libswscale_x64_fix_v2 (http://pastebin.com/aUHckFQF) <BugMaster>
ffms2_threads_fix (http://pastebin.com/WZP1YCcW) <komisar>
x264 Builds:

x264_x64_r1523M (http://www.multiupload.com/V2AOQC8POF)

./configure --prefix=/c/x264/x86_64-pc-mingw32 --extra-cflags=-march=core2 --host=x86_64-pc-mingw32 --cross-prefix=x86_64-pc-mingw32-

Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
avi output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=/f/x264/pedestrian_1920x1080.yuv
x264_x86_r1523M (http://www.multiupload.com/XB1ENWPV00)

./configure --prefix=/c/x264/i686-pc-mingw32 --extra-cflags=-march=core2

Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
avi output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=/f/x264/pedestrian_1920x1080.yuv
x264 Patches:
x264_sws_typecast (http://pastebin.com/kVYc1BYn) <komisar>
x264_demuxer_threads (http://pastebin.com/XUFQYemT) <komisar>
x264_thread_pool_v2.7 (http://pastebin.com/yCd3bXCP) <BugMaster>
x264_fix_float_point_exception (http://pastebin.com/mG4gi0hW) <BugMaster>
x264_avi_output.v3 (http://pastebin.com/e54DR1vb) <BugMaster>

[MasterNobody]

**removed until I can figure out why avi output format wasn't working**
For correct compiling with AVI-output you need to configure ffmpeg with such additional options:--enable-muxer=avi --enable-protocol=fileor simply take komisar's libpack from this page (http://komisar.gin.by/mingw/index.html)

[LoRd_MuldeR]

I tried lots of different settings, and in each case I got borked output in CRF mode with mb-tree on. I just tried the amdfam10 build of x264 r1323 from xvidvideo.ru and that has the exact same problem as outlaw.78's build, borked output with mb-tree on, whereas with the core2 build from xvidvideo.ru it works fine.

Some testes from my Intel Core2 Q6600 machine:
File Size RIPEMD-160
parkrun.1280x720.crf20.gcc345.generic.avi 41.164.020 B54683EEFF99DF9032951E69A20372B9769F9860
parkrun.1280x720.crf20.gcc450.generic.avi 41.164.020 B54683EEFF99DF9032951E69A20372B9769F9860
parkrun.1280x720.crf20.gcc450.core2.avi 41.164.020 B54683EEFF99DF9032951E69A20372B9769F9860
parkrun.1280x720.crf20.gcc450.pentium3.avi 41.164.020 B54683EEFF99DF9032951E69A20372B9769F9860
parkrun.1280x720.crf20.gcc450.amdfam10.avi 53.389.452 E6BDE3785594AD489583F88D88F3307581B7AA9D
parkrun.1280x720.crf20.gcc443.generic.avi 41.164.020 B54683EEFF99DF9032951E69A20372B9769F9860
parkrun.1280x720.crf20.gcc443.amdfam10.avi 53.389.452 E6BDE3785594AD489583F88D88F3307581B7AA9D

x264 version:
version: 0.92.1523M 25ca5b0

Settings that were used:
options: 1280x720 fps=50/1 timebase=1/50 cabac=1 ref=8 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=16 b_pyramid=2 b_adapt=2 b_bias=0 direct=3 wpredb=1 wpredp=2 keyint=750 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=60 rc=crf mbtree=1 crf=20.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.40 aq=1:1.00

[Dark Shikari]

If the amdfam version used an instruction incompatible with Intel chips, it would crash, not give incorrect output.

It's likely, given gcc's track record, that the build is just broken.

[burfadel]

Interestingly enough, for me it went in the other direction, around 25 percent smaller output file not 25 percent larger! Anyways, looks as though the last few GCC builds (as it happens with 1310 as well) is broken, I think earlier GCC 4.5.0 builds worked, but how far back that was I have no idea!

Is there any reason why it would only occur with mb-tree on? if there is an instruction used there and not elsewhere? at least a bug report can be submitted to the GCC development team if the cause is known :)

[LoRd_MuldeR]

Is there any reason why it would only occur with mb-tree on? if there is an instruction used there and not elsewhere? at least a bug report can be submitted to the GCC development team if the cause is known :)

Obviously GCC either miscompiled the MB-Tree code itself or it miscompiled something else that becomes apparent with MB-Tree enabled.

Also: Even if the miscompilation can be tracked down to MB-Tree, it doesn't mean you will be fine with MB-Tree disabled. Other more subtle things may be miscompiled too.

(Looking at the output from the amdfam10-optimized build I see some kind of "flickering" that isn't there in the output from the other builds)

[outlaw.78]

hmmmmm, i will try to compile using gcc 4.4.3 from komisar and post as soon as i am done

[LoRd_MuldeR]

hmmmmm, i will try to compile using gcc 4.4.3 from komisar and post as soon as i am done

Exactly same result with GCC 4.4.3 (Komisar's build). Please see this (http://forum.doom9.org/showpost.php?p=1389891&postcount=3102) post.

[outlaw.78]

Exactly same result with GCC 4.4.3 (Komisar's build). Please see this (http://forum.doom9.org/showpost.php?p=1389891&postcount=3102) post.

i see...
i wonder if that has something to do with -ffast-math switch

[burfadel]

Some testes from my Intel Core2 Q6600 machine:

Tests with that extra 'e' means something completely different :)

It would be good to get to the bottom of the issue, it would be bad for someone trying x264 for the first time using a miscompiled build...

[MasterNobody]

It seems this is not the miscompilation. This builds probably correctly work only on AMD K10 CPU (which support SSE4A / AMD SSE4). Because gcc generates LZCNT instruction which seems to be incorrectly interpretated as BSR without crash on CPUs without support of SSE4A.

[LoRd_MuldeR]

It seems this is not the miscompilation. This builds probably correctly work only on AMD K10 CPU (which support SSE4A / AMD SSE4). Because gcc generates LZCNT instruction which seems to be incorrectly interpretated as BSR without crash on CPUs without support of SSE4A.

http://www.cosgan.de/images/smilie/konfus/g070.gif

[Dark Shikari]

A miscompilation check for this case has been added to x264. The next release will error out loudly if an amdfam10 build is run on any non-Phenom CPU.

[LoRd_MuldeR]

A miscompilation check for this case has been added to x264. The next release will error out loudly if an amdfam10 build is run on any non-Phenom CPU.

:thanks:

EDIT: Even on an older AMD machine (Athlon64) the "amdfam10" build produced different output than the generic build.

[Dark Shikari]

:thanks:

EDIT: Even on an older AMD machine (Athlon64) the "amdfam10" build produced different output than the generic build.Obviously, it will do so on any machine that doesn't have SSE4a.

[LoRd_MuldeR]

Obviously, it will do so on any machine that doesn't have SSE4a.

Help me understand this: AMD re-used opcodes in SSE4a that they already had used for something else on their own processors before? How braindead is this? :eek:

Anyway, if you add the aforementioned miscompilation the check for "amdfam10" and "non-Phenom", will there be a way to disabled/skip this check in the "fprofiling" phase?

Otherwise I wouldn't be able to fprofile "amdfam10" builds anymore :o

[J_Darnley]

So AMD re-used opcodes in SSE4a that they already had used for something else on their own processors before? How braindead is this? :eek:

Anyway, if you add the aforementioned miscompilation the check for "amdfam10" and "non-Phenom", will there be a way to disabled/skip this check in the "fprofiling" phase?

Otherwise I wouldn't be able to fprofile "amdfam10" builds anymore :o

The result is not wrong when you have this instruction. See: http://pastebin.org/142635
[EDIT] Oh, do you mean you want to run one of these on an problematic cpu?

[LoRd_MuldeR]

Oh, do you mean you want to run one of these on an problematic cpu?

I don't want to use an "amdfam10" optimized build on my Intel CPU and it's good that x264 normally won't let me do that. But: I still want to be able to fprofile those builds on my CPU. But if it always aborts, I cannot run fprofile for "amdfam10" on Non-Phenom CPU's. And I don't have a Phenom available. Getting "borked" output from fprofiling shouldn't be a big deal, as we discard that output anyway...

[kemuri-_9]

I don't want to use an "amdfam10" optimized build on my Intel CPU and it's good that x264 normally won't let me do that. But: I still want to be able to fprofile those builds on my CPU. But if it always aborts, I cannot run fprofile for "amdfam10" on Non-Phenom CPU's. And I don't have a Phenom available. Getting "borked" output from fprofiling shouldn't be a big deal, as we discard that output anyway...

let those of us with phenom pcs worry about getting our fprofiled -march=amdfam10 builds, ok?
I think it's better that x264 prevents the situation with an error to prevent those who don't know better than to allow those who do know better to be able to fprofile it.
there are more who don't know better than those who do.

[LoRd_MuldeR]

Sure. I was more thinking about something like a "#ifdef FPROFILE_GENERATE ... #endif" around the miscompilation check(s) ;)

[aegisofrime]

So... the conclusion is the amdfam10 builds are fine to use, but only if you have a K10 CPU?

[LoRd_MuldeR]

So... the conclusion is the amdfam10 builds are fine to use, but only if you have a K10 CPU?

Right. And once this (http://pastebin.org/142635) patch is committed, they will simply error out on unsupported CPU's.

[alexins]

So... the conclusion is the amdfam10 builds are fine to use, but only if you have a K10 CPU?

Yes, only for: Athlon X2, Athlon II, Phenom, Phenom II, Phenom X3, Phenom X4.

[burfadel]

That patch is a great way of doing it, as it is instruction specific and not processor specific, meaning new processors that support those instructions will still work and not error out if the current specific supporting processors aren't detected :)

[MasterNobody]

Help me understand this: AMD re-used opcodes in SSE4a that they already had used for something else on their own processors before? How braindead is this? :eek:
Not fully correct. They re-used combination of REP:BSR (which with 99.99% probabiltiy wouldn't be used by any compiler for generating of BSR instruction) for new instruction LZCNT. But because REP prefix is safe to use with most instructions (and it would be simply ignored in combinations which doesn't make sense) it doesn't crash even on CPUs which doesn't support it.

[Dark Shikari]

I don't want to use an "amdfam10" optimized build on my Intel CPU and it's good that x264 normally won't let me do that. But: I still want to be able to fprofile those builds on my CPU. But if it always aborts, I cannot run fprofile for "amdfam10" on Non-Phenom CPU's. And I don't have a Phenom available. Getting "borked" output from fprofiling shouldn't be a big deal, as we discard that output anyway...This is stupid. If the output of x264 is "borked", surely the results of an fprofile cannot be reliable anyways.

[deank]

For those like me - not going after speed and stuff - is it really hard to build a release without all these fprofiled requirements like AMD or Intel compatibility. I guess I'm missing something, but I have a Celeron, and AMD and a CoreDue PCs... Does it mean that I need to use 2 or 3 different builds just to be sure that x264 works with all 3 PCs??

[Dark Shikari]

For those like me - not going after speed and stuff - is it really hard to build a release without all these fprofiled requirements like AMD or Intel compatibility.It's completely unnecessary and gives practically no speed benefit. It just makes people feel better.

[outlaw.78]

It's completely unnecessary and gives practically no speed benefit. It just makes people feel better.

agree.
on my phenom x4 running my builds vs generic builds is at most 1-2 % gain and sometimes even 0% ....
its just for fun!

[outlaw.78]

x264 0.93.1538 x64 & x86 (http://www.mediafire.com/?4zd20wmzjom)


gcc 4.5.0 20100406 (pre-release)
ffmpeg svn 22838
swscale svn 31029
ffms2 svn 309
pthreads 2.9.0.0 static (thanks to rack04 for providing the patches)
x264 0.93.1538 x86,x64,amdfam10,fprofiled

[jpsdr]

I personnaly notice a speed difference between the rack04 build, and the test build DS give for validating the update of nal-hrd (around 1.15fps vs around 1.3fps).

[Dark Shikari]

I personnaly notice a speed difference between the rack04 build, and the test build DS give for validating the update of nal-hrd (around 1.15fps vs around 1.3fps).That's hardly surprising. My build was using an ancient gcc (3.4).

[jpsdr]

At least, on my i7@965, i've noticed that fact. Maybe the profile/options/intel optimisations rack04 use on his build is more noticeable on my CPU...
Well, i'm not complaining... ^_^

[burfadel]

I think the argument of noticeable speed gain of profiling vs non-profiling is really only valid when comparing it against using the same GCC version, and same settings and tools other than using the -fprofile option. That way the speed is because of the profiling, and not just becuase it was compiled using a different system.

An example is having two cars of the same model and year, lets call them model X. One of them is the standard model and the other a slightly tweaked sports model (fprofiled). Its easy enough to say that the sports model is faster, it seems obvious. However, if you replace the engine in the sports model (currently say GCC 4.4.3/GCC 4.5.0 prerelease) with one from the same type of car, model X sports, but from around 5 years before (GCC 3.4), the comparison is no longer valid. Although the engine may have the same displacement, it may be less efficient to the point where the standard model of the current years car is actually more efficient.

[rack04]

Here are various builds that I hope will assist in comparing the speed of gcc optimizations and thread pooling to x264 defaults. I will add links as they are available.

Please note that all the builds in this post have the following configuration:

Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: no
ffms input: no
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

Toolchain:
GCC 4.4.3
GPAC 0.4.6-DEV Revison 5
Pthreads 2.9.0.0
Yasm 2320
clean x264 fprofiled builds:

x264_x86_core2_fprofiled_r1538 (http://www.multiupload.com/V2A7XNQRJ2)

x264_x86_generic_fprofiled_r1538 (http://www.multiupload.com/91Y3LKTC9W)
clean x264 builds:

x264_x86_core2_r1538 (http://www.multiupload.com/UBYF9JG9Y2)

x264_x86_generic_r1538 (http://www.multiupload.com/Y4UCUWFPL7)
patched x264 fprofiled builds (x264_thread_pool_v2.7_r1538 (http://pastebin.com/q2dz3WbM)):

x264_x86_core2_fprofiled_r1538M (http://www.multiupload.com/YS0K3VU05K)

x264_x86_generic_fprofiled_r1538M (http://www.multiupload.com/7WILZEDH91)
patched x264 builds (x264_thread_pool_v2.7_r1538 (http://pastebin.com/q2dz3WbM)):

x264_x86_core2_r1538M (http://www.multiupload.com/1PAVCFFPWG)

x264_x86_generic_r1538M (http://www.multiupload.com/UJDX1UEYPE)

[outlaw.78]

what does thread pool patch improves?

[rack04]

x264_x86_core2_fprofiled_r1538

Trial fps kb/s Mean =5.13
1 5.03 4910.57 Standard Error =0.0315
2 5.17 4910.42 Median =5.16
3 5.08 4911.10 Mode =#N/A
4 5.16 4910.10 Standard Deviation =0.0705
5 5.20 4910.08 Sample Variance =0.0050
Kurtosis =2.1909
Skewness =1.0954
Range =0.17
Minimum =5.03
Maximum =5.20
Sum =25.64
Count =5
Confidence (95%) =0.0213


x264_x86_core2_fprofiled_r1538M

Trial fps kb/s Mean =5.20
1 5.20 4910.51 Standard Error =0.0361
2 5.08 4910.14 Median =5.20
3 5.27 4910.09 Mode =#N/A
4 5.28 4910.53 Standard Deviation =0.0807
5 5.18 4910.47 Sample Variance =0.0065
Kurtosis =2.1909
Skewness =1.0954
Range =0.20
Minimum =5.08
Maximum =5.28
Sum =26.01
Count =5
Confidence (95%) =0.0244


x264_x86_core2_r1538

Trial fps kb/s Mean =5.22
1 5.20 4910.42 Standard Error =0.0360
2 5.19 4910.09 Median =5.20
3 5.36 4910.43 Mode =#N/A
4 5.15 4910.09 Standard Deviation =0.0804
5 5.21 4910.52 Sample Variance =0.0065
Kurtosis =2.1909
Skewness =1.0954
Range =0.21
Minimum =5.15
Maximum =5.36
Sum =26.11
Count =5
Confidence (95%) =0.0243


x264_x86_core2_r1538M

Trial fps kb/s Mean =5.25
1 5.17 4910.48 Standard Error =0.0286
2 5.34 4910.69 Median =5.26
3 5.28 4910.12 Mode =#N/A
4 5.26 4910.88 Standard Deviation =0.0639
5 5.22 4910.71 Sample Variance =0.0041
Kurtosis =2.1909
Skewness =1.0954
Range =0.17
Minimum =5.17
Maximum =5.34
Sum =26.27
Count =5
Confidence (95%) =0.0193


x264_x86_generic_fprofiled_r1538

Trial fps kb/s Mean =5.23
1 5.22 4910.89 Standard Error =0.0521
2 5.28 4910.58 Median =5.22
3 5.17 4910.53 Mode =#N/A
4 5.08 4910.58 Standard Deviation =0.1165
5 5.39 4910.42 Sample Variance =0.0136
Kurtosis =2.1909
Skewness =1.0954
Range =0.31
Minimum =5.08
Maximum =5.39
Sum =26.14
Count =5
Confidence (95%) =0.0351


x264_x86_generic_fprofiled_r1538M

Trial fps kb/s Mean =5.22
1 5.21 4910.13 Standard Error =0.0218
2 5.31 4910.49 Median =5.21
3 5.21 4910.09 Mode =5.21
4 5.19 4910.82 Standard Deviation =0.0488
5 5.20 4910.48 Sample Variance =0.0024
Kurtosis =2.1909
Skewness =1.0954
Range =0.12
Minimum =5.19
Maximum =5.31
Sum =26.12
Count =5
Confidence (95%) =0.0147


x264_x86_generic_r1538

Trial fps kb/s Mean =5.23
1 5.30 4910.48 Standard Error =0.0196
2 5.19 4910.09 Median =5.21
3 5.23 4910.48 Mode =#N/A
4 5.20 4910.44 Standard Deviation =0.0439
5 5.21 4910.49 Sample Variance =0.0019
Kurtosis =2.1909
Skewness =1.0954
Range =0.11
Minimum =5.19
Maximum =5.30
Sum =26.13
Count =5
Confidence (95%) =0.0133

[Dark Shikari]

Numbers like that are useless without stddev.

[rack04]

Numbers like that are useless without stddev.

I am in the process of updating the numbers. Hopefully these will be more useful.

[rack04]

Here is a test build that includes ffmpeg-mt/ffms2-mt input and avi output.

x264_x86_r1538M (http://www.multiupload.com/SN93174MDO)

./configure

Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
avi output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

make

[roozhou]

Here is a test build that includes ffmpeg-mt/ffms2-mt input and avi output.

Any good reason to use ffmpeg-mt against non-mt ffmpeg?

[Mr VacBob]

Huffyuv is faster until you run out of HD bandwidth. H264 is faster until it's more profitable to start more x264 threads. Which probably happens pretty fast, but I haven't benchmarked it.

[rack04]

Any good reason to use ffmpeg-mt against non-mt ffmpeg?

For testing to see if there is any speed difference.

[Blue_MiSfit]

H.264 decoding benefits hugely in ffmpeg-mt, especially when one tries to do high speed transcoding (i.e. 20x realtime for SD). Removing the decoder bottleneck lets x264 itself run as quickly as it can ;)

My experience is in using ffms2 with and without ffmpeg-mt. I saw MASSIVE speedup in cases as I've described.

~MiSfit

[roozhou]

H.264 decoding benefits hugely in ffmpeg-mt, especially when one tries to do high speed transcoding (i.e. 20x realtime for SD). Removing the decoder bottleneck lets x264 itself run as quickly as it can ;)

My experience is in using ffms2 with and without ffmpeg-mt. I saw MASSIVE speedup in cases as I've described.

~MiSfit
20x real-time transcoding from H264 to H264 for what purpose?

[jpsdr]

what does thread pool patch improves?

I'm curious too, what this patch is for ?

[LoRd_MuldeR]

I'm curious too, what this patch is for ?

I think currently x264 creates a new "encoder" thread for each frame and destroys that thread once the frame has been encoded. Creating and destroying threads has some overhead. The idea of having a "pool of threads" is: Created a certain number of threads once and re-use those threads over and over again. If you need a thread to run a task, you simply pick an idle thread from the pool (or wait for one to become idle). And if the thread has done its work (i.e. completed the task), it returns to the pool and waits for a new task to run. This could give some speed-up, because the thread creation/destruction overhead is avoided. But I have no numbers for x264. I assume if the thread pool really gave a significant speed-up, it would have been committed already. This patch is floating around for a long time now...

http://en.wikipedia.org/wiki/Thread_pool

[rack04]

H.264 decoding benefits hugely in ffmpeg-mt, especially when one tries to do high speed transcoding (i.e. 20x realtime for SD). Removing the decoder bottleneck lets x264 itself run as quickly as it can ;)

My experience is in using ffms2 with and without ffmpeg-mt. I saw MASSIVE speedup in cases as I've described.

~MiSfit

In the test that I just performed I noticed faster speeds without ffmpeg-mt, 6.04 fps vs 5.96 fps.

[Atak_Snajpera]

6.04 fps vs 5.96 fps.
whole 1% :) ffmpeg-mt is very usefull when you encode BD or any AVC-HD source to PSP (480x272), iphone and so on

[rack04]

whole 1% :) ffmpeg-mt is very usefull when you encode BD or any AVC-HD source to PSP (480x272), iphone and so on

All I was trying to convey is that in my limited testing ffmpeg-mt and ffms2-mt decoding as a x264 input method doesn't seem to benefit from the multithreading. The source in my test was a Blu-ray Disc. However, your point about the benefits of resizing is a non issue since lavf/ffms as a x264 input method doesn't support resizing, cropping, or padding yet.

[roozhou]

whole 1% :) ffmpeg-mt is very usefull when you encode BD or any AVC-HD source to PSP (480x272), iphone and so on
How do you accomplish this with x264's internal lavf or ffms?
I would rather do it with ffdshow. The decoder and the resizer will run in separate threads.

[Atak_Snajpera]

I always use ffshow.

[Blue_MiSfit]

@Roozhou:

Suppose you had a very high quality ~10-20mbps 480p H.264 file (or a whole giant lot of them, in my case), and you wanted to transcode them to various CBR bitrates as quickly as possible without totally looking like crap. A good way to do this is via 1 pass CBR encodes with --preset veryfast, or thereabouts. It works very well for my purposes anyway, and you can get insanely high transcoding speeds this way.

While it's true that my testing has only been via FFMS2 in AviSynth, my script is usually otherwise empty. Therefore, I would expect similar performance when using x264 directly on the sources, via its internal FFMS2 when built with ffmpeg-mt.

~MiSfit

[roozhou]

While it's true that my testing has only been via FFMS2 in AviSynth, my script is usually otherwise empty. Therefore, I would expect similar performance when using x264 directly on the sources, via its internal FFMS2 when built with ffmpeg-mt.
~MiSfit
FFMS2 needs extra indexing so it is not suitable for high-speed transcoding.

And if you have a lot of videos, spawning multiple encodings gives faster speed and better quality because you don't have to use multi-threaded encoding.

[Blue_MiSfit]

Maybe true, but indexing the source can sometimes be worth the additional time.

Regarding the whole "spawn multiple encodes vs use more threads" debate, I dunno... I've always been more comfortable with the idea of being able to rush through a single file if I needed to, versus always running a bunch of single or lightly threaded encodes.

I do totally agree that in theory it should be faster / better quality to do the latter, but I would bet the differences would be minor, especially since on a large scale, you would cause a lot more random I/O activity. But, I'm getting off-topic.

Regardless, I think ffmpeg-mt is very nice to have in x264 when I simply want to take an existing H.264 file and transcode to a lower bitrate as quickly as possible. I actually use this same method to transcode content from unrestricted / High@4.1 down to a lower level for device compatibility (iPhone etc). I do this alllll the time when I'm in a hurry, and headed to the gym, laudromat, or airport in need of new media to consume. :)

~MiSfit

[rack04]

Toolchain:
gcc 4.4.3
gpac 0.4.6-dev revison 5
pthreads 2.9.0.0 gc-static
yasm 1.0.0
x264_x86_r1542M_Generic (http://www.multiupload.com/TUI1S1IW3D)

Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

Patches:
x264.open-gop.19_r1542 (http://pastebin.com/MbKdh684) <Trahald>
ffmpeg_static_pthreads_r22912 (http://pastebin.com/xyQiwPYD) <angustia>
ffms2_threads_fix_r309 (http://pastebin.com/FppV5KE6) <komisar>
x264_x86_r1542M_Generic (http://www.multiupload.com/OOBVLDAYLL)

Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
filters: resize select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no

Patches:
x264.open-gop.19_r1542 (http://pastebin.com/MbKdh684) <Trahald>
x264_filtering_r1542 (http://pastebin.com/Xqv2G1bS) <kemuri-_9>
ffmpeg_static_pthreads_r22912 (http://pastebin.com/xyQiwPYD) <angustia>
ffms2_threads_fix_r309 (http://pastebin.com/FppV5KE6) <komisar>

[outlaw.78]

x264 0.93.1542 x64 & x86 (http://www.mediafire.com/?m5rghmbjxyz)

gcc 4.5.0
ffmpeg svn 22926
swscale svn 31053
ffms2 svn 309
pthreads 2.9.0.0 static
x264 0.93.1542 x86,x64,amdfam10,fprofiled

[bob0r]

pthreads 2.9.0.0 static
Where does this made up version come from?

[kemuri-_9]

Where does this made up version come from?

pthread.h:

/*
* See the README file for an explanation of the pthreads-win32 version
* numbering scheme and how the DLL is named etc.
*/
#define PTW32_VERSION 2,9,0,0
#define PTW32_VERSION_STRING "2, 9, 0, 0\0"

[roozhou]

pthread.h:

/*
* See the README file for an explanation of the pthreads-win32 version
* numbering scheme and how the DLL is named etc.
*/
#define PTW32_VERSION 2,9,0,0
#define PTW32_VERSION_STRING "2, 9, 0, 0\0"


Where can i get the source code of pthreads-win32 2.9.0.0?

[Audionut]

x264_x86_r1542M_Generic

Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
filters: resize select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no

Patches:
x264.open-gop.19_r1542 (http://pastebin.com/MbKdh684) <Trahald>
x264_filtering_r1542 (http://pastebin.com/Xqv2G1bS) <kemuri-_9>
ffmpeg_static_pthreads_r22912 (http://pastebin.com/xyQiwPYD) <angustia>
ffms2_threads_fix_r309 (http://pastebin.com/FppV5KE6) <komisar>

Hi rack04, any chance of a 64bit build with these patches?

[LoRd_MuldeR]

Where can i get the source code of pthreads-win32 2.9.0.0?

http://sourceware.org/cgi-bin/cvsweb.cgi/pthreads/?cvsroot=pthreads-win32

[alexins]

Where can i get the source code of pthreads-win32 2.9.0.0?

http://sources.redhat.com/pthreads-win32/
cvs -d :pserver:anoncvs@sourceware.org:/cvs/pthreads-win32 login
{enter ``anoncvs'' for the password}
cvs -d :pserver:anoncvs@sourceware.org:/cvs/pthreads-win32 checkout pthreads

[rack04]

Toolchain:
gcc 4.4.3
gpac 0.4.6-dev revison 5
pthreads 2.9.0.0 gc-static
yasm 1.0.0
LAVF/FFMS Builds:
ffmpeg svn22939 and libswscale svn31054 (http://www.multiupload.com/8MEH109002)
ffms2 svn310 (http://www.multiupload.com/M7ITP46POL)
x264 Builds:
x264_x86_r1542M (http://www.multiupload.com/VNMD003PNB)

Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
filters: resize select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x64_r1542M (http://www.multiupload.com/IEIPFI7PMR)

Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
filters: resize select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no
Patches:
x264.open-gop.19_r1542 (http://pastebin.com/MbKdh684) <Trahald>
x264_filtering_r1542 (http://pastebin.com/Xqv2G1bS) <kemuri-_9>
ffmpeg_static_pthreads_r22912 (http://pastebin.com/xyQiwPYD) <angustia>
ffms2_threads_fix_r309 (http://pastebin.com/FppV5KE6) <komisar>

[outlaw.78]

x264 0.94.1564 x64 & x86 (http://www.mediafire.com/?nqjdmmm2ilm)

gcc 4.5.0
ffmpeg svn 22960
swscale svn 31067
ffms2 svn 310
pthreads 2.9.0.0 static
x264 0.94.1564 x86,x64,amdfam10,fprofiled

[alwa]

Hello,
i've tried today to compile x264 with the new 2.7 release of the GCC frontend for llvm. (http://llvm.org/releases/download.html#2.7)
It produces a smaller executable than GCC, that sadly crashes immediately (standard configuration no ffmpeg stuff). But if asm is disabled the executable works (at least with the default x264 stettings so far).
The the first speed impressions are disillusioning.
With the x264 default settings on SOCCER_704x576_30fps.yuv with a Q9550:
~13fps gcc executable
~9fps llvm executable
(i'know no stdev and stuff, but llvm builds still seem to be clearly slower)

Maybe some x264 dev can take a look on compiles with llvm (if not already done) and diagnose the asm problem and figure out if there would be any benefit in supporting llvm.

I'm aware that the compiler is not that important for the speed of x264, i just wanted to put some thoughts out there.

[rack04]

Toolchain:
GCC 4.4.3
GPAC 0.4.6-DEV Revison 5
Pthreads 2.9.0.0 GC-static
Yasm 1.0.0
LAVF/FFMS Builds:

ffmpeg SVN-r23012M and libswscale SVN-r31128M (http://www.multiupload.com/YWJ7FHCXS5)
ffms2 SVN-r311M (http://www.multiupload.com/6OJPV3X6LU)
LAVF/FFMS Patches:
ffmpeg_static_pthreads_r23011 (http://pastebin.com/0LMeaBqt) <angustia>
libswscale_x64_fix_r31032 (http://pastebin.com/0yAGkLXC) <BugMaster>
ffms2_threads_fix_r309 (http://pastebin.com/i0M5EuHs) <komisar>
x264 Builds:

x264_x64_r1570M_Generic (http://www.multiupload.com/PBQK3WN7OC)
Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x86_r1570M_Generic (http://www.multiupload.com/3KHHTA89IC)
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264 Patches:
x264_sws_typecast_r1570 (http://pastebin.com/78yXue1H) <komisar>
x264_demuxer_threads_r1570 (http://pastebin.com/rQpuTTAY) <komisar>
x264.open-gop.20_r1570 (http://pastebin.com/LiDUepz8) <Trahald>

[kemuri-_9]

gcc 4.4.4 and gcc 4.5.0 are out, builders still using 4.4.3 should update to one of them.

[Audionut]

rack04, could you include this patch, http://x264.fushizen.eu/patches/x264_fade_compensation-1542.diff
in your next build please.

[rack04]

Toolchain:
GCC 4.4.3
GPAC 0.4.6-DEV Revison 5
Pthreads 2.9.0.0 GC-static
Yasm 1.0.0
LAVF/FFMS Builds:

ffmpeg SVN-r23022M and libswscale SVN-r31137M (http://www.multiupload.com/7NABARIGI0)
ffms2 SVN-r311M (http://www.multiupload.com/APHVP0EDF9)
LAVF/FFMS Patches:
ffmpeg_static_pthreads_r23016 (http://pastebin.com/f8NWT5j5) <angustia>
libswscale_x64_fix_r31032 (http://pastebin.com/0yAGkLXC) <BugMaster>
ffms2_threads_fix_r309 (http://pastebin.com/i0M5EuHs) <komisar>
x264 Builds:

x264_x64_r1570M (http://www.multiupload.com/IZX18M32JD)
Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x86_r1570M (http://www.multiupload.com/2P68UNJPX7)
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264 Patches:
x264_sws_typecast_r1570 (http://pastebin.com/78yXue1H) <komisar>
x264_demuxer_threads_r1570 (http://pastebin.com/rQpuTTAY) <komisar>
x264.open-gop.20_r1570 (http://pastebin.com/LiDUepz8) <Trahald>
x264_fade_compensation_r1570_v2 (http://pastebin.com/dhCNv6bx) <Dark Shikari>

[julius666]

rack04, could you include this patch, http://x264.fushizen.eu/patches/x264_fade_compensation-1542.diff
in your next build please.

What changes do this patch make?

[JEEB]

Basically makes use of x264's internal fade-finding mechanism and assigns more bits to those places that are "marked" as fades. Works when mbtree is on with weightp 0 and 2 IIRC.

Adds a setting that controls the strength of this feature (how strong the effect is).

--fade-compensate <float> Allocate more bits to fades [0.0]
Approximate sane range: 0.0 - 1.0

Edit: A small fix pointed out by VFR Maniac. Line 19 on the pastebin'd 1570 patch, change %2.f to %.2f

[outlaw.78]

x264 0.94.1570 x64 & x86 (http://www.mediafire.com/?wbddnmnwh2a) AMD

gcc 4.5.1 20100429 pre-release
ffmpeg svn 23017
swscale svn 31136
ffms2 svn 311
pthreads 2.9.0.0 static
x264 0.94.1570 x86,x64,amdfam10,fprofiled

[Audionut]

Thanks rack04. Were you aware of the fix before you made your build?

[rack04]

Thanks rack04. Were you aware of the fix before you made your build?

No. I will post updated builds soon.

[jpsdr]

Not too soon maybe, open-gop have seems to have a high probability to update to 21 soon...
BTW, thanks for your builds.

[rack04]

Not too soon maybe, open-gop have seems to have a high probability to update to 21 soon...
BTW, thanks for your builds.

I edited my previous post with a new x264 build patched with x264_fade_compensation_r1570_v2 (http://pastebin.com/dhCNv6bx)

[rack04]

Toolchain:
GCC 4.4.3
GPAC 0.4.6-DEV Revison 5
Pthreads 2.9.0.0 GC-static
Yasm 1.0.0
LAVF/FFMS Builds:

ffmpeg SVN-r23034M and libswscale SVN-r31139M (http://www.multiupload.com/ZBG0S2KPMR)
ffms2 SVN-r311M (http://www.multiupload.com/2ANQARVAO1)
LAVF/FFMS Patches:
ffmpeg_static_pthreads_r23016 (http://pastebin.com/f8NWT5j5) <angustia>
libswscale_x64_fix_r31032 (http://pastebin.com/0yAGkLXC) <BugMaster>
ffms2_threads_fix_r309 (http://pastebin.com/i0M5EuHs) <komisar>
x264 Builds:

x264_x64_r1583M (http://www.multiupload.com/QZ3ED30O1S)
Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x86_r1583M (http://www.multiupload.com/UJX3V6BZPV)
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264 Patches:
x264_sws_typecast_r1570 (http://pastebin.com/78yXue1H) <komisar>
x264_demuxer_threads_r1570 (http://pastebin.com/rQpuTTAY) <komisar>
x264.open-gop.20_r1583 (http://pastebin.com/uEsyh9Xf) <Trahald>
x264_fade_compensation_r1583 (http://pastebin.com/bfL8MNgR) <Dark Shikari>

I will post some GCC 4.4.4 builds later to compare to GCC 4.4.3.

EDIT: I get a segmentation fault when trying to build ffmpeg using GCC 4.4.4.

[alexins]

EDIT: I get a segmentation fault when trying to build ffmpeg using GCC 4.4.4.

I did build x 264, using GCC 4.4.4 (Stable) (http://www.xvidvideo.ru/2009-10-22-10-49-14/doc_details/3567-cross-mingw-x86x64-201004292200-with-gcc-444-stable-pthreads-290-static.html). No error, here's a detailed logs build ffmpeg, ffms2, gpac, x 264 (http://www.mediafire.com/?riz2czdfdnm).

[rack04]

I did build x 264, using GCC 4.4.4 (Stable) (http://www.xvidvideo.ru/2009-10-22-10-49-14/doc_details/3567-cross-mingw-x86x64-201004292200-with-gcc-444-stable-pthreads-290-static.html). No error, here's a detailed logs build ffmpeg, ffms2, gpac, x 264 (http://www.mediafire.com/?riz2czdfdnm).

This is what I get when i cross compile x64 ffmpeg using GCC 4.4.4.

http://i11.photobucket.com/albums/a199/rack04/untitled.jpg

[kemuri-_9]

it works fine here with komisar's gcc 4.4.4 binutil set, so try that instead i guess.

[roozhou]

This is what I get when i cross compile x64 ffmpeg using GCC 4.4.4.

http://i11.photobucket.com/albums/a199/rack04/untitled.jpg
Try "make" instead of "make -j2/-j4".

[burfadel]

Just curious, is it known how useful all the new instructions coming out at the end of the year and next year will be, on processors that support them? Like AvX, CVT16 etc?

[bob0r]

Also a ffmpeg error here on gcc 4.4.4:


CC libavcodec/dsputil.o
libavcodec/dsputil.c: In function 'put_h264_qpel2_mc10_c':
libavcodec/dsputil.c:2586: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: *** [libavcodec/dsputil.o] Error 1


Latest working ffmpeg git revision: 22940

Side note: the same file, dsputil.c segmentation faulted before, then on gcc 4.4.3.
It was fixed 1 days after pasting it in #ffmpeg, but that was a coincidence i guess.
(i have how ever pasted it again :p)

[rack04]

Try "make" instead of "make -j2/-j4".

I used "make". BTW, I have no problem cross compiling x64 ffmpeg using GCC 4.4.4 in x64 Win7 but I get the error above in x32 WinXP.

[roozhou]

I used "make". BTW, I have no problem cross compiling x64 ffmpeg using GCC 4.4.4 in x64 Win7 but I get the error above in x32 WinXP.
I got the same error with TDM's GCC 4.4.1 long ago. You can also try qp gcc builds (http://code.google.com/p/qp-gcc/downloads/list).

[juGGaKNot]

Need a generic gcc 4.4.4 32bit build with fade compensation guys.

anyone ?

[[ReX]]

Need a generic gcc 4.4.4 32bit build with fade compensation guys.

anyone ?

ffmpeg/ffms2 is a little old, but not too much (not even a month old if I remember).

Only patch used: x264_fade_compensation_r1583
GCC 4.4.4 x86
make fprofiled
http://www.mediafire.com/?zyzymyvyzmn

[rack04]

I got the same error with TDM's GCC 4.4.1 long ago. You can also try qp gcc builds (http://code.google.com/p/qp-gcc/downloads/list).

Turns out it is a bug in ffmpeg. It has been reproduced and reported by angustia. Evidently it will work if you don't disable filters.

[juGGaKNot]

;1398603']ffmpeg/ffms2 is a little old, but not too much (not even a month old if I remember).

Only patch used: x264_fade_compensation_r1583
GCC 4.4.4 x86
make fprofiled
http://www.mediafire.com/?zyzymyvyzmn

thnx.

[jsday187]

Is there a possiblilty of getting an up to date DLL of ffms2 with thread fix patch separate from these builds?

[burfadel]

You mean an avisynth ffms2 filter so you can us ffvideosource? I second the request with an automated thankyou!

[[ReX]]

I think it was fixed, so there's no need for patch.
http://code.google.com/p/ffmpegsource/source/detail?r=312

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6-DEV
Pthreads 2.9.0.0
YASM 1.0.0
x264 Builds:
x264_x86_r1583M (http://www.multiupload.com/BHUIZOAYGH)

Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x64_r1583M (http://www.multiupload.com/4LBMK9508B)

Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
Patches:
x264_sws_typecast_r1570 (http://pastebin.com/2D94ZEm7) <komisar>
x264_demuxer_threads_r1570 (http://pastebin.com/X8uQdiE9) <komisar>
x264.open-gop.22 (http://pastebin.com/363tDMnb) <Trahald>
x264_fade_compensation_r1583 (http://pastebin.com/yfwNyqxG) <Dark Shikari>

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6-DEV Rev 5
Pthreads 2.9.0.0
Yasm 1.0.0
LAVF/FFMS Builds:

ffmpeg SVN-r23156M and libswscale SVN-r31179M (http://www.multiupload.com/60DNAC7CSR)
ffms2 SVN-r312 (http://www.multiupload.com/43NOZEOH35)
LAVF/FFMS Patches:
ffmpeg_static_pthreads_r23179 (http://codetidy.com/42) <angustia>
libswscale_x64_fix_r31032 (http://codetidy.com/44) <BugMaster>
x264 Builds:

x264_x64_r1592M (http://www.multiupload.com/VL5W219EDI)
Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x86_r1592M (http://www.multiupload.com/W2U7A8DF7I)
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264 Patches:
x264_sws_typecast_r1570 (http://codetidy.com/45) <komisar>
x264_demuxer_threads_r1570 (http://codetidy.com/46) <komisar>
x264.open-gop.22_r1592 (http://codetidy.com/47) <Trahald>
x264_fade_compensation_r1583 (http://codetidy.com/48) <Dark Shikari>

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6-DEV Rev 5
Pthreads 2.9.0.0
Yasm 1.0.0
LAVF/FFMS Builds:

ffmpeg SVN-r23201M and libswscale SVN-r31186M (http://www.multiupload.com/QSJ47SDG8N)
ffms2 SVN-r312 (http://www.multiupload.com/I9MTBQD10P)
LAVF/FFMS Patches:
ffmpeg_static_pthreads_r23179 (http://pastebin.com/Phx49DGt) <angustia>
llibswscale_x64_fix_r31032 (http://pastebin.com/hNQGLpYm) <BugMaster>
x264 Builds:

x264_x64_r1592M (http://www.multiupload.com/7NR8FBZQLP)
Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
avi output: yes
pthread: yes
filters: resize select_every crop hqdn3d
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x86_r1592M (http://www.multiupload.com/56NLFZ4CUQ)
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
avi output: yes
pthread: yes
filters: resize select_every crop hqdn3d
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264 Patches:
x264_sws_typecast_r1570 (http://pastebin.com/qcNYfXWZ) <komisar>
x264_demuxer_threads_r1570 (http://pastebin.com/G7zjaChB) <komisar>
x264.open-gop.22_r1592 (http://pastebin.com/at39YNXN) <Trahald>
x264_fade_compensation_r1583 (http://pastebin.com/rf9EZfN2) <Dark Shikari>
x264_avi_output.v4_r1592 (http://pastebin.com/xyNNAqy6) <MasterNobody>
x264_filtering_r1592 (http://pastebin.com/98VLM5Pg) <kemuri-_9>
x264_filtering_changes_r1592 (http://pastebin.com/1eiDAmiv) <J_Darnley>

[Audionut]

Thanks rack04

[jpsdr]

I don't know where to put it, just to notify, in the help, the default mode for nal-hrd is not specified.

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.0
LAVF/FFMS Builds:

ffmpeg SVN-r23285M and libswscale SVN-r31206M (http://www.multiupload.com/2TYCAHXMLK)
ffms2 SVN-r312 (http://www.multiupload.com/N69SBIXUFP)
Patches:
ffmpeg_static_pthreads_r23179 (http://pastebin.com/LMuCc9hd) <angustia>
libswscale_x64_fix_r31032 (http://pastebin.com/GiDV9aVf) <BugMaster>
x264 Builds:

x264_x64_r1602 (http://www.multiupload.com/ANLADULZG0)
Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x86_r1602 (http://www.multiupload.com/ZIJOZK6PVP)
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x64_r1602M (http://www.multiupload.com/PSN6VJ76VS)
Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
avi output: yes
pthread: yes
filters: resize select_every crop hqdn3d
debug: no
gprof: no
PIC: no
shared: no
visualize: no
Patches:
x264_sws_typecast_r1570 (http://pastebin.com/Gj3vR7re) <komisar>
x264_demuxer_threads_r1602 (http://pastebin.com/12ECMUPX) <komisar>
x264_open-gop.22_r1602 (http://pastebin.com/enPSBBGK) <Trahald>
x264_fade_compensation_r1602 (http://pastebin.com/qw8WCBJf) <Dark Shikari>
x264_avi_output.v4_r1602 (http://pastebin.com/4sew624g) <MasterNobody>
x264_filtering_r1602 (http://pastebin.com/KEEGHzBB) <kemuri-_9>
x264_filtering_changes_r1602 (http://pastebin.com/QU9Xwxy6) <J_Darnley>
x264_x86_r1602M (http://www.multiupload.com/NTX2YJVK19)
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
avi output: yes
pthread: yes
filters: resize select_every crop hqdn3d
debug: no
gprof: no
PIC: no
shared: no
visualize: no
Patches:
x264_sws_typecast_r1570 (http://pastebin.com/Gj3vR7re) <komisar>
x264_demuxer_threads_r1602 (http://pastebin.com/12ECMUPX) <komisar>
x264_open-gop.22_r1602 (http://pastebin.com/enPSBBGK) <Trahald>
x264_fade_compensation_r1602 (http://pastebin.com/qw8WCBJf) <Dark Shikari>
x264_avi_output.v4_r1602 (http://pastebin.com/4sew624g) <MasterNobody>
x264_filtering_r1602 (http://pastebin.com/KEEGHzBB) <kemuri-_9>
x264_filtering_changes_r1602 (http://pastebin.com/QU9Xwxy6) <J_Darnley>

[tormento]

@ rack04

Using x264_x64_r1602M I get the error

raw [error]: raw input requires a resolution

[rack04]

@ rack04

Using x264_x64_r1602M I get the error

raw [error]: raw input requires a resolution

http://doom10.org/index.php?topic=177.msg2130#msg2130

[tormento]

http://doom10.org/index.php?topic=177.msg2130#msg2130
Is it possible to get a x64 version with all the patches but the one that causes that issue?

Staxrip can't change the command line.

[easyfab]

Toolchain:

x264_x86_r1592M (http://www.multiupload.com/56NLFZ4CUQ)
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
avi output: yes
pthread: yes
filters: resize select_every crop hqdn3d
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264 Patches:
x264_sws_typecast_r1570 (http://pastebin.com/qcNYfXWZ) <komisar>
x264_demuxer_threads_r1570 (http://pastebin.com/G7zjaChB) <komisar>
x264.open-gop.22_r1592 (http://pastebin.com/at39YNXN) <Trahald>
x264_fade_compensation_r1583 (http://pastebin.com/rf9EZfN2) <Dark Shikari>
x264_avi_output.v4_r1592 (http://pastebin.com/xyNNAqy6) <MasterNobody>
x264_filtering_r1592 (http://pastebin.com/98VLM5Pg) <kemuri-_9>
x264_filtering_changes_r1592 (http://pastebin.com/1eiDAmiv) <J_Darnley>

Is it possible to set % for the resize filter, for example 75% of the original size ?

[J_Darnley]

Is it possible to set % for the resize filter, for example 75% of the original size ?

No...

[rack04]

Is it possible to get a x64 version with all the patches but the one that causes that issue?

Staxrip can't change the command line.

Use the unpatched version.

[tormento]

Use the unpatched version.

I'd like to get the benefits of other patches...:eek:

[Audionut]

I'd like to get the benefits of other patches...:eek:

http://komisar.gin.by/

And thanks for using the filtering patch again rack04.

[burfadel]

Is it possible to get a x64 version with all the patches but the one that causes that issue?

Staxrip can't change the command line.

If the patch provides an extra command line option, it can be added under 'config codec', under the 'Command Line' tab. There are three boxes under the command line tab. The first is to change the options for all passes, or in CRF mode, and the other two are for first and second pass options.

If there is a patch that changes an existing option, you can also change it. For example, if there were a new AQ patch that added AQ mode 3 for testing (and this has been done in the past)!, you can't change it via the standard gui options. What you do is leave/change AQ mode to 1 in the gui (typical default), in which case its not specific in the command line. You can then add --aq-mode 3 in the command line section and you will see it with all the options selected at the bottom of that tab.

This has been a feature of Staxrip for a long while, but if you haven't got the very latest version, it would still be a good idea to update :)

Of course, you can use later versions of any component Staxrip uses by replacing the ones that come with Staxrip. You can then accept the message saying its newer and it should be ok! (unless the updated version of the programme changes the required command line syntax or function).

[tormento]

If the patch provides an extra command line option, it can be added under 'config codec', under the 'Command Line' tab.
Very kind answer, thanks. I have the latest version but can't find how to replace a mandatory command line option with another.

[outlaw.78]

x264 0.96.1612M x64 & x86 (http://www.mediafire.com/?mkmzjmdzcdm)


gcc 4.5.1 20100523 prerelease
ffmpeg svn 23327
swscale svn 31217
ffms2 svn 312
pthreads 2.9.0.0 static
x264 0.96.1612M x86,x64,amdfam10,fprofiled
patches used :
04_x264_thread_pool_v2.9.r1602.diff (http://komisar.gin.by/old/1602/p/04_x264_thread_pool_v2.9.r1602.diff)
x264_demuxer_threads.diff (http://komisar.gin.by/old/1602/p/x264_demuxer_threads.diff)
x264_sws_typecast.diff (http://komisar.gin.by/old/1602/p/x264_sws_typecast.diff)
x264_avi_output.v4.diff (http://komisar.gin.by/old/1602/p/x264_avi_output.v4.diff)

[burfadel]

Very kind answer, thanks. I have the latest version but can't find how to replace a mandatory command line option with another.

Which mandatory command line are you trying to replace?

[3ngel]

Hi,

from some time, i'm facing a strange problem.

I'm not able to complete an encode whetever parameters i set, because of the error after some time (first pass)

"ratecontrol _init: can't open stats file"

After investigation, i found that pheraps there is a memory allocation problem.

That is, actually i'm doing an encoding, first pass, and x264.exe has allocated already 1.575.233 bytes, and is slowly but constantly increasing.

Now the memory user space on a 32bit system is 2GB, so i can assume that when the allocation reaches the 2GB, the encoder fails because _malloc can't allocate anymore.

I could try with the /3G switch but i think it's not normal to allocate for an encoding such a huge amount of memory (and i suspect that even with the /3G the encoder would reach the limit).

Any confirm on this from someone?

Possible solution?

I'm on Windows 2003 intel i7 6 cores.

Thanks

[Dark Shikari]

Hi,

from some time, i'm facing a strange problem.

I'm not able to complete an encode whetever parameters i set, because of the error after some time (first pass)

"ratecontrol _init: can't open stats file"

After investigation, i found that pheraps there is a memory allocation problem.

That is, actually i'm doing an encoding, first pass, and x264.exe has allocated already 1.575.233 bytes, and is slowly but constantly increasing.x264 will print a malloc error if a memory allocation fails.

[J_Darnley]

Which mandatory command line are you trying to replace?

He's trying to get the filter patch working via staxrip. The change he needs is that the input resolution must be given with --input-res instead of just the argument after the input file name.

[rack04]

He's trying to get the filter patch working via staxrip. The change he needs is that the input resolution must be given with --input-res instead of just the argument after the input file name.

What raw inputs files do you need to specify --input-res?

[nm]

What raw inputs files do you need to specify --input-res?

All that are really raw and don't have a container. Apparently Staxrip is piping raw video to x264, so --input-res is required when using the filtering patch.

[rack04]

All that are really raw and don't have a container. Apparently Staxrip is piping raw video to x264, so --input-res is required when using the filtering patch.

Thanks. The reason I asked is because I am feeding yuv, have the resolution set in the filename, and it still works fine.

[nm]

Thanks. The reason I asked is because I am feeding yuv, have the resolution set in the filename, and it still works fine.

Yes, that is still an option, but not when piping without a FIFO file.

[J_Darnley]

What raw inputs files do you need to specify --input-res?

All raw input needs the resolution set. I had forgotten about the filename parsing though.

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r23340M and libswscale SVN-r31226M (http://www.multiupload.com/7J673HAZOW)
ffms2 SVN-r312 (http://www.multiupload.com/TVBZPXWJDE)
x264 Builds:

x264_x64_r1613 (http://www.multiupload.com/9SSR7BIARU)
x264_x86_r1613 (http://www.multiupload.com/THYZ0VBC9N)
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x64_r1613M (http://www.multiupload.com/VCXRCEEEIU)
x264_x86_r1613M (http://www.multiupload.com/GNF6148HX8)
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
avi output: yes
pthread: yes
filters: resize select_every crop hqdn3d
debug: no
gprof: no
PIC: no
shared: no
visualize: no
Patches:
x264_sws_typecast_r1570 (http://pastebin.com/Gj3vR7re) <komisar>
x264_demuxer_threads_r1602 (http://pastebin.com/12ECMUPX) <komisar>
x264.open-gop.22_r1613 (http://pastebin.com/5AScMVNS) <Trahald>
x264_fade_compensation_r1612 (http://pastebin.com/JhY4G5XU) <Dark Shikari>
x264_avi_output.v4_r1602 (http://pastebin.com/4sew624g) <MasterNobody>
x264_filtering_r1612 (http://pastebin.com/AZdGNwMv) <kemuri-_9>
x264_filtering_changes_r1602 (http://pastebin.com/QU9Xwxy6) <J_Darnley>
x264_thread_pool_v2.9_r1613 (http://pastebin.com/R3ADAXuj) <MasterNobody>

[komisar]

rack04, x264_thread_pool_v2.9_r1612 patch by <MasterNobody>...

[rack04]

rack04, x264_thread_pool_v2.9_r1612 patch by <MasterNobody>...

Fixed. Thank you.

[ajp_anton]

What happened to the Intel builds?

[Schrade]

rack04, x264_x86_r1613M download link links to an archive named x264_x86_r1612M.7z

Is it just a typo?

[rack04]

rack04, x264_x86_r1613M download link links to an archive named x264_x86_r1612M.7z

Is it just a typo?

What does --help say?

x264 core:97 r1613M 81e75e9

[jpsdr]

Rack04 : Big problem with your x64 1613M version. I have the program wich brutaly crash/stop without any kind of error message after encoding 30 frames of the 1rst pass (video is 1280x720 23.976fps)...

Commande line used :

@echo off

SET E_SRC=%6%1.avs
SET E_DST=%3%1.264
SET STAT_FILE=%1.stats
SET TUNING=%4
SET LOG_FILE_1=%1_log_1.txt
SET LOG_FILE_2=%1_log_2.txt

REM Set of max bitrate (ici le bitrate max)
set MAX_BR=15000

REM Set of Buffer (ici le buffer)
set BUF_BR=30000

REM 1ère passe
x264_x64.exe --profile "high" --preset "placebo" --tune %TUNING% --pass 1 --bitrate %2 --stats %STAT_FILE% --level "4.0" --qpmin 0 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 48 --min-keyint 2 --mvrange 511 --ref 6 --bframe 3 --b-pyramid "strict" --open-gop --subme 9 --trellis 1 --me "umh" --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --videoformat "ntsc" --sar 1:1 --qpfile %5 --threads 0 --thread-input --output NUL %E_SRC% 2> %LOG_FILE_1%

REM 2ème passe
x264_x64.exe --profile "high" --preset "placebo" --tune %TUNING% --pass 2 --bitrate %2 --stats %STAT_FILE% --level "4.0" --qpmin 0 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 48 --min-keyint 2 --mvrange 511 --ref 6 --bframe 3 --b-pyramid "strict" --open-gop --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --videoformat "ntsc" --sar 1:1 --qpfile %5 --threads 0 --thread-input --output %E_DST% %E_SRC% 2> %LOG_FILE_2%

[rack04]

Rack04 : Big problem with your x64 1613M version. I have the program wich brutaly crash/stop without any kind of error message after encoding 30 frames of the 1rst pass (video is 1280x720 23.976fps)...

Commande line used :

Post a sample that can be reproduced. Do it work with unpatched build?

[tormento]

Which mandatory command line are you trying to replace?

Well, replace the older command line with the newer that should use rack04 patched compile.

[jpsdr]

I'll make other tests this evening. With unpatched build, the command line will be of course without open-gop.

[kypec]

Fixed. Thank you.
You've only fixed _x86 part. <komisar> is still mentioned at _x64 part.
I think it would be easier for you and also for the readers to join that
descriptive links to patches. Write them just once together with compilation
settings used and post only separate download links to _x86 / _x64 builds underneath.
Same suggestion to unpatched builds applies.
It's redundant and likely error prone to write same information twice, no need for that.

[Wishbringer]

Big problem with your x64 1613M version. I have the program wich brutaly crash/stop without any kind of error message after encoding 30 frames of the 1rst pass...

Same here, tried to encode 1920x1080/24
--profile high --preset veryslow --tune film --slices 4 --level 4.0 --keyint 48 --min-keyint 2 --aq-mode 2 --b-pyramid strict --aud --nal-hrd vbr --open-gop --vbv-bufsize 31250 --vbv-maxrate 15000 --direct auto

Same encode worked with 1603, I just updated the exe to 1613M and restarted encode.

[rack04]

Same encode worked with 1603, I just updated the exe to 1613M and restarted encode.

Have you tried without open-gop? Can you post a sample?

[Wishbringer]

Without --open-gop it works (1st pass was ok, atm it started 2nd pass and is at 10%).
Sorry, no sample, am here at girlfriend with only 64kbit/sec upload speed.

[rack04]

Without --open-gop it works (1st pass was ok, atm it started 2nd pass and is at 10%).
Sorry, no sample, am here at girlfriend with only 64kbit/sec upload speed.

I found the problem. Try (http://www.multiupload.com/VCXRCEEEIU) this build. I will update the download link in the other post.

[jpsdr]

Was the problem specific to x64 build ?

[rack04]

Was the problem specific to x64 build ?

Nope. I managed to screw up the the open-gop patch. It should be fixed now.

[Wishbringer]

Seems to work now, 1st pass at 30%, no crash like first build at 0-1%.

Thanks rack04!

[jpsdr]

@Rack04Thanks for the builds and the updates. I'll test it.
@Wishbringer : Level 4.0 don't need slices (if encoding for blu-ray), so, removing will slighty improve quality.

[3ngel]

I continue to have the same situation with first pass truncked after some minutes with only a "encode failed" and second pass that can't find the "stat file".

I've downloaded again from the Rack04 updated post the new build (with the open gop corrected patch), but same problem.

I download the x86 without filters.

Am i missing something?

Thanks

[Wishbringer]

I continue to have the same situation with first pass truncked after some minutes with only a "encode failed" and second pass that can't find the "stat file".

I've downloaded again from the Rack04 updated post the new build (with the open gop corrected patch), but same problem.

I download the x86 without filters.


The 1613 build without "M" in name?
Does it even have open-gop-patch? it's not "Modified"!
Maybe your 1st pass doesn't start because it can't recognize "--open-gop" command.

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r23424 and libswscale SVN-r31303 (http://www.multiupload.com/YUWSC4I0YH)
ffms2 SVN-r312 (http://www.multiupload.com/OQOYFB5ID9)
x264 Builds:

x264_x64_r1627 (http://www.multiupload.com/347NAPXR9D)
x264_x86_r1627 (http://www.multiupload.com/4J4LYXN9E6)
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

[3ngel]

I continue to get this error after some minutes of encoding

x264.1627.x86.exe --pass 1 --slow-firstpass --profile
high --preset veryslow --tune grain --bitrate 5832 --no-deblock --ssim --level
4.1 --output NUL s2.avs
avs [info]: 1920x1080p 0:0 @ 10000000/417083 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
x264 [error]: x264_encoder_encode failed50.21 kb/s, eta 7:29:39

What is related to?

How can i resolve?

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r23439 and libswscale SVN-r31309 (http://www.multiupload.com/UR61SHUQHN)
ffms2 SVN-r312 (http://www.multiupload.com/890GM7F1VK)
x264 Builds:

x264_x64_r1629 (http://www.multiupload.com/UQHOWB3ZK8)
x264_x86_r1629 (http://www.multiupload.com/QVO60QPT79)
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x64_r1629M (http://www.multiupload.com/SWLVZ6FSHM)
x264_x86_r1629M (http://www.multiupload.com/YK0B52W77K)
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
Patches:
x264_open-gop.22_r1629 (http://pastebin.com/t2Y0QYA8) <Trahald>

[kemuri-_9]

MinGW ffmpeg+x264 builders:
please update ffmpeg to r23448+ to fix >4GB file support in ffmpeg (and ffms2).
*NOTE*: this only applies if you haven't already patched your mingw to already fix the issue...
I've confirmed that JEEB, rack04, and x264.nl builds are all broken in this regard...

[JEEB]

Oh ffu~.

Thanks for the heads-up and great job on getting stuff fixed in ffmpeg. Will have to rerun the compilation script once more it seems :)

Edit: Could you also possibly link to the related "fixing it on the mingw side" patch? Would be nice to know just in case.

[kemuri-_9]

Edit: Could you also possibly link to the related "fixing it on the mingw side" patch? Would be nice to know just in case.

I received http://pastebin.com/sz0Gc4HE from Nicholi on the matter

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r23467 and libswscale SVN-r31314 (http://www.multiupload.com/SXF8B8VHCO)
ffms2 SVN-r312 (http://www.multiupload.com/DU5APARCNO)
x264 Builds:

x264_x64_r1629 (http://www.multiupload.com/0PFS2K388D)
x264_x86_r1629 (http://www.multiupload.com/5FLZW54876)
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
x264_x64_r1629M (http://www.multiupload.com/JQMTS68C32)
x264_x86_r1629M (http://www.multiupload.com/GHWP53LONW)
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
Patches:
x264_open-gop.22_r1629 (http://pastebin.com/t2Y0QYA8) <Trahald>

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r23486 and libswscale SVN-r31321 (http://www.multiupload.com/0AU1IH676Z)
ffms2 SVN-r312 (http://www.multiupload.com/80ZNKANZHE)
x264 Builds:

x264_x64_r1629M (http://www.multiupload.com/RWKMNCQ6SD)
x264_x86_r1629M (http://www.multiupload.com/A6JZVGTP73)
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
Patches:
x264_open-gop.26_r1629 (http://pastebin.com/iPZTiykn) <Trahald>

[aegisofrime]

Hi there. I have a question that I guess some will find really weird. But anyway...

I'm about to start an encode of a TempGaussMC'ed 1080i content. As one can imagine, the process will be slow. The last time I did this it took 2 weeks.

As such, I will like to ask if the x264 developers have any major quality or speed improvements in the pipeline soon, so I can hold off my encode until that release.

Thanks :)

[jpsdr]

Personnaly, i do all process before encoding, and save the result in a file with lossless codec (i use Lagarith in YV12 mode).
Like this, if you encode in multi-pass, you gain speed of not having all your pre-processing doing twice, and if there is a problem with the encode, and you need to do it again, at least your pre-processing is already done. This is the first thing to do to gain speed, i think.

[julius666]

I'm about to start an encode of a TempGaussMC'ed 1080i content. As one can imagine, the process will be slow. The last time I did this it took 2 weeks.


That's simply insane. :eek:
Are you sure that it's worth the effort? The + quality that TempGaussMC gives (over TDeint for example) is not "so huge", let alone in FullHD.
What's your source? What avisynth script do you using?

[Blue_MiSfit]

If you're going to TempGaussMC a 1080i source, for god's sake save it at crf 12 or some equally high bitrate mezzanine file. Don't let that HUGE amount of time to go to waste. Srsly.

Derek

[mp3dom]

Sorry to ask, is there a recent (1629) patched version based on the plain vanilla build + only the fade improvement patch?

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r23548 and libswscale SVN-r31351 (http://www.multiupload.com/4TQNG2JECT)
ffms2 SVN-r312 (http://www.multiupload.com/VDKSOX6M2Y)
x264 Builds:

x264_x64_r1643M (http://www.multiupload.com/FYPUE1NSNC)
x264_x86_r1643M (http://www.multiupload.com/7XE5S8YUR3)
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
Patches:
x264_sws_typecast (http://pastebin.com/EVSqTqAi)
x264.open_gop.28 (http://pastebin.com/suAVft2F)
x264_fade_compensation (http://pastebin.com/WGEapT1e)
x264_thread_pool_v2.9 (http://pastebin.com/9MMaKDER)

[mp3dom]

Thanks rack04!

[outlaw.78]

x264 0.98.1643M x86 & x64 (http://www.mediafire.com/?mmufji2y2nj)

gcc 4.5.1 20100523 prerelease
ffmpeg svn 23555
swscale svn 31357
ffms2 svn 312
pthreads 2.9.0.0 static
x264 0.98.1643M x86,x64,amdfam10,fprofiled
patches used :
x264_thread_pool_v2.9 (http://pastebin.com/9MMaKDER)

[RainyDog]

x264 0.98.1643M x86 & x64 (http://www.mediafire.com/?mmufji2y2nj)

gcc 4.5.1 20100523 prerelease
ffmpeg svn 23555
swscale svn 31357
ffms2 svn 312
pthreads 2.9.0.0 static
x264 0.98.1643M x86,x64,amdfam10,fprofiled
patches used :
x264_thread_pool_v2.9 (http://pastebin.com/9MMaKDER)

Thanks Outlaw, been waiting for one of your new amdfam builds :)

[tormento]

komisar: waiting for your build... braaaaiiinnn...

[outlaw.78]

x264 0.98.1649M x86 & x64 (http://www.mediafire.com/?xkluikx3jiu)


gcc 4.5.1 20100614 prerelease
ffmpeg svn 23619
swscale svn 31428
ffms2 svn 312
pthreads 2.9.0.0 static
x264 0.98.1649M amdfam10,fprofiled,LTO
patches used :
x264_thread_pool_v2.9 (http://komisar.gin.by/old/1643/p/x264_thread_pool_v2.9.r1643.diff)

[rack04]

I'm trying to compile the latest x264 with x264_open_gop_40. Each time make fprofiled finishes with one of the encodes I get a crash with debug screen. If I click debug the next encode runs. I'm wondering if anyone else has experienced this.

BTW, I'm using cross-mingw.gcc450.generic.20100612 (http://komisar.gin.by/mingw/cross-mingw.gcc450.generic.20100612.7z) without LTO.

[bnshrdr]

I just used the same compiler as you posted and with x264 patched and it seems to be working ok (I'm only about 5 encodes through in fprofile). I'm targeting x86_64-mingw32.

Would it matter what clip you use to fprofile? If it means anything, I'm using 720p5994_stockholm_ter.yuv

[komisar]

rack04, gcc 450 and 451 broked... :( dont use it (i am remove link from my site)

EDIT: but wait... 450 is normal compile... (recheck again...)

[rack04]

rack04, gcc 450 and 451 broked... :( dont use it (i am remove link from my site)

EDIT: but wait... 450 is normal compile... (recheck again...)

make fprofile i686-pc-mingw32? cross-mingw.gcc444.generic.20100506 works fine.

[bnshrdr]

Ok, I can confirm your error when targeting i686-pc-mingw32, but the fprofile seems to be fine when targeting x86_64-pc-mingw32

[komisar]

rack04, no... for 32-bit gcc450 also broked...

As BugMaster investigate this problem: "found that gcc can produce code with missaligned SSE (MOVAPS) access when -fprofile-generate used"
Need rebuild toolchain with "-fno-tree-vectorize" (as DS say)

EDIT: or wait gcc451 release ;)

[bnshrdr]

DOWNLOAD: x264_r1649 (http://www.mediafire.com/download.php?finamqymnzw)

Builds Included:
x86 Generic
x86 Patched (patch listed below)
x86_64 Generic
x86_64 Patched (patch listed below)

Libraries:
gcc 4.4.4
zlib-1.2.3
bzip2-1.0.5
pthreads 2.9.0.0 GC-static
ffmpeg-svn: FFMPEG-r23763/SWSCALE-r31555
yasm-svn: YASM-r2334
ffmpegsource-svn: ffmpegsource-r312
gpac-cvs: gpac-0.4.6-DEV

Patches:
ffmpeg_patch (http://pastebin.com/WbVwYT0z)
applied with patch -p0 -i ffmpeg_patch.patch
x264_thread_pool_v2.9_updated (http://pastebin.com/gANSYv4i)
applied with patch -p0 -i x264_thread_pool_v2.9_updated.patch

[lexor]

@bnshrdr: is that x264_thread_pool patch something different from the thread pool incorporated into the official git repository? I know there was a thread pool patch before git had thread pool support, but now that git has it, why is there still a patch for it?

[sneaker_ger]

bnshrdr's build is revision 1649 which didn't have the commit. The newest version is 1659.

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
x264 Builds:

x264_x64_r1659 (http://www.multiupload.com/H1IYWFR5WM)
x264_x86_r1659 (http://www.multiupload.com/4BYZMQV7UI)
System: MINGW
asm: yes
avs input: yes
lavf input: no
ffms input: no
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

[lexor]

bnshrdr's build is revision 1649 which didn't have the commit. The newest version is 1659.

Is there a way to get revision # from git's web ui? I usually check http://git.videolan.org/?p=x264.git;a=shortlog, but it's hard to tell who's builds have which submissions in them, atm.

[Chikuzen]

Is there a way to get revision # from git's web ui?

I always look x264.nl's changelog.
http://mirror01.x264.nl/x264/changelog.txt

[LoRd_MuldeR]

Is there a way to get revision # from git's web ui?

I wrote this simple tool for that purpose:
http://mulder.googlecode.com/svn/trunk/libx264/git2rev.exe

Usage:
git log > changelog.txt
git2rev changelog.txt

[outlaw.78]

x264 0.100.1659 x86 & x64 (http://www.mediafire.com/?yi3dmkmqniw)

gcc 4.5.1 20100623 prerelease
ffmpeg svn 23787
swscale svn 31559
ffms2 svn 312
pthreads 2.9.0.0 static
x264 0.100.1659 amdfam10,fprofiled,LTO

[qyot27]

I wrote this simple tool for that purpose:
http://mulder.googlecode.com/svn/trunk/libx264/git2rev.exe

Usage:
git log > changelog.txt
git2rev changelog.txt
Awesome, I've been needing a tool like this. How portable is it? It'd be nice to use it under Linux or OSX, too.

Testing on ffmpeg's changelog resulted in a ~200 revision disparity, though (SVN reports r23791, git2rev reports r23587). Is that on their end with the SVN/git syncing process, or do you think something else is going on?

[JEEB]

Awesome, I've been needing a tool like this. How portable is it? It'd be nice to use it under Linux or OSX, too.

git rev-list HEAD | wc -l | sed -e 's/^ *//' > revision.txt

Testing on ffmpeg's changelog resulted in a ~200 revision disparity, though (SVN reports r23791, git2rev reports r23587). Is that on their end with the SVN/git syncing process, or do you think something else is going on?

I would guess this is because of libswscale being in the same repo on the SVN side.

[LoRd_MuldeR]

Awesome, I've been needing a tool like this. How portable is it? It'd be nice to use it under Linux or OSX, too.?

It's written in Delphi, so no native Linux or Mac binary. But I guess the Win32 binary would work under Wine/Linux too.

Anyway, it's really nothing special! I hacked that together in three minutes. You could probably do the same with a few lines of Shell/Python/Perl script :p

[mgb]

Are there any sources of x264 built as a shared library for windows?

I need to write a video stream as x264, the vfw is too slow and IU haven't had any luck trying to build it.

[LoRd_MuldeR]

Are there any sources of x264 built as a shared library for windows?

I need to write a video stream as x264, the vfw is too slow and IU haven't had any luck trying to build it.

http://forum.doom9.org/showthread.php?p=1412089#post1412089 :p

[mgb]

http://forum.doom9.org/showthread.php?p=1412089#post1412089 :p
Excellent thanks, now I just have to go through the Avidemux source to work out how to use it!

I need to record 1080p @ 60fps so the alternative is a $1000 hardware H264 capture board or a very big raid system.

Thanks again
Martin

ps. Unless there is a way of using the x264 command line client to read raw YUV from a pipe?

[LoRd_MuldeR]

Excellent thanks, now I just have to go through the Avidemux source to work out how to use it!

No need for that. All you need is the interface defined in "x264.h".

Applications using x264 as a library don't need to know anything but the functions/types defined in that file ;)

But make sure you use a "x264.h" that matches the DLL version. Currently 97 for my DLL's.

Anyway, you can have a look here (mainly the "encoder.cpp" will be interesting) for an usage example:
http://svn.berlios.de/wsvn/avidemux/branches/avidemux_2.5_branch_gruntster/plugins/ADM_videoEncoder/ADM_vidEnc_x264/#_branches_avidemux_2.5_branch_gruntster_plugins_ADM_videoEncoder_ADM_vidEnc_x264_


ps. Unless there is a way of using the x264 command line client to read raw YUV from a pipe?

This works for sure ;)

your_app.exe | x264.exe --demuxer yuv [more options] - 720x576


I need to record 1080p @ 60fps so the alternative is a $1000 hardware H264 capture board or a very big raid system.

1080p @ 60 fps will be though! I guess you want to use "--preset superfast" or even "--preset ultrafast" for that purpose ;)

[mgb]

No need for that. All you need is the interface defined in "x264.h".
I understand that there are one or two options to set in H264 ;-)

1080p @ 60 fps will be though! I guess you want to use "--preset superfast" or even "--preset ultrafast" for that purpose ;)
That's what I was trying with the vfw build but I was only getting 6-7fps.
It may have been either a disk I/O bottleneck or a threading issue - it was only using 15% CPU on a 8 core machine

[LoRd_MuldeR]

Testing on ffmpeg's changelog resulted in a ~200 revision disparity, though (SVN reports r23791, git2rev reports r23587). Is that on their end with the SVN/git syncing process, or do you think something else is going on?

Well, I simply grab the log from git via "git log > file.txt" and then I walk through all lines (in reverse direction) counting the lines that start with a "commit" keyword.

This is a very simple approach and it works fine for the x264 log. No idea what is going on with the FFmpeg log. Maybe they have branches and other fancy stuff that I don't handle at all...

[LoRd_MuldeR]

That's what I was trying with the vfw build but I was only getting 6-7fps.
It may have been either a disk I/O bottleneck or a threading issue - it was only using 15% CPU on a 8 core machine

I get something like ~10 fps for 1080p footage (source is a HuffYUV AVI from HDD) with "--preset ultrafast --crf 22" on my Core2 Q6600.

CPU usage is around 33% for this scenario...

EDIT: Actually for this scenario the "veryfast" preset doesn't seem to be noticeably slower on my system, but causes ~55% CPU usage.

[J_Darnley]

Testing on ffmpeg's changelog resulted in a ~200 revision disparity, though (SVN reports r23791, git2rev reports r23587). Is that on their end with the SVN/git syncing process, or do you think something else is going on?

ffmpeg's git doesn't track this "release" business they're doing.

[LoRd_MuldeR]

I get something like ~10 fps for 1080p footage (source is a HuffYUV AVI from HDD) with "--preset ultrafast --crf 22" on my Core2 Q6600.

CPU usage is around 33% for this scenario...

EDIT: Actually for this scenario the "veryfast" preset doesn't seem to be noticeably slower on my system, but causes ~55% CPU usage.

I need to correct myself: The source turned out to be FFV1, not HuffYUV :o

This time I used a real HuffYUV 1080p source and I got ~22 fps with "--preset ultrafast --crf 22" for 1080p :cool:

[qyot27]

It's written in Delphi, so no native Linux or Mac binary. But I guess the Win32 binary would work under Wine/Linux too.

Anyway, it's really nothing special! I hacked that together in three minutes. You could probably do the same with a few lines of Shell/Python/Perl script :p
Yeah, Wine is always an option, I simply prefer to use Wine as a last resort (I was wrangling with it yesterday night trying to get Sherpya's mencoder build to correctly interpret Kanji in ASS subtitles; I have RVM's native build from SMPlayer's PPA working fine for that, but getting Sherpya's build to work was for the benefit of another system where I don't have that luxury).

git rev-list HEAD | wc -l | sed -e 's/^ *//' > revision.txt
Thanks. I knew that there was probably a way to do it with git and some of the query tools *nix systems usually come with, but said tools' usage generally goes right over my head.

I would guess this is because of libswscale being in the same repo on the SVN side.
I suspected as much, although running the rev-list command above on just libswscale prints out a revision number in the 1000s. I guess it's not a case of simple addition.

Doesn't matter as much for ffmpeg, though - I would only need it for some of the forks that lack an SVN repo to pull from (specifically the Lagarith decoder and Ordered Chapters branches hosted on repo.or.cz (http://repo.or.cz/w/FFMpeg-mirror.git/forks)), and I don't mess with them all too often, or I just do a regular merge with the main project, so it wouldn't really matter, knowing what the main branch's revision number is at.


In any case, this means I can [easily] use the revision number for x264 when I pack up tarballs rather than needing to compile it first to find out what the number is, or my usual solution of just using the date I cloned it instead.

ffmpeg's git doesn't track this "release" business they're doing.
'Release'? Do you mean the 0.5.2 or 0.6 packages? I ignore those completely.

[J_Darnley]

'Release'? Do you mean the 0.5.2 or 0.6 packages? I ignore those completely.

Yes, they are branches in the svn tree. A commit to one of these will have a revision number which is not known by git. Try subversion rev 23747, you won't find it in the git log.

[qyot27]

Yes, they are branches in the svn tree. A commit to one of these will have a revision number which is not known by git. Try subversion rev 23747, you won't find it in the git log.
I fully admit I might be misunderstanding this, but it seems like it is in there, though:
http://git.ffmpeg.org/?p=ffmpeg;a=commit;h=ebc0bc8eba20291fe45b0916020a4e2062c13464

Committed 5 days ago, although the SVN commit was logged to yesterday.

[Maccara]

Yes, they are branches in the svn tree. A commit to one of these will have a revision number which is not known by git. Try subversion rev 23747, you won't find it in the git log.

Why don't they track the branches in the mirror? It's trivial. (or do they? didn't check, as I did my own mirror long ago when I had trouble with the "official" mirror)

Shows just fine in mine:

$ git show 5aa73351e66
commit 5aa73351e66c88a0b5c1d0baa9cf9e801bacd5bf
Author: siretart <siretart@9553f0bf-9b14-0410-a0b8-cfaf0461ba5b>
Date: Thu Jun 24 05:46:58 2010 +0000

10l: aacsbr: Fix f_master[2] calculation when k2diff == -1.



backport r23660 by alexc


git-svn-id: svn://svn.ffmpeg.org/ffmpeg/branches/0.6@23747 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

diff --git a/libavcodec/aacsbr.c b/libavcodec/aacsbr.c
index 0de81a5..0de89c2 100644
--- a/libavcodec/aacsbr.c
+++ b/libavcodec/aacsbr.c
@@ -402,7 +402,7 @@ static int sbr_make_f_master(AACContext *ac, SpectralBandReplication *sbr,
k2diff = sbr->k[2] - sbr->k[0] - sbr->n_master * dk;
if (k2diff < 0) {
sbr->f_master[1]--;
- sbr->f_master[2]-= (k2diff < 1);
+ sbr->f_master[2]-= (k2diff < -1);
} else if (k2diff) {
sbr->f_master[sbr->n_master]++;
}

[J_Darnley]

The branches are not tracked on git.ffmpeg.org. If they were everyone should be able to find this commit twice over

[Maccara]

The branches are not tracked on git.ffmpeg.org.

Apparently so. I just wonder, why not...

[B.F.]

Any rev. 1659 with fade compensation patch?

[MatLz]

Any rev. 1659 with fade compensation patch?

There is one here (http://vfrmaniac.fushizen.eu/x264/x264_DANGEROUS/1600-1699/)
Other good things in bonus like fgo, mixaq...

[rack04]

Is it true that mingw has to be patched to compile the latest ffmpeg? From what I've read stdio.h and string.h must be patched.

[bnshrdr]

Is it true that mingw has to be patched to compile the latest ffmpeg? From what I've read stdio.h and string.h must be patched.
What version of mingw are you using?

Currently I'm using komisar's 4.4.4 build (4.5.0 had some i686 problems) and I'm not having any problems building ffmpeg, despite the small patch needed in libswscale/swscale_template.c

What kinds of errors/warnings are you running into?

[Underground78]

There is one here (http://vfrmaniac.fushizen.eu/x264/x264_DANGEROUS/1600-1699/)
Other good things in bonus like fgo, mixaq...

Can any of the patches used in this build become part of main tree one day ?

[rack04]

What version of mingw are you using?

Currently I'm using komisar's 4.4.4 build (4.5.0 had some i686 problems) and I'm not having any problems building ffmpeg, despite the small patch needed in libswscale/swscale_template.c

What kinds of errors/warnings are you running into?

I am using komisar's 4.4.4 build and I get the following error:

libavfilter/parseutils.c: In function 'color_table_compare'"
libavfilter/parseutils.c:217: error: implicit declaration of function 'strcasecmp'
make: *** [libavfilter/parseutils.o] Error 1

[komisar]

rack04

workaround-1: from general.texi in ffmpeg:FFmpeg cannot be compiled because of broken system headers, add
@code{--extra-cflags=-U__STRICT_ANSI__} to the configure options as aworkaround.

workaround-2: use "--disable-filters" in configure options for ffmpeg

information about this bug: http://permalink.gmane.org/gmane.comp.gnu.mingw.announce/2815

[bnshrdr]

Thanks komisar. I kept seeing that #ifndef __STRICT_ANSI__ in the header files and knew there had to be a way to feed it to gcc.

[kemuri-_9]

__STRICT_ANSI__ is defined automatically by -std=c99
which is what ffmpeg uses for some reason unbeknownst to me.
it should realistically use -std=gnu99 instead

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r23925 and libswscale SVN-r31591 (http://www.multiupload.com/RHKW6F9CM1)
ffms2 SVN-r314 (http://www.multiupload.com/OXSZWS0CXD)
x264 Builds:

x264_x64_r1659M (http://www.multiupload.com/MEXR8EO7J4)
x264_x86_r1659M (http://www.multiupload.com/E1J731O9LH)
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
Patches:
x264_sws_typecast (http://pastebin.com/nzYGvT9S)
x264_demuxer_threads (http://pastebin.com/qWkMKqbg)
x264_fade_compensation (http://pastebin.com/BBwB72Az)
x264_open_gop_bluray (http://pastebin.com/TvhtWhTu)

[lexor]

I'm curious, why does sws_typecast patch still exists as just a patch? It's been included in builds for so long. It seems so simple, why not just commit it? Do developers see it as just another annoyance of GCC not for x264 to dignify with a fix?

Similar question for demuxer_threads... though I don't recall when if first appeared, so maybe it's still unproven or not universally better/faster?

[kemuri-_9]

I'm curious, why does sws_typecast patch still exists as just a patch? It's been included in builds for so long. It seems so simple, why not just commit it? Do developers see it as just another annoyance of GCC not for x264 to dignify with a fix?

A) the patch is purely cosmetic to avoid a warning when compiling x264 with lavf and/or ffms support
B) the issue is also fixed with the filtering patch.

Similar question for demuxer_threads... though I don't recall when if first appeared, so maybe it's still unproven or not universally better/faster?

I vaguely remember something along the lines of pengvado saying not all of the threading done in ffmpeg's decoders is stable.

[Blue_MiSfit]

Yes, from what I recall threads in ffmpeg is somewhat unstable with some codecs.

[bin_ch]

B) the issue is also fixed with the filtering patch.


Speaking of the filtering patch, any news on it?
Thanks.

[kemuri-_9]

Speaking of the filtering patch, any news on it?
Thanks.

Dark_Shikari is cracking the whip on me to get it committed before the first phase of the audio filtering/encoding patch.
the latter will try and get committed at GSOC midterms, which i heard is the 12th of july.

[D3C0D3R]

can someone tell how new 9,10 bit depths patch affect compression, or better post x264 compiled with --bit-depth 10
as i understand it sets on compile stage and on x264.nl lies 8-bit version
166 page and 1666 :devil: revision change ))

[kemuri-_9]

can someone tell how new 9,10 bit depths patch affect compression, or better post x264 compiled with --bit-depth 10
as i understand it sets on compile stage and on x264.nl lies 8-bit version
166 page and 1666 revision change ))

configuring with bit-depth 9 or 10 will cause x264 to output video with that bit depth, which will require the use of the High10 profile (outside of lossless)
naturally this will cause the generated videos to take slightly more space....

at the moment there isn't much of a practical use for it as
A) there's practically no asm for high bit depth mode (so it runs REALLY slow)
B) x264 still only accepts input that has a bit-depth of 8.
C) no free/popular decoder outside of JM seems to even decode High10 correctly - only some 'pro' ones do it seems

all of these issues will eventually need be fixed to have it be more practical for use,
the first 2 are already planned/in works for x264 but the 3rd is something outside of x264's hands.
and then it'll be primarily only useful for videos where the input is >8 bit depth

[D3C0D3R]

naturally this will cause the generated videos to take slightly more space....
hm, but quality is rises? extra precision never hurts.
A) there's practically no asm for high bit depth mode (so it runs REALLY slow)
i didnt scared sLOW speed, perhaps like many people on this forum i use placebo options ))
B) x264 still only accepts input that has a bit-depth of 8.
i understand that and interesting how 10 bit precision can help to improve 8-bit quality e.g. dealing with banding effect

[julius666]

naturally this will cause the generated videos to take slightly more space....

If I remember correctly, DS said that 10 bit would give ~10-15% quality gain against 8 bit, at the same bitrate (I don't know the exact reason, maybe because less dithering is needed).

[lexor]

If I remember correctly, DS said that 10 bit would give ~10-15% quality gain against 8 bit, at the same bitrate (I don't know the exact reason, maybe because less dithering is needed).

He didn't qualify this statement though. Is it ~10% increase with 8bit source and 10bit output or do you need high bit source too? If the latter, then we are screwed, because all the common sources we get are 8bit.

[MasterNobody]

If judge by SSIM/PSNR than higher bit depth give higher quality on the same bitrate for 8-bit sources also.

[julius666]

Is it ~10% increase with 8bit source and 10bit output or do you need high bit source too? If the latter, then we are screwed, because all the common sources we get are 8bit.

I'm pretty sure that the former. His statement doesn't make sense otherwise.

A question: 10 bit colourspace isn't compatible with DXVA, am I right?

[LoRd_MuldeR]

A question: 10 bit colourspace isn't compatible with DXVA, am I right?

I doubt DXVA does handle the "High 10" profile of H.264...

[JEEB]

A question: 10 bit colourspace isn't compatible with DXVA, am I right?

Basically agreeing with LoRd_MuldeR here.

I would say that you'd be pressed to find decoders for 10bit H.264 at the moment, software and hardware-wise. DXVA and CoreAVC should be out for sure, as well as other GPU-based solutions ('out' as in 'out of the question').

"Some professional decoders" seem to be capable of decoding the given material, as far as I've heard. But given that we still can't input 10bit into x264 itself, I'm not exactly pressed to see what those are at the moment.

[lexor]

"Some professional decoders" seem to be capable of decoding the given material, as far as I've heard. But given that we still can't input 10bit into x264 itself, I'm not exactly pressed to see what those are at the moment.

Well, if it's true that we get a noticeable quality improvement even with 8bit source, I think we should all be interested in those rare decoders that can play it. In particular I am hoping higher bit depth will help with the banding (to smooth out gradients).

On a related note, what's the purpose of 9bit? Is it just to offer another performance grade for those who want better quality but can't wait for 10bit encoding? Seems an odd (literally) number, I mean I've seen 8, 10, and 12 bit video sources, but I've never heard of anything working in 9bits.

Speaking of which, why isn't there a 12 bit mode, since some pro-apps do output it (in their RAWish/uncompressed intermediate formats of choice, not h264)? Seems like it would be a perfect fit for x264 lossless to slide in there.

[mp3dom]

10bit could be useful for professional use (mainly if you capture in h264 rather than uncompressed yuv, but probably the decoding cycle of h264 will be larger without an hardware decoder). If you've a 8bit source, converting to 10bit is totally useless unless you need to do color correction or other similar things. Higher bit depth will preserve smooth gradients IF the source have smooth gradients. If you have already color banding, converting to 10bit will keep all the color banding (also avisynth is 8bit only so all its filters works in 8bit). If you can hide/mask/fix color banding with avisynth then you can save it in lossless h264.
Actually it's not so useful to have a 10bit output if the source needs to be 8bit, anyway this could be a lot useful in future when x264 could support 10bit as input, or it could be VERY useful if it could dither a 10bit source to an 8bit output (IMHO the most useful option)

[Blue_MiSfit]

Yes, very!!

I would love to see 10 bit input support, possibly with an option to dither down to 8 bit as well.

Derek

[masterkivat]

Since JEEB system hanged out (http://x264.fushizen.eu/?p=206), can someone build the new evil build :devil: with fade_compensation .diff?
Thanks in advance :thanks:

[rack04]

Since JEEB system hanged out (http://x264.fushizen.eu/?p=206), can someone build the new evil build :devil: with fade_compensation .diff?
Thanks in advance :thanks:

Explain evil build.

[Midzuki]

Explain evil build.

r1666 :devil:

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r24064 and libswscale SVN-r31639 (http://www.multiupload.com/FYKG5OL4OM)
ffms2 SVN-r317 (http://www.multiupload.com/LZMNP9BUB3)
x264 Builds:

x264_x64_r1666M (http://www.multiupload.com/CGB3AA0T60)
x264_x86_r1666M (http://www.multiupload.com/A5B34AL9QM)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_sws_typecast (http://pastebin.com/6TjQAKV3)
x264_fade_compensation (http://pastebin.com/2L1PCDLx)

[D3C0D3R]

as i know divx d3c0d3r support High10 so can someone build 10bit :devil: build ?

2 komisar - your crazy devil x264vfw build sets mb-tree=0 when use Command line option is off.

[julius666]

If you've a 8bit source, converting to 10bit is totally useless unless you need to do color correction or other similar things. Higher bit depth will preserve smooth gradients IF the source have smooth gradients. If you have already color banding, converting to 10bit will keep all the color banding (also avisynth is 8bit only so all its filters works in 8bit)

If the 8 bit source has banding, than the 10 bit output will obviously have it too. But if your source is dithered, than x264 will chop down the dither (especially at lower bitrates) and create banding. With more precision the banding could be less visible in this case.

[komisar]

D3C0D3R, yes... mb_tree=0 because [warning]: lookaheadless mb-tree requires intra refresh (http://sourceforge.net/projects/x264vfw/forums/forum/770225/topic/3759827)
if you known what you do -- add needed options to "Extra options:"-box...

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r24069 and libswscale SVN-r31642 (http://www.multiupload.com/CHBOA7QFO8)
ffms2 SVN-r317 (http://www.multiupload.com/T24S6H1PPG)
x264 Builds:

x264_x64_r1666M_8bit (http://www.multiupload.com/LAXU555UTY)
x264_x86_r1666M_8bit (http://www.multiupload.com/VU3TNW6ZNA)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
x264_x64_r1666M_9bit (http://www.multiupload.com/7JYVOJ3E92)
x264_x86_r1666M_9bit (http://www.multiupload.com/08H0VT58B1)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 9
x264_x64_r1666M_10bit (http://www.multiupload.com/HX4MVQA8C0)
x264_x86_r1666M_10bit (http://www.multiupload.com/660A5UNRH1)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 10
Patches:
x264_sws_typecast (http://pastebin.com/6TjQAKV3)
x264_fade_compensation (http://pastebin.com/2L1PCDLx)

[D3C0D3R]

2 rack04 thank you for 9,10 bit builds and off course BIG Respect to Oskar, who developed this patch.

2 komisar - i always place in extra textbox something like "--rc-lookahead 120" and had in 1659 mb-tree=1, but in 1666 i didnt see any warnings and mb-tree=0 :(
AFAIK this is no other way to turn on MB-Tree only to off it ))

[komisar]

D3C0D3R
http://forum.doom9.org/showthread.php?p=1414971#post1414971

[D3C0D3R]

2 komisar thanx 4 help - works

high 10: first impressions & quick tests 8,9,10 bits
http://forum.doom9.org/showthread.php?p=1415028#post1415028

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r24248 and libswscale SVN-r31736 (http://www.mediafire.com/?kmwjmngj5yymgth)
ffms2 SVN-r318 (http://www.mediafire.com/?xlkzytwj1zjfznh)
x264 Builds:

x264_x64_r1675M (http://www.mediafire.com/?nzazgxz2jmmhwnm)
x264_x86_r1675M (http://www.mediafire.com/?yzjyztdmzmjmd2n)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
filters: resize crop select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/Sp5bLbhJ)

[Audionut]

Hi rack04,

Your 64bit build crashes when using --vf

32bit build is working fine.

[rack04]

Hi rack04,

Your 64bit build crashes when using --vf

32bit build is working fine.

What is your command line?

EDIT: This works for me. Windows 7 64bit Ultimate.

"C:\Program Files\x264\x264.exe" --preset veryslow --tune film --crf 18 --force-cfr --vf resize:1280,528,1:1 --aud --output "E:\Work\110902669-output.264" "E:\Work\110902669.mov"

BTW: Here is a new build.

x264_x64_r1677 (http://mfi.re/?itwkgmonrnnwz2m)

[Soichiro]

I have discovered that the current build of avs4x264 and vfw4x264 broke with the filtering patch (r1672). As such, I have created a fixed version for anyone using either of these for piping to 64-bit x264.

Updated vfw4x264+avs4x264 w/ source (http://www.megaupload.com/?d=NDPO6W7G)

[Audionut]

A simple sucker like this is enough,

--vf resize:640,272 -o f:\output.264 f:\input.avi

Crashes with the new build also.
On win7 64 ultimate

[rack04]

A simple sucker like this is enough,

--vf resize:640,272 -o f:\output.264 f:\input.avi

Crashes with the new build also.
On win7 64 ultimate

Any error message?

[Soichiro]

A simple sucker like this is enough,

--vf resize:640,272 -o f:\output.264 f:\input.avi

Crashes with the new build also.
On win7 64 ultimate

rack04, I can confirm that this crashes on your build (at the very beginning of the encode), although it runs fine on my personal build.

Windows (7 Ultimate x64) just pops up with a dialog message saying "x264_64.exe has crashed, what do you wanna do about it?"

[Audionut]

Yup, what ^^^^ he said.

rack04, are you on x264 irc to make debugging faster.

[rack04]

rack04, I can confirm that this crashes on your build (at the very beginning of the encode), although it runs fine on my personal build.

Windows (7 Ultimate x64) just pops up with a dialog message saying "x264_64.exe has crashed, what do you wanna do about it?"

I don't know what to say. It works with the .mov that I have handy.

[Audionut]

Tried on mkv and avs source. Same problem.

[komisar]

problem in libswscale... win64 is bad friend for ffmpeg&co :(

[JEEB]

problem in libswscale... win64 is bad friend for ffmpeg&co :(
At least Dark_Shikari has shown interest in giving a try to fix it as soon as a real backtrace is gotten with other ffmpeg devs. Although yes, as win64 is not officially supported, a bug report would most probably otherwise be brushed off as "lol win64".

[Selur]

anyone building current 9/10bit builds for win32bit? (rack04?)

[rack04]

Currently I'm not on a 64bit machine. Once I get get off work I will attempt to provide a useful gdb backtrace. For those who may want to help please refer to the following links for debug builds.

x264_x64_r1677_debug (http://www.mediafire.com/?ysi24vmd5c83n1y)

[rack04]

A simple sucker like this is enough,

--vf resize:640,272 -o f:\output.264 f:\input.avi

Crashes with the new build also.
On win7 64 ultimate

Try this (http://www.mediafire.com/?j27p724jlj3puu4) build.

[Audionut]

Try this (http://www.mediafire.com/?j27p724jlj3puu4) build.

That works. Thanks.

Can you patch that with fade-compensate.

[RedDwarf1]

Why do recent builds, since mb-tree was introduced it might of been, produce files with an incorrect number of reference frames?

General
Complete name : L:\VIDEO_TS\test2.mkv
Format : Matroska
File size : 5.68 MiB
Duration : 40s 40ms
Overall bit rate : 1 190 Kbps
Writing application : x264 r1649 c54c47d
Writing library : Haali Matroska Writer b0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Muxing mode : Container profile=Unknown@3.1
Codec ID : V_MPEG4/ISO/AVC
Duration : 40s 40ms
Bit rate : 1 167 Kbps
Nominal bit rate : 1 149 Kbps
Width : 704 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Resolution : 8 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.115
Stream size : 5.57 MiB (98%)
Writing library : x264 core 98 r1649 c54c47d
Encoding settings : cabac=1 / ref=5 / deblock=1:-1:-1 / analyse=0x3:0x113 / me=umh / subme=7 / psy=1 / psy_rd=1.00:0.20 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=1149 / ratetol=4.0 / qcomp=0.50 / qpmin=10 / qpmax=51 / qpstep=8 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.20

And before you start claiming that MediaInfo is incorrectly reporting the number of reference frames, AVInaptic also shows an incorrect number of reference frames, there being one less than was used to encode.

So why are both these programs showing lower numbers of reference frames than the number set when encoding?

[Trahald]

It's due to bpyramid. 'Normal' manages the flow of the dpb and makes sure there is one space for nonreference frames (when needed). Normal mode designates dpbslots and ref numbers as the same since it's smarter then strict and if possible uses the last dpb space for reference frames. Bpyramid strict 'always' leaves one spot open for one nonreference frame so ref is set to one less dpbsize. Normal is more efficient so unless you are doing bluray, use normal mode.

[rack04]

That works. Thanks.

Can you patch that with fade-compensate.

I'll post something later today.

[Audionut]

Sweet, thankyou sir.

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r24287 and libswscale SVN-r31748 (http://www.mediafire.com/?yt5i6uoalxeg4p4)
ffms2 SVN-r318 (http://www.mediafire.com/?4f5p6s6fbllfy3k)
x264 Builds:

x264_x64_r1677M (http://www.mediafire.com/?6qwhe8e513cqzjo)
x264_x86_r1677M (http://www.mediafire.com/?0vnny5ubtop37fg)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
filters: resize crop select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/5Xnfraqd)

[RedDwarf1]

It's due to bpyramid. 'Normal' manages the flow of the dpb and makes sure there is one space for nonreference frames (when needed). Normal mode designates dpbslots and ref numbers as the same since it's smarter then strict and if possible uses the last dpb space for reference frames. Bpyramid strict 'always' leaves one spot open for one nonreference frame so ref is set to one less dpbsize. Normal is more efficient so unless you are doing bluray, use normal mode.

Thank you for the explanation. A test has just confirmed it when using Normal, the reported ref frames is as was set in the encoding options.

The reason why I used strict was because I wanted improved quality while trying to retain hardware compatibility for hardware media player playback. I have been researching different media players using chipsets such as those made by Realtek and Sigma Designs because I wanted to purchase one. I don't want to get one and find it won't playback my already/recently encoded files.

[Dark Shikari]

Thank you for the explanation. A test has just confirmed it when using Normal, the reported ref frames is as was set in the encoding options.

The reason why I used strict was because I wanted improved quality while trying to retain hardware compatibility for hardware media player playback. I have been researching different media players using chipsets such as those made by Realtek and Sigma Designs because I wanted to purchase one. I don't want to get one and find it won't playback my already/recently encoded files.Strict does not improve hardware compatibility, it just improves compatibility with the Blu-ray spec.

[burfadel]

It seems pretty common that for animation, or sources where there are lines that separate too flat surfaces, for people to raise the deblocking to 1:1

I know the deblocking filter is already automated somewhat and that adjusts the bias, my question relates to the deblocking in certain scenarios like that above. Is it possible for x264 to increase the strength and threshold of deblocking up to say 1:1 (or part thereof), when transitions between different flat surfaces is detected, such as in animation? This would be more beneficial for lower res animation, say 512x384 or 640x352. At higher resolutions the bias to be automatic scaled, such that at 720x576 it would be more like (for example) 0.6:0.6.

For high resolution images, have this scaled back to the point where there is a high resolution image the deblocking is at the default. I think this would be very beneficial if possible. The deblocking bias should only be applied to the relatively flat surfaces/shaded surfaces and the transitions between such surfaces, and not to higher detailed parts of the picture. Of course, the deblocking can still be changed for peoples preference.

Probably a stupid idea, but I'm guessing I'm not the only one that has thought of it...

[Dark Shikari]

It seems pretty common that for animation, or sources where there are lines that separate too flat surfaces, for people to raise the deblocking to 1:1

I know the deblocking filter is already automated somewhat and that adjusts the bias, my question relates to the deblocking in certain scenarios like that above. Is it possible for x264 to increase the strength and threshold of deblocking up to say 1:1 (or part thereof), when transitions between different flat surfaces is detected, such as in animation? This would be more beneficial for lower res animation, say 512x384 or 640x352. At higher resolutions the bias to be automatic scaled, such that at 720x576 it would be more like (for example) 0.6:0.6.

For high resolution images, have this scaled back to the point where there is a high resolution image the deblocking is at the default. I think this would be very beneficial if possible. The deblocking bias should only be applied to the relatively flat surfaces/shaded surfaces and the transitions between such surfaces, and not to higher detailed parts of the picture. Of course, the deblocking can still be changed for peoples preference.

Probably a stupid idea, but I'm guessing I'm not the only one that has thought of it...Deblocking can only be set per-slice. Trying to add enough slices to cover objects efficiently would hurt compression quite a bit.

[burfadel]

Ah ok! that explains it :)! I knew there would have to be a simple reason why its not done automatically!

How about using something like me-prepass to determine whether the consecutive frames are animation or film, and adjust deblocking based on that?

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6-DEV
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r24352 and libswscale SVN-r31758 (http://www.mediafire.com/?4d7gcu8gt74ppyi)
ffms2 SVN-r320 (http://www.mediafire.com/?d1wark634cg0yod)
x264 Builds:

x264_x64_r1680M (http://www.mediafire.com/?qb609r42rc2q52i)
x264_x86_r1680M (http://www.mediafire.com/?dgk2400dxtxw8l8)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (LINK)

[ckmox]

anyone help please im getting this error

ffms [error]: could not create index
lavf [error]: could not open input file
raw [error]: raw input requires a resolution.
x264 [error]: could not open input file `o.mkv' via any method!


my commandline
x264 --preset slow --tune animation --crf 27 --vf resize:704,400 -o "i.mkv" "o.mkv"

im on Windows XP SP3 32-bit

[nm]

my commandline
x264 --preset slow --tune animation --crf 27 --vf resize:704,400 -o "i.mkv" "o.mkv"

Looks like you have i.mkv and o.mkv reversed in that command line, if i=input and o=output.

[ckmox]

Looks like you have i.mkv and o.mkv reversed in that command line, if i=input and o=output.

haha ye thats it silly me thanks a lot

[Snowknight26]

And hopefully it doesn't really say
x264 [error]: could not open input file `o.mkv' via any method!
Who uses grave accents in place of apostrophes?

[Midzuki]

And hopefully it doesn't really say
x264 [error]: could not open input file `o.mkv' via any method!
Who uses grave accents in place of apostrophes?

Looks like a "bad habit" that was born in the "7-bit age". :)

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r24429 and libswscale SVN-r31767 (http://www.mediafire.com/?rdj7obkdvmtdo3i)
ffms2 SVN-r320 (http://www.mediafire.com/?99072bq150nnmk1)
x264 Builds:

x264_x64_r1683M (http://www.mediafire.com/?ah46kc955lckb3w)
x264_x86_r1683M (http://www.mediafire.com/?er1hcnlyabg8tlk)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/4tB1dw26)

[JEEB]

x264 r1683 64bit unpatched:
download (http://x264.fushizen.eu/files/revision1683/x264.exe) ; hash (http://x264.fushizen.eu/files/revision1683/x264.md5)

built on Jul 22 2010, gcc: 4.4.4 (x86_64.generic.Komisar)
fprofiled, 8bit

________________________________________________________________________________

x264 r1683 32bit
download (http://x264.fushizen.eu/files/1683/x264_1683_32.7z)

built on Jul 22 2010, gcc: 4.4.4 (x86.generic.Komisar)
fprofiled, 8bit


x264 r1683 64bit
download (http://x264.fushizen.eu/files/1683_64/x264_1683_64.7z)

built on Jul 22 2010, gcc: 4.4.4 (x86_64.generic.Komisar)
fprofiled, 8bit


patched with:

mp4muxer.diff (http://vfrmaniac.fushizen.eu/OtherStuff/L-SMASH/mp4muxer.diff)
x264_fade_compensation_1629.patch (http://x264.fushizen.eu/patches/x264_fade_compensation_1629.patch)
x264_film_grain_optimization_1680.patch (http://x264.fushizen.eu/patches/x264_film_grain_optimization_1680.patch)


After sorting out the problems with my encoding environment, here's something newer. After talking about FGO (http://x264dev.multimedia.cx/?p=25) with VFR Maniac, I decided to take it in. Currently using --psy-rd 0.8:0.4 --fgo 2 and got pretty good results.

[Soichiro]

I don't get it. I thought the whole point of Psy-RD and Psy-Trellis was to optimize for film grain in a way that wouldn't also destroy videos that lack grain. I also thought that was why builds with FGO were discontinued 1-2 years ago and why FGO never made it into the git. Correct me if I'm wrong though.

[JEEB]

I don't get it. I thought the whole point of Psy-RD and Psy-Trellis was to optimize for film grain in a way that wouldn't also destroy videos that lack grain. I also thought that was why builds with FGO were discontinued 1-2 years ago and why FGO never made it into the git. Correct me if I'm wrong though.

They are quite different tools and concepts, I would say (and thus do not cover each other off). Not to mention that FGO by itself, as you say, is nothing new. The main reason I took it into my own builds was because VFR Maniac commented to me that "it was/is a way of retaining some grain/noise while still not breaking the image with relatively low bitrates, unlike psy-rd and psy-trellis." I must say, I was interested.

And because I saw that it was extra something that might be useful, and, even if used, doesn't really break anything as long as you don't overdo it (high FGO and Psy-RD/-Trellis together seem like something you wouldn't want to use), I decided upon adding the properly updated patch to my builds. VFR Maniac and BakaPop have kept this patch up-to-date and 64bit-compatible (and their own builds of course contain this patch).

[elguaxo]

Sounds interesting, thanks JEEB!

Currently using --psy-rd 0.8:0.4 --fgo 2 and got pretty good results.

Just to know where to start my tests. I'll try it at a medium/low bitrate. Is that suggestion above for film or animation.

:thanks:

[JEEB]

Is that suggestion above for film or animation.
I mostly encode animation recently, which leads to most of my settings being closer to animation than live action. I guess I could've mentioned this in the post itself.

Anyways, since --fgo 5 is "weak", --fgo 2 is even weaker. This was mainly a precaution because I was trying it on an encode that I would rather like to come up nice the first time. Although I did up it from the recommendation of 1 that came from VFR Maniac ;) .

[elguaxo]

Ok! Thanks for the quick replay. :)

[rack04]

Has something changed in how x264 ./configure detects ffms and lavf. I'm trying to compile the latest x264 and it says no for both ffms and lavf.

[MasterNobody]

Has something changed in how x264 ./configure detects ffms and lavf. I'm trying to compile the latest x264 and it says no for both ffms and lavf.
Probably this is libavcore dependence. Try with this patch: http://pastebin.org/428030

[rack04]

Probably this is libavcore dependence. Try with this patch: http://pastebin.org/428030

That fixes it. Thanks.

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r24577 and libswscale SVN-r31859 (http://www.mediafire.com/?i06g5a4ko628655)
ffms2 SVN-r320 (http://www.mediafire.com/?ayqcvcqkfmj3dcu)
x264 Builds:

x264_x64_r1688M (http://www.mediafire.com/?boo762he0q0hozm)

x264_x86_r1688M (http://www.mediafire.com/?tn626hv2vgd4gll)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
filters: resize crop select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/cSww2Afe)
x264_libavcore (http://pastebin.com/FpUsDC1y)
x264_x86_r1688M_Filtering (http://www.mediafire.com/?wuxrditjff33ac1)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
filters: resize crop select_every hqdn3d yadif pad
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/cSww2Afe)
x264_libavcore (http://pastebin.com/FpUsDC1y)
x264_filtering (http://pastebin.com/Pzu85cwi)

[Soichiro]

Has something changed in how x264 ./configure detects ffms and lavf. I'm trying to compile the latest x264 and it says no for both ffms and lavf.

In msys/mingw32? Mine does this sometimes too, and I don't understand why. If I just rerun the configure script again, though, it usually detects everything properly. It's weird...

[pistacho]

@ rack04

Thank you very much by the build with filters. I've tested and works perfect :)

The command line is:
x264.exe --bitrate 5000 --preset medium --tune
film --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --fps "2
4000/1001" --force-cfr --keyint 24 --b-pyramid strict --open-gop bluray --bframe
s 3 --slices 4 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709
" --sar 1:1 --vf "pad:,,,,1920,1080" --pass 2 -o "T:\TEMP\El_negociador.264" "E:
\TEST\El Negociador-006.mkv"
ffms [info]: 1920x800p 1:1 @ 24000/1001 fps (cfr)
pad [info]: expanding frame to 1920x1080, picture starting at (0,140)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cach
e64
x264 [info]: profile High, level 4.1
[20.6%] 633/3078 frames, 8.10 fps, 5119.04 kb/s, eta 0:05:01

Input: a 2.40:1 AR MKV (1920x800)
Ouput: 16:9 AR (1920x1080) AVCHD/Blu-Ray compilancy

I think this function is very useful to encode for Blu-ray when the source is not 16:9. (requires add borders).

I will add it to my application when I have more tested. I hope that soon could be included in x264 official releases.

:thanks:
________
amber trichomes (http://trichomes.org)
________
Triumph Sprint ST (http://www.cyclechaos.com/wiki/Triumph_Sprint_ST)

[JEEB]

Anyone else having trouble when building 64bit builds with pkg-config with lavf/ffms?

config.log paste (http://privatepaste.com/2f1472a7e9)

ffmpeg and ffmpegsource seem to build fine with the correct prefixes and all (like earlier) together with 32bit x264, but 64bit x264 seems to fail like this.

used command lines (have used them for quite some time now on my buildscript):
ffmpeg
./configure --prefix=/mingw/x86_64-pc-mingw32 --cross-prefix=x86_64-pc-mingw32- --arch=x86_64 --target-os=mingw32 --enable-gpl --enable-postproc --enable-filters --disable-network --disable-encoders --extra-cflags='-U__STRICT_ANSI__' --enable-runtime-cpudetect --enable-pthreads

ffmpegsource
PKG_CONFIG_PATH=/mingw/x86_64-pc-mingw32/lib/pkgconfig/ ./configure --host=x86_64-pc-mingw32 --prefix=/mingw/x86_64-pc-mingw32

x264
PKG_CONFIG_PATH=/mingw/x86_64-pc-mingw32/lib/pkgconfig/ ./configure --cross-prefix=x86_64-pc-mingw32- --host=x86_64-pc-mingw32

[kemuri-_9]

does adding --extra-ldflags=-lavcore to x264's ./configure fix the issue?

[JEEB]

does adding --extra-ldflags=-lavcore to x264's ./configure fix the issue?

Aand yes, it did. I wonder why pkg-config doesn't handle that, though. I wonder if it's my damn system or something else :|

x264 r1688 64bit unpatched:
download (http://x264.fushizen.eu/files/revision1688/x264.exe) ; hash (http://x264.fushizen.eu/files/revision1688/x264.md5)

built on Jul 31 2010, gcc: 4.4.4 (x86_64.generic.Komisar)
fprofiled, 8bit

________________________________________________________________________________

x264 r1688 32bit
download (http://x264.fushizen.eu/files/1688/x264_1688_32.7z)

built on Jul 31 2010, gcc: 4.4.4 (x86.generic.Komisar)
fprofiled, 8bit


x264 r1688 64bit
download (http://x264.fushizen.eu/files/1688_64/x264_1688_64.7z)

built on Jul 31 2010, gcc: 4.4.4 (x86_64.generic.Komisar)
fprofiled, 8bit


patched with:

mp4muxer.diff (http://vfrmaniac.fushizen.eu/OtherStuff/L-SMASH/mp4muxer.diff)
x264_fade_compensation_1629.patch (http://x264.fushizen.eu/patches/x264_fade_compensation_1629.patch)
x264_film_grain_optimization_1680.patch (http://x264.fushizen.eu/patches/x264_film_grain_optimization_1680.patch)

[qyot27]

x264_r1688-allbits.7z

Flags:
--extra-cflags="-march=pentium3"

Contains:
x264 r1688 (8-, 9-, and 10-bit)
FFmpeg git ~ of SVN-r24652 + Lagarith decoder (http://repo.or.cz/w/FFMpeg-mirror/lagarith.git)
FFMS2 r320 (FFmpeg git ~ of SVN-r24643 + Lagarith)
LAVF "2010-01-30 17:52" + Lagarith + Ordered Chapters (http://repo.or.cz/w/FFMpeg-mirror/ordered_chapters.git)
git checkout `git rev-list -n 1 --before="2010-01-30 17:52" master`
Notes:
No patching outside of the branch mergings. I forgot to use L-SMASH this time, so it's still using GPAC.

Cross-compiled on Ubuntu 10.04 using mingw-x (supposedly, gcc 4.4.5 prerelease; I somehow doubt this but lack any way of proving it).

All of the above are 32-bit. I don't have access to 64-bit Windows at all.

The disparity between the FFmpeg used for FFMS2 and the fully-built one is due to how ancient my computer is (i.e. it takes upwards of a half hour to compile FFmpeg at any stage; see also the -march used...I'm on a Coppermine-based Celeron), and an initial lack of Internet connection.

As the stats say, the LAVF these builds use is six months out-of-date. Newer versions of FFmpeg break the Ordered Chapters branch in a way I haven't a clue how to fix using Meld.

The Lagarith support is, well, a little spotty. Only YV12 files, and seems to have problems with fades.

[laserfan]

...
patched with:

mp4muxer.diff (http://vfrmaniac.fushizen.eu/OtherStuff/L-SMASH/mp4muxer.diff)
x264_fade_compensation_1629.patch (http://x264.fushizen.eu/patches/x264_fade_compensation_1629.patch)...
I can't seem to find any information on the usage of the fade compensation patch. Can anyone direct me to a site/thread where ppl talk about settings, sources, results etc?

Or maybe the folks who use it include a specific setting for every one of their encodings without tweaking (if yes, what setting would that be)? :confused:

[JEEB]

I can't seem to find any information on the usage of the fade compensation patch. Can anyone direct me to a site/thread where ppl talk about settings, sources, results etc?

Or maybe the folks who use it include a specific setting for every one of their encodings without tweaking (if yes, what setting would that be)? :confused:

There was some talk about it on doom10 and on IRC. Most people I see use it with settings around the 0.6-0.8 range, which is normally rather effective. Of course, if x264 doesn't find the fade a fade, nothing can really be done about that.

[moosekaka]

Toolchain:

ffmpeg SVN-r24577 and libswscale SVN-r31859 (http://www.mediafire.com/?i06g5a4ko628655)
ffms2 SVN-r320 (http://www.mediafire.com/?ayqcvcqkfmj3dcu)
x264 Builds:

x264_x64_r1688M (http://www.mediafire.com/?boo762he0q0hozm)

x264_x86_r1688M (http://www.mediafire.com/?tn626hv2vgd4gll)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
filters: resize crop select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/cSww2Afe)
x264_libavcore (http://pastebin.com/FpUsDC1y)
x264_x86_r1688M_Filtering (http://www.mediafire.com/?wuxrditjff33ac1)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
filters: resize crop select_every hqdn3d yadif pad
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/cSww2Afe)
x264_libavcore (http://pastebin.com/FpUsDC1y)
x264_filtering (http://pastebin.com/Pzu85cwi)


hi, is the pad filtering patch available on 64bit x264 build? or is it somehow difficult to implement on 64 bit? thanks

[detmek]

x264_x86_r1688M_Filtering (http://www.mediafire.com/?wuxrditjff33ac1)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
filters: resize crop select_every hqdn3d yadif pad
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/cSww2Afe)
x264_libavcore (http://pastebin.com/FpUsDC1y)
x264_filtering (http://pastebin.com/Pzu85cwi)

Hi. I tried using this build but I get this warrning:

ffms [info]: 720x304p 1:1 @ 24/1 fps (vfr)
pad [info]: expanding frame to 720x480, picture starting at (0,88)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow SlowCTZ
x264 [info]: profile Baseline, level 3.0
x264 [warning]: non-strictly-monotonic pts at frame 1 (0 <= 0)
x264 [warning]: non-strictly-monotonic pts at frame 2 (0 <= 1)
x264 [warning]: non-strictly-monotonic pts at frame 3 (0 <= 2)
x264 [warning]: too many nonmonotonic pts warnings, suppressing further ones
x264 [warning]: 3015 suppressed nonmonotonic pts warnings

x264 [info]: frame I:13 Avg QP:17.54 size: 19819
x264 [info]: frame P:3006 Avg QP:19.32 size: 5262
x264 [info]: mb I I16..4: 100.0% 0.0% 0.0%
x264 [info]: mb P I16..4: 8.4% 0.0% 0.0% P16..4: 28.3% 0.0% 0.0% 0.0% 0.0% skip:63.3%
x264 [info]: coded y,uvDC,uvAC intra: 23.0% 35.5% 11.9% inter: 15.2% 14.1% 2.4%
x264 [info]: i16 v,h,dc,p: 45% 28% 14% 13%
x264 [info]: i8c dc,h,v,p: 52% 25% 14% 8%
x264 [info]: kb/s:1022.40

encoded 3019 frames, 72.20 fps, 1022.44 kb/s


Command line is --vf pad:0,88,0,88/ --preset ultrafast -o testpad.mp4 D3.avi

D3.avi is:
General
Complete name : C:\ft\D3.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 151 MiB
Duration : 2mn 5s
Overall bit rate : 10.1 Mbps
Writing library : VirtualDub build 32817/release

Video
ID : 0
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:4:4 Predictive@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Codec ID : H264
Duration : 2mn 5s
Bit rate : 10.1 Mbps
Width : 720 pixels
Height : 304 pixels
Display aspect ratio : 2.35:1
Frame rate : 24.000 fps
Resolution : 8 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 1.921
Stream size : 151 MiB (100%)
Writing library : x264 core 102 r1666bm d058f37
Encoding settings : cabac=1 / ref=2 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=4 / psy=0 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=0 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=0 / weightp=1 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc=cqp / mbtree=0 / qp=0

I found some posts but those are about resize filter problem, but my OS is WinXP Pro SP3 32-bit and I don't use Avisynth, as x264 log shows. Same problem with --preset medium. I did not have problems with resize filter, only with padding.

Tested again. No warrnings if I add --force-cfr to command line. VFR is the problem, I think.

[rack04]

hi, is the pad filtering patch available on 64bit x264 build? or is it somehow difficult to implement on 64 bit? thanks

No it is not available.

[JEEB]

And another update to my build script (http://x264.fushizen.eu/files/buildx264.sh), L-SMASH straight from the git repo :3

Yes, it looks ugly and very much like a hack, but works and seems to be the official way to install git L-SMASH at the moment. If anyone has a better version, please do share <3.

x264 r1698 64bit unpatched:
download (http://x264.fushizen.eu/files/revision1698/x264.exe) ; hash (http://x264.fushizen.eu/files/revision1698/x264.md5)

built on Aug 16 2010, gcc: 4.4.4 (x86_64.generic.Komisar)
fprofiled, 8bit

________________________________________________________________________________

x264 r1698 32bit
download (http://x264.fushizen.eu/files/1698/x264_1698_32.7z)

built on Aug 16 2010, gcc: 4.4.4 (x86.generic.Komisar)
fprofiled, 8bit


x264 r1698 64bit
download (http://x264.fushizen.eu/files/1698/x264_1698_64.7z)

built on Aug 16 2010, gcc: 4.4.4 (x86_64.generic.Komisar)
fprofiled, 8bit


patched with:

0001-Fix-compilation-to-support-L-SMASH.patch (http://up-cat.net/L-SMASH/0001-Fix-compilation-to-support-L-SMASH.patch)
Adding the whole L-SMASH git repo (http://repo.or.cz/w/L-SMASH.git) (revision 2d99fcd) into /output and then rewriting the x264 mp4.c with the one for L-SMASH.
x264_fade_compensation_1629.patch (http://x264.fushizen.eu/patches/x264_fade_compensation_1629.patch)
x264_film_grain_optimization_1680.patch (http://x264.fushizen.eu/patches/x264_film_grain_optimization_1680.patch)


Flabbergasted and not really getting what I did? Read the build script, it should be more understandable ^^;. Seems to be working, though.

[julius666]

JEEB: Could you upload the files (the compiled binaries at least) to a file-sharing site like mediafire? For some reason I can't reach your webpage from Hungary just through a proxy. :(

[mariush]

I've put them here on the mplayer's mirror i host:

http://mplayer.savedonthe.net/x264/x264_r1698_64bit_unpatched.exe
http://mplayer.savedonthe.net/x264/x264_1698_32.7z
http://mplayer.savedonthe.net/x264/x264_1698_64.7z

... in the order they appear in the post

[julius666]

Thank you, that works :)

[rack04]

Toolchain:
GCC Version 4.5.1 Experimental Release SVN rev. 162774, 2010.07.31
Pthreads 2.9.0.0 Static
Yasm 1.1.0 r2361
LAVF/FFMS Build:

ffmpeg SVN-r24819 and libswscale SVN-r31971 (http://www.mediafire.com/?36b9y9ic4o9m8se)
ffms2 SVN-r325 (http://www.mediafire.com/?x0268x5cxw6sf4o)
x264 Build:

x264_x86_r1698M (http://www.mediafire.com/?idgw2sziatdh1it)
Platform: X86
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
audio: yes (raw)
gpac: yes
pthread: yes
filters: resize crop select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
mp4muxer.diff (http://vfrmaniac.fushizen.eu/OtherStuff/L-SMASH/mp4muxer.diff)

[qyot27]

x264_r1698-allbits.7z

x264=r1698 [8-, 9-, and 10-bit]
FFMS2=r325
FFmpeg=r24829

Patches:
http://vfrmaniac.fushizen.eu/OtherStuff/L-SMASH/mp4muxer.diff

Flags:
-march=pentium3

Cross-compiled on Ubuntu 10.04, GCC 4.4.5 prerelease (again, something I doubt but can't verify)
AAC encoding requires Quicktime to be installed. The version shipped with iTunes is sufficient, although I assume you need Quicktime 7.3 or higher; if you can use iTunes to access the Store, chances are it's a right version of Quicktime.

[RainyDog]

x264 0.100.1659 x86 & x64 (http://www.mediafire.com/?yi3dmkmqniw)

gcc 4.5.1 20100623 prerelease
ffmpeg svn 23787
swscale svn 31559
ffms2 svn 312
pthreads 2.9.0.0 static
x264 0.100.1659 amdfam10,fprofiled,LTO

Outlaw, will you be doing anymore of your amdfam builds? Cheers.

[qyot27]

With all the talk about licensing going on elsewhere in this section, I've made the decision to drop the builds I've made. Instead, I'll post the steps I took for the audio encoding one in the meanwhile (since the LAGS+OC build was a pain in the neck to get working right, and I'd have to constantly recheck the steps involved):

1. Sign up for a free account on Apple Developer Connection (sadly, there's no way around this part) and download the Quicktime 7.3 SDK for Windows (http://developer.apple.com/quicktime/download/).

2. Install the SDK normally.

3. Copy the contents of C:\Program Files\Quicktime SDK to a directory on msys' root called /qtsdk. Alternately, you could just install to said location right away, but you need to remember to rename the directory so there aren't any spaces in the path name.

4. When configuring x264, use --qtsdk=/qtsdk. It should recognize it and under Audio should respond with yes (raw, qtaac, qtaac_he).

4a. Cross-compiling on Linux is possible, but requires the .lib files in /qtsdk/Libraries to be renamed/copied/symlinked to have upper-case (.LIB, not .lib) extensions - case sensitivity causes configure to fail otherwise. Windows doesn't have this problem.

[bob0r]

You should not be scared by the money makers.
If it wasn't for "us" xvid and x264 would never grown so popular. We did all the hard work, and now companies make money of it.
If you are afraid of hosting stuff, you can always host it on x264.nl.

[qyot27]

Well, at least in my own case, those two builds were mainly for esoteric features/purposes, and my ability to churn them out with regularity was already a problem because of how old my comp is. The tide of progress on all the parts inside them would have made it a moot point in relatively short order anyhow. It already somewhat did to the r1688 build with Lagarith and Ordered Chapters. The Quicktime stuff is a regular part of the L-SMASH patch now, it's just a matter of whether one chooses to supplement said patch with AAC encoding or not by downloading the SDK from Apple.

It would be far more convenient for me to document what I did to get there, because this flare-up still points out that source code is apparently different from binaries; I'm comfortable with being told what to do with source code, or to rely on existing pipelines to get a hold of things, I've just re-evaluated whether I myself want to or have the time/ability to be part of said pipelines. Binaries may be more convenient for an average user without knowledge of compiling software, but the methodology to get different results is more valuable to those that feel confident with compiling it themselves - not to mention most of them would get through the process faster than I could simply due to better underlying hardware. Waiting 1h45m-2h or so just for a complete cycle of ffmpeg->ffms2->x264->ffmpeg is getting to be too much for me anyhow. That should seriously take me a half hour (or less!), not 3-4x that. Discounting, of course, any extra time racked up due to stuff causing builds to fail mid-way through and start the process over again trying to troubleshoot it.

[jpsdr]

@rack04 : Do you intend to make a 32/64 bit with fade_compensation patch of the last version ?

[easyfab]

Can someone make a build for LAVF/ffmpeg SVN but with all audio codec enable ( aac,lame,vorbis ... ) because I want to try to build "x264 audio" and I don't know how to build ffmpeg correctly under mingw/msys. ( A guide for ffmpeg under mingw/msys can also be good)

[lucassp]

I'm also looking for a recent Mac build of x264 with ffms/lavf. Or at least a build tutorial. Thanks :)

[qyot27]

I'm also looking for a recent Mac build of x264 with ffms/lavf. Or at least a build tutorial. Thanks :)
For OSX,
A) install Xcode - it's on the OSX install disc or through Apple Developer Connection.
B) Install MacPorts (by following Parts 1 & 2 from http://davidbaumgold.com/tutorials/wine-mac/ - although if you want to go on to install wine feel free to).
C) Use MacPorts to install subversion, git-core, yasm, nasm, texi2html, automake, autoconf, libtool, pkg-config (might already be installed through Xcode...I can never seem to remember this), and I think that's it.



svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg
svn checkout http://ffmpegsource.googlecode.com/svn/trunk/ ffms2
git clone git://git.videolan.org/x264.git

cd ffmpeg
./configure --prefix=$HOME/ffms2_build --enable-gpl --enable-version3 --enable-postproc --disable-encoders \
--disable-muxers --disable-debug --disable-network --disable-hwaccels --disable-indevs --disable-outdevs \
--extra-cflags="-march=pentium3"
make
make install

cd ../ffms2
./configure --prefix=$HOME/ffms2_build PKG_CONFIG_PATH=$HOME/ffms2_build/lib/pkgconfig
make
make install

cd ../x264
wget http://vfrmaniac.fushizen.eu/OtherStuff/L-SMASH/mp4muxer.diff
patch -p1 < mp4muxer.diff
PKG_CONFIG_PATH=$HOME/ffms2_build/lib/pkgconfig ./configure --extra-cflags="-march=pentium3"
make
make install
make distclean

PKG_CONFIG_PATH=$HOME/ffms2_build/lib/pkgconfig ./configure --prefix=$HOME/x264-9bit \
--extra-cflags="-march=pentium3" --bit-depth=9
make
make install
make distclean

PKG_CONFIG_PATH=$HOME/ffms2_build/lib/pkgconfig ./configure --prefix=$HOME/x264-10bit \
--extra-cflags="-march=pentium3" --bit-depth=10
make
make install



All -march=pentium3 parts should be changed to the processor you actually have; refer to GCC's documentation for that list (http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html)...-march=native could also be used if you'd rather not take the time to target your cpu explicitly and let GCC autodetect it.

The MSYS/MinGW instructions are pretty much identical to those - the only place they differ are that ffmpeg requires two additional options: --enable-memalign-hack and -U__STRICT_ANSI__ needs to be added to the cflags, like --extra-cflags"-U__STRICT_ANSI__ -march=pentium3".

EDIT: I forgot...I have read reports that ffmpeg won't build under Snow Leopard unless --disable-asm and --arch=x86_64 are also given. I'm not entirely sure because I can't remember if I've ever built without those options, so be aware of that as well.

[jpsdr]

@jeeb : I've tested your x64 patched 1703 version, with the following command line :

@echo off

SET E_SRC=%6%1.avs
SET E_DST=%3%1.264
SET CHAPTERS=%6%5
SET STAT_FILE=%6%1.stats
SET TUNING=%4
SET LOG_FILE_1=%6%1_log_1.txt
SET LOG_FILE_2=%6%1_log_2.txt

REM Set of max bitrate (ici le bitrate max)
set MAX_BR=40000

REM Set of Buffer (ici le buffer)
set BUF_BR=30000

REM 1ère passe
x264_x64.exe --profile "high" --preset "placebo" --tune %TUNING% --pass 1 --bitrate %2 --stats %STAT_FILE% --level "4.1" --qpmin 0 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 24 --min-keyint 2 --mvrange 511 --ref 4 --bframe 3 --slices 4 --b-pyramid "strict" --open-gop "bluray" --fade-compensate 0.7 --subme 9 --trellis 1 --me "umh" --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --videoformat "ntsc" --sar 1:1 --qpfile %CHAPTERS% --threads 0 --thread-input --output NUL %E_SRC% 2> %LOG_FILE_1%

REM 2ème passe
x264_x64.exe --profile "high" --preset "placebo" --tune %TUNING% --pass 2 --bitrate %2 --stats %STAT_FILE% --level "4.1" --qpmin 0 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 24 --min-keyint 2 --mvrange 511 --ref 4 --bframe 3 --slices 4 --b-pyramid "strict" --open-gop "bluray" --fade-compensate 0.7 --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --videoformat "ntsc" --sar 1:1 --qpfile %CHAPTERS% --threads 0 --thread-input --output %E_DST% %E_SRC% 2> %LOG_FILE_2%


My avisynth script is only AVISource("File.avi"), where avi is Lagarith YV12 without audio.
2 problems :
- It displays avs errors about audio... First time i'm having this kind of message, specialy when output is raw h264...
- It never finish the 1st pass... Process is some kind of locked, i've one thread (ie one CPU) at 100%, log of 1st pass seems completed, but still used/locked by the process, and there is no log of 2nd pass, which mean 2nd pass is not starting.
Reproductible at 100%, even with a small file of few frames.

[livetolove92]

This is my settings
x264.exe --profile high --level 4.1 --pass 1 --preset veryslow --bitrate 1900 --stats ".stats" --min-keyint 24 --thread-input --threads 6 --deblock -3:-3 --deadzone-inter 21 --deadzone-intra 11 --qcomp 0.6 --bframes 4 --b-adapt 2 --direct auto --b-bias 0 --scenecut 40 --keyint 250 --ref 6 --rc-lookahead 00 --aq-mode 1 --aq-strength 0.7 --merange 24 --me umh --subme 7 --no-dct-decimate --mixed-refs --partitions all --trellis 2 --psy-rd 0.8:0.1 --ipratio 1.4 --pbratio 1.3 --no-fast-pskip --output NUL "F:\Worker\x.avs"

x264.exe --profile high --level 4.1 --pass 2 --preset veryslow --bitrate 1900 --stats ".stats" --min-keyint 24 --thread-input --threads 6 --deblock -3:-3 --deadzone-inter 21 --deadzone-intra 11 --qcomp 0.6 --bframes 4 --direct auto --b-bias 0 --scenecut 40 --keyint 250 --ref 6 --rc-lookahead 00 --aq-mode 1 --aq-strength 0.7 --merange 24 --me umh --subme 7 --no-dct-decimate --mixed-refs --partitions all --trellis 2 --psy-rd 0.8:0.1 --ipratio 1.4 --pbratio 1.3 --no-fast-pskip --output "x.mkv" "F:\Worker\x.avs" 2>log.txt
And this my avs
LoadCPlugin("F:\Encode software\megui-core_0_3_4_15_x64\tools\ffms\ffms2.dll")
ffmpegsource2("H:\US\X.mkv")
Spline36Resize(960,406) # Spline36 (Neutral)

This my log
avs [info]: 960x406p 0:0 @ 24000/1001 fps (cfr)
x264 [warning]: lookaheadless mb-tree requires intra refresh or infinite keyint
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [error]: ratecontrol_init: can't open stats file
x264 [error]: x264_encoder_open failed

I use the latest x264, ffms2, megui, avisynth for x64.
I can't create the .stats file. x264 crash immediately when i run the bat.

[jpsdr]

@jeeb
I've tested your x64 1713 patched build, still the same issue i've described in post #3397 (http://forum.doom9.org/showthread.php?p=1431557#post1431557)

[kemuri-_9]

@jeeb
I've tested your x64 1713 patched build, still the same issue i've described in post #3397 (http://forum.doom9.org/showthread.php?p=1431557#post1431557)

have you even tried the unpatched x64 build to see if it also exhibits the issues?
iirc JEEB is using the still-being-developed audio support patch which would explain the audio warning...

[jpsdr]

Patched x86 and x64 don't work.
Unpatched x64 work, but of course i've to remove the --fade-compensate option.

[JEEB]

Will see if I can see what's the reason. Have you tried with scripts that don't relate to Lagarith?

Anyways, what I can see being the problem:

Lagarith is having fun
L-SMASH or something results in it failing
Cosmic radiation


Am building a new build with an updated L-SMASH to see if I can re-create what is happening to you at all.

As for the audio error, it's fine. Happens every time you don't use the audio feature >_>.

Edit: Chikuzen had tested it with UTVideo and it seems to be fine. I'm running a test encode on 32bit build + avs at the moment myself. Thus I'm inclined to blame Lagarith.

[jpsdr]

I'm only using avi in lagarith YV12. Work fine with patched 1688 rack04 version...

[JEEB]

I'm only using avi in lagarith YV12. Work fine with patched 1688 rack04 version...
From the results so far I can see that most probably some part of the new code is just affecting Lagarith, and nothing else.

Until you tell me it breaks something else, my care levels will be very low to do something about it. Lagarith has been and still is a broken pile of balls, and it even has good alternatives nowadays (did I mention UT Video already from YV12 all the way to RGBA, or, you know, something that can be decoded by ffmpeg if you only need YV12?). Of course this isn't the best thing you could've expected, but unfortunately Lagarith just is what it is. Re-encoding those YV12 sequences into something else should've been your goal for a long time now, to be honest.

Of course, if you actually find that it breaks something else that I can do something about, do tell me.

[livetolove92]

This is my settings

And this my avs

This my log

I use the latest x264 1713, ffms2, megui, avisynth for x64.
I can't create the .stats file. x264 crash immediately when i run the bat.

Somebody helps me

[Guest]

Somebody helps me You have specified your stats file as ".stats". Try giving it a real name before the extension:

--stats "movie.stats"

[livetolove92]

still not work. But I can use the same command with FFVideosource instead of ffmpegsource2.
If I del --b-adapt 2 new issue happens
x264 [error]: timebase mismatch with 1st pass (1001/24000 vs 1/25). The source's fps is 23.976

Anyway, tks for your help ^^

[Guest]

You still get the --stats error when specifying a proper filename? Or are you reporting a new error?

[livetolove92]

I still get the --stats error when specifying a proper filename. x264 crash immediately when I run the command. But if I replaced ffmpegsource2 by FFVideosource in avs it works correctly.

[jpsdr]

Lagarith has been and still is a broken pile of balls, and it even has good alternatives nowadays (did I mention UT Video already from YV12 all the way to RGBA, or, you know, something that can be decoded by ffmpeg if you only need YV12?).
Of course, if you actually find that it breaks something else that I can do something about, do tell me.

When i was looking for a lossless YV12 codec with keyframe only, i only found lagarith (or found maybe 1 or 2 others, but toooo slow), and, as it was working fine until now, i didn't see the point of changing.
Now, i didn't know UT Video, i've just take a look, and i'll give a try. Seems interesting, as you can also say if video is interlaced or not.

I'll tell you my results.

Edit : Works fine with UT Video. Thanks.

[livetolove92]

You still get the --stats error when specifying a proper filename? Or are you reporting a new error?

I have fix it. It sucks. I just add 2>log1.txt to pass 1.

[easyfab]

For OSX,
A) install Xcode - it's on the OSX install disc or through Apple Developer Connection.
B) Install MacPorts (by following Parts 1 & 2 from http://davidbaumgold.com/tutorials/wine-mac/ - although if you want to go on to install wine feel free to).
C) Use MacPorts to install subversion, git-core, yasm, nasm, texi2html, automake, autoconf, libtool, pkg-config (might already be installed through Xcode...I can never seem to remember this), and I think that's it.



svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg
svn checkout http://ffmpegsource.googlecode.com/svn/trunk/ ffms2
git clone git://git.videolan.org/x264.git

cd ffmpeg
./configure --prefix=$HOME/ffms2_build --enable-gpl --enable-version3 --enable-postproc --disable-encoders \
--disable-muxers --disable-debug --disable-network --disable-hwaccels --disable-indevs --disable-outdevs \
--extra-cflags="-march=pentium3"
make
make install

cd ../ffms2
./configure --prefix=$HOME/ffms2_build PKG_CONFIG_PATH=$HOME/ffms2_build/lib/pkgconfig
make
make install

cd ../x264
wget http://vfrmaniac.fushizen.eu/OtherStuff/L-SMASH/mp4muxer.diff
patch -p1 < mp4muxer.diff
PKG_CONFIG_PATH=$HOME/ffms2_build/lib/pkgconfig ./configure --extra-cflags="-march=pentium3"
make
make install
make distclean

PKG_CONFIG_PATH=$HOME/ffms2_build/lib/pkgconfig ./configure --prefix=$HOME/x264-9bit \
--extra-cflags="-march=pentium3" --bit-depth=9
make
make install
make distclean

PKG_CONFIG_PATH=$HOME/ffms2_build/lib/pkgconfig ./configure --prefix=$HOME/x264-10bit \
--extra-cflags="-march=pentium3" --bit-depth=10
make
make install



All -march=pentium3 parts should be changed to the processor you actually have; refer to GCC's documentation for that list (http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html)...-march=native could also be used if you'd rather not take the time to target your cpu explicitly and let GCC autodetect it.

The MSYS/MinGW instructions are pretty much identical to those - the only place they differ are that ffmpeg requires two additional options: --enable-memalign-hack and -U__STRICT_ANSI__ needs to be added to the cflags, like --extra-cflags"-U__STRICT_ANSI__ -march=pentium3".

EDIT: I forgot...I have read reports that ffmpeg won't build under Snow Leopard unless --disable-asm and --arch=x86_64 are also given. I'm not entirely sure because I can't remember if I've ever built without those options, so be aware of that as well.

Thanks qyot27 , very useful.

FFmepg/lavf build is now Ok and LAME, FAAC too
but not FFMS2 r331 I got compile error mesage ( pthread problems ) ? I use Komisar pthreads 2.9.0.0 GC-static
build for info .

But it's ok I can build x264 audio with mp3 and faac .

Here is my build (based on the experimental silverfilain-x264 source ) if someone want to try.

Link removed as request

I think It's only working with mp4 muxer and sometimes audio is not sync but it give a good overview of futur x264 with audio encoder.

Let play with it if you want :)

[Chikuzen]

@easyfab
Please don't distribute the binary that links libfaac.
Distributing the binary that links libfaac undertakes the violation of the license since it contains a lot of codes of the reference encoder(GPL incompatible).
(I proposed that add "--enable-nonfree" in the configure, and it was approved. )

[tormento]

I am currently suffering of macroblock and fluctuations in dark areas. I read there was a patch, called AQ patch, created to alleviate this problem.

Is it implemented on current tree or is there a newer, better, one?

[nurbs]

There are currently 2 different AQ modes in x264 and the first one is activated by default. I haven't heard anything about a new patch. The last change to AQ was at the beginning of this year IIRC. If you use low bitrates the blocking is in some cases very hard to get rid of, especially when the picture is dark and contains fog or smoke.

[tormento]

There are currently 2 different AQ modes in x264 and the first one is activated by default.
Where can I find syntax/switches?

Thanks.

[nurbs]

x264 --fullhelp

Same as always.

[Chikuzen]

I am currently suffering of macroblock and fluctuations in dark areas. I read there was a patch, called AQ patch, created to alleviate this problem.

Is it implemented on current tree or is there a newer, better, one?

I think that it is Haali 's AQ Pathch that you look for.
Haali's AQ is older than VAQ, and the one to do working that lowers QP in dark and blue points.
(because HAQ doesn't decrease bits at all unlike VAQ, the filesize will be increased if you use.)
The patch is still maintained by VFR maniac (http://vfrmaniac.fushizen.eu/x264/x264_DANGEROUS/), and includes his "MixAQ build".

[rack04]

I have compiled x86 and x64 builds of x264 r1834 for the sole purpose of performing your own speed tests relating to threading.

x264_r1834_x86-x64_posix (http://www.mediafire.com/?scnu6p8jkx6a168)

x264_r1834_x86-x64_win32thread (http://www.mediafire.com/?dtxfrwwjdlcdw52)

My results:

CPU: Intel Core2 Duo T7250
OS: Windows XP Professional SP3

x264_r1834_x86-x64_posix
encoded 2595 frames, 32.84 fps, 429.02 kb/s

x264_r1834_x86-x64_win32thread
encoded 2595 frames, 33.86 fps, 429.02 kb/s

[soneca]

Hi, rack04
Here the difference was much smaller.
Using RipBot264...

CPU: Intel i7 980x
OS: Windows 7 Ultimate 64bit

x264_r1834_x86-x64_posix
encoded 47162 frames, 95.40 fps, 3033.76 kb/s

x264_r1834_x86-x64_win32thread
encoded 47162 frames, 95.66 fps, 3033.76 kb/s

[kemuri-_9]

it should be noted that for those that are doing comparisons of pthread-win32 threading against native windows threading that the windows threading takes different codepaths depending on the version of windows:
A) 2000/XP
B) Vista/7/(anything beyond this)

as such, comparing pthread-win32 against win32thread should take this into account.

[aegisofrime]

Any improvement no matter how small is welcomed :)

Thanks rack04 for the 64-bit builds. Neither x264.nl nor fushizen has them yet.

[LoRd_MuldeR]

it should be noted that for those that are doing comparisons of pthread-win32 threading against native windows threading that the windows threading takes different codepaths depending on the version of windows:
A) 2000/XP
B) Vista/7/(anything beyond this)

as such, comparing pthread-win32 against win32thread should take this into account.

May I ask: What was the main motivation to implement support for native Win32 threads? Speedup? Getting rid of pthreads?

[kemuri-_9]

May I ask: What was the main motivation to implement support for native Win32 threads? Speedup? Getting rid of pthreads?

pthread-win32 is LGPL, this causes a conflict with --disable-gpl x264 builds.
it was not done for performance reasons.

though since we were doing it, might as well use windows for all its worth when it's available (for vista+ platforms) so there might be a very small performance increase there.


the windows threading might be more important later when support for windows 7 x86_64's (and similar/later x86_64 platforms) way of handling systems with over 64 logical cores is added
(yes, microsoft totally made things a bit odd to extend support to 256 logical cores on the x86_64 systems starting with 7/server 2008 R2).

[Dark Shikari]

pthread-win32 is LGPL, this causes a conflict with --disable-gpl x264 builds.No it doesn't. Even a commercial x264 can link fine with LGPL libs.

It caused a conflict with a customer who didn't like LGPL libs ;)

[upyzl]

Excuse me, is it still worth patching ME-prepass(#5 (http://forum.doom9.org/showthread.php?p=1050161#post1050161)) now? (or can the patch be available now? Of course manually -- ignore patch's line numbers)

Because of large changes in x264, I want to patch it myself manually

[upyzl]

...and another question

Is ME prepass patch (rev 680, #1 (http://forum.doom9.org/showthread.php?t=130364)) the latest?

[Kurosaki Ichigo]

Hi there, I'm new. I don't know if I'm writing in the right place. I have a problem with Lagarith Lossless Codec. I tried the 1.3.2.0 version and the last 1.3.2.5, but when the process finished, the output file is too small

This is the source RAW

General
Unique ID : 235762869933910293037496416019526284763 (0xB15E46EFE5A7B520951159776D4175DB)
Complete name : J:\[IM9 & FTF] RAW Anime\Freezing\[Yousei-raws] Freezing 01 [BDrip 1920x1080 x264 FLAC].mkv
Format : Matroska
Format version : Version 2
File size : 2.26 GiB
Duration : 23mn 41s
Overall bit rate : 13.6 Mbps
Encoded date : UTC 2011-04-02 07:30:50
Writing application : mkvmerge v4.6.0 ('Still Crazy After All These Years') сборка от Mar 10 2011 02:50:32
Writing library : libebml v1.2.0 + libmatroska v1.1.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Muxing mode : Header stripping
Codec ID : V_MPEG4/ISO/AVC
Duration : 23mn 41s
Nominal bit rate : 12.9 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.259
Writing library : x264 core 114 r1924 08d04a4
Encoding settings : cabac=1 / ref=4 / deblock=1:-2:-2 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=0.90:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=0 / bitrate=12860 / ratetol=1.0 / qcomp=0.65 / qpmin=9 / qpmax=32 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=30000 / vbv_bufsize=27000 / nal_hrd=none / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:0.90
Language : Japanese

Audio
ID : 2
Format : FLAC
Format/Info : Free Lossless Audio Codec
Codec ID : A_FLAC
Duration : 23mn 41s
Bit rate mode : Variable
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Writing library : libFLAC 1.2.1 (UTC 2007-09-17)
Language : Japanese

And this, the output with Lagarith, in Full Processing Mode:

General
Complete name : J:\Freezing 01.avi
Format : AVI
Format/Info : Audio Video Interleave
Format profile : OpenDML
File size : 37.5 GiB
Duration : 23mn 41s
Overall bit rate : 226 Mbps
Writing application : VirtualDubMod 1.5.10.2 (build 2540/release)
Writing library : VirtualDubMod build 2540/release

Video
ID : 0
Format : Lagarith
Codec ID : LAGS
Duration : 23mn 41s
Bit rate : 226 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : RGB
Bit depth : 8 bits
Bits/(Pixel*Frame) : 4.552
Stream size : 37.5 GiB (100%)


For what I know about Lagarith, this file size is too small. I don't know if I missed something when installed it. I have the last version of K-lite codec pack for 32 bit, on Windows 7 32 bit without SP1. Anyone Have an idea?

[Guest]

@Kurosaki Ichigo

Please read and follow forum rules, especially rule 6 regarding downloaded files, torrents, etc. Further violations will incur strikes.

@all

No help on this. Thank you.

[Kurosaki Ichigo]

I get it for rule number 6. I'll pay attention in future! ^^ Thanks anyway...

[Guest]

Thank you for your understanding.

[Kurosaki Ichigo]

Don't say it! It's a rule, it's just normal! ^^

[RipFan]

Thanks for all the information and effort.
I have only one question, I use Megui 2624 (latest version) downloaded x264 2638 Kmod and replaced it by the "x264_64.exe" that was placed inside megui folder "tools".
My question is: to use a fade_compensate CLI do I have to download the patch as well?
If the answer is yes, where do I have to place this Patch?

Best regards and many thanks once again

[sneaker_ger]

The patch file (.diff) is not needed, that's just what the kMod creator used to build x264.exe from.

[RipFan]

The patch file (.diff) is not needed, that's just what the kMod creator used to build x264.exe from.

Thanks a lot, just what I nedded to know:thanks:

[benwaggoner]

That said, it's been about 8 years since the first post was updated. It'd be nice to have a current version of this thread with up-to-date info.