Direct264 - special x264 CLI build that supports input from DirectShow

[roozhou]

VFR mp4 output is ok now. Also add two options to set start and end position.

[video_magic]

Thanks for the work and the new version :)

[tebasuna51]

@roozhou
With your dshow2wav.exe I obtain 16 bit stereo from a WMV with multichannel WMA audio (like I say you in Audio Ecoding forum).

Maybe the thread WMA 5.1ch. in WMV only decodes to stereo? (http://forum.doom9.org/showthread.php?t=110449) help you to improve this interesting tool.

[roozhou]

@tebasuna51
Have you checked speaker setup in control panel? According to zembelli's words, you should set it to 5.1 to enable multichannel decoding.

[tebasuna51]

@tebasuna51
Have you checked speaker setup in control panel? According to zembelli's words, you should set it to 5.1 to enable multichannel decoding.

Of course, I have attached a receiver with 6 analog input to PC audio output. All is Ok.

With DirectShowSource() in .avs the output is Ok.

With a simple Test6chan.wma the avs output is 16 bit/6 channels, with dshow2wav 16 bit/2 ch.

With the MS HD sample Amazing_Caves_1080.wmv, the avs output 24 bit/6 ch., with dshow2wa 16 bit/2 ch.

I'm talk about the changes in DirectShowSource than IanB make "to poke the High Res output(_HIRESOUTPUT)'"

Edit: with GraphEdit I have also 16 bit/2 ch

[roozhou]

Of course, I have attached a receiver with 6 analog input to PC audio output. All is Ok.

With DirectShowSource() in .avs the output is Ok.

With a simple Test6chan.wma the avs output is 16 bit/6 channels, with dshow2wav 16 bit/2 ch.

With the MS HD sample Amazing_Caves_1080.wmv, the avs output 24 bit/6 ch., with dshow2wa 16 bit/2 ch.

I'm talk about the changes in DirectShowSource than IanB make "to poke the High Res output(_HIRESOUTPUT)'"

Edit: with GraphEdit I have also 16 bit/2 ch

Thank you very much for providing this information. In next version it will be fixed.

P.S. some one is working on a wma pro decoder which belongs to this year's ffmpeg google SOC project. As soon as it is finished, we can send the crappy WMAudio Decoder DMO to the ground.

[roozhou]

Updated again.
WMA Pro issue solved.

[tebasuna51]

@roozhou
Your last package: dshow_x264_20081104
still don't work for me.

Maybe your:

dump.ax 28/10/2008 16:15

is outdated, because:

dump.cpp 03/11/2008 16:43

[roozhou]

:stupid:
Plz download 20081105 build (http://files.filefront.com/dshow+x264+200811057z/;12255629;/fileinfo.html)

[tebasuna51]

Thanks. Now work fine.

[tebasuna51]

Maybe is not important but always is better put all waveheader fields correctly, you forget block_align (at end of dshow2wav.c):
waveheader.channels = ((dwAudioInfo >> 24) & 0xF);
waveheader.sample_rate = (dwAudioInfo & 0xFFFFFF);
waveheader.bits_per_sample = ((dwAudioInfo >> 25) & 0xF8);
+ waveheader.block_align = waveheader.channels * waveheader.bits_per_sample / 8;
+ waveheader.avg_bytes_sec = waveheader.block_align * waveheader.sample_rate;
- waveheader.avg_bytes_sec = waveheader.channels * waveheader.sample_rate * waveheader.bits_per_sample / 8;

[roozhou]

Maybe is not important but always is better put all waveheader fields correctly, you forget block_align (at end of dshow2wav.c):
waveheader.channels = ((dwAudioInfo >> 24) & 0xF);
waveheader.sample_rate = (dwAudioInfo & 0xFFFFFF);
waveheader.bits_per_sample = ((dwAudioInfo >> 25) & 0xF8);
+ waveheader.block_align = waveheader.channels * waveheader.bits_per_sample / 8;
+ waveheader.avg_bytes_sec = waveheader.block_align * waveheader.sample_rate;
- waveheader.avg_bytes_sec = waveheader.channels * waveheader.sample_rate * waveheader.bits_per_sample / 8;

I noticed that because oggenc2 prints warning on incorrect block_align. And there's another bug in dump.ax making CTAACEncoder crash. Fixed builds will be released tomorrow.

[roozhou]

Plz check the 11-06 build.

[tebasuna51]

I noticed that because oggenc2 prints warning on incorrect block_align.

The oggenc2 still can't work with dshow2wav because need correct datalength.

I make a feature request (http://www.hydrogenaudio.org/forums/index.php?showtopic=60755) to ogg developpers about that.

The official branch (http://www.hydrogenaudio.org/forums/index.php?showtopic=65975) seems accept the request (#1326) but still is in beta stage.

But John33 (oggenc2-rarewares) don't say nothing. Maybe next week (http://www.hydrogenaudio.org/forums/index.php?showtopic=60755#) (Mar 7 2008).

Maybe persons interested in oggenc2 encodes can remember to John33 the --ignorelength parameter.

---------------------------------------
Test with flac seems work with this parameters:
dshow2wav <input-file> | flac --force -o <output.flac> --silent --channel-map=none --ignore-chunk-sizes -

----------------------------------------
edit: the 11-06 pack work fine with block-align

[tebasuna51]

To encode now with oggenc2 or other encoders than need physical wav files you can use:

WavSplit
======
If you want encode to DTS or with some AC3 encoders you need monowavs, then:

dshow2wav <input_file> | WavSplit - <prefix.wav> -ignorelength

and you obtain: prefix_FL.wax, prefix_FR.wav, ...
Also can split in stereo wav files more easy for edit.

Wavfix
=====
If the wav file is > 4GB and you want use w64 format (or also rf64):

dshow2wav <input_file> | WavFix - <output.w64> -ignorelength -o 3

[-o #] Output header. 0=RAW, 1=WAV(Default), 2=RF64, 3=W64
The RiffLength and DataLength are rewrited with correct data (int64).

Maybe you need the multichannel wav output with WAVE_FORMAT_EXTENSIBLE header:

dshow2wav <input_file> | WavFix - <output.wav> -ignorelength -m 0

[-m #] MaskChannel. Force output WAVE_FORMAT_EXTENSIBLE. 0 to default for the numchannels detected.
This feature can be integrated in dshow2wav.

If you are interested I can send you these utils.

[roozhou]

In latest oggenc2 from rareware.org there is a "--ignorelength" option. And for neroAacEnc it's "-ignorelength" and for aften it's "-readtoeof 1".

[tebasuna51]

I was tired of ask to John33 about this. Thanks.

And yes the Aften -readtoeof 1 is other old little battle (http://forum.doom9.org/showthread.php?p=962455#post962455)

EDIT: Tested last oggenc2 from rarewares

Oggenc2.85 using libVorbis v1.2.0 2008-03-16
Oggenc2.85 using aoTuVb5.5 2008-03-31

and --ignorelength isn't supported.

[roozhou]

I was tired of ask to John33 about this. Thanks.

And yes the Aften -readtoeof 1 is other old little battle (http://forum.doom9.org/showthread.php?p=962455#post962455)

EDIT: Tested last oggenc2 from rarewares

Oggenc2.85 using libVorbis v1.2.0 2008-03-16
Oggenc2.85 using aoTuVb5.5 2008-03-31

and --ignorelength isn't supported.

Get the latest oggenc2 builds here.
http://www.hydrogenaudio.org/forums/index.php?showtopic=60956&st=125

[tebasuna51]

Thanks. Now work --ignorelength

[roozhou]

Updated to 2008-11-25

x264 r1032
Added "--no-versioninfo" to remove encoding settings from bitstream.
Supports y4m from stdin, making piping from mplayer available

[Dark Shikari]

Updated to 2008-11-25

x264 r1032
Added "--no-versioninfo" to remove encoding settings from bitstream.As an x264 developer, I strongly request that you remove this option. I don't want to make it easy for people to strip encoding settings out of their files to cover up their incompetence and force me to do more detailed analysis for no good reason. At least force them to go into the code and do it themselves.

[roozhou]

As an x264 developer, I strongly request that you remove this option. I don't want to make it easy for people to strip encoding settings out of their files to cover up their incompetence and force me to do more detailed analysis for no good reason. At least force them to go into the code and do it themselves.

Actually I was just aiming at reducing overhead. And I guess it is easy for you to find out how bad their encoding settings are even without that information in bitstream :)

[buzzqw]

what about adding a crop and resize ability? (and maybe including hqdn3d denoiser...)
thanks!

BHH

[roozhou]

what about adding a crop and resize ability? (and maybe including hqdn3d denoiser...)
thanks!

BHH

You can find them in latest ffdshow. I will only add functions that current dshow filters do NOT have.

[buzzqw]

:(

i prefer a "direct" approach (and so like building a gui aroud it)

thanks anyway

BHH

[roozhou]

:(

i prefer a "direct" approach (and so like building a gui aroud it)

thanks anyway

BHH

I would rather hacking mencoder than adding this to x264. A GUI can do this job by setting ffdshow reg keys.

[CruNcher]

yep buzzqw leverage ffdshow it gives you alot of possibilities :)
also accessing avisynth for special effect purposes a very powerfull (OSS) base this could become under Windows :) very comparable to Nero Recode (and with the time beyond) just with X264 as Core and not only that with stable Dshow Decoder i think it would be even a good base for a NLE, (though very important here minimizing Dshow Hell as good as possible like with a chain management ala MPC) :)

i already build very simple logic (based on batch scripting around it) just 1 command and i can transcode all video stuff to H.264 in a snap very powerful also integrated it into the Windows Explorer :) trying to achive all that with Mencoder,ffmpeg and co under Windows gave me major headaches (especially with non supported Video/Audio by ffmpeg or the problems with mencoder piping under win32) and the best i can leverage all the metadata of the encoding into the final result :) it's even easier and faster then Mediacoder (and more stable based on Dshow, no joke, you just have to keep the chain under control) (also i can encode and live preview the encode result via GPU without makeing the encode slower, and jep also tested delayed live streaming of the result @ the same time everything seems to magicaly work and i can do live overlays too, and yeah also integrated it testwise with BDA (DVB-S2) works too :) (Broadcast stuff only Video yet no live muxing)

I can just say it Natively perfectly integrates into Windows that way (a nice efficient task optimized gui now for it would rock) :D

[Guest]

I also need a one-pass adaptive ivtc dshow filter (not avisynth filter, they either need index or do not work in one-pass mode). That's not correct. Neither Telecide()/Decimate() nor TIVTC() require indexing or multiple passes.

[roozhou]

That's not correct. Neither Telecide()/Decimate() nor TIVTC() require indexing or multiple passes.

That's right. But avisynth does require two passes. Can you encode vfr video in one pass without indexing w/ avisynth?

[Guest]

We were talking about IVTC, not encoding VFR. And saying "Avisynth requires two passes" is absurd.

You obviously have an agenda so I won't bother you again with facts.

[roozhou]

We were talking about IVTC, not encoding VFR. And saying "Avisynth requires two passes" is absurd.

You obviously have an agenda so I won't bother you again with facts.

Consider mixed progress + telecined video. TIVTC cannot do its work in one pass without indexing it first. And indexing should be treated as one pass.

[CruNcher]

I had a Problem of how to handle interlaced bitstreams automatically i didn't want to use the bad performing internal Software Deinterlacer of most Dshow Decoder so i analyze the Source now and then incorporate ffdshow into the chain (by just changing the registry entry for the colorspace rendering to all supported and to handle all frames as interlaced with yadif, works not bad) only when using a different decoder then fffdshow itself, it's a little inflexible then mencoder but it works. :)
Also tried that with Progressive as interlaced bad flagged streams seems not a big problem doesn't hurt much in transcoding quality (helps compression a bit too).
It's not perfect that way a integrated solution like your --deldup would be more effective and adaptive i guess same for ivtc, as internally you could get all the bitstream information @ playback :)

Source: http://www.mediafire.com/download.php?hnlqnznnzzw
1 Pass 5,49 fps Transcoding result: = http://mirror05.x264.nl/CruNcher/force.php?file=./dshow-batchframework/mc.ts-yadif.mp4 Transcoding time 0:01:33 :)

Mencoder doesn't support the Source yet

[popper]

roozhou, have you ever looked at Eigen 2.0 for some x86 SIMD optimisations that might help improve the general speed of all the video coding (more Vectorization re-codeing is always good)work we see here at doom9, not least x264, you might enjoy it.

http://eigen.tuxfamily.org/index.php?title=Main_Page

and if you ever dabble in PPC linux ,then markos's freevec SIMD work is probably interesting too
http://www.freevec.org/

the benchmarks are very interesting for both platforms SIMD work.

[roozhou]

roozhou, have you ever looked at Eigen 2.0 for some x86 SIMD optimisations that might help improve the general speed of all the video coding (more Vectorization re-codeing is always good)work we see here at doom9, not least x264, you might enjoy it.

http://eigen.tuxfamily.org/index.php?title=Main_Page

and if you ever dabble in PPC linux ,then markos's freevec SIMD work is probably interesting too
http://www.freevec.org/

the benchmarks are very interesting for both platforms SIMD work.

Most of x264's time-consuming functions have already been optimized with SIMD instructions, so i don't think Eigen 2.0 would help a lot. And you'd better talk to Dark Shikari who is one of the current developers of x264.

[Dark Shikari]

roozhou, have you ever looked at Eigen 2.0 for some x86 SIMD optimisations that might help improve the general speed of all the video coding (more Vectorization re-codeing is always good)work we see here at doom9, not least x264, you might enjoy it.I have yet to encounter any program or library whose x86 optimization is even close to the same level as x264.

And if it was close, I would take the code, make it better, and use that instead.

[roozhou]

Updated to 2008-12-12

The new package contains two x264 builds, one is GCC 4.3.2 fprofiled build (x264.exe) and the other is MSVC 2005 PGO build (x264_msvc.exe).

This is my first attemp to build x264 with MSVC. Although several SSE2/SSSE3 functions are disabled for stack-alignment issues, MSVC build seems to run a bit faster than GCC build with low quality settings and the EXE is 25% smaller in size.

Anyone interested in comparing speed of GCC and MSVC builds could use each build to encode, and of course with the same settings. If one is significantly faster than the other, please post your command line here.

[Dark Shikari]

Updated to 2008-12-12

The new package contains two x264 builds, one is GCC 4.3.2 fprofiled build (x264.exe) and the other is MSVC 2005 PGO build (x264_msvc.exe).

This is my first attemp to build x264 with MSVC. Although several SSE2/SSSE3 functions are disabled for stack-alignment issuesAnd all intrinsics, and all inline assembly...

[roozhou]

And all intrinsics, and all inline assembly...

Where is the inline assembly in x264?

Yes my dshow patch contains gcc inline assembly and i added VC inline assembly to make it compile under VS 2005.

e.g.

#ifdef _MSC_VER
__asm emms
#else
asm volatile("emms \n\t");
#endif

[Dark Shikari]

Where is the inline assembly in x264?common/x86/utils.h

Intrinsics are in common/osdep.h (x264_clz and x264_endian_fix).

Also, you don't need to create an emms, we already have one (x264_emms, not an intrinsic).

[roozhou]

common/x86/utils.h

Intrinsics are in common/osdep.h (x264_clz and x264_endian_fix).

Also, you don't need to create an emms, we already have one (x264_emms, not an intrinsic).

I am porting all these to MSVC.

Just one problem, what does "+r" mean here in util.h?


"movq %%mm4, %0 \n"
:"=m"(output), "+r"(i_mvc)
:"r"(mvc), "m"(*(struct {int16_t x[4];} *)mvc)

[Dark Shikari]

I am porting all these to MSVC.

Just one problem, what does "+r" mean here in util.h?


"movq %%mm4, %0 \n"
:"=m"(output), "+r"(i_mvc)
:"r"(mvc), "m"(*(struct {int16_t x[4];} *)mvc)
The "+r" is a register constraint: its taking i_mvc as a value in a register and modifying it (hence the +).

Also, be very careful specifying your clobbers and dependencies: the whole "struct" nonsense is because we had to fool gcc into realizing that we were, in fact, dependent on the input array.

[roozhou]

The "+r" is a register constraint: its taking i_mvc as a value in a register and modifying it (hence the +).

Also, be very careful specifying your clobbers and dependencies: the whole "struct" nonsense is because we had to fool gcc into realizing that we were, in fact, dependent on the input array.

Here is the original gcc inline-assembly version

static inline int x264_predictor_difference_mmxext( int16_t (*mvc)[2], intptr_t i_mvc )
{
int sum = 0;
uint16_t output[4];
asm(
"pxor %%mm4, %%mm4 \n"
"test $1, %1 \n"
"jnz 3f \n"
"movd -8(%2,%1,4), %%mm0 \n"
"movd -4(%2,%1,4), %%mm3 \n"
"psubw %%mm3, %%mm0 \n"
"jmp 2f \n"
"3: \n"
"sub $1, %1 \n"
"1: \n"
"movq -8(%2,%1,4), %%mm0 \n"
"psubw -4(%2,%1,4), %%mm0 \n"
"2: \n"
"sub $2, %1 \n"
"pxor %%mm2, %%mm2 \n"
"psubw %%mm0, %%mm2 \n"
"pmaxsw %%mm2, %%mm0 \n"
"paddusw %%mm0, %%mm4 \n"
"jg 1b \n"
"movq %%mm4, %0 \n"
:"=m"(output), "+r"(i_mvc)
:"r"(mvc), "m"(*(struct {int16_t x[4];} *)mvc)
);
sum += output[0] + output[1] + output[2] + output[3];
return sum;
}


And i "translated" it into MSVC inline-assembly

static inline int x264_predictor_difference_mmxext( int16_t (*mvc)[2], intptr_t i_mvc )
{
uint64_t output;
__asm
{
mov eax, i_mvc
mov edx, mvc
pxor mm4, mm4
test eax, 1
jnz l3
movd mm0, [edx+eax*4-8]
movd mm3, [edx+eax*4-4]
psubw mm0, mm3
jmp l2
l3:
dec eax
l1:
movq mm0, [edx+eax*4-8]
psubw mm0, [edx+eax*4-4]
l2:
pxor mm2, mm2
sub eax, 2
psubw mm2, mm0
pmaxsw mm0, mm2
paddusw mm4, mm0
jg l1
movq output, mm4
}
return ((uint16_t*)&output)[0] + ((uint16_t*)&output)[1] + ((uint16_t*)&output)[2] + ((uint16_t*)&output)[3];
}


Unfortunately the latter one does not give the same result. I traced into the gcc build and it was using eax and edx as %1 and %2. Could someone tell me where the problem is?

[Dark Shikari]

return ((uint16_t*)&output)[0] + ((uint16_t*)&output)[1] + ((uint16_t*)&output)[2] + ((uint16_t*)&output)[3];I'm pretty sure that this line is enormous violation of strict aliasing.

You need to keep it declared as a uint16_t array.

[CruNcher]

@roozhou
i realized a slight speed increase with your msvc build when

Slow_mod4_stack is being used compared to the GCC build that doesn't use it :) (AMD Athlon 64 Toledo)
Though not sure if that comes from the MSVC VS GCC difference or the actuall modification yet :)

The difference
(msvc build) x264 [info]: using cpu capabilities: MMX2 SSE2Slow Slow_mod4_stack
(gcc build) x264 [info]: using cpu capabilities: MMX2 SSE2Slow

[roozhou]

I'm pretty sure that this line is enormous violation of strict aliasing.

You need to keep it declared as a uint16_t array.

Thanks, it works:)

And I wonder which one runs faster.

1

uint16_t output[4];
__asm{
...
movq output, mm4
}
return output[0] + output[1] + output[2] + output[3];


2

uint32_t output;
__asm{
...
movd eax, mm4
punpckhdq mm4, mm4
movzx edx, ax
shr eax, 16
add edx, eax
movd eax, mm4
mov output, edx
movzx edx, ax
shr eax, 16
add edx, eax
add output, edx
}
return output;

[roozhou]

Updated to 2008-12-16

Well, I finished porting all GCC inline-assembly to MSVC inline-assembly. They works fine for me(with minor cosmetics).

Hope someone could add it to git :)

