[Mplayer-users] another broken one

[Juergen Keil]

I've tried to reproduce the "signal 11" problem with the sig11broken.avi
file you transfered to the incoming directory on the ftp server, but I don't
think I succeeded.  I've tried it on Linux & Solaris.  I get a signal 11,
indeed; but I get that ~14.4 seconds into the video, and that's apparently
when the truncated (!) avi file ends.

Problem with the 11821048 bytes sig11broken.avi is apparently that EOF is
not tested everywhere on a stream read; this feeds junk data into the win32
DLLs and MPlayer crashes during video decoding inside the DLLs.  Because it's
crashing inside the DLLs, compiling with -g doesn't produce a symbolic stack
backtrace,  and gdb is also confused by the "stdcall" stack frames used in the
win32 code so that no useful stack backtrace is printed at all.



I see that your original file is 95404544 bytes, but MPlayer at one point
tries to seek to fileoffset 163942000:

> Found movie at 0x800 - 0x5AEDA18
> Reading INDEX block, 3693 chunks for 3454 frames
> stream_seek: WARNING! Can't seek to 0x9C58E70 !

0x9C58E70 hex == 163942000

Unless the index reading code is broken, I'd say that even your 95MB file is
truncated, too.


Do you still have the sig11broken.avi chunk available somewhere, that you've
uploaded to the ftp site?  (can be easily reconstructed from the original 95MB
file using "dd if=original.avi bs=11821048 count=1 of=sig11broken.avi").

What happens when you play that chunk on your system?  Does it crash during
the first 1 or 2 seconds,  or does it play until mplayer reaches EOF at
14.4 seconds?

--
Jürgen Keil          		jk at tools.de
Tools GmbH			+49 (228) 9858011


_______________________________________________
Mplayer-users mailing list
Mplayer-users at lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/mplayer-users