x264 + MEncoder + Core 2 = Crash

[LoRd_MuldeR]

Hi.

I have the following problem: Every time I try to use the x264 encoder via MEncoder on my new Core 2 Quad system (WindowsXP x64) it simply crashes on me. Happens with older builds and up-to-date builds. I tried with the different builds by Celtic Druid (http://tirnanog.fate.jp/mirror/mplayer/) (all the CPU types, including the Runtime Detection build) as well as the oss.netfarm.it (http://oss.netfarm.it/mplayer-win32.php) builds. But always the same result: Windows just pops up one of those "MEncoder.exe has encountered a problem and needs to close..." messages. Also tried with a debugger and got some "Access violation at address 0x12345678" error. Looks I'm not alone with that problem:

http://celticdruid.no-ip.com/phpBB3/viewtopic.php?f=9&t=278

Encoding via x264.exe or via Avidemux works like a charm :confused:

[buzzqw]

do you specify the parameter threads ?

i have a simple p4 northwood but using threads=auto i got no problem

BHH

[LoRd_MuldeR]

do you specify the parameter threads ?

i have a simple p4 northwood but using threads=auto i got no problem

BHH

I did not use any parameters, except the mandatory ones. So everything should be at default. Also threads should default to "auto" if I don't specify anything else. My commandline was something like:

MEncoder.exe -o c:\out.avi -oac pcm -ovc x264 -x264encopts crf=22 c:\input.mpg


Just for notice: In Avidemux I can choose "Auto Detect" for x264 and it will encode with all 4 cores at 100%. Same for x264.exe without "--threads" parameter specified (auto detect). Furthermore x264 will use all my CPU capabilities, like MMX, SSE, SSE2, SSSE3, when using Avidemux or x264.exe.

[buzzqw]

tried with bitrate parameter ? (not crf ?)

BHH

[LoRd_MuldeR]

http://img508.imageshack.us/img508/9181/filex264crashzy5.png (http://imageshack.us)
http://img508.imageshack.us/img508/9181/filex264crashzy5.878d47a5d4.jpg (http://g.imageshack.us/g.php?h=508&i=filex264crashzy5.png)

[Sharktooth]

uhm... build it without pthread and see if it still crashes (however it wont use multiple encoding threads...)

[LoRd_MuldeR]

Why do you think the problem is related to threads?
Threads do work 100% fine with x264.exe as well as with Avidemux. And they all are built with pthread as far as I know...

http://img512.imageshack.us/img512/967/filex264admye7.th.png (http://img512.imageshack.us/my.php?image=filex264admye7.png)

[Sharktooth]

just a try

[akupenguin]

build x264 with "CFLAGS=-O0 ./configure --enable-debug", link mencoder to that version, run with noasm, look at the gdb backtrace.

[LoRd_MuldeR]

build x264 with "CFLAGS=-O0 ./configure --enable-debug", link mencoder to that version, run with noasm, look at the gdb backtrace.

If I knew how to do that, I would :confused:

BTW: Are there any Core 2 (Quad) users who actually got that working ???

[LoRd_MuldeR]

Using gdb, I get this, even without passing any paramters to Mencoder :(

http://img517.imageshack.us/img517/6969/filex264gdbxo5.png (http://imageshack.us)
http://img517.imageshack.us/img517/6969/filex264gdbxo5.f9ab03e32c.jpg (http://g.imageshack.us/g.php?h=517&i=filex264gdbxo5.png)


[EDIT]

I fact this happens with all executables I try to run with gdb ?!?!
So far I tried gdb v5.2.1-1 and v6.3-1 ...

[morph166955]

Correct me if im wrong here, but isnt mplayer/mencoder a 32-bit program and if im not mistaken doesn't it have issues when running on 64-bit os's? I know when I compile it on my x86_64 bit linux I have to do so in 32-bit mode so that it works properly. Where did you get the mencoder/mplayer build itself from?

[nm]

I have been running 64-bit builds of MPlayer and MEncoder + x264 without problems for two or three years on Linux. What kind of issues have you had (except for binary win32/quicktime codecs, which are rarely needed anyway)?

[LoRd_MuldeR]

Correct me if im wrong here, but isnt mplayer/mencoder a 32-bit program and if im not mistaken doesn't it have issues when running on 64-bit os's?

No. 32-Bit programs do run just fine under Windows x64. Actually most applications under Windows x64 are still 32-Bit programs. I can run a 32-Bit build of x264.exe or Avidemux without problem. Only MEncoder crashes for some reason...

[DarkZell666]

Hmm I recently had some wierd crashes with mencoder's x264 on my C2D E6420 (2 cores) as well using the cpu auto-detection build, I'll try again this evening :). I'm running on 32bit WinXP though ... (and I didn't even know 64bit XP would run on a C2D, I gotta try that too some day ;)).

[LoRd_MuldeR]

(and I didn't even know 64bit XP would run on a C2D, I gotta try that too some day ;)).

Core 2 is a 64-Bit architecture. Actually it's the good old x86 architecture with a 64-Bit extension. Intel calls that architecture "Intel 64" (formerly known as "EMT64"). AMD, who initially invented this architecture, calls the same thing "AMD64" (formerly known as "x86_64"). To make it even more confusing, M$ uses the name "x64". So all "x64" Windows versions (Windows XP x64-Edition, Windows Vista x64) will run on "AMD64" CPU's as well as on "Intel 64" CPU's. And most important: 32-Bit applications will run 100% fine on x64 Windows. Well, all except MEncoder :p

Also note that Intel's "AI-64" architecture is a completely different architecture, which is absolutely incompatible to x86 and x64. That's why it never had wide success and Intel finally switched to AMD's approach: Extend x86 and keep backward-compatibility, instead of creating a completely new architecture from the scratch...

Back to topic: How do I get MEncoder to run? ^^

[Yong]

hmm, try disable subq or 8x8dct?
i also got this problem too :p
http://forum.doom9.org/showpost.php?p=952970&postcount=15

[LoRd_MuldeR]

hmm, try disable subq or 8x8dct?
i also got this problem too :p
http://forum.doom9.org/showpost.php?p=952970&postcount=15

Thanks for the hint, but it doesn't help :(

I tried with this cmdline:
>MEncoder.exe -o c:\Temp\test.avi -ovc x264 -oac pcm -x264encopts no8x8dct:crf=22 D:\_Temp\input.avi

Same crash as usual ...

[DarkZell666]

I just tried all CD's builds from 2007-08-19, and I indeed need subq=1:no8x8dct together to get them not to crash (either option alone doesn't fix it). The real question now is why and what to do about it ? :rolleyes:

