[MPlayer-advusers] mplayer crash when geometry changes

[David Hollister]

Hi Reimar,

Thanks for your quick response.

On 12/ 3/11 11:21 AM, Reimar Döffinger wrote:
> On Sat, Dec 03, 2011 at 10:50:16AM -0700, David Hollister wrote:
>> First off, the system is running Solaris 11.  I always have to make
>> a handful of modifications in order to get it to compile, but I've
>> never had problems before.  (I can provide all the diffs I have to
>> make whenever I update the source if anybody really wants to know).
>
> Unless they are due to not having switched Solaris to the POSIX
> environment we would want to fix those issues, yes/

I am attaching another diff containing the changes I make to get things 
to work for Solaris.  They are actually much smaller now than they were 
a few months ago :)

A quick description of why:

mp3lib/dct64_sse.c: As is, I'll get the following errors:

Assembler: dct64_sse.c
	"<stdin>", line 250 : Illegal mnemonic
	Near line: "	fistps 512(%esi)"
	"<stdin>", line 250 : Syntax error
...
	"<stdin>", line 258 : Illegal mnemonic
	Near line: "	fists  256(%ebx)"
	"<stdin>", line 258 : Syntax error
	Near line: "	fists  256(%ebx)"
...

This is with the following gcc: gcc (GCC) 4.6.2 20110826 (prerelease) 
(also happens with gcc 4.3.3 and 4.5.x).


libmpcodecs/dec_video.c: This change is not necessary to compile... it 
will compile as-is.  However, it results in the following when I try to run:

$ file mplayer
mplayer: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically 
linked (uses shared libs), not stripped, uses FPU TSC CMOV MMX AMD_3DNow 
SSE SSE2 SSE3 SSSE3 SSE4.1

$ ./mplayer
ld.so.1: mplayer: fatal: mplayer: hardware capability (CA_SUNW_HW_1) 
unsupported: 0x100  [ AMD_3DNow ]
Killed

So, I suppose the Solaris ld.so will refuse to run binaries with 
hardware capabilities it knows aren't supported by the current 
processor.  Just FYI, There are a couple of ffmpeg files that require 
similar changes (libavcodec/x86/cavsdsp_mmx.c and dsputilenc_mmx.c)


help/help_mp-en.h: As is, this will result in the following compile error:

libao2/ao_sun.c: In function 'realtime_samplecounter_available':
libao2/ao_sun.c:161:35: error: 'MSGTR_AO_SUN_RtscWriteFailed' undeclared 
(first use in this function)
libao2/ao_sun.c:161:35: note: each undeclared identifier is reported 
only once for each function it appears in
gmake: *** [libao2/ao_sun.o] Error 1

>> During my testing, I found that it's only the frame passed in to
>> draw_image/draw_slice immediately following the geometry change that
>> has the incorrect width and height.  Subsequent frames were correct.
>
> Please provide a sample file.
> Also say whether this also happens with -noslices and -vo x11 or -vo gl
> or such.

Unfortunately, the sample file is about 1.8GB in size.  However, I'm 
pretty sure I can easily generate one that is much smaller.  I'll try to 
do that and will post a link as soon as I can.

With "-noslices -vo x11": Still crashes.

With "-vo gl": Appears to work fine.

>> Any thoughts about whether this is appropriate, or what a proper fix
>> would be?  Given this issue, I'm also not sure whether there may be
>> similar issues in some of the other VOs.
>
> I doubt there is an issue in the vo at all.
> mpi->w and image_width should never differ.
> I guess there might be a delayed frame getting stuck, in which case I
> would say this is a libavcodec bug if it does not output it.
> _______________________________________________
> MPlayer-advusers mailing list
> MPlayer-advusers at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-advusers
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diffs.out
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-advusers/attachments/20111203/bf6b1981/attachment.ksh>