Hi, the mp4live tool crashes at startup with the following message: localhost bin # mp4live 15:34:29.839-mp4live-3: type 0 usb type 0 15:34:29.886-mp4live-3: mp4live version 1.4.1 V4L2 Illegal instruction GDB Stacktrace says: (gdb) run Starting program: /home/emanuel/temp/bin/mp4live [Thread debugging using libthread_db enabled] [New Thread 47188270361088 (LWP 11549)] 15:34:50.403-mp4live-3: type 0 usb type 0 15:34:50.449-mp4live-3: /home/emanuel/temp/bin/mp4live version 1.4.1 V4L2 Program received signal SIGILL, Illegal instruction. [Switching to Thread 47188270361088 (LWP 11549)] 0x00002aeadf2f0200 in xvid_plugin_psnr () from /usr/lib/libxvidcore.so.4 The bug is reproduceable. As workaround mpeg4ip-1.4.1 can be compiled without xvid support. [ebuild R ] media-video/mpeg4ip-1.4.1 USE="a52 aac alsa arts ffmpeg ipv6 lame mp4live mpeg2 v4l2 x264 xvid -esd -id3 -nas -player" 0 kB localhost bin # emerge --info Portage 2.1_pre7-r4 (default-linux/amd64/2006.0, gcc-3.4.4, glibc-2.3.5-r2, 2.6.16-gentoo-r1 x86_64) ================================================================= System uname: 2.6.16-gentoo-r1 x86_64 Intel(R) Pentium(R) D CPU 2.80GHz Gentoo Base System version 1.6.14 dev-lang/python: 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=nocona -O2 -fomit-frame-pointer -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/env.d" CXXFLAGS="-march=nocona -O2 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LINGUAS="de en" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X a52 aac acl acpi alsa amr apache2 arts artswrappersuid avi berkdb bitmap-fonts cli crypt ctype cups dba dri dts eds emboss encode expat fastbuild ffmpeg foomaticdb force-cgi-redirect fortran ftp gd gif gpm gstreamer gtk gtk2 hal ieee1394 imlib input_devices_keyboard input_devices_mouse ipv6 isdnlog java jpeg kde kdeenablefinal lame lzw lzw-tiff matroska memlimit mono mp3 mp4 mp4live mpeg mpeg2 ncurses nls nptl ogg opengl pam pcre pdflib perl png posix pppd python qt quicktime rdesktop readline samba sdl session simplexml soap sockets speex spell spl ssl tcpd threads tiff tokenizer truetype truetype-fonts type1-fonts unicode usb v4l v4l2 video_cards_ati vorbis wxwindows x264 xinerama xml xpm xsl xv xvid zeroconf zlib elibc_glibc kernel_linux linguas_de linguas_en userland_GNU" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
hmm, can't reproduce here.. but I have an Athlon64. Which version of xvid do you have ? in gdb, when it crashes, can you do bt ? and disassemble. I'm curious to know which instruction fails.
I have [ebuild R ] media-libs/xvid-1.1.0 USE="-doc" 0 kB The bad boy is line video_xvid10.cpp:290, the jump goes into /usr/lib/libxvidcore.so.4. The call for this is m_vopBufferLength = xvid_encore(m_xvidHandle, XVID_ENC_ENCODE, &xvidFrame, &m_xvidResult); Now I will look whether there are some fixes for xvid... Stay tuned
It seems to be somewhere in Program received signal SIGILL, Illegal instruction. 0x00002ab4f5ef93b0 in emms_3dn () from /usr/lib/libxvidcore.so.4 My guess is that xvid tries to use some 3D-Now AMD commands which are unknown to the x64 Intel architecture.
then its an xvid bug.. reassigning to media-video it seems to be in xvidcore/src/utils/x86_64_asm/cpuid.asm emms_3dn calls the opcode "femms" with is AMD specific. in src/xvid.c it sets the emms=emms_3dn if x86_64, but it should check for the 3dnow flag first. As a workaround, you should downgrade to the stable xvid.. it seems to use the mmx version for x86_64.
Okay to resolve this bug we have only these ways: a) resurrect the 3dnow useflag; b) use PROFILE_ARCH like sparc does, and making sure that with em64t that part of the code is disabled; c) change the code to use cpuid to identify the CPU and its ability to run 3Dnow code; d) use __3dNOW__ define to check if to use it or not; but without -march=athlon64 it _will_ disable 3dnow support at all. I'm not sure how much media-video can do about this, it's more for amd64@g.o IMHO. Having a check on /proc/cpuinfo at compile time is a no go.
Reassigning to amd64 herd, going for solution (c), but someone has to help with asm coding.
Okay, I should have looked to the code instead of going by memory of 1.0 series. The code already has a cpu_flags loading capabilities, so I can just check against that, hopefully... still a check on em64t should be done to make sure that there's no code that tries to execute AMD-specific instructions, and that's up to amd64 team anyway.
Diego, the real problem lies in src/xvid.c: xvid does == emms = emms_c; <snip> if ((cpu_flags & XVID_CPU_MMX) || (cpu_flags & XVID_CPU_MMXEXT) || (cpu_flags & XVID_CPU_3DNOW) || (cpu_flags & XVID_CPU_3DNOWEXT) || (cpu_flags & XVID_CPU_SSE) || (cpu_flags & XVID_CPU_SSE2)) { /* Restore FPU context : emms_c is a nop functions */ emms = emms_mmx; } <snip> if ((cpu_flags & XVID_CPU_3DNOW)) { emms = emms_3dn; == That looks quite sane to me. I rather think that the detection of XVID_CPU_3DNOW is somewhat b0rked.
Could not reproduce this bug on em64t. Emanuel: Please run mp4live throught gdb and break at xvid_global. Then step through and add a watchpoint on emms. Please tell us where it gets assigned emms_3dn. I don't see any possibility where this could happen.
This gets tricky, 1.1.0-r1 that should fix this problem breaks on 3dNow! enabled systems.
*** Bug 135326 has been marked as a duplicate of this bug. ***
*** Bug 131422 has been marked as a duplicate of this bug. ***
I've added a straight-to-stable -r2 to fix the issue because it was starting to be quite obnoxious. This is one of the cases in which we'd need a 3dnow useflag on amd64 profiles...
Bug #135326 has been marked as a duplicate of this bug and both have been marked resolved. However, I still suffer from the textrel issue with mencoder. Removing the textrel patch solves the problem. I think bug #135326 should be reopened.
xvid-1.1.0-r2 still do not work on my AMD XP 2000+! I have the same behavior as described in this bug: http://bugs.gentoo.org/show_bug.cgi?id=131422 . So better reopen 131422 it? I now use xvid-1.1.0 - the last one which worked on my AMD XP 2000+. # cat /proc/cpuinfo |grep "flags" flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow ts
This starts to be funny, different problems with very similar behaviour... Well, this one should now be fixed for good and we should be kosher, I'll reopen one of the others.
Well, it might work for EM64T now, but the patch for xvid-1.1.0-r2 seriously butchered xvid performance on AMD machines for me. On the same source material with the same options I went from 15 fps to 3 fps on a 2 pass encode, both with mencoder and transcode. Commenting out the 3dnow-2.patch in the ebuild got me back to where performance was supposed to be.
This should be fixed with xvid-1.1.0-r3, closing bug.
