April 2006 - MPlayer-dev-eng - lists.mplayerhq.hu

[RFC] Stride support in ve_raw/libvo draw_image interface
by John Koleszar 27 Apr '06

27 Apr '06

Reposting this issue since it seems to have slipped through the cracks. I'm a little rusty on the details as it's been so long, so please bear with me. There are two places I've found where vf's require packed images but can be passed images with larger strides. This typically happens when playing material that has a width that isn't a multiple of 16 (or 8? I forget.) 1. ve_raw writes packed images to the muxer. These images must be packed, as the stride and offset information isn't stored in any container mencoder supports. 2. libvo's legacy draw_image interface requires a buffer to a packed RGB image, as the stride information isn't passed into the vo. The attached patch is a workaround for the ve_raw case. I allocate a buffer, then copy the image into that buffer if it isn't packed. There are some comments in the patch about why I allocate my own buffer instead of using the vf_get_image interface. I haven't maintained a patch fixing the vf_vo issue, I use a better vo now. The conditions that triggered it were very obscure (QT RLE material | mplayer -vo sdl | ssh -X | xfree86/Cygwin). Don't ask about the performance :) When I did maintain that fix, it was similar - use a temp buffer, copy the image if necessary. There exists a flag VFCAP_ACCEPT_STRIDE that indicates whether a vf requires a packed buffer or not. ve_raw does not set this flag. In the draw_image case I found, VFCAP_ACCEPT_STRIDE was not set. The vf layer (the common vf_get_image code, most likely) ignores this flag. I still think that the problem should be fixed for all vf's and the VFCAP_ACCEPT_STRIDE should be honored, but that idea was rejected last time, so I won't push it. I don't think the patch in this form is suitable to apply due the the large amount of code duplicated from vf_get_image. If it is agreed that this is the right fix in principle, I can post another patch moving the code that's common to a new function. Encoding any oddly sized material with -ovc raw should trigger the bug.. I can't remember how to trigger the vf_vo bug, but if you check the archives for my last post related to this, I think I had instructions there. A test clip I use is linked below (~30MB). ftp://opensource:opensource@ftp.on2.com/mobile_378_203_rle.mov

2 2

MPlayer and gcc ia32 intrinsics
by Jason Tackaberry 27 Apr '06

27 Apr '06

I've received an patch to my vf_overlay filter (of which I will be sending an update here soon) that implements SSE2 using gcc ia32 intrinsics. I haven't seen ia32 intrinsics used anywhere else in mplayer, so it seemed prudent to ask if a patch containing such code would be accepted? Cheers, Jason.

7 7

[PATCH] Fix memory corruption in libmpeg2 decoder
by Uoti Urpala 27 Apr '06

27 Apr '06

The libmpeg2 decoder allocates an array whose size depends on image parameters. It's allocated only once even though the parameters might change to require a larger array. As a result memory outside the array will be overwritten. This might be usable for security exploits but probably not easily as the overwriting bytes can not be chosen freely. The changes in vd_libmpeg2.c are the main fix, the vf.c change is a sanity check to make sure nothing else reuses an old qscale pointer (there shouldn't be any uses in current code).

1 3

Re: [MPlayer-dev-eng] [PATCH] MacOS X build weirdness
by sci-fi＠hush.ai 27 Apr '06

27 Apr '06

Hi, < snip -- I've seen these too many times ;) > I believe setting LDFLAGS=-Wl,-read_only_relocs,suppress is "allowing" all multiple symbol defs in my case. For background, this is why I came up with that setting: I have almost everything imaginable built & installed from scratch myself (no Fink here), so the ./configure step rakes in as much support as possible, including both X11 and OpenGL (and SDL and ...). I've been compiling with several gcc tweaks for ppc7450 etc. plus I have several env-vars set (I follow many projects via CVS/SVN, so I need such things as LIBTOOLIZE=glibtoolize for autogen etc.). I get a bunch of the multiple symbol defs also with the iconv libs & related stuff, since I build them, too, into /usr/local, but some projects apparently are hard-coded to peek at Apple's libs in /usr, so you can see how these multiple things can happen. Yeah I know: "submit patches" to those other projects. ;) MPlayer is by far *not* the only project that gets these same multiple symbol thingies. It can happen quite easily. I used to add -bind_at_load but that parm has been finicky: some projects need it with the '-Wl,' in front, some not -- this should let the multiple symbolic addresses be determined *and* be consistent with one-another at run-time. Usually the make scripts have this parm already written in if it's needed at all, but some projects are so old they didn't know about Darwin back then. ;) p.s. I mentioned this a while back on this list. I am still having to patch all of MPlayer's configure scripts to single-thread the .depends (IIRC going back to the old way with for-loop single modules in the gcc -MM) only when -fast is in the CxxFLAGS. I did submit a representative patch in my post back then. I'd hoped XCode 2.2.1 might've fixed this but alas no. I am slowly moving things to a Dual G5, and I've already found -fast with ppc970 tweaks will generate some bad code for many projects (par2verify, for example, sometimes cannot find header records in .par2 files when -fast is set, but is okay without it). So I'm (re)rerebuilding everything without -fast and will try to file a bug report with Apple (I can't afford a non-free ADC account, so I don't know if this is already known ;) ). Hey this is for fun & learning anyway, not complaining at all. Thanks for letting me barge-in here, hope this helps somehow. Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485

