mplayer crash when geometry changes
Hi folks, I've been on the list for a while, but haven't seen too many posts, so I apologize in advance if I don't include all the relevant information. 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). I've also never had this type of video before, so while I doubt it has anything to do with any of my changes, I suppose it isn't outside the realm of possibility. I have an MPEG-2 TS video that starts out at 1920x1080, then after about 18 seconds changes to 720x480. Right at the change, mplayer crashes. The stack trace is as follows: Program received signal SIGSEGV, Segmentation fault. 0xfe1cc5ef in memcpy () from /lib/libc.so.1 (gdb) bt #0 0xfe1cc5ef in memcpy () from /lib/libc.so.1 #1 0x08170768 in memcpy_pic2 (dst=0xfbd0e900, src=0x98be710, bytesPerLine=1920, height=1080, dstStride=720, srcStride=752, limit2width=0) at libvo/fastmemcpy.h:91 #2 0x08171607 in draw_slice (image=0x9503f6c, stride=0x9503f7c, w=1920, h=1080, x=0, y=0) at libvo/vo_xv.c:437 #3 0x081718d4 in draw_image (mpi=0x9503f40) at libvo/vo_xv.c:483 #4 0x0817239e in control (request=13, data=0x9503f40) at libvo/vo_xv.c:748 #5 0x081da92c in put_image (vf=0x96683e8, mpi=0x9503f40, pts=18.825455555555557) at libmpcodecs/vf_vo.c:168 #6 0x081a786f in filter_video (sh_video=0x94fe1c0, frame=0x9503f40, pts=18.825455555555557) at libmpcodecs/dec_video.c:484 #7 0x0811f73b in update_video (blit_frame=0x804769c) at mplayer.c:2457 #8 0x08122e6a in main (argc=3, argv=0x80477a4) at mplayer.c:3721 The crash occurs when memcpy_pic2 calls memcpy() and 'i' is 720. I was able to make it work with the attached 'svn diff' output, but having not spent a great deal of time doing any actual development, it's not clear to me whether the change is really a fix or just a workaround. 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. 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. Thanks, David
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/
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.
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.
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@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mplayer-advusers
On Sat, Dec 03, 2011 at 01:44:34PM -0700, David Hollister wrote:
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).
No surprise since it is a binutils issue, you can change compilers all you want and it won't make a difference. But did you test your change? My understanding is that these should be 16-bit stores, and removing the "s" would make them 32 bit. Though my tests indicate that "s" seems to be the default here. Anyway mp3lib is deprecated so just disabling it might be the better solution.
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)
That is just broken, instructions in the binary don't generally have much to do with instructions needed to execute. Also, this: http://ffmpeg.org/pipermail/ffmpeg-cvslog/2011-September/040912.html seems to indicate this should only happen when compiling with suncc?
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
Strange, I am sure that worked at some point.
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.
You should be able to just cut out a few MB at the transition point with dd. I think there's even a command you could bind to a key top make MPlayer print the current file position in bytes. get_property stream_pos I think.
With "-noslices -vo x11": Still crashes.
With "-vo gl": Appears to work fine.
Probably just luck that -vo gl works. Would also appreciate if you could test my patch.
Index: libmpcodecs/dec_video.c =================================================================== --- libmpcodecs/dec_video.c (revision 34378) +++ libmpcodecs/dec_video.c (working copy) @@ -423,12 +423,16 @@ #if HAVE_MMX // some codecs are broken, and doesn't restore MMX state :( // it happens usually with broken/damaged files. +#if HAVE_AMD3DNOW if (gCpuCaps.has3DNow) { __asm__ volatile ("femms\n\t":::"memory"); - } else if (gCpuCaps.hasMMX) { + } else +#else + if (gCpuCaps.hasMMX) { __asm__ volatile ("emms\n\t":::"memory"); } #endif +#endif
That will actually break --enable-runtime-cpudetection builds that are run on a CPU without 3DNow - neither emms nor femms will be executed in that case. Since 3DNow implies MMX the #if should just be split I think. Might get a bit ugly though.
On 12/ 3/11 02:15 PM, Reimar Döffinger wrote:
On Sat, Dec 03, 2011 at 01:44:34PM -0700, David Hollister wrote:
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).
No surprise since it is a binutils issue, you can change compilers all you want and it won't make a difference. But did you test your change? My understanding is that these should be 16-bit stores, and removing the "s" would make them 32 bit. Though my tests indicate that "s" seems to be the default here. Anyway mp3lib is deprecated so just disabling it might be the better solution.
Fair enough. I'll just disable it. For the record, though, I've been running various builds of mplayer with this change for several months now. I mostly run mencoder, not mplayer, but I've not seen any issues with any of the encodings I've done.
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)
That is just broken, instructions in the binary don't generally have much to do with instructions needed to execute. Also, this: http://ffmpeg.org/pipermail/ffmpeg-cvslog/2011-September/040912.html seems to indicate this should only happen when compiling with suncc?
I would agree. I will see what I can find out about this. However, it's really a linker issue, not a compiler issue. I don't recall whether I've tried with the GNU linker, but I haven't had a lot of luck with it on Solaris in the past.
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
Strange, I am sure that worked at some point.
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.
You should be able to just cut out a few MB at the transition point with dd. I think there's even a command you could bind to a key top make MPlayer print the current file position in bytes. get_property stream_pos I think.
With "-noslices -vo x11": Still crashes.
With "-vo gl": Appears to work fine.
Probably just luck that -vo gl works. Would also appreciate if you could test my patch.
I tried your patch, and it appears to work as expected. As for a segment of that video, if you'd still like it, I'll see what I can do to cut out a snippet for you. Just can't get to it right this moment, though. If you still want it, let me know.
Index: libmpcodecs/dec_video.c =================================================================== --- libmpcodecs/dec_video.c (revision 34378) +++ libmpcodecs/dec_video.c (working copy) @@ -423,12 +423,16 @@ #if HAVE_MMX // some codecs are broken, and doesn't restore MMX state :( // it happens usually with broken/damaged files. +#if HAVE_AMD3DNOW if (gCpuCaps.has3DNow) { __asm__ volatile ("femms\n\t":::"memory"); - } else if (gCpuCaps.hasMMX) { + } else +#else + if (gCpuCaps.hasMMX) { __asm__ volatile ("emms\n\t":::"memory"); } #endif +#endif
That will actually break --enable-runtime-cpudetection builds that are run on a CPU without 3DNow - neither emms nor femms will be executed in that case. Since 3DNow implies MMX the #if should just be split I think. Might get a bit ugly though.
If you look closely at the patch, the #if HAVE_AMD3DNOW essentially is breaking the if/else into just one "if" in the case where HAVE_AMD3DNOW is 0. I'm not arguing this is the best way to do this, or is even correct. Just wanted to ensure you didn't miss that. David
On Sat, Dec 03, 2011 at 03:31:03PM -0700, David Hollister wrote:
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)
That is just broken, instructions in the binary don't generally have much to do with instructions needed to execute. Also, this: http://ffmpeg.org/pipermail/ffmpeg-cvslog/2011-September/040912.html seems to indicate this should only happen when compiling with suncc?
I would agree. I will see what I can find out about this. However, it's really a linker issue, not a compiler issue. I don't recall whether I've tried with the GNU linker, but I haven't had a lot of luck with it on Solaris in the past.
It is not only a linker issue, since the linker can't know what instructions exist. So at the very last it needs cooperation from the assembler.
You should be able to just cut out a few MB at the transition point with dd. I think there's even a command you could bind to a key top make MPlayer print the current file position in bytes. get_property stream_pos I think.
With "-noslices -vo x11": Still crashes.
With "-vo gl": Appears to work fine.
Probably just luck that -vo gl works. Would also appreciate if you could test my patch.
I tried your patch, and it appears to work as expected.
Good, I'll probably go ahead with that.
As for a segment of that video, if you'd still like it, I'll see what I can do to cut out a snippet for you. Just can't get to it right this moment, though. If you still want it, let me know.
Yes, it would be good. I think FFmpeg behaviour is not ideal in this case (it returns an AVFrame with dimensions that contradict the AVCodecContext width/height).
Index: libmpcodecs/dec_video.c =================================================================== --- libmpcodecs/dec_video.c (revision 34378) +++ libmpcodecs/dec_video.c (working copy) @@ -423,12 +423,16 @@ #if HAVE_MMX // some codecs are broken, and doesn't restore MMX state :( // it happens usually with broken/damaged files. +#if HAVE_AMD3DNOW if (gCpuCaps.has3DNow) { __asm__ volatile ("femms\n\t":::"memory"); - } else if (gCpuCaps.hasMMX) { + } else +#else + if (gCpuCaps.hasMMX) { __asm__ volatile ("emms\n\t":::"memory"); } #endif +#endif
That will actually break --enable-runtime-cpudetection builds that are run on a CPU without 3DNow - neither emms nor femms will be executed in that case. Since 3DNow implies MMX the #if should just be split I think. Might get a bit ugly though.
If you look closely at the patch, the #if HAVE_AMD3DNOW essentially is breaking the if/else into just one "if" in the case where HAVE_AMD3DNOW is 0. I'm not arguing this is the best way to do this, or is even correct. Just wanted to ensure you didn't miss that.
The case to consider is HAVE_AMD3DNOW == 1 gCpuCaps.has3DNow == 0 gCpuCaps.hasMMX == 1 old code executes EMMS, your patched code I just realized won't even compile if HAVE_AMD3DNOW is 1...
On 12/ 3/11 04:15 PM, Reimar Döffinger wrote:
You should be able to just cut out a few MB at the transition point with dd. I think there's even a command you could bind to a key top make MPlayer print the current file position in bytes. get_property stream_pos I think.
Yes, I had forgotten that MPEG-2 streams can be dissected like that. I created a segment that's roughly 2MB in size. You should be able grab it here: http://wishingwell.homeip.net:8088/test.m2ts I don't typically have this port open on my router, so please let me know when you've grabbed it so I can turn it back off.
Would also appreciate if you could test my patch.
I tried your patch, and it appears to work as expected.
Good, I'll probably go ahead with that.
Great! Glad I could help at least a little.
Index: libmpcodecs/dec_video.c =================================================================== --- libmpcodecs/dec_video.c (revision 34378) +++ libmpcodecs/dec_video.c (working copy) @@ -423,12 +423,16 @@ #if HAVE_MMX // some codecs are broken, and doesn't restore MMX state :( // it happens usually with broken/damaged files. +#if HAVE_AMD3DNOW if (gCpuCaps.has3DNow) { __asm__ volatile ("femms\n\t":::"memory"); - } else if (gCpuCaps.hasMMX) { + } else +#else + if (gCpuCaps.hasMMX) { __asm__ volatile ("emms\n\t":::"memory"); } #endif +#endif
That will actually break --enable-runtime-cpudetection builds that are run on a CPU without 3DNow - neither emms nor femms will be executed in that case. Since 3DNow implies MMX the #if should just be split I think. Might get a bit ugly though.
If you look closely at the patch, the #if HAVE_AMD3DNOW essentially is breaking the if/else into just one "if" in the case where HAVE_AMD3DNOW is 0. I'm not arguing this is the best way to do this, or is even correct. Just wanted to ensure you didn't miss that.
The case to consider is HAVE_AMD3DNOW == 1 gCpuCaps.has3DNow == 0 gCpuCaps.hasMMX == 1 old code executes EMMS, your patched code I just realized won't even compile if HAVE_AMD3DNOW is 1...
I tried it. It appears to compile fine, but really it's neither here nor there at this point. Although it seems to work fine in my particular case, I had no illusions that it was a realistic patch. It was provided more just FYI. I still plan to see what I can find out about the Solaris linker bailing when the AMD_3dnow HW capability is present. If I find out anything of interest, I'll let you know. David
On Sat, Dec 03, 2011 at 04:51:06PM -0700, David Hollister wrote:
On 12/ 3/11 04:15 PM, Reimar Döffinger wrote:
You should be able to just cut out a few MB at the transition point with dd. I think there's even a command you could bind to a key top make MPlayer print the current file position in bytes. get_property stream_pos I think.
Yes, I had forgotten that MPEG-2 streams can be dissected like that.
I created a segment that's roughly 2MB in size. You should be able grab it here:
http://wishingwell.homeip.net:8088/test.m2ts
I don't typically have this port open on my router, so please let me know when you've grabbed it so I can turn it back off.
Got it. Sorry, had some internet trouble yesterday (had to push everything through my phone).
Would also appreciate if you could test my patch.
I tried your patch, and it appears to work as expected.
Good, I'll probably go ahead with that.
Great! Glad I could help at least a little.
Applied, it definitely is a good idea to have, even if we should come up with a better fix.
Hi! On Sat, 3 Dec 2011, Reimar Döffinger wrote:
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
Strange, I am sure that worked at some point.
This is a regression since r33915. Carl Eugen
On Sat, Dec 03, 2011 at 01:44:34PM -0700, David Hollister wrote:
On 12/ 3/11 11:21 AM, Reimar Döffinger wrote:
On Sat, Dec 03, 2011 at 10:50:16AM -0700, David Hollister wrote:
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
--- help/help_mp-en.h (revision 34378) +++ help/help_mp-en.h (working copy) @@ -1229,6 +1229,7 @@
// ao_sun.c #define MSGTR_AO_SUN_RtscSetinfoFailed "[AO SUN] rtsc: SETINFO failed.\n" +#define MSGTR_AO_SUN_RtscWriteFailed "[AO SUN] rtsc: write failed.\n" #define MSGTR_AO_SUN_CantOpenAudioDev "[AO SUN] Can't open audio device %s, %s -> nosound.\n" #define MSGTR_AO_SUN_UnsupSampleRate "[AO SUN] audio_setup: your card doesn't support %d channel, %s, %d Hz samplerate.\n"
This part is correct, I applied it locally, will push in a moment. Diego
On Sat, Dec 03, 2011 at 01:44:34PM -0700, David Hollister wrote:
Index: libmpcodecs/dec_video.c =================================================================== --- libmpcodecs/dec_video.c (revision 34378) +++ libmpcodecs/dec_video.c (working copy) @@ -423,12 +423,16 @@ #if HAVE_MMX // some codecs are broken, and doesn't restore MMX state :( // it happens usually with broken/damaged files. +#if HAVE_AMD3DNOW if (gCpuCaps.has3DNow) { __asm__ volatile ("femms\n\t":::"memory"); - } else if (gCpuCaps.hasMMX) { + } else +#else + if (gCpuCaps.hasMMX) { __asm__ volatile ("emms\n\t":::"memory"); } #endif +#endif
I think I have come up with a simpler and actually working method (won't work with -O0 though).
Great! For what it's worth, I played around with this a bit today. Unfortunately, the Solaris linker guru that sits down the hall from me didn't seem to be in the office today. It does appear, though, that it is the Solaris linker that inserts the hardware capabilities. Based on that, it makes sense that it was reported with the SunStudio compiler. However, as I believe is typically the case, the version of gcc I use was also configured to use the Solaris linker. Without a gcc that uses the GNU linker, I didn't have a quick way to verify, but I expect that it would not do this. So, with that in mind, I adapted configure script to do essentially what the ffmpeg patch does. With the attached patch, I was able to build mplayer from scratch with no modifications (except the patch you provided a couple of days ago). I can't get mplayer to build with the latest SolarisStudio compiler (12.3) and I've had issues with 12.1 and 12.2 as well, which is why I don't bother. However, I was able to run configure with 12.3 and verify that it does create the mapfile and add the proper option to extra_ldflags. Perhaps in the next few days I will see what it takes to get it to compile with some flavor of SunStudio. David On 12/ 5/11 11:44 AM, Reimar Döffinger wrote:
On Sat, Dec 03, 2011 at 01:44:34PM -0700, David Hollister wrote:
Index: libmpcodecs/dec_video.c =================================================================== --- libmpcodecs/dec_video.c (revision 34378) +++ libmpcodecs/dec_video.c (working copy) @@ -423,12 +423,16 @@ #if HAVE_MMX // some codecs are broken, and doesn't restore MMX state :( // it happens usually with broken/damaged files. +#if HAVE_AMD3DNOW if (gCpuCaps.has3DNow) { __asm__ volatile ("femms\n\t":::"memory"); - } else if (gCpuCaps.hasMMX) { + } else +#else + if (gCpuCaps.hasMMX) { __asm__ volatile ("emms\n\t":::"memory"); } #endif +#endif
I think I have come up with a simpler and actually working method (won't work with -O0 though). _______________________________________________ MPlayer-advusers mailing list MPlayer-advusers@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mplayer-advusers
On Mon, Dec 05, 2011 at 07:50:40PM -0700, David Hollister wrote:
+# The hardware capabilities inserted into the ELF header by the Solaris linker +# may keep the run-time loader from allowing the binary to run on some x86 +# platforms. The GNU linker presumably does not insert these capabilities. +if sunos ; then + echocheck "Solaris linker" + if test "$cc_name" = "gcc" ; then + if cflag_check "-Wl,-z,help" ; then + echo "hwcap_1 = OVERRIDE;" > mapfile && extra_ldflags="$extra_ldflags -Wl,-M,mapfile" + echores "yes" + else + echores "no" + fi + elif test "$cc_vendor" = "sun" ; then + echo "hwcap_1 = OVERRIDE;" > mapfile && extra_ldflags="$extra_ldflags -Mmapfile"
Why not just check if one of -Wl,-M,mapfile or -Mmapfile works and if yes use that? Also "make distclean" should remove "mapfile"
Sorry it took me so long to get back on this. How does the new attached patch look. Better? Thanks, David On 12/11/11 08:20 AM, Reimar Döffinger wrote:
On Mon, Dec 05, 2011 at 07:50:40PM -0700, David Hollister wrote:
+# The hardware capabilities inserted into the ELF header by the Solaris linker +# may keep the run-time loader from allowing the binary to run on some x86 +# platforms. The GNU linker presumably does not insert these capabilities. +if sunos ; then + echocheck "Solaris linker" + if test "$cc_name" = "gcc" ; then + if cflag_check "-Wl,-z,help" ; then + echo "hwcap_1 = OVERRIDE;"> mapfile&& extra_ldflags="$extra_ldflags -Wl,-M,mapfile" + echores "yes" + else + echores "no" + fi + elif test "$cc_vendor" = "sun" ; then + echo "hwcap_1 = OVERRIDE;"> mapfile&& extra_ldflags="$extra_ldflags -Mmapfile"
Why not just check if one of -Wl,-M,mapfile or -Mmapfile works and if yes use that? Also "make distclean" should remove "mapfile" _______________________________________________ MPlayer-advusers mailing list MPlayer-advusers@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mplayer-advusers
On Wed, Dec 28, 2011 at 09:57:41AM -0700, David Hollister wrote:
Sorry it took me so long to get back on this.
How does the new attached patch look. Better?
Diego is to say, it looks fine to me (only generating the mapfile by configure might be a bit questionable).
On Sat, Dec 03, 2011 at 10:50:16AM -0700, David Hollister wrote:
I have an MPEG-2 TS video that starts out at 1920x1080, then after about 18 seconds changes to 720x480. Right at the change, mplayer crashes. The stack trace is as follows:
Program received signal SIGSEGV, Segmentation fault. 0xfe1cc5ef in memcpy () from /lib/libc.so.1 (gdb) bt #0 0xfe1cc5ef in memcpy () from /lib/libc.so.1 #1 0x08170768 in memcpy_pic2 (dst=0xfbd0e900, src=0x98be710, bytesPerLine=1920, height=1080, dstStride=720, srcStride=752, limit2width=0) at libvo/fastmemcpy.h:91
While you'll lose one frame, attached patch should be a temporary fix, unless/until FFmpeg can be improved. (Obviously not tested since I did not have a suitable file to test it).
participants (4)
-
Carl-Eugen Hoyos -
David Hollister -
Diego Biurrun -
Reimar Döffinger