common/x86/util.h


#define x264_median_mv x264_median_mv_mmxext
static inline void x264_median_mv_mmxext( int16_t *dst, int16_t *a, int16_t *b, int16_t *c )
{
__asm
{
mov eax, a
mov edx, b
movd mm0, [eax]
movd mm1, [edx]
mov eax, c
mov edx, dst
movq mm3, mm0
movd mm2, [eax]
pmaxsw mm0, mm1
pminsw mm1, mm3
pminsw mm0, mm2
pmaxsw mm0, mm1
movd [edx], mm0
}
}
#define x264_predictor_difference x264_predictor_difference_mmxext
static inline int x264_predictor_difference_mmxext( int16_t (*mvc)[2], intptr_t i_mvc )
{
__asm
{
mov eax, i_mvc
mov edx, mvc
pxor mm4, mm4
test eax, 1
jnz l3
movd mm0, [edx+eax*4-8]
movd mm3, [edx+eax*4-4]
psubw mm0, mm3
jmp l2
l3:
dec eax
l1:
movq mm0, [edx+eax*4-8]
psubw mm0, [edx+eax*4-4]
l2:
pxor mm2, mm2
sub eax, 2
psubw mm2, mm0
pmaxsw mm0, mm2
paddusw mm4, mm0
jg l1
movd edx, mm4
punpckhdq mm4, mm4
movd eax, mm4
add edx, eax
movzx eax, dx
shr edx, 16
add eax, edx
}
}
#undef array_non_zero_int
#define array_non_zero_int array_non_zero_int_mmx
static inline int array_non_zero_int_mmx( void *v, int i_count )
{
if(i_count == 128)
{
__asm
{
mov eax, v
movq mm0, [eax]
por mm0, [eax+8]
por mm0, [eax+16]
por mm0, [eax+24]
por mm0, [eax+32]
por mm0, [eax+40]
por mm0, [eax+48]
por mm0, [eax+56]
por mm0, [eax+64]
por mm0, [eax+72]
por mm0, [eax+80]
por mm0, [eax+88]
por mm0, [eax+96]
por mm0, [eax+104]
por mm0, [eax+112]
por mm0, [eax+120]
packsswb mm0, mm0
movd eax, mm0
test eax, eax
setnz al
and eax, 1
}
}
else return array_non_zero_int_c( v, i_count );
}