Edit: builds here http://oss.netfarm.it/mplayer-win32.php work with 8x8dct:subq=7 for me though ... (p4 p3 and rtm builds with precompiled xvid and x264 work like a charm). Except those are quite "old" (build 23404 from May 29th.)

Edit2: CD's builds from around the same date (2007.05.23 2007.04.25) don't work though ...

[LoRd_MuldeR]

I just tried all CD's builds from 2007-08-19, and I indeed need subq=1:no8x8dct together to get them not to crash (either option alone doesn't fix it). The real question now is why and what to do about it ? :rolleyes:

You are right: Both options disabled and it does not crash :)

http://img507.imageshack.us/img507/3353/filex264workingei8.png

[Yong]

tested on celeron 1.2ghz with these options,
bitrate=400:keyint=400:frameref=5:bframes=3:b_adapt:b_pyramid:deblock=-3,-3:cabac:direct_pred=auto:weight_b:partitions=all:8x8dct:subq=6:chroma_me:mixed_refs:brdo:bime:trellis=2:me=umh
no crash :D
video source is youtube video(h263 @ 320x240), mencoder build is r23833-4.2.0(celtic druid)

[DarkZell666]

Actually, does anyone else with a C2D/C2Q manage to get mencoder's x264 to work with LoRd_MuldeR's simple command-line ?

If so, what builds ? I'm surprised to see so few complaints about the problem, it seems we're like a maximum of 5 people having it (and obviously, googling "mencoder x264 crash" links directly to this topic :D).

I also noticed something else this morning in fact : the encoding always crashed on frame 4 of my source file (I only tried a single source file btw). Frame 4 could be the first occurence of either a P or a B frame imho, and my command-line was a bit more complex than that (it had some brdo and trellis stuff inside too, as well as bframes=3 ... which makes me think frame 4 was the last b-frame before the first p-frame actually ... is IBBBP a valid stream start ?). I gotta try gdb and filemon, and actually try other sources just in case ...

[LoRd_MuldeR]

I gotta try gdb and filemon, and actually try other sources just in case ...

Can you give me some hint on how to run MEncoder with gdb?

I tried to run gdb form MinGW\Bin dir:

>cd MingGW\bin
>gdb.exe c:\Parth_to_MEncoder\MEncoder.exe

As well as from MEncoder dir:
>cd Path_to_MEncoder
>c:\MingGW\bin\gdb.exe MEncoder.exe

But in both cases, as soon as I type run, gdb simply crashes :confused:

[DarkZell666]

I would expect for gdb to work properly that mencoder should be compiled with extra debugging info inside it (the console seems to say so anyway).

It seems to launch for me though, I can run "gdb.exe mencoder.exe" and I get some sort of "gdb command prompt" with which I don't have the slightest clue what to do :P (no crash, it just sits there waiting for something to happen).

Edit: here is what I get after typing "run myinput.avi -ovc x264 -oac pcm -x264encopts crf=20 -o myoutput.avi" : (RTFM does help lol)

F:\mystuff>C:\MinGW\bin\gdb.exe "mencoder.exe"
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(no debugging symbols found)
<i -oac pcm -ovc x264 -x264encopts crf=20 -o whateveroutput.avi
Starting program: f:\cli/mencoder.exe whateverinput.avi -oac pcm -ovc x264 -x264
encopts crf=20 -o whateveroutput.avi
Loaded symbols for C:\WINDOWS\system32\ntdll.dll
Loaded symbols for C:\WINDOWS\system32\kernel32.dll
Loaded symbols for C:\WINDOWS\system32\advapi32.dll
Loaded symbols for C:\WINDOWS\system32\rpcrt4.dll
Loaded symbols for C:\WINDOWS\system32\msvcrt.dll
Loaded symbols for C:\WINDOWS\system32\ole32.dll
Loaded symbols for C:\WINDOWS\system32\gdi32.dll
Loaded symbols for C:\WINDOWS\system32\user32.dll
Loaded symbols for f:\cli\pthreadGC2.dll
Loaded symbols for C:\WINDOWS\system32\wsock32.dll
Loaded symbols for C:\WINDOWS\system32\ws2_32.dll
Loaded symbols for C:\WINDOWS\system32\ws2help.dll
Loaded symbols for C:\WINDOWS\system32\winmm.dll
MEncoder dev-SVN-r24100-4.2.1 (C) 2000-2007 MPlayer Team
CPU: Intel(R) Core(TM)2 CPU 6420 @ 2.13GHz (Family: 6, Model: 15, Step
ping: 6)
CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2

113 audio & 235 video codecs
success: format: 0 data: 0x0 - 0x2236e32
AVI file format detected.
[aviheader] Video stream found, -vid 0
[aviheader] Audio stream found, -aid 1
VIDEO: [XVID] 704x396 24bpp 30.000 fps 3967.0 kbps (484.2 kbyte/s)
[V] filefmt:3 fourcc:0x44495658 size:704x396 fps:30.00 ftime:=0.0333
==========================================================================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
AUDIO: 48000 Hz, 2 ch, s16le, 128.0 kbit/8.33% (ratio: 16000->192000)
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
==========================================================================
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1, osd: 1, aspect: 0.000000, round: 1
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4)
==========================================================================
VDec: vo config request - 704 x 396 (preferred colorspace: Planar YV12)
VDec: using Planar I420 as output csp (no 1)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
x264 [warning]: width or height not divisible by 16 (704x396), compression will
suffer.
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSSE3
Pos: 0.0s 1f ( 0%) 0.00fps Trem: 0min 0mb A-V:0.000 [0:0]
Program received signal SIGSEGV, Segmentation fault.
0x00a247b2 in ?? ()
(gdb)

