mencoder+x264

[bond]

using ffmpeg as decoder leads to that i get 3 zero length frames, compared to libmpeg2, which leads to 2 zero length frames with the same following cmdl (adding the proposed "noskip, harddup.." doesnt make a difference:
mencoder.exe -ss 00:00:00.400 -frames 100 -noskip -mc 0 -sws 9 -vf crop=720:416:0:82,scale=640:256,harddup "C:\path\matrix1.vob" -ovc x264 -of avi -ffourcc VSSH -o mencoder.avialso the greenish picture, plus the one too much reference frame signalling in the nal stays the same :(

[akupenguin]

Weirdness... it seems that -noskip sometimes (whenever there are B-frames?) adds null frames at the beginning. Try with harddup and -mc 0 but without -noskip.
You might try filing a bugreport, but most of the devs refuse to touch mencoder. I'm not sure I could fix it either.

Reference frame signalling is now fixed. (It was unconditionally allowing an extra ref for B-frames.)

Green tint is acknowledged. I don't know what's causing it.

[bond]

ok i tried the following: with the settings as mentioned above (-frames 100 and no (!!!) b-frames set (default setting)) with cd's latest compile (not using your latest updates):

- decoding with ffmpeg, no -noskip, with harddup: 1 zero length frame reported, also during encoding i get a "1 duplicate frame(s)" message (mpeg4ips avi2raw tool writes 98 frames of 100 frames)
- decoding with ffmpeg, using -noskip and harddup: 3 zero length frames reported, but no "1 duplicate frame(s)" message during encoding (97 frames written)
- decoding with ffmpeg, no -noskip, no harddup: 2 zero length, 1 duplicate frame (97 frames written)

- decoding with libmpeg2 and no -noskip, with harddup: no zero length frame reported! but during encoding "1 duplicate frames" (99 frames written)
- decoding with libmpeg2 and -noskip, with harddup: 2 zero length frames, no duplicate message (98 frames written)
- decoding with libmpeg2, no -noskip, no harddup: 1 zero length frame, 1 duplicate (98 frames written)



doing the math:
- not using -noskip leads to the removal of 1 (not zero length) frame (called "duplicate frame" during encoding) during encoding with both ffmpeg and libmpeg2 and outputting 1 frame too few independant of the zero frames issue
- using noskip on the other side also leads to that two frames of the output are zero length frames with both ffmpeg and libmpeg2

independant of using -noskip:
- using ffmpeg as decoder leads to that two frames of the output are zero length frames
- using libmpeg2 as decoder leads to that one frame of the output is a zero length frame

- using harddup removes 1 zero length frame with both ffmpeg and libmpeg2


if i didnt made a mistake thats the only solution fitting my findings

edit: adding/removing "-mc 0" gives exactly the same results

[bond]

and another thing: does x264 or mencoder automatically set the aspect ratio info in the avc bitstream?
if yes, how does this work?

i checked this as a x264 stream imported to .mp4 was played back anamorphically with nero, altough i didnt resize during the encoding process

[akupenguin]

Yes.

Mplayer/Mencoder can detect aspect from a variety of sources, in your case the mpeg2 headers. If mencoder can't detect aspect, it is assumed to be 1:1 SAR. You can force the input to be 1:1 SAR with "-noaspect", or you can override DAR with "-aspect #:#"
If you perform filtering (-vf crop,scale) that modifies these, it does the right thing: preserves SAR across crop, preserves DAR across scale. This computation is not disabled by -noaspect.
The encoder frontend (ve_x264.c) is always given a pixel resolution and a display resolution, from which it calculates SAR. It then passes SAR to libx264, which writes it in the header. There may be a little rounding involved here, since DAR is in units of integer pixels.

[Yong]

What's wrong with my x264 encoding option?

start /b /low /w mencoder %1 -noskip -nosound -o nul: -ovc x264 -x264encopts keyint=300:nocabac:no4x4mv:nob8x8mv:subq=0:pass=1: -passlogfile "x2642ndpass.log"

start /b /low /w mencoder %1 -audio-preload 2.0 -noskip -oac copy -o "%userprofile%\desktop\%~n1.avi" -ovc x264 -x264encopts keyint=300:pass=2:bframes=3:bitrate=1000 -passlogfile "x2642ndpass.log" -ffourcc X264

some stupid pose deleted...

I tried many time with the latest mplayer build, but no b-frame on output video...

[akupenguin]

Originally posted by Yong
I tried many time with the latest mplayer build, but no b-frame on output video...
Frame types are decided on the 1st pass. You didn't enable bframes there.

[Yong]

That's mean at the first-pass
CLI option need to add "...:bframes=3"?

[akupenguin]

yes.

And for now, use "bframes=1" instead of 3. Higher numbers don't yet help quality.

[Yong]

@akupenguin:
Thanks for the answers.:)
And for now, use "bframes=1" instead of 3. Higher numbers don't yet help quality.
Yeah, i tried with bframes=16, looks terrible:D

[Doom9]

uhh, shouldn't mencoder support AVI input? Here's what I'm trying to do

C:\temp\mplayer>mencoder d:\kill_bill_vol2\video_ts\killbill2.avi -ovc x264 -x264encopts keyint=300:frameref=3:bframes=1:deblock:deblockalpha=-3:deblockbeta=-3:cabac:subq=4 -o NUL: -passlogfile "x264_2pass.log". killbill2.avi is a wrapped AviSynth script (makeAVIS), that even bitchy MS tools accept. Yet mencoder only throws a
File not found: 'frameno.avi'
Failed to open frameno.avi
x264encopts is not an MEncoder option

Exiting... (error parsing cmdline)
There's no frameno.avi anywhere on my system, but it's not in the commandline so I don't understand why mencoder is looking for it. Likewise, x264encopts is a friggin mencoder option, it's definied right there on the manpage.

mencoder is a standard w32 compile right from the mplayer homepage. build 1.0pre6

[bond]

Originally posted by Doom9
killbill2.avi is a wrapped AviSynth script (makeAVIS), that even bitchy MS tools accept. Yet mencoder only throws a
File not found: 'frameno.avi'
Failed to open frameno.avi
x264encopts is not an MEncoder option

Exiting... (error parsing cmdline)
There's no frameno.avi anywhere on my system, but it's not in the commandline so I don't understand why mencoder is looking for it. Likewise, x264encopts is a friggin mencoder option, it's definied right there on the manpage.the frameno.avi thing has nothing to do with this. i also always get that message, its not a problem

whats causing your problem is more that i think the latest official compile might not support x264 already (or not completely), as it noted that -x264encopts is not an option mencoder understands
use the latest compile from celtic_druid here (http://celticdruid.no-ip.com/xvid/mplayer/), it works here for sure

[Doom9]

whats causing your problem is more that i think the latest official compile might not support x264 already (or not completely), as it noted that -x264encopts is not an option mencoder understandsGreat, then why is it on the manpage that comes with the build?

So I updated my winrar and got celticdruid's compile, now I'm stuck with a VIDEO: [AVIS] 640x272 16bpp 23.976 fps 0.8 kbps ( 0.1 kbyte/s)
[V] filefmt:3 fourcc:0x53495641 size:640x272 fps:23.98 ftime:=0.0417
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1 (-1=autodetect) osd: 1
==========================================================================
Cannot find codec matching selected -vo and video format 0x53495641.
Read DOCS/HTML/en/codecs.html!
==========================================================================

[bond]

i seems the default decoder doesnt recognize these files

try adding "-vfm ffmpeg,dshow,vfw", that will first try to decode the stream with ffmpeg, if this doesnt work it will try to decode it with dshow (will surely work if ffdshow is installed and the AVIS support option in the dshow decoder is enabled), than if that doesnt work will try to find a vfw decoder

[Doom9]

doesn't work either.

I got avs2yuv working though so I'm using that now.

BTW, the manpage says the following about x264 bitrate
bitrate=<value>

Sets the bitrate to be used in kbits/second (default: off). This is required if you want a CBR (constant bitrate) encode.

Yet, you have to specify a bitrate in 2 pass mode. I'm a bit confused though how to perform the first pass. Do I have to specify anything but pass=1 in the first pass, and pass=2:bitrate=mybitrate in the 2nd pass, or do I have to specify the bitrate in both passes?

[Sharktooth]

Doom9 are you going to update your codec comparison or yours is simply a x264 interest?:)

[Doom9]

Doom9 are you going to update your codec comparisonNot for at least half a year. Currently, x264 is not ready imho. Look at the problems above, then there's the b-frame issue (muxing and playback mostly so unrelated to the x264), rate control could still need some improvement according to bond, and of course usability ;)

[bond]

Originally posted by Doom9
Do I have to specify anything but pass=1 in the first pass, and pass=2:bitrate=mybitrate in the 2nd pass, or do I have to specify the bitrate in both passes?you have two possibilities:
either set a fixed quant for the first pass, which matches the average quant of your desired 2nd pass bitrate
or you set the desired bitrate in the firstpass too (meaning both passes aim at the same bitrate, 1st pass is cbr, 2nd pass vbr)
you could even do a third or more passes (like divx5's multipass option), but i think it might not be necessary

about the other options: aku posted some hints about what can be disabled in firstpass, when used in secondpass too, but generally i would use the same settings in the first as in the second pass (x264 is not really slow, so that shouldnt be a problem)

[Bogalvator]

I use something like

-x264encopts keyint=300:bframes=1:nodeblock:pass=1:qcomp=1:subq=1

in the fist pass and then something like

-x264encopts bitrate=???:keyint=300:bframes=1:nodeblock:pass=2:qcomp=1:direct_pred=1:subq=5

Probably sub-optimal, but fast (difference in quality is probably not noticeable anyway). If you're paranoid then you can set the pass option to pass=3 for the second pass, and run it twice (pass=3 is n-th pass encoding in mencoder) to do 3 passes.

Also, the ratecontrol in x264 is already excellent - test the above and you will see (not usually more than 3 kbps out in my tests on a reasonable length encode i.e. at least 1 hour)

You'll probably want to activate deblocking for lower bitrates (less than about 750kbps for 640x352 resolution) though I myself wouldn't go any higher than -3 (even that's sometimes too strong for my liking)

EDIT: Note the above will default to fixed quant encoding for the first pass

[Doom9]

what are allowable sizes for ip_factor, pb_factor, qp_step, rc_buffer_size and rc_buffer_init?

[hellfred]

Originally posted by Doom9
what are allowable sizes for ip_factor, pb_factor, qp_step, rc_buffer_size and rc_buffer_init?
akupenguin once (http://forum.doom9.org/showthread.php?s=&threadid=83039&perpage=20&pagenumber=3) pointed out that rc_buffer_size gives good results when set around 0.5-1 second worth of video bitrate for CBR, or 1-2 seconds worth of bitrate for multi-pass.
Meaning when you are doing your onpass with bitrat 450 kbits/second go for 225 kbits/second to 450 kbits/second, and to 450 kbits/second to 900 kbits/second for multipass encoding with same bitrate.

I am doing just a little bit of guess when it comes to rc_buffer_init, but i would set it to something near one times bitrate specified in rc_buffer_size when clip starts with a hard to encode sequence, so that rate controll can start distributing additional bits right away. If clip start with easy to encode frames go down to the default value of 1/4 time bitrate specified.

Hellfred

[akupenguin]

ip_factor: allows 1..10. sane values: 1.2 .. 1.5
pb_factor: allows 1..10. sane values: 1 .. 1.4
qp_step: allows 1 .. 51. sane values: 1 .. 3
rc_buffer_size: allows (bitrate/fps) .. bignum. sane values: (bitrate/2) .. (bitrate*2)
rc_buffer_init: I just changed this to be a fraction (0..1) (previously it was in units of kbit). I set the default to 0.25 because most movies begin with some seconds of blackness or otherwise no motion, so the buffer will quickly fill up anyway. It you're encoding a clip that starts right away, you might set rc_buffer_init to 0.5 or more. (Only matters for CBR.)

Meaning when you are doing your onpass with bitrate 450 kbits/second go for 225 kbits/second to 450 kbits/second, and to 450 kbits/second to 900 kbits/second for multipass encoding right, except that the units of rc_buffer_size are kbit, not kbit/second.

Also, the ratecontrol in x264 is already excellent - test the above and you will see (not usually more than 3 kbps out in my tests on a reasonable length encode i.e. at least 1 hour) Sure, it can accurately meet your specified average bitrate. That's easy. (I have no idea why WMV9 and VP6 have such issues with it.) But that doesn't mean it's good ratecontrol: The reason 2pass is better than 1 is that the codec can adjust the distribution of bits based on the complexity of the scene. And my distribution algorithm was mostly pasted from libavcodec, with only minor tweaks for H.264.

[giandrea]

Hello, I'm trying to compile the last SVN version of x264 (v80 if I remember correctly) with the last CVN snapshot of Mplayer, but it is giving strange errors:
#error We do not support old versions of x264. Get the latest from SVN.
So I was wondering if it is a known problem or if it is me doing something wrong.
Thank you,

giandrea

[akupenguin]

You must have an old version of x264.h somewhere. Make sure that the one actually included/linked is v80.

[giandrea]

Originally posted by akupenguin
You must have an old version of x264.h somewhere. Make sure that the one actually included/linked is v80.
Men, how could I be so stupid... after compiling x264 I replaced the old library file with the new one, but I forgot the include... :eek: :D
Thank you again,

giandrea

[Doom9]

ip_factor: allows 1..10. sane values: 1.2 .. 1.5
pb_factor: allows 1..10. sane values: 1 .. 1.4
qp_step: allows 1 .. 51. sane values: 1 .. 3What's the default for those?

[akupenguin]

ip_factor=1.4, pb_factor=1.3, qp_step=1
But there's no theoretical basis behind my defaults. I just took the settings for optimal PSNR with my current ratecontrol, and turned them down a notch.

[Doom9]

I have another question, regarding the (no)4x4mv parameter. How does it work? I figured it would apply to all macroblock size and types listed in the manpage (i16x16, i4x4, p16x16, p16x8, p8x16, p8x8, p8x4, p4x8, p4x4, skip), so if I for instance don't want to have 16x16 macroblocks in I-frames, I'd use "noi16x16mv", but that doesn't appear to work. So how does that option work?

[bond]

i talked to aku about that yesterday and the man page has been updated accordingly making the options more clear :)

the possible options are:
- nob8x8mv
- b8x8mv
- no4x4mv
- 4x4mv

(no)b8x8mv:
Use additional macroblock types b16x8, b8x16, b8x8 (default: enabled). Without this option, B-frames will use only types i16x16, i4x4, b16x16, skip, di- rect. See 4x4mv for details.

(no)4x4mv:
Use additional macroblock types p8x4, p4x8, p4x4 (default: disabled). Without this option, P-frames will use only types i16x16, i4x4, p16x16, p16x8, p8x16, p8x8, skip.

[bond]

akupenguin, i now encoded a stream with the by syskin updated vfw wrapper for x264 (code from today), with b-frames, mref3, loop, cabac and subp5 and when extracting the stream again to raw with the avi2raw tool, i get the "warning: one zero length frame ignored" message, and it outputs one frame less than there should be outputted
edit: when using 2 b-frames the message says "two zero length frames..."
when disabling b-frames that error message is gone

now, as this doesnt really fit into the mencoder results (which was able to avoid the zero length issue even with b-frames) i dunno whether this is caused by x264 itself, or the vfw interface not able to handle b-frames 100% correctly or virtualdub (which always had a problem with outputting frames at the end of the stream, i assume its the same here too)

[bond]

Originally posted by akupenguin
Reference frame signalling is now fixed. (It was unconditionally allowing an extra ref for B-frames.)it still says one too much

i encoded with 1 b-frame and 3 reference frames and the nal looks like that:
Nal length 23
ref 3 type 7 Sequence parameter set
profile 4d
constaint_set0_flag: 0
constaint_set1_flag: 0
constaint_set2_flag: 0
level_idc: 21
seq parameter set id: 0
log2_max_frame_num_minus4: 5
pic_order_cnt_type: 0
log2_max_pic_order_cnt_lsb_minus4: 6
num_ref_frames: 4
...when using 2 b-frames, it says the same (4)

when disabling b-frames it says "3" as it should be

[akupenguin]

Originally posted by bond
it still says one too much

i encoded with 1 b-frame and 3 reference frames and the nal looks like that:
num_ref_frames: 4
when using 2 b-frames, it says the same (4)
That is correct. The x264 option "frameref" sets the number of references used in a P-frame. B-frames have one more than that (the future P-frame.)
It is possible that some other distribution of references would produce better compression per CPU cost, but until I run that comparison, this is the most logical implementation.

[bond]

Originally posted by akupenguin
That is correct. The x264 option "frameref" sets the number of references used in a P-frame. B-frames have one more than that (the future P-frame.)ah yes of course, thx for the info :)

[hellfred]

Originally posted by bond
akupenguin, i now encoded a stream with the by syskin updated vfw wrapper for x264 (code from today), with b-frames, mref3, loop, cabac and subp5 and when extracting the stream again to raw with the avi2raw tool

Bond, where to get the updated vfw wrappper. Comparing latest svn checkout of x264 (rev82) with older checkouts(rev72) showed not changes.
And i can not access the x264 mailing list archive (http://www.via.ecp.fr/via/ml/x264-devel/index-en.html) for 2005 right now.

Hellfred

[bond]

Originally posted by hellfred
Bond, where to get the updated vfw wrappper. Comparing latest svn checkout of x264 (rev82) with older checkouts(rev72) showed not changes.
And i can not access the x264 mailing list archive (http://www.via.ecp.fr/via/ml/x264-devel/index-en.html) for 2005 right now.it hasnt been in the x264 svn till now as syskin hasnt finished it till now (wants to make 2pass working too, aso)

you can find his latest binary and source here (http://homepages.ihug.com.au/~syskin/x264/)

[akupenguin]

Originally posted by bond
i now encoded a stream with the by syskin updated vfw wrapper for x264 (code from today), with b-frames, mref3, loop, cabac and subp5 and when extracting the stream again to raw with the avi2raw tool, i get the "warning: one zero length frame ignored" message, and it outputs one frame less than there should be outputted.
B-frames in vfw need application support. Virtualdub knows about divx/xvid delayed frames, and doesn't mux them. I assume that it doesn't treat x264 specially.

[hellfred]

Originally posted by akupenguin
B-frames in vfw need application support. Virtualdub knows about divx/xvid delayed frames, and doesn't mux them. I assume that it doesn't treat x264 specially.
So one needs to use a codec that knows of bframes to decode the stream to raw frames. Maybe using a AVISynth Script to open the avi with DirectShowSource (if you use latest ffdshow with updated h264 decoding) or AviSource (using the same and enabling it to decode h264 for vfw, too= will work for you then.

Hellfred

[bond]

akupenguin referred to the problems of b-frames with vfw (vfw cant by itself not handle b-frames). there have been workarounds developed to make b-frames work in vfw. syskin is at it to add these to x264 vfw too, like they exist for xvid

[Yong]

What problem with my x264 encoding options? During first-pass, mencoder display some message:
buffer underflow -xxxxx...
Will it hurt quality?

start /b /low /w mencoder %1 -noskip -nosound -o nul: -ovc x264 -x264encopts keyint=300:nocabac:no4x4mv:nob8x8mv:subq=0:bframes=2:pass=1:bitrate=600 -passlogfile "x2642ndpass.log"

start /b /low /w mencoder %1 -audio-preload 2.0 -noskip -oac copy -o "%temp%\temp.avi" -ovc x264 -x264encopts keyint=300:frameref=5:deblockalpha=-3:deblockbeta=-3:ip_factor=1.4:
pb_factor=1.3:cabacidc=2:scenecut=40:idrint=2:cabac:4x4mv:b8x8mv:
direct_pred=2:subq=5:qp_step=6:rc_sens=1:qp_min=26:qp_max=51:
pass=2:bframes=2:bitrate=600 -passlogfile "x2642ndpass.log" -ffourcc X264

EDIT:
Disable smilies to prevent a** appear:D

[akupenguin]

Originally posted by Yong
What problem with my x264 encoding options? During first-pass, mencoder display some message: buffer underflow -xxxxx...
Will it hurt quality? That means the CBR ratecontrol couldn't meet your specified bitrate (for some scene) due to the qp_min=26. It will not hurt quality unless your 2nd pass decides to use quants < 26.

[Doom9]

rc_buffer_size: allows (bitrate/fps) .. bignum. sane values: (bitrate/2) .. (bitrate*2)Whats a bignum? long aka 64 bit integer? thanks for indicating all the sane values btw..

[akupenguin]

The specific definition of bignum is an infinite precision integer type. I was using the more general definition of some number that's big enough that you don't have to know exactly what it is. In this case, rc_buffer_size is actually stored in a 32bit signed int. x264 places no further limits, while mencoder (for no particular reason) limits it to 24e6 (measured in kbit, so that converts to 188 MiB).

[Yong]

@akupenguin:
Thanks for the replies:)
(looks like here is x264 support center):p

What's the meaning by this?
bits<0.9
mencoder print alot of this word at the beginning of second pass.
(the x264 encoding option is same as my last post)

Again, thanks for your replies:)

[akupenguin]

Originally posted by Yong
bits<0.9
That means you had some size 0 frames (absolutely no motion) and my ratecontrol complained. It should have no side-effects, and I removed the message on 2005-01-05.

[bond]

Originally posted by bond
ok i tried the following: with the settings as mentioned above (-frames 100 and no (!!!) b-frames set (default setting)) with cd's latest compile (not using your latest updates):

- decoding with ffmpeg, no -noskip, with harddup: 1 zero length frame reported, also during encoding i get a "1 duplicate frame(s)" message (mpeg4ips avi2raw tool writes 98 frames of 100 frames)
- decoding with ffmpeg, using -noskip and harddup: 3 zero length frames reported, but no "1 duplicate frame(s)" message during encoding (97 frames written)
- decoding with ffmpeg, no -noskip, no harddup: 2 zero length, 1 duplicate frame (97 frames written)

- decoding with libmpeg2 and no -noskip, with harddup: no zero length frame reported! but during encoding "1 duplicate frames" (99 frames written)
- decoding with libmpeg2 and -noskip, with harddup: 2 zero length frames, no duplicate message (98 frames written)
- decoding with libmpeg2, no -noskip, no harddup: 1 zero length frame, 1 duplicate (98 frames written)



doing the math:
- not using -noskip leads to the removal of 1 (not zero length) frame (called "duplicate frame" during encoding) during encoding with both ffmpeg and libmpeg2 and outputting 1 frame too few independant of the zero frames issue
- using noskip on the other side also leads to that two frames of the output are zero length frames with both ffmpeg and libmpeg2

independant of using -noskip:
- using ffmpeg as decoder leads to that two frames of the output are zero length frames
- using libmpeg2 as decoder leads to that one frame of the output is a zero length frame

- using harddup removes 1 zero length frame with both ffmpeg and libmpeg2


if i didnt made a mistake thats the only solution fitting my findings

edit: adding/removing "-mc 0" gives exactly the same results ok i now noticed something similar with direct .avs input (source has 50 frames):
- no matter if i use b-frames or not the output always adds one frame to the input (51 frames in the case that no b-vops are used)
- it seems the last frame is double and that last frame is not a zerolength frame

- using 1 b-frame in a row leads to that additionally 1 frame less gets outputted (51-1 = 50 frames)
- using 2 b-frames in a row leads to that additionally 2 frames less gets outputted (51-2 = 49 frames) aso...

- using "-mc 0", "-noskip" and "-vf harddup" doesnt change this behaviour
- using avi or rawvideo output doesnt change this behaviour


somehow i have the feeling mencoder isnt really working 100% correctly :D

[Doom9]

Has anybody else with an Athlon64 noticed that when mencoder lists the cpu flags, it doesn't list either sse or sse2 as present. consequently it seems both athlonxp and amd64 builds from celticdruid do not use the full potential of the cpu, and run at the same speed.

[virus]

@Doom9:

well, this is what I see with my build on my P4 (same output with celtic_druid's one):
MEncoder dev-CVS-050218-20:59-3.2.3 (C) 2000-2005 MPlayer Team
CPU: Intel Pentium 4/Xeon/Celeron Foster (Family: 8, Stepping: 7)
Detected cache-line size is 64 bytes
CPUflags: Type: 8 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 0

[Doom9]

virus: that's also incorrect. to at least the sse detection is b0rked. Here's the output from the athlon xp compile:

CPU: Advanced Micro Devices (Family: 8, Stepping: 0)
Detected cache-line size is 64 bytes
CPUflags: Type: 8 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE

and here from the amd64 compile

CPU: Advanced Micro Devices (Family: 8, Stepping: 0)
Detected cache-line size is 64 bytes
CPUflags: Type: 8 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2

makes one wonder, doesn't it?

[celtic_druid]

It isn't just me. Every build that I have ever tried from numerous different sources always has 0 for SSE/SSE2.

[Doom9]

Every build that I have ever tried from numerous different sources always has 0 for SSE/SSE2.so another confirmation that something is wrong. I'm just wondering if the detection has anything to do with enabling/disabling of any optimized codepaths. I guess I need to run a longer test of the two builds that work on my box and see if the build that ought to use sse2 actually is faster.