1 0

LDFLAGS and CPPFLAGS -> ended up in cvs admin -o
by "Gábor Bérczi (Gabucino)" 26 Apr '06

26 Apr '06

Some lousy amateur (judging from the style of his mail to arpi, probably koth) just reverted my fix on configure. And by using forbidden admin -o :) (never mind that current libavcodec doesn't compile on OSX/G4/fink/ darwinports because the current BROKEN way involves using custom CFLAGS [!] or BRAINDEAD mplayer-specific --with-extraincdir and -- with-extralibdir configure options [instead of correct and standard CPPFLAGS and LDFLAGS] which in turn disables some otherwise properly detected and mandatory CFLAG options for Altivec support, ultimately ending up in compile errors in imgresample.c) But hey, you may as well drown in your own shit, like hell I care. Learn something about portability. Log Message: add support for CPPFLAGS and LDFLAGS Index: configure =================================================================== RCS file: /cvsroot/mplayer/main/configure,v retrieving revision 1.1162 retrieving revision 1.1163 diff -u -r1.1162 -r1.1163 --- configure 18 Apr 2006 21:16:46 -0000 1.1162 +++ configure 20 Apr 2006 08:23:40 -0000 1.1163 @@ -586,6 +586,13 @@ # stuff explicitly as command line argument. In other words: It would be # resonable to have only /usr/include or only /usr/local/include. +# Gabucino: all the above is bullshit, people who babble this much trash +# never used any real UNIX, only [debian] linux. LDFLAGS and CPPFLAGS must +# always be honoured. + +_ld_extra="$_ld_extra $LDFLAGS" +_inc_extra="$_inc_extra $CPPFLAGS" + if freebsd ; then _ld_extra="$_ld_extra -L/usr/local/lib" _inc_extra="$_inc_extra -I/usr/local/include" -- Gábor Bérczi

4 4

[PATCH] make mencoder stream size printing use 64 bits
by Corey Hickey 26 Apr '06

26 Apr '06

...just like the subject says. Currently, the printing uses a signed int, so any stream size over 2 GB gets misrepresented. Bug reported by by mslama <<at>> email <<dot>> cz. Thanks to Reimar for pointing out the PRIu64 stuff. Did I do it right? I'll apply this tomorrow unless someone objects. -Corey Index: mencoder.c =================================================================== RCS file: /cvsroot/mplayer/main/mencoder.c,v retrieving revision 1.351 diff -u -r1.351 mencoder.c --- mencoder.c 25 Apr 2006 02:01:21 -0000 1.351 +++ mencoder.c 25 Apr 2006 17:16:04 -0000 @@ -1572,10 +1572,10 @@ } mp_msg(MSGT_MENCODER, MSGL_INFO, MSGTR_VideoStreamResult, - (float)(mux_v->size/mux_v->timer*8.0f/1000.0f), (int)(mux_v->size/mux_v->timer), (int)mux_v->size, (float)mux_v->timer, decoded_frameno); + (float)(mux_v->size/mux_v->timer*8.0f/1000.0f), (int)(mux_v->size/mux_v->timer), (uint64_t)mux_v->size, (float)mux_v->timer, decoded_frameno); if(sh_audio) mp_msg(MSGT_MENCODER, MSGL_INFO, MSGTR_AudioStreamResult, - (float)(mux_a->size/mux_a->timer*8.0f/1000.0f), (int)(mux_a->size/mux_a->timer), (int)mux_a->size, (float)mux_a->timer); + (float)(mux_a->size/mux_a->timer*8.0f/1000.0f), (int)(mux_a->size/mux_a->timer), (uint64_t)mux_a->size, (float)mux_a->timer); if(sh_audio){ uninit_audio(sh_audio);sh_audio=NULL; } if(sh_video){ uninit_video(sh_video);sh_video=NULL; } Index: help/help_mp-en.h =================================================================== RCS file: /cvsroot/mplayer/main/help/help_mp-en.h,v retrieving revision 1.246 diff -u -r1.246 help_mp-en.h --- help/help_mp-en.h 24 Apr 2006 19:14:16 -0000 1.246 +++ help/help_mp-en.h 25 Apr 2006 17:16:05 -0000 @@ -266,8 +266,8 @@ "Your encode might be broken!\n" #define MSGTR_ErrorWritingFile "%s: Error writing file.\n" #define MSGTR_RecommendedVideoBitrate "Recommended video bitrate for %s CD: %d\n" -#define MSGTR_VideoStreamResult "\nVideo stream: %8.3f kbit/s (%d B/s) size: %d bytes %5.3f secs %d frames\n" -#define MSGTR_AudioStreamResult "\nAudio stream: %8.3f kbit/s (%d B/s) size: %d bytes %5.3f secs\n" +#define MSGTR_VideoStreamResult "\nVideo stream: %8.3f kbit/s (%d B/s) size: %"PRIu64" bytes %5.3f secs %d frames\n" +#define MSGTR_AudioStreamResult "\nAudio stream: %8.3f kbit/s (%d B/s) size: %"PRIu64" bytes %5.3f secs\n" #define MSGTR_OpenedStream "success: format: %d data: 0x%X - 0x%x\n" #define MSGTR_VCodecFramecopy "videocodec: framecopy (%dx%d %dbpp fourcc=%x)\n" #define MSGTR_ACodecFramecopy "audiocodec: framecopy (format=%x chans=%d rate=%d bits=%d B/s=%d sample-%d)\n"

1 1

[PATCH] MacOS X build weirdness
by Chris Roccati 26 Apr '06

26 Apr '06

From: Chris Roccati <rratboy(a)pobox.com> Date: 24 April 2006 11:28:37 GMT+02:00 To: mplayer-dev-eng(a)mplayerhq.hu Subject: [PATCH] MacOS X build weirdness Hello, something weird must have happened: when trying to build for MacOS X (PPC) 10.4.x with the default configuration (provided by ./configure), the link phase fails with the following error: /usr/bin/ld: multiple definitions of symbol _glPointParameteri /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/ libGL.dylib(gll_api.o) definition of _glPointParameteri /usr/X11R6/lib/libGL.a(dri_dispatch.o) definition of _glPointParameteri in section (__TEXT,__text) /usr/bin/ld: multiple definitions of symbol _glPointParameteriv /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/ libGL.dylib(gll_api.o) definition of _glPointParameteriv /usr/X11R6/lib/libGL.a(dri_dispatch.o) definition of _glPointParameteriv in section (__TEXT,__text) This seems to be due to the fact that the default MPlayer binary tries to be both a Quartz application AND a X11 application - if this actualy makes any sense is left as an exercise for the reader... I don't recall this happening before (but I built MPlayer from CVS last time in november); by manually disabling X11, obviously, everything builds fine. The following patch simply disables X11 support if building under MacOS X.

8 23

[PATCH] option to skip slow -identify output
by kiriuja 26 Apr '06

26 Apr '06

When -identify is used on a DVD, mp_describe_titleset is called for each VTS, which takes a lot of time if there are many of them. So the attached patch skips that call along with DVDDiscID unless -identify is given twice. Someone please check and apply. -- kiriuja

6 20

Paid development offer
by Uri Shkolnik 26 Apr '06

26 Apr '06

All, I would like to offer a commercial project for experience developer(s) familiar with MPlayer. The project deals with supporting a new MDTV receiver, using various MDTV standards, targeting multiple ports (Linux, embedded Linux, WinCE, Win32). The project is demanding (E.g. requires full time development, probably for more than a single developer). Please contact me directly ( mailto:urishk@yahoo.com ), Regards, Uri http://www.siano-ms.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Ты сегодня ко мне приедешь?
by Michaelni 25 Apr '06

25 Apr '06

1 0