[LoRd_MuldeR]

When it crashes, type "bt" for a full backtrace.

The problem is, I don't get to this point. Which build did you use?

[DarkZell666]

My gdb build was this one : http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=20507&release_id=53765
This happens on CD's mplayer builds (after double check the ossfarm.it builds work just normally even via gdb).

And here's the backtrace from gdb that goes with a build I can't identify since I can't reproduce it :
==========================================================================
VDec: vo config request - 704 x 396 (preferred colorspace: Planar YV12)
VDec: using Planar I420 as output csp (no 1)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
x264 [warning]: width or height not divisible by 16 (704x396), compression will
suffer.
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSSE3
Pos: 0.0s 1f ( 0%) 0.00fps Trem: 0min 0mb A-V:0.000 [0:0]
Program received signal SIGSEGV, Segmentation fault.
0x00a247b2 in ?? ()
(gdb) bt
#0 0x00a247b2 in ?? ()
#1 0x0022ce90 in ?? ()
#2 0x009cec7e in ?? ()
#3 0x0022ceb8 in ?? ()
#4 0x00000020 in ?? ()
#5 0x01a1c520 in ?? ()
#6 0x00000010 in ?? ()
#7 0x00000008 in ?? ()
#8 0xc26e1032 in ?? ()
#9 0x434fa979 in ?? ()
#10 0x003d0000 in ?? ()
#11 0x0022cc2c in ?? ()
#12 0xc252c60c in ?? ()
#13 0x0022d06c in ?? ()
#14 0x7c91ee18 in strchr () from C:\WINDOWS\system32\ntdll.dll
#15 0x00000d08 in ?? ()
#16 0xffffffff in ?? ()
#17 0x7c92b686 in wcsncat () from C:\WINDOWS\system32\ntdll.dll
#18 0x7c92b298 in wcsncat () from C:\WINDOWS\system32\ntdll.dll
#19 0x003d0000 in ?? ()
#20 0x01a74200 in ?? ()
#21 0x00000000 in ?? ()
(gdb)

I don't have a clue what it means, except that the call stack went through some windows system dll's before crashing.

Here's the backtrace from CD's latest RTM build :
Program received signal SIGSEGV, Segmentation fault.
0x00a02fa2 in ?? ()
(gdb) bt
#0 0x00a02fa2 in ?? ()
#1 0x0022cea0 in ?? ()
#2 0x009afeb0 in ?? ()
#3 0x0022cec8 in ?? ()
#4 0x00000020 in ?? ()
#5 0x019fc520 in ?? ()
#6 0x00000010 in ?? ()
#7 0x00000008 in ?? ()
#8 0xc252c60c in ?? ()
#9 0x420fab52 in ?? ()
#10 0xc1383357 in ?? ()
#11 0xc1bef1e2 in ?? ()
#12 0x41f9379d in ?? ()
#13 0x4104aa97 in ?? ()
#14 0x003d0000 in ?? ()
#15 0x0022cc3c in ?? ()
#16 0x00000000 in ?? ()
(gdb)

