May 2012 - MPlayer-dev-eng - lists.mplayerhq.hu

Homepage skin download issue
by Ingo Brückl 09 Sep '15

09 Sep '15

Yesterday, I updated hwswskin to 1.3, but it still isn't downloadable. Is the generation of the skin download tarballs working? Ingo

3 8

Homepage DOCS needs update
by Ingo Brückl 24 Apr '14

24 Apr '14

If it's already on the to-do list ignore, but the documentation on the homepage doesn't get updated. Ingo

3 12

[PATCH] xvmc: handle shm xvimage allocation error
by Marcin Slusarz 06 Jan '14

06 Jan '14

- handle xvimage/shm allocation failure and fallback to non-shm xv - assert xvimage->data_size!=0 because 0 size will lead to memory corruptions (I hit it because of bug in Nouveau's early xvmc implementation) Index: libvo/vo_xvmc.c =================================================================== --- libvo/vo_xvmc.c (wersja 34098) +++ libvo/vo_xvmc.c (kopia robocza) @@ -181,6 +181,15 @@ return cur_render->state || (cur_render->mpi && cur_render->mpi->usage_count); } +static void allocate_xvimage_non_shm(int xvimage_width, int xvimage_height, int xv_format) +{ + xvimage = (XvImage *) XvCreateImage(mDisplay, xv_port, xv_format, NULL, + xvimage_width, xvimage_height); + assert(xvimage->data_size); + xvimage->data = malloc(xvimage->data_size); + XSync(mDisplay,False); +} + static void allocate_xvimage(int xvimage_width,int xvimage_height,int xv_format) { /* @@ -188,7 +197,8 @@ * mit-shm this will bomb... trzing to fix ::atmos */ #ifdef HAVE_SHM - if ( mLocalDisplay && XShmQueryExtension( mDisplay ) ) Shmem_Flag = 1; + if ( mLocalDisplay && XShmQueryExtension( mDisplay ) ) + Shmem_Flag = 0; else { Shmem_Flag = 0; @@ -198,25 +208,41 @@ { xvimage = (XvImage *) XvShmCreateImage(mDisplay, xv_port, xv_format, NULL, xvimage_width, xvimage_height, &Shminfo); + if (!xvimage) + goto noshmimage; + assert(xvimage->data_size); Shminfo.shmid = shmget(IPC_PRIVATE, xvimage->data_size, IPC_CREAT | 0777); + if (Shminfo.shmid == -1) + goto shmgetfail; + Shminfo.shmaddr = (char *) shmat(Shminfo.shmid, 0, 0); + if ((long)Shminfo.shmaddr == -1) + goto shmatfail; + Shminfo.readOnly = False; xvimage->data = Shminfo.shmaddr; - XShmAttach(mDisplay, &Shminfo); + if (!XShmAttach(mDisplay, &Shminfo)) + goto shmattachfail; + XSync(mDisplay, False); shmctl(Shminfo.shmid, IPC_RMID, 0); } else #endif - { - xvimage = (XvImage *) XvCreateImage(mDisplay, xv_port, xv_format, NULL, xvimage_width, xvimage_height); - xvimage->data = malloc(xvimage->data_size); - XSync(mDisplay,False); - } -// memset(xvimage->data,128,xvimage->data_size); + allocate_xvimage_non_shm(xvimage_width, xvimage_height, xv_format); return; + +shmattachfail: + shmdt(Shminfo.shmaddr); +shmatfail: + shmctl(Shminfo.shmid, IPC_RMID, 0); +shmgetfail: + XFree(xvimage); +noshmimage: + Shmem_Flag = 0; + allocate_xvimage_non_shm(xvimage_width, xvimage_height, xv_format); } static void deallocate_xvimage(void)

4 6

GUI and vo_x11 functions
by Ingo Brückl 02 Mar '13

02 Mar '13

I'm about to commit the vo_x11_ewmh_fullscreen() patch which adds a window parameter to the function, but I'm not quite sure whether this really is ok, although I got permission. The question is whether vo_x11_ewmh_fullscreen() and all the other vo_x11 functions should only operate on the global vo variables (like vo_window in that case) or whether they should be reusable functions, offering services for whoever wants to call them (the GUI in my case). The reason why I raise this issue is that the GUI does call three other vo_x11 functions (with relative success), namely vo_x11_decoration() vo_x11_sizehint() vo_x11_setlayer() While vo_x11_decoration() seems to be problem-free (it has some useful parameters, but uses global variables as well), vo_x11_sizehint() mostly uses global variables (which causes some X errors with the GUI then if called at a time when these variables aren't yet set). vo_x11_setlayer() is pointlessly called by the GUI, because it doesn't do anything in case of WinID >= 0. So, what is the right way to continue? Setting all necessary global vo variables in the GUI - even prior to the vo driver (vo_window is known to become WinID later anyway, for example), trying to modestly patch these four functions so that they can be reused or copy the code and letting the GUI use its own copies? All these four functions are window specific and window handling should be GUI's task although commonly used code is convenient. Pros and cons should be obvious. Ingo

3 16

[PATCH] Fix regression in v4l2 channel tuning on cx88 cards
by Jon Doe 11 Jun '12

11 Jun '12

Hi, This patch tries to improve (not completely fix) a v4l regression from svn r27057 which introduced per channel resetting of v4l2 normids when tuning channels. The relevant bug report can be found at http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1326. I tested on cx88 and bt878 based cards. Only the cx88 is affected. The problem is that cx88 based cards will reset the picture size to 320x240 when changing norms, squashing the picture to a quarter size in the top left corner when changing channels in mplayer. The cx8800 driver needs to reset the picture size due to a hardware filter recalculation requirement when changing norms. Others have also noticed this problem in the driver, but no comprehensive fix was found - see http://www.mail-archive.com/linux-media@vger.kernel.org/msg00157.html The fix proposed is to only change the norm if the new channel norm (eg. NTSC) differs from the current norm (eg. PAL-I), as specified in the user config file. This should at least work for most people most of the time and speed up channel tuning at the same time.

2 3

Crash with unsharp filter and x264 mp4 files
by Ingo Brückl 30 May '12

30 May '12

Since a short time ago (can't exactly say since when) I'm noticing a strange behaviour with x264 encoded mp4 video files which I blamed the files for, thinking they were buggy, but they aren't. When playing those files with the unsharp filter (l7x7:1.7), there are some greenish stripes at the top of the video and after a while MPlayer crashes after printing "Ran out of numbered images, expect crash. Filter before vo is broken." Without the filter, everything is fine. You can experience this with one of our sample files, namely http://samples.mplayerhq.hu/V-codecs/h264/mp4_h264/h264_parser.mp4 although this sample is too short to cause the crash. I've had an issue with this filter once before (some alignment issue on ffmpeg's side if I remember correctly). Any idea what it might be this time (side effect of recent changes concerning frames / direct rendering?) or what I should do to track it down? Ingo

2 6

[PATCH] compile as PIE by default
by Reimar Döffinger 26 May '12

26 May '12

Hello, below patch would compile MPlayer as PIE on x86 by default. On 32 bit, the cost would only be in a larger binary size and having to do relocations at startup, but no real cost at runtime. On 64 bit, there is almost no size or runtime overhead, mostly that in some cases PIC-relative addressing has to be used. I believe that none of the assembler code will be disabled by either. I have not made any changes to other architectures since I can't judge the impact. A side effect of the 64 bit case is that MPlayer will refuse to link against some static libraries (those not compiled with PIC and thus violating the ABI), one example (which only exists as static library) is LIVE555 as provided by Debian. Another point is that backtraces without debug info will probably be even less useful. Any comments? My belief is that there is negligible if any disadvantage for a sometimes significant win in security. Index: configure =================================================================== --- configure (revision 34955) +++ configure (working copy) @@ -2643,6 +2643,22 @@ fi +# try to create a relocatable binary by default +echocheck "relocatable binary" +if x86_32 && cflag_check -pie ; then + extra_ldflags="$extra_ldflags -pie" + relocatable=yes + res_comment="non-PIC" +elif x86_64 && cflag_check -fpie -pie ; then + extra_ldflags="$extra_ldflags -fpie -pie" + extra_cflags="$extra_cflags -fpie" + relocatable=yes + res_comment="fast PIC" +else + relocatable=no + res_comment="unavailable or untested architecture" +fi +echores $relocatable if x86_32 ; then # Checking assembler (_as) compatibility...

3 5

[PATCH] ralf support with native demuxer
by Roberto Togni 26 May '12

26 May '12

Hi, this adds support for ralf codec (ffmpeg decoder only, not the binary dll) to our real demuxer. Tested with the two ralf sample that I have. I'll apply it in a few days if no comments (and if my svn account still works). Ciao, Roberto

3 4

Release 1.1 first packaging attempt
by Reimar Döffinger 25 May '12

25 May '12

Hello, we decided it is time to do a release again. However there are two problems with that 1) We generally need a lot of testing to check that there are no too serious issues. 2) The usual people seem to have no time, FFmpeg has switched to git etc. so some knowledge on how to make the release tarball got lost. So I just made the first try of creating one from current trunk. I'd like as many people as possible to test compiling and running. I'd also like people to check that the right stuff is included (i.e. the HTML DOCS are there and work as expected, there are no .svn or .git directories etc.). I also have not decided on the formats, though I tend towards not making a .tar.gz available but only a .tar.bz2 and possibly .tar.xz. Opinions on that are welcome, too. And here's the tarball for you to test: http://www1.mplayerhq.hu/MPlayer/releases/MPlayer-1.1_testing_only.tar.bz2 Thanks for your help, Reimar Döffinger

7 8

[Patch] live555 configure error
by Zongyao Qu 23 May '12

23 May '12

I found live555 checking is extended, but libliveMedia.a is forgotten. as a result, live555 will never get passed. this patch is going to fix this. Best Regards, Zongyao QU

2 2