[kemuri-_9]

it would have a chance of going into the repository quicker if you:
1. got a clean checkout of the repository
2. add in your changes w/ preprocessor conditionals so only MSVC tries to compile it, without interfering with the current GCC code.
3. use diff to generate a cleanly applyable patch so it can be easily applied+tested.

then when there it has been confirmed to have no problems, it can then make its way in

[roozhou]

it would have a chance of going into the repository quicker if you:
1. got a clean checkout of the repository
2. add in your changes w/ preprocessor conditionals so only MSVC tries to compile it, without interfering with the current GCC code.
3. use diff to generate a cleanly applyable patch so it can be easily applied+tested.

then when there it has been confirmed to have no problems, it can then make its way in

Well, I am also building with GCC so don't worry about that.

Here is the patch.

diff --git a/common/x86/util.h b/common/x86/util.h
index b67c903..7d41d67 100644
--- a/common/x86/util.h
+++ b/common/x86/util.h
@@ -127,6 +105,96 @@ static ALWAYS_INLINE int array_non_zero_int_mmx( void *v, int i_count )
}
else return array_non_zero_int_c( v, i_count );
}
+#elif defined(_MSC_VER)
+#define x264_median_mv x264_median_mv_mmxext
+static inline void x264_median_mv_mmxext( int16_t *dst, int16_t *a, int16_t *b, int16_t *c )
+{
+ __asm
+ {
+ mov eax, a
+ mov edx, b
+ movd mm0, [eax]
+ movd mm1, [edx]
+ mov eax, c
+ mov edx, dst
+ movq mm3, mm0
+ movd mm2, [eax]
+ pmaxsw mm0, mm1
+ pminsw mm1, mm3
+ pminsw mm0, mm2
+ pmaxsw mm0, mm1
+ movd [edx], mm0
+ }
+}
+#define x264_predictor_difference x264_predictor_difference_mmxext
+static inline int x264_predictor_difference_mmxext( int16_t (*mvc)[2], intptr_t i_mvc )
+{
+ __asm
+ {
+ mov eax, i_mvc
+ mov edx, mvc
+ pxor mm4, mm4
+ test eax, 1
+ jnz l3
+ movd mm0, [edx+eax*4-8]
+ movd mm3, [edx+eax*4-4]
+ psubw mm0, mm3
+ jmp l2
+ l3:
+ dec eax
+ l1:
+ movq mm0, [edx+eax*4-8]
+ psubw mm0, [edx+eax*4-4]
+ l2:
+ pxor mm2, mm2
+ sub eax, 2
+ psubw mm2, mm0
+ pmaxsw mm0, mm2
+ paddusw mm4, mm0
+ jg l1
+ movd edx, mm4
+ punpckhdq mm4, mm4
+ movd eax, mm4
+ add edx, eax
+ movzx eax, dx
+ shr edx, 16
+ add eax, edx
+ }
+}
+#undef array_non_zero_int
+#define array_non_zero_int array_non_zero_int_mmx
+static inline int array_non_zero_int_mmx( void *v, int i_count )
+{
+ if(i_count == 128)
+ {
+ __asm
+ {
+ mov eax, v
+ movq mm0, [eax]
+ por mm0, [eax+8]
+ por mm0, [eax+16]
+ por mm0, [eax+24]
+ por mm0, [eax+32]
+ por mm0, [eax+40]
+ por mm0, [eax+48]
+ por mm0, [eax+56]
+ por mm0, [eax+64]
+ por mm0, [eax+72]
+ por mm0, [eax+80]
+ por mm0, [eax+88]
+ por mm0, [eax+96]
+ por mm0, [eax+104]
+ por mm0, [eax+112]
+ por mm0, [eax+120]
+ packsswb mm0, mm0
+ movd eax, mm0
+ test eax, eax
+ setnz al
+ and eax, 1
+ }
+ }
+ else return array_non_zero_int_c( v, i_count );
+}
#endif

#endif

[kemuri-_9]

oh right, forgot to mention to put in preprocessor conditionals so that it also doesn't try to compile it when compiling for x64

since in M$ infinite wisdom and power (/sarcasm), inline asm is not accepted for x64 building....

changing
#elif defined(_MSC_VER)
to
#elif defined(_MSC_VER) && defined(_M_IX86)
should be the most effective way to achieve this

the other option would be to export it out to assembly files to be compiled with yasm so that it could be used in both x86 and x64...
(granted getting the x64 part to actually work is going to be even more of a task)

[roozhou]

the other option would be to export it out to assembly files to be compiled with yasm so that it could be used in both x86 and x64...

No, they cannot be inlined once written in an asm file. I guess DS does not like these routines to be called as functions so he choose inline-assembly.