Gotta build some debug-aware mplayer/mencoder version now ... (I'll read more on that tomorrow, unless you or someone else has all the stuff installed for doing it).

[LoRd_MuldeR]

Sorry, I'm a complete Noob on building MEncder/MPlayer. I usually just grab the builds from Celtic Druid. I have MinGW installed, but the last time I tried to compile MPlayer myself, some dependencies were missing (at least I think that was the problem) and I didn't figure out what exactly was missing, nor where to get it, nor where to put it. I should have a deeper look at this, when I have more time ...

[akupenguin]

In order to get a meaningful backtrace, you need to compile with debugging support. Which means you can't use one of the standard mencoder win32 binaries.

subq=1:no8x8dct
This indicates that the crash is in satd.

Now try -x264encopts noasm

[DarkZell666]

Indeed, noasm makes CD's builds work (2x slower but hey, it works :D)
But why do ossfarm.it builds work and not CelticDruid's ? (considering I tried CD's from around the same date as ossfarm's and they had the same problem as now, already at that time ...).

Sorry, I'm a complete Noob on building MEncder/MPlayer. Well, we're 2 then :p I've got to learn to build my own stuff and I think now is the right time :)

*off to bed, got enough sleep to catch upon already :D*

[LoRd_MuldeR]

But why do ossfarm.it builds work and not CelticDruid's?

As mentioned before, I tried with ossfarm.it builds and it crashed too.

I can confirm that noasm avoids the crash. So this indicates it's some of x264's Assembler Code that causes the crash. But why in the world the Assembler Code does crash in MEncoder when it works 100% fine in x264.exe and Avidemux? AFAIK Celtic Druid builds MEncoder with latest x264 SVN, so there should be no difference to x264.exe from x264.nl, right? Avidemux also uses latest SVN of x264.

And still no explanation why gdb crashes here. Even with a "normal" build of MEncoder the gdb shouldn't simply crash...

[DarkZell666]

Well, I'm up to almost nowhere building mplayer yet :confused:

Here's what I did :

- Got mplayer sources from svn
- Installed mingw 5.1.2
- Installed msys 1.0 because the howto I found told me to (you'll smile in a couple of lines ...).
- Copied mplayer sources into c:/msys/1.0/home/myusername/
- Went to the mplayer sources directory and did "./configure --prefix=/mingw" and it answered in the end "*** Please downgrade/upgrade C compiler to version gcc-2.95, 3.x or 4.x! ***".
- Since I couldn't find an easy-to-install gcc 4.x package from the mingw download page and that I learnt that msys was a fork from cygwin, I went on and installed cygwin instead, which seems to work a bit better (it recognizes gcc 5.x anyway).
- I did "mount c:/mingw /mingw"
- Copied the sources over again to c:/cygwin/home/myusername
- Went there and did ./configure --prefix=/mingw (which worked !).
- Launched "make" and watched gazillions of warnings about defined but unused functions, and redundant declarations ...
To finally end on :

cc -o mplayer.exe osdep/mplayer-rc.o mplayer.o m_property.o mp_fifo.o mp_msg.o m
ixer.o parser-mpcmd.o subopt-helper.o command.o asxparser.o codec-cfg.o cpudetec
t.o edl.o find_sub.o m_config.o m_option.o m_struct.o mpcommon.o parser-cfg.o pl
aytree.o playtreeparser.o spudec.o sub_cc.o subreader.o vobsub.o unrarlib.o libv
o/libvo.a libao2/libao2.a input/libinput.a vidix/libvidix.a libmpcodecs/libmpcod
ecs.a libaf/libaf.a libmpdemux/libmpdemux.a stream/stream.a libswscale/libswscal
e.a libvo/libosd.a libavformat/libavformat.a libavcodec/libavcodec.a libavutil/l
ibavutil.a libpostproc/libpostproc.a loader/libloader.a mp3lib/libmp3.a liba52/l
iba52.a libmpeg2/libmpeg2.a libfaad2/libfaad2.a tremor/libvorbisidec.a dvdread/l
ibdvdread.a libdvdcss/libdvdcss.a libass/libass.a osdep/libosdep.a -lXext -lX11
-lGL -lgdi32 -lggi -lggiwmh -laa -laa -lX11 -lncurses -lwinmm -lesd -laudiofile
-lm -L/usr/lib -L/usr/X11R6/lib -lwinmm -liconv -lncurses -lpng -lz -ljpeg -lu
ngif -lfreetype -lz -lfontconfig -lz -lspeex -ladvapi32 -lole32 -lm
libavcodec/libavcodec.a(mpegaudiodec.o):mpegaudiodec.c:(.text+0x5e0): undefined
reference to `_llrint'
Info: resolving _aa_defrenderparams by linking to __imp__aa_defrenderparams (aut
o-import)
Info: resolving _aa_defparams by linking to __imp__aa_defparams (auto-import)
Info: resolving _aa_displayrecommended by linking to __imp__aa_displayrecommende
d (auto-import)
Info: resolving _aa_help by linking to __imp__aa_help (auto-import)
Info: resolving _speex_wb_mode by linking to __imp__speex_wb_mode (auto-import)
Info: resolving _speex_uwb_mode by linking to __imp__speex_uwb_mode (auto-import
)
Info: resolving _speex_nb_mode by linking to __imp__speex_nb_mode (auto-import)
collect2: ld returned 1 exit status
make: *** [mplayer.exe] Error 1

freak2fast4u@xas ~/mplayer-src
I'm cursed, any pointers as to what could be going on or what I might have forgotten ?

Actually, I fear in advance enabling the debugging when I will have gotten this to work because they say this :cabac.h:526: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'

* On x86, you can't compile mplayer after configuring with --enable-debug, because cabac.h in libavcodec can't be compiled with all optimizations when debugging is turned on.

Three possible solutions:

1. Don't configure with enable-debug
2. Use -fomit-frame-pointer: Copy the line beginning with "cc" ending with "-c -o h264.o h264.c" (from make output immediately above the error) and add "-fomit-frame-pointer": This might affect debugging for h264.o
3. Don't compile the optimized code: Add "#undef HAVE_EBX_AVAILABLE" to libavcodec/cabac.h

I'm gonna try harder, but any friendly hints are welcome ...

[nm]

Try this patch: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-September/016213.html

[Yong]

looks like some kind of "shared-libs" problem :p
what i found out in mpegaudiodec.c and math.h is, it does have llrint, but without underscore...

[Yong]

ok just compiled mencoder with x264 in debug mode,
here is the binary for win32:p
http://y0ngc6.googlepages.com/mencoder_debug.7z

this build is for debugging x264 only, was build without ffmpeg, except libavutil.
it should work with mpeg1/2 input.
it doesnt crash for me, so if someone have gdb, please test it;)

[LoRd_MuldeR]

ok just compiled mencoder with x264 in debug mode,
here is the binary for win32:p
http://y0ngc6.googlepages.com/mencoder_debug.7z

this build is for debugging x264 only, was build without ffmpeg, except libavutil.
it should work with mpeg1/2 input.
it doesnt crash for me, so if someone have gdb, please test it;)

Thanks a lot, this build seems to work 100% fine, except multi-threading seems to be disabled.

My commandline:
>mencoder_debug.exe -ovc x264 -oac pcm -o c:\Temp\Test.avi -x264encopts crf=22:me=umh:ref=8:8x8dct:subme=7:brdo:mixed_refs:threads=6 d:\_VIDEO_20070822_204332.mpg

Doesn't crash :)

[DarkZell666]

Right, here's some interesting info (at last :D).

@nm : thx for the patch, that did the trick ;)

I managed to build mencoder with x264, xvid, and pthreads !

First I did it with x264 r656M from oss.netfarm.it. That build works.
Then I tried with the latest x264 tarball from yesterday 22:45. That build ... crashes.

Get both of them here and compare : http://xeoteam.info/d9/

They don't have debugging enabled yet, but some kind soul on #mplayer@freenode.net said that mplayer with pthreads on win32 hasn't been officially tested. So I need to do the following now :
- Rebuild both without pthreads
- Rebuild the 4 previous builds each with debugging enabled.
- Try other tarballs from a date close to r656 and see where it starts b0rking.
I hope there aren't too many headaches ahead, but we're getting there ;)

@Yong : did you do anything special to enable debugging ? I read there could be some trouble with cabac (see my last post below). Please prove me wrong =) (btw, expectedly, your build doesn't crash for me either).

[Yong]

@DarkZell666/LoRd_MuldeR:
my mencoder was build without libavcodec/libavformat and pthread, nothing special, gcc is 4.2.1sjlj downloaded form mingw.org :p

im just updated the mplayer source code, trying to complie a normal build with pthread,
but now cant compile it anymore:devil:
its either stuck at "creating config.mak" or config.h...:confused:

[nm]

Maybe you already have those files from the last compile with read-only permissions? Remove them manually before running configure.

[Yong]

Maybe you already have those files from the last compile with read-only permissions? Remove them manually before running configure.
nope thats not the problem,
lol i think i need a faster cpu/patience to compile stuffs:D

ok here is the new build,pls test it :p
http://y0ngc6.googlepages.com/mencoder-r24210-gcc4.2.1sjlj.7z
still without libavcodec/format, but now its compiled with x264 with pthreads.
avisynth should work with it.
judging from the x264 encoding fps, my compile seems a little bit faster than celtic druid build:p

if my build doesnt crash, thats mean its prolly cause by the gcc version.

EDIT:my build is faster, obviously cause by the cache effect, stupid me :p

[LoRd_MuldeR]

nope thats not the problem,
lol i think i need a faster cpu/patience to compile stuffs:D

ok here is the new build,pls test it :p
http://y0ngc6.googlepages.com/mencoder-r24210-gcc4.2.1sjlj.7z
still without libavcodec/format, but now its compiled with x264 with pthreads.
avisynth should work with it.
judging from the x264 encoding fps, my compile seems a little bit faster than celtic druid build:p

if my build doesnt crash, thats mean its prolly cause by the gcc version.

EDIT:my build is faster, obviously cause by the cache effect, stupid me :p

Great!

This build works stable with all options I have tested and it uses all 4 cores now :)

>mencoder.exe -o c:\Temp\Test.avi -oac pcm -ovc x264 -x264encopts crf=22:me=umh:bframes=3:subme=7:brdo:ref=6:mixed_refs:threads=6 d:\_VIDEO_20070822_204332.mpg

[Jjeje007]

Hi,

I've got also an segfault with mencoder + x264 + core 2 duo
Mencoder and x264 compil from subversion (I'm running Gentoo Linux)

I did an gdb backtrace :

gdb mencoder
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run MOVIE.EVO -vc ffvc1 -fps 24000/1001 -of rawvideo -ofps 24000/1001 -ovc x264 -x264encopts bitrate=3878:pass=1:subq=4:me=dia:frameref=5:bframes=2:b_pyramid:weight_b:direct_pred=auto:partitions=all:qcomp=0.75:ip_factor=1.10:pb_factor=1.40:threads=2 -vf crop=1920:784:0:148 -nosound -o /dev/null
Starting program: /usr/bin/mencoder MOVIE.EVO -vc ffvc1 -fps 24000/1001 -of rawvideo -ofps 24000/1001 -ovc x264 -x264encopts bitrate=3878:pass=1:subq=4:me=dia:frameref=5:bframes=2:b_pyramid:weight_b:direct_pred=auto:partitions=all:qcomp=0.75:ip_factor=1.10:pb_factor=1.40:threads=2 -vf crop=1920:784:0:148 -nosound -o /dev/null
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
MEncoder dev-SVN-r24537 (C) 2000-2007 MPlayer Team
CPU: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz (Family: 6, Model: 15, Stepping: 6)
CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compilé avec détection du CPU à l'exécution.115 codecs audio & 236 codecs vidéo
succès : format : 0 data : 0x0 - 0x5bca1000
Fichier de type MPEG-PS détecté.
Searching for VC1 sequence header... found
VIDEO: VC-1 1920x1080, 29.970 fps, header len: 33
[V] filefmt:2 fourcc:0x31435657 size:1920x1080 fps:29.97 ftime:=0.0334
Le fps d'entrée sera plutôt interprété comme 23.98
Ouverture du filtre vidéo : [expand osd=1]
Expand: -1 x -1, -1 ; -1, osd: 1, aspect: 0.000000, round: 1
Ouverture du filtre vidéo : [crop w=1920 h=784 x=0 y=148]
Crop: 1920 x 784, 0 ; 148
==========================================================================
Codec vidéo forcé : ffvc1
Ouverture du décodeur vidéo : [ffmpeg] FFmpeg's libavcodec codec family
Codec vidéo choisi : [ffvc1] vfm : ffmpeg (FFmpeg M$ WVC1)
==========================================================================
VDec : requête de config de vo - 1920 x 1080 (espace colorimétrique préferé : Planar YV12)
VDec: using Planar I420 as output csp (no 1)
L'aspect du film est 1.78:1 - pré-redimensionnement à l'aspect correct.
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSSE3
New_Face failed. Maybe the font path is wrong.
Please supply the text font file (~/.mplayer/subfont.ttf).
subtitle font: load_sub_face failed.
Pos: 0.0s 3f ( 0%) 0.00fps Trem: 0min 0mb A-V:0.000 [0:0]
Program received signal SIGSEGV, Segmentation fault.
0xb7f5e84e in x264_pixel_satd_8x8_ssse3 () from /usr/lib/libx264.so.56
(gdb) quit
The program is running. Exit anyway? (y or n) y


So it look like the segfault is related to ssse3

Should I do an bug report ?

Edit : x264 rev 676

Jjeje007

[akupenguin]

Yes please.
backtrace / disassembly / registers
does it depend on input, or does everything crash?
how about x264cli?

[Jjeje007]

does it depend on input, or does everything crash?

It doesn't depend on input, everything crash :(

backtrace / disassembly / registers

Hum, i never done that before, but i'll try.

how about x264cli?

Edit : Segfault as well :( :

gdb x264
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run -o outfile.264 test.yuv 720x480 -p 1 -B 1000
Starting program: /usr/bin/x264 -o outfile.264 test.yuv 720x480 -p 1 -B 1000
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSSE3

Program received signal SIGSEGV, Segmentation fault.
0x080be91e in x264_pixel_satd_8x8_ssse3 ()


And ssse3 again

Any way, i'm almost sure at 99% it is related to ssse3 because i have an another pc which run exactly the same revision (mencoder, ffmpeg, x264) and the same system (Gentoo Linux) but it doesn't have ssse3 support (and everything is working well)
By the way, i just tried with ffmpeg and it segfault as well :(

[LoRd_MuldeR]

The new builds finally fixed the crash :D :D :D
http://oss.netfarm.it/mplayer-win32.php

At least I cannot reproduce any crash on my Core2 Quad with the latest builds!
Now I hope Celtic Druid will fix his builds too ...

[Jjeje007]

The new builds finally fixed the crash :D :D :D
http://oss.netfarm.it/mplayer-win32.php

At least I cannot reproduce any crash on my Core2 Quad with the latest builds!
Now I hope Celtic Druid will fix his builds too ...

And the encoder use ssse3 ?

Now, i'm sure at 100% this is cause by ssse3, because i compil the "official" x264-svn (20070325) from portage (x264 core:54 svn-635M) and with this build, there is no problem BUT ssse3 is NOT enable :mad: :

x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2

Also, I did an diff between the rev 635(M?) and the actuall rev (at least) 676 and "grep ssse3" :

diff -ru x264/ x264-svn-20070325/ | grep ssse3
+cglobal x264_pixel_satd_8x4_ssse3
+cglobal x264_pixel_satd_8x8_ssse3
+cglobal x264_pixel_satd_16x8_ssse3
+cglobal x264_pixel_satd_8x16_ssse3
+cglobal x264_pixel_satd_16x16_ssse3
+cglobal x264_pixel_sa8d_8x8_ssse3
+cglobal x264_pixel_sa8d_16x16_ssse3
+cglobal x264_quant_4x4_dc_core15_ssse3
+cglobal x264_quant_4x4_core15_ssse3
+cglobal x264_quant_8x8_core15_ssse3
+; void x264_quant_4x4_dc_core15_ssse3( int16_t dct[4][4],
+x264_quant_4x4_dc_core15_ssse3:
+; void x264_quant_4x4_core15_ssse3( int16_t dct[4][4],
+x264_quant_4x4_core15_ssse3:
+; void x264_quant_8x8_core15_ssse3( int16_t dct[8][8],
+x264_quant_8x8_core15_ssse3:
-QUANT_SSE ssse3
+cglobal x264_pixel_satd_8x4_ssse3
+cglobal x264_pixel_satd_8x8_ssse3
+cglobal x264_pixel_satd_16x8_ssse3
+cglobal x264_pixel_satd_8x16_ssse3
+cglobal x264_pixel_satd_16x16_ssse3
+cglobal x264_pixel_sa8d_8x8_ssse3
+cglobal x264_pixel_sa8d_16x16_ssse3
+cglobal x264_quant_4x4_dc_core15_ssse3
+cglobal x264_quant_4x4_core15_ssse3
+cglobal x264_quant_8x8_core15_ssse3
+; void x264_quant_4x4_dc_core15_ssse3( int16_t dct[4][4],
+x264_quant_4x4_dc_core15_ssse3:
+; void x264_quant_4x4_core15_ssse3( int16_t dct[4][4],
+x264_quant_4x4_core15_ssse3:
+; void x264_quant_8x8_core15_ssse3( int16_t dct[8][8],
+x264_quant_8x8_core15_ssse3:
-QUANT_SSE ssse3
-SATDS ssse3
-QUANT_SSE ssse3
-void x264_quant_4x4_dc_ssse3( int16_t dct[4][4], int mf, int bias );
-void x264_quant_4x4_ssse3( int16_t dct[4][4], uint16_t mf[16], uint16_t bias[16] );
-void x264_quant_8x8_ssse3( int16_t dct[8][8], uint16_t mf[64], uint16_t bias[64] );
+void x264_quant_8x8_core15_ssse3( int16_t dct[8][8],
+void x264_quant_4x4_core15_ssse3( int16_t dct[4][4],
+void x264_quant_4x4_dc_core15_ssse3( int16_t dct[4][4],
-SATDS ssse3
-QUANT_SSE ssse3
-void x264_quant_4x4_dc_ssse3( int16_t dct[4][4], int mf, int bias );
-void x264_quant_4x4_ssse3( int16_t dct[4][4], uint16_t mf[16], uint16_t bias[16] );
-void x264_quant_8x8_ssse3( int16_t dct[8][8], uint16_t mf[64], uint16_t bias[64] );
+void x264_quant_8x8_core15_ssse3( int16_t dct[8][8],
+void x264_quant_4x4_core15_ssse3( int16_t dct[4][4],
+void x264_quant_4x4_dc_core15_ssse3( int16_t dct[4][4],
pixf->satd[PIXEL_16x16]= x264_pixel_satd_16x16_ssse3;
pixf->satd[PIXEL_16x8] = x264_pixel_satd_16x8_ssse3;
pixf->satd[PIXEL_8x16] = x264_pixel_satd_8x16_ssse3;
pixf->satd[PIXEL_8x8] = x264_pixel_satd_8x8_ssse3;
pixf->satd[PIXEL_8x4] = x264_pixel_satd_8x4_ssse3;
pixf->sa8d[PIXEL_16x16]= x264_pixel_sa8d_16x16_ssse3;
pixf->sa8d[PIXEL_8x8] = x264_pixel_sa8d_8x8_ssse3;
+ pf->quant_8x8_core = x264_quant_8x8_core15_ssse3;
+ pf->quant_4x4_core = x264_quant_4x4_core15_ssse3;
+ pf->quant_4x4_dc_core = x264_quant_4x4_dc_core15_ssse3;
- pf->quant_4x4_dc = x264_quant_4x4_dc_ssse3;
- pf->quant_4x4 = x264_quant_4x4_ssse3;
- pf->quant_8x8 = x264_quant_8x8_ssse3;
pixf->satd[PIXEL_16x16]= x264_pixel_satd_16x16_ssse3;
pixf->satd[PIXEL_16x8] = x264_pixel_satd_16x8_ssse3;
pixf->satd[PIXEL_8x16] = x264_pixel_satd_8x16_ssse3;
pixf->satd[PIXEL_8x8] = x264_pixel_satd_8x8_ssse3;
pixf->satd[PIXEL_8x4] = x264_pixel_satd_8x4_ssse3;
pixf->sa8d[PIXEL_16x16]= x264_pixel_sa8d_16x16_ssse3;
pixf->sa8d[PIXEL_8x8] = x264_pixel_sa8d_8x8_ssse3;
+ pf->quant_8x8_core = x264_quant_8x8_core15_ssse3;
+ pf->quant_4x4_core = x264_quant_4x4_core15_ssse3;
+ pf->quant_4x4_dc_core = x264_quant_4x4_dc_core15_ssse3;
- pf->quant_4x4_dc = x264_quant_4x4_dc_ssse3;
- pf->quant_4x4 = x264_quant_4x4_ssse3;
- pf->quant_8x8 = x264_quant_8x8_ssse3;


(Don't know if this could help)

Jjeje007

[LoRd_MuldeR]

I get this on my Core2 Quad:
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSSE3

And there is no crash ...

[akupenguin]

@Jjeje007
see http://ffmpeg.mplayerhq.hu/bugreports.html for how to get a disassembly. use x264cli, latest version, configured with --enable-debug.

[Jjeje007]

Hi,

use x264cli, latest version, configured with --enable-debug.

Here we go :

gdb x264
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run -o outfile.264 test.yuv 720x480 -p 1 -B 1000
Starting program: /usr/bin/x264 -o outfile.264 test.yuv 720x480 -p 1 -B 1000
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSSE3

Program received signal SIGSEGV, Segmentation fault.
0x080beabe in x264_pixel_satd_8x8_ssse3 ()
(gdb) bt
#0 0x080beabe in x264_pixel_satd_8x8_ssse3 ()
#1 0x08079698 in x264_slicetype_mb_cost (h=0x80d52f0, a=0xbff24d18, frames=0xbff27594, p0=0, p1=0, b=0, dist_scale_factor=128) at encoder/slicetype.c:206
#2 0x08079950 in x264_slicetype_frame_cost (h=0x80d52f0, a=0xbff24d18, frames=0xbff27594, p0=0, p1=0, b=0, b_intra_penalty=0) at encoder/slicetype.c:304
#3 0x0807b319 in x264_rc_analyse_slice (h=0x80d52f0) at encoder/slicetype.c:530
#4 0x08099c15 in rate_estimate_qscale (h=0x80d52f0) at encoder/ratecontrol.c:1344
#5 0x0809a677 in x264_ratecontrol_start (h=0x80d52f0, i_force_qp=0) at encoder/ratecontrol.c:692
#6 0x08055fdc in x264_encoder_encode (h=0x80d52f0, pp_nal=0xbff278f8, pi_nal=0xbff278f4, pic_in=0xbff27e38, pic_out=0xbff278b8) at encoder/encoder.c:1411
#7 0x0804c7af in Encode_frame (h=0xbff24b68, hout=0x80d5008, pic=0x80d7880) at x264.c:714
#8 0x0804d431 in main (argc=9, argv=0xbff27f44) at x264.c:797
#9 0x49260fd8 in __libc_start_main () from /lib/libc.so.6
#10 0x0804bbf1 in _start ()
(gdb) disass $pc-32 $pc+32
Dump of assembler code from 0x80bea9e to 0x80beade:
0x080bea9e <x264_pixel_satd_8x8_ssse3+606>: paddusw %mm1,%mm0
0x080beaa1 <x264_pixel_satd_8x8_ssse3+609>: paddusw %xmm3,%xmm2
0x080beaa5 <x264_pixel_satd_8x8_ssse3+613>: paddusw %xmm0,%xmm6
0x080beaa9 <x264_pixel_satd_8x8_ssse3+617>: paddusw %xmm2,%xmm6
0x080beaad <x264_pixel_satd_8x8_ssse3+621>: psrlw $0x1,%xmm6
0x080beab2 <x264_pixel_satd_8x8_ssse3+626>: call 0x80beab7 <x264_pixel_satd_8x8_ssse3+631>
0x080beab7 <x264_pixel_satd_8x8_ssse3+631>: pop %ebx
0x080beab8 <x264_pixel_satd_8x8_ssse3+632>: add $0xd1f3,%ebx
0x080beabe <x264_pixel_satd_8x8_ssse3+638>: pmaddwd 0xffffe84c(%ebx),%xmm6
0x080beac6 <x264_pixel_satd_8x8_ssse3+646>: movhlps %xmm6,%xmm7
0x080beac9 <x264_pixel_satd_8x8_ssse3+649>: paddd %xmm7,%xmm6
0x080beacd <x264_pixel_satd_8x8_ssse3+653>: pshuflw $0xe,%xmm6,%xmm7
0x080bead2 <x264_pixel_satd_8x8_ssse3+658>: paddd %xmm7,%xmm6
0x080bead6 <x264_pixel_satd_8x8_ssse3+662>: movd %xmm6,%eax
0x080beada <x264_pixel_satd_8x8_ssse3+666>: pop %ebx
0x080beadb <x264_pixel_satd_8x8_ssse3+667>: ret
0x080beadc <x264_pixel_satd_8x8_ssse3+668>: lea 0x0(%esi),%esi
End of assembler dump.
(gdb) info all-registers
eax 0xbff24b68 -1074640024
ecx 0x80d7880 135100544
edx 0x10 16
ebx 0x80cbcaa 135052458
esp 0xbff24978 0xbff24978
ebp 0xbff24c78 0xbff24c78
esi 0xbff24a68 -1074640280
edi 0x80d52f0 135090928
eip 0x80beabe 0x80beabe <x264_pixel_satd_8x8_ssse3+638>
eflags 0x210206 [ PF IF RF ID ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
st0 -nan(0x1f001f001f001f0) (raw 0xffff01f001f001f001f0)
st1 -nan(0x1f001f001f001f0) (raw 0xffff01f001f001f001f0)
st2 <invalid float value> (raw 0xffff0000000000000000)
st3 -nan(0x2000000000) (raw 0xffff0000002000000000)
st4 <invalid float value> (raw 0xffff0000000000000000)
st5 -nan(0xf0f0f0f0f0f0f0f) (raw 0xffff0f0f0f0f0f0f0f0f)
st6 -nan(0xf000f000f000f) (raw 0xffff000f000f000f000f)
st7 <invalid float value> (raw 0xffff0000000000000000)
fctrl 0x37f 895
fstat 0x20 32
ftag 0xaaaa 43690
fiseg 0x73 115
fioff 0x8099b0d 134847245
foseg 0x7b 123
fooff 0xbff27688 -1074628984
fop 0x55d 1373
xmm0 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x8, 0x0, 0x0, 0x0, 0x8, 0x0, 0x0, 0x0}, v4_int32 = {
0x8, 0x0, 0x8, 0x0}, v2_int64 = {0x8, 0x8}, uint128 = 0x00000000000000080000000000000008}
xmm1 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x4, 0x0, 0x0, 0x0}, v4_int32 = {
0x0, 0x0, 0x4, 0x0}, v2_int64 = {0x0, 0x4}, uint128 = 0x00000000000000040000000000000000}
xmm2 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x8, 0x0, 0x0, 0x0, 0x8, 0x0, 0x0, 0x0}, v4_int32 = {
0x8, 0x0, 0x8, 0x0}, v2_int64 = {0x8, 0x8}, uint128 = 0x00000000000000080000000000000008}
xmm3 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x8, 0x0, 0x0, 0x0, 0x4, 0x0, 0x0, 0x0}, v4_int32 = {
0x8, 0x0, 0x4, 0x0}, v2_int64 = {0x8, 0x4}, uint128 = 0x00000000000000040000000000000008}
xmm4 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0xfc, 0xff, 0x0 <repeats 14 times>}, v8_int16 = {0xfffc, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0xfffc, 0x0, 0x0, 0x0}, v2_int64 = {0xfffc,
0x0}, uint128 = 0x0000000000000000000000000000fffc}
xmm5 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x10, 0x10, 0xf, 0xf, 0xf, 0xf, 0x10, 0x10, 0xf, 0xf, 0xf, 0xf, 0x10, 0x10, 0xf, 0xf}, v8_int16 = {0x1010, 0xf0f, 0xf0f, 0x1010, 0xf0f, 0xf0f,
0x1010, 0xf0f}, v4_int32 = {0xf0f1010, 0x10100f0f, 0xf0f0f0f, 0xf0f1010}, v2_int64 = {0x10100f0f0f0f1010, 0xf0f10100f0f0f0f}, uint128 = 0x0f0f10100f0f0f0f10100f0f0f0f1010}
xmm6 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x10, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x10, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0},
v4_int32 = {0x10, 0x0, 0x10, 0x0}, v2_int64 = {0x10, 0x10}, uint128 = 0x00000000000000100000000000000010}
xmm7 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},
uint128 = 0x00000000000000000000000000000000}
mxcsr 0x1f80 [ IM DM ZM OM UM PM ]
mm0 {uint64 = 0x1f001f001f001f0, v2_int32 = {0x1f001f0, 0x1f001f0}, v4_int16 = {0x1f0, 0x1f0, 0x1f0, 0x1f0}, v8_int8 = {0xf0, 0x1, 0xf0, 0x1, 0xf0, 0x1, 0xf0, 0x1}}
mm1 {uint64 = 0x1f001f001f001f0, v2_int32 = {0x1f001f0, 0x1f001f0}, v4_int16 = {0x1f0, 0x1f0, 0x1f0, 0x1f0}, v8_int8 = {0xf0, 0x1, 0xf0, 0x1, 0xf0, 0x1, 0xf0, 0x1}}
mm2 {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}
mm3 {uint64 = 0x2000000000, v2_int32 = {0x0, 0x20}, v4_int16 = {0x0, 0x0, 0x20, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x20, 0x0, 0x0, 0x0}}
mm4 {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}
mm5 {uint64 = 0xf0f0f0f0f0f0f0f, v2_int32 = {0xf0f0f0f, 0xf0f0f0f}, v4_int16 = {0xf0f, 0xf0f, 0xf0f, 0xf0f}, v8_int8 = {0xf, 0xf, 0xf, 0xf, 0xf, 0xf, 0xf, 0xf}}
mm6 {uint64 = 0xf000f000f000f, v2_int32 = {0xf000f, 0xf000f}, v4_int16 = {0xf, 0xf, 0xf, 0xf}, v8_int8 = {0xf, 0x0, 0xf, 0x0, 0xf, 0x0, 0xf, 0x0}}
mm7 {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}
(gdb)

Hope this could help :)

Jjeje007

[akupenguin]

@Jjeje007
Upgrade yasm to r1952 or later. A related bug was fixed yesterday.

[Jjeje007]

YES !!

You're right, updating yasm to the latest version from subversion and all is working like a charm :D

Really great !

For Gentoo users, here an ebuild for the yasm subversion (perhaps, it could be usefull :rolleyes: ) :

# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $


inherit subversion

ESVN_REPO_URI="http://www.tortall.net/svn/yasm/trunk/yasm"
ESVN_PROJECT="yasm"
ESVN_BOOTSTRAP=autogen.sh

DESCRIPTION="assembler that supports amd64"
HOMEPAGE="http://www.tortall.net/projects/yasm/"

LICENSE="BSD"
SLOT="0"
KEYWORDS="-* ~amd64 ~x86"
IUSE="nls"

RDEPEND="nls? ( virtual/libintl )"
DEPEND="nls? ( sys-devel/gettext )"

src_unpack() {
subversion_src_unpack
}

src_compile() {
econf $(use_enable nls) || die "econf failed"
emake || die "emake failed"
}

src_install() {
emake DESTDIR="${D}" install || die "make install failed"
dodoc AUTHORS INSTALL
}

Thanks !!

Jjeje007