[Ffmpeg-devel] Problem in ff_fdct_sse2 in libavcodec

[Dave Hayes]

Hello everyone. :)

I seem to be having a mysterious problem in ff_fdct_sse2() in the
libavcodec.so library. On one machine, a movie conversion I do
works fine. On the other machine, it dies horribly:

/usr/local/bin/ffmpeg -y -i 1_1133898927.wmv -ab 56 -ar 22050 -b 500 -r 15 -s 
320x240 foo.flv
ffmpeg version 0.4.9-pre1, build 4756, Copyright (c) 2000-2004 Fabrice Bellard
  configuration:  --cc=cc --prefix=/usr/local --make=gmake --disable-debug 
--enable-memalign-hack --enable-shared --source-path=/usr/ports/multimedia/ffmp
eg-devel/work/FFMpeg-20050620 --enable-a52 --disable-a52bin --enable-faac 
--enable-faad --enable-faadbin --enable-gpl --enable-mp3lame --enable-libogg 
--enable-pp --enable-shared-pp --enable-pthreads --disable-ffplay 
--enable-vorbis
  built on Dec  6 2005 12:21:44, gcc: 2.95.4 20020320 [FreeBSD]

Seems that stream 1 comes from film source: 1000.00 (1000/1) -> 30.00 (30/1)
Input #0, asf, from '1_1133898927.wmv':
  Duration: 00:00:09.6, start: 3.000000, bitrate: 334 kb/s
  Stream #0.0: Audio: wmav2, 44100 Hz, stereo, 64 kb/s
  Stream #0.1: Video: msmpeg4, yuv420p, 320x240, 1000.00 fps
Output #0, flv, to 'foo.flv':
  Stream #0.0: Video: flv, yuv420p, 320x240, 15.00 fps, q=2-31, 500 kb/s
  Stream #0.1: Audio: mp3, 22050 Hz, stereo, 56 kb/s
Stream mapping:
  Stream #0.1 -> #0.0
  Stream #0.0 -> #0.1
[flv @ 0x28377bd8]removing common factors from framerate
Press [q] to stop encoding
Illegal instruction (core dumped)

gdb `which ffmpeg` ffmpeg.core 
GNU gdb 4.18 (FreeBSD)
...
#0  0x282ef48f in ff_fdct_sse2 () from /usr/local/lib/libavcodec.so
(gdb) bt
#0  0x282ef48f in ff_fdct_sse2 () from /usr/local/lib/libavcodec.so
#1  0x283066e9 in dct_quantize_SSE2 () from /usr/local/lib/libavcodec.so
#2  0x28133ec3 in encode_mb () from /usr/local/lib/libavcodec.so
#3  0x2813ae87 in encode_thread () from /usr/local/lib/libavcodec.so
#4  0x28120ec2 in avcodec_default_execute () from /usr/local/lib/libavcodec.so
#5  0x2813bc20 in encode_picture () from /usr/local/lib/libavcodec.so
#6  0x28128a56 in MPV_encode_picture () from /usr/local/lib/libavcodec.so
#7  0x28121305 in avcodec_encode_video () from /usr/local/lib/libavcodec.so
#8  0x804bad6 in _start ()
(gdb) disass $pc-32 $pc+32
Dump of assembler code from 0x282ef46f to 0x282ef4af:
0x282ef46f <ff_fdct_sse2+595>:  movq   %mm0,0x18(%ebx)
0x282ef473 <ff_fdct_sse2+599>:  paddsw %mm4,%mm5
0x282ef476 <ff_fdct_sse2+602>:  movq   %mm7,0x38(%ebx)
0x282ef47a <ff_fdct_sse2+606>:  psubsw %mm1,%mm3
0x282ef47d <ff_fdct_sse2+609>:  movq   %mm5,0x58(%ebx)
0x282ef481 <ff_fdct_sse2+613>:  movq   %mm3,0x78(%ebx)
0x282ef485 <ff_fdct_sse2+617>:  mov    $0x0,%edx
0x282ef48a <ff_fdct_sse2+622>:  mov    $0x0,%eax
0x282ef48f <ff_fdct_sse2+627>:  movdqa (%eax),%xmm6
0x282ef493 <ff_fdct_sse2+631>:  movq   0x0(%ebx),%xmm2
0x282ef498 <ff_fdct_sse2+636>:  movq   0x8(%ebx),%xmm0
0x282ef49d <ff_fdct_sse2+641>:  movdqa 0x20(%edx),%xmm3
0x282ef4a2 <ff_fdct_sse2+646>:  movdqa 0x30(%edx),%xmm7
0x282ef4a7 <ff_fdct_sse2+651>:  movdqa 0x0(%edx),%xmm4
0x282ef4ac <ff_fdct_sse2+656>:  movdqa 0x10(%edx),%xmm5
End of assembler dump.
(gdb) info all-registers
eax            0x2837ef80       674754432
ecx            0x81b8010        136019984
edx            0x2837efa0       674754464
ebx            0xbfbf5d00       -1077977856
esp            0xbfbf5ce8       0xbfbf5ce8
ebp            0xbfbf5d80       0xbfbf5d80
esi            0x81b8010        136019984
edi            0x0      0
eip            0x282ef48f       0x282ef48f
eflags         0x210292 2163346
cs             0x1f     31
ss             0x2f     47
ds             0x2f     47
es             0x2f     47
fs             0x2f     47
gs             0x2f     47

Now I've triple checked the installation. The MD5 checksum of both
the binary and the shared library "libavcodec.so" are exactly
the same on both machines. The OS is exactly the same with the exact
same configuration file (FreeBSD 4.11). The CPUs however are different. 
On the machine that works:

# sysctl -a | grep model
hw.model: Intel Pentium III

...but on the machine that does not:

# sysctl -a | grep model
hw.model: Intel(R) Xeon(TM) CPU 3.06GHz

My weakly supported theory is that the assembler involved is
non-portable. Most likely I've forgotten a key define or configure
switch. ;) I'm not used to having to worry about what CPU I'm using.

So...is this a real bug or am I just naive? 

Also before you ask, I am attempting to "use the current CVS
snapshot", however I am building from FreeBSD ports, and the port
that supports the current snapshot appears to be broken.

Thanks in advance for any timely help that anyone can provide.
------
Dave Hayes - Consultant - Altadena CA, USA - dave at jetcafe.org 
>>> The opinions expressed above are entirely my own <<<

One of the big differences between questions and answers is
that a question may be asked at almost any time, but its
answer may only come at a special time and place.