This is from this forum thread: http://forums.gentoo.org/viewtopic-t-418802.html My JPEGs are all 970x462, and this seems to result in segfaults. I did this: $ for i in *; do convert -extent 512x384 $i s-$i ; done $ jpeg2yuv -f 10 -j s-%04d.jpg -b 0101 -I p > ../part1-s.yuv Quick and very dirty, but no segfaults and a big fat yuv file. However, for the unclipped images, my output looks like this: $ jpeg2yuv -f 10 -j %04d.jpg -b 0101 -I p > ../part1.yuv INFO: [jpeg2yuv] Parsing & checking input files. INFO: [jpeg2yuv] YUV colorspace detected. INFO: [jpeg2yuv] Starting decompression INFO: [jpeg2yuv] Image dimensions are 970x462 INFO: [jpeg2yuv] Movie frame rate is: 10.000000 frames/second INFO: [jpeg2yuv] Non-interlaced/progressive frames. INFO: [jpeg2yuv] Frame size: 970 x 462 INFO: [jpeg2yuv] Number of Loops 1 INFO: [jpeg2yuv] Now generating YUV4MPEG stream. INFO: [jpeg2yuv] Processing non-interlaced/interleaved 0101.jpg, size 42455 Segmentation fault This might be an upstream problem, I don't know - but I thought it'd be a good thing to post here anyway.
Reopen after you've attach some image to reproduce and post emerge --info... Also, some backtrace would be really useful. http://www.gentoo.org/doc/en/bugzilla-howto.xml
I had the same bug on my system and I found it was caused by jpeg-mmx # jpeg2yuv -v 2 -n 200 -I p -f 29.97 -j output1.jpg > img.dat INFO: [jpeg2yuv] Parsing & checking input files. --DEBUG: [jpeg2yuv] Analyzing output1.jpg to get the right pic params INFO: [jpeg2yuv] YUV colorspace detected. INFO: [jpeg2yuv] Starting decompression INFO: [jpeg2yuv] Image dimensions are 720x480 INFO: [jpeg2yuv] Movie frame rate is: 29.970030 frames/second INFO: [jpeg2yuv] Non-interlaced/progressive frames. INFO: [jpeg2yuv] Frame size: 720 x 480 INFO: [jpeg2yuv] Number of Loops 1 INFO: [jpeg2yuv] Now generating YUV4MPEG stream. --DEBUG: [jpeg2yuv] Preparing frame INFO: [jpeg2yuv] Processing non-interlaced/interleaved output1.jpg, size 54054 Segmentation fault (core dumped) # rm /usr/lib/libjpeg-mmx.so.62 # ln -s /usr/lib/libjpeg.so.62 /usr/lib/libjpeg-mmx.so.62 # jpeg2yuv -v 2 -n 200 -I p -f 29.97 -j output1.jpg > img.dat INFO: [jpeg2yuv] Parsing & checking input files. --DEBUG: [jpeg2yuv] Analyzing output1.jpg to get the right pic params INFO: [jpeg2yuv] YUV colorspace detected. INFO: [jpeg2yuv] Starting decompression INFO: [jpeg2yuv] Image dimensions are 720x480 INFO: [jpeg2yuv] Movie frame rate is: 29.970030 frames/second INFO: [jpeg2yuv] Non-interlaced/progressive frames. INFO: [jpeg2yuv] Frame size: 720 x 480 INFO: [jpeg2yuv] Number of Loops 1 INFO: [jpeg2yuv] Now generating YUV4MPEG stream. --DEBUG: [jpeg2yuv] Preparing frame INFO: [jpeg2yuv] Processing non-interlaced/interleaved output1.jpg, size 54054 INFO: [jpeg2yuv] Rescaling color values. --DEBUG: [jpeg2yuv] Frame decoded, now writing to output stream. --DEBUG: [jpeg2yuv] Preparing frame INFO: [jpeg2yuv] Processing non-interlaced/interleaved output1.jpg, size 54054 INFO: [jpeg2yuv] Rescaling color values. --DEBUG: [jpeg2yuv] Frame decoded, now writing to output stream. --DEBUG: [jpeg2yuv] Preparing frame <snip>
I reemerged jpeg-mmx then I unpacked mjpegtools into /var/tmp/portage/mjpegtools-1.8.0-r1/work/mjpegtools-1.8.0. Then ran configure and make. Then cd to lavtools and then the following: lavtools # gdb GNU gdb 6.4 Copyright 2005 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". (gdb) file .libs/jpeg2yuv Reading symbols from /var/tmp/portage/mjpegtools-1.8.0-r1/work/mjpegtools-1.8.0/lavtools/.libs/jpeg2yuv...done. Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run -v 2 -n 200 -I p -f 29.97 -j /mnt/vg/mythdata/output1.jpg Starting program: /var/tmp/portage/mjpegtools-1.8.0-r1/work/mjpegtools-1.8.0/lavtools/.libs/jpeg2yuv -v 2 -n 200 -I p -f 29.97 -j /mnt/vg/mythdata/output1.jpg [Thread debugging using libthread_db enabled] [New Thread -1210272064 (LWP 23720)] INFO: [jpeg2yuv] Parsing & checking input files. --DEBUG: [jpeg2yuv] Analyzing /mnt/vg/mythdata/output1.jpg to get the right pic params INFO: [jpeg2yuv] YUV colorspace detected. INFO: [jpeg2yuv] Starting decompression INFO: [jpeg2yuv] Image dimensions are 720x480 INFO: [jpeg2yuv] Movie frame rate is: 29.970030 frames/second INFO: [jpeg2yuv] Non-interlaced/progressive frames. INFO: [jpeg2yuv] Frame size: 720 x 480 INFO: [jpeg2yuv] Number of Loops 1 INFO: [jpeg2yuv] Now generating YUV4MPEG stream. YUV4MPEG2 W720 H480 F30000:1001 Ip A1:1 C420jpeg --DEBUG: [jpeg2yuv] Preparing frame INFO: [jpeg2yuv] Processing non-interlaced/interleaved /mnt/vg/mythdata/output1.jpg, size 54054 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210272064 (LWP 23720)] 0xb7f344b6 in jpeg_idct_ifast () from /usr/lib/libjpeg-mmx.so.62 (gdb) (gdb) q The program is running. Exit anyway? (y or n) y jmd0 lavtools # emerge --info Portage 2.1_pre7-r1 (default-linux/x86/2006.0, gcc-3.4.5, glibc-2.3.6-r3, 2.6.13-gentoo-r3 i686) ================================================================= System uname: 2.6.13-gentoo-r3 i686 AMD Athlon(tm) MP 2200+ Gentoo Base System version 1.12.0_pre16 ccache version 2.3 [disabled] dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 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.15.92.0.2-r1, 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r4 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-mp -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-mp -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig candy distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.mirrors.pair.com/ http://gentoo.netnitco.net http://gentoo.ccccom.com http://194.117.143.69" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow X Xaw3d acl acpi alsa apache2 apm arts avi bash-completion berkdb bitmap-fonts bzlib cli crypt ctype cups dba dga divx4linux doc dri dvd dvdr eds emacs emboss encode esd expat fastbuild fbcon font-server foomaticdb force-cgi-redirect fortran ftp gd gdbm gif gmp gnome gpm gstreamer gtk gtk2 gtkhtml imlib isdnlog java jikes joystick jpeg kde libg++ libwww lirc mad memlimit mikmod mmx motif mozilla mp3 mpeg mysql mysqli ncurses nls nptl ogg opengl oss pam pcre pdflib perl php png posix postgres pppd python qt quicktime readline samba sdl session simplexml smp soap sockets spell spl sse ssl svga tcpd tiff tokenizer truetype truetype-fonts type1-fonts udev usb videos vorbis wmf wxwindows xine xinerama xml xml2 xmms xsl xv xvid zlib elibc_glibc kernel_linux userland_GNU" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LANG, LC_ALL, LDFLAGS, LINGUAS
Created attachment 83423 [details] output1.jpg Here is the jpeg, I used. I have been able to reproduce this bug only on athlon xp or mp machines and not amd64.
After sending my info here I found the solution to this problem for me it is that jpeg-mmx segfaults when compiled with the -fomit-frame-pointer flag. There is a bugreport and patch here that worked for me: http://bugs.gentoo.org/show_bug.cgi?id=114103
Hmmm 'k, sounds like a dupe then.
*** This bug has been marked as a duplicate of 114103 ***
