January 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 wrong runtime and average bitrate for VBR MP3.
by Benoît Thébaudeau 18 May '12

18 May '12

Hi all, According to http://www.mpgedit.org/mpgedit/mpeg_format/mpeghdr.htm, the MP3 frame size depends only on the MP3 Layer, while according to http://www.codeproject.com/KB/audio-video/mpegaudioinfo.aspx#XINGHeader, the size of the Layer III side information depends only on the MPEG version, so spf can not be used by mp3_vbr_frames() to determine the Layer III side information size. Fix this by using lsf instead. Moreover, spf was not filled by mp_get_mp3_header() for NULL freq, which was an issue for mp3_vbr_frames(). This is also fixed. Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau(a)advansee.com> Best regards, Benoît Thébaudeau

2 6

[PATCH] libmpdemux/demux_audio: Fix audio time length.
by Benoît Thébaudeau 18 May '12

18 May '12

Hi all, This patch fixes the lack of use of movi_start by the audio demuxer to compute the audio time length. Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau(a)advansee.com> Best regards, Benoît Thébaudeau

2 5

[PATCH] libmpdemux/demux_audio: Skip ID3v2.4 tags.
by Benoît Thébaudeau 18 May '12

18 May '12

Hi all, ID3v2.4 tags may have a footer, and they may be appended to MP3 files, before ID3v1 tags. Skip these like other ID3 tags. Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau(a)advansee.com> Best regards, Benoît Thébaudeau

3 45

[PATCH] fix OSD decimal output for dvdnav
by Roger Pack 22 Apr '12

22 Apr '12

Hello. Apologies for the flood. Anyway, currently with the OSD decimal output, it gets the "second" portion from demuxer_get_current_time (the NAV packets) and gets the "decimal portion" of the output from sh_video->pts. Since these don't match with DVD's (the NAV packets only occur every 0.5s, and are usually about 0.1s "off" the MPEG timestamps), it can lead to odd OSD output, for example: $ mplayer dvdnav://1 -osd-fractions 1 -osdlevel 2 OSD output: ... 00:00:04.04 00:00:04.08 00:00:04.12 00:00:04.16 00:00:04.20 00:00:04.24 00:00:04.29 00:00:04.33 00:00:05.37 # note the shift here... 00:00:05.41 00:00:05.45 00:00:05.50 00:00:05.55 00:00:05.60 00:00:05.65 00:00:05.70 00:00:05.75 00:00:05.80 00:00:05.84 00:00:05.90 00:00:05.95 00:00:05.99 00:00:05.04 # shift again, because the two are offset. ... [repeat] Also if there has been a timestamp reset ever, it leads to even odder output numbers, like 01:20:05.-8 displayed in the OSD. This patch makes the OSD "monotonically increase" and doesn't seem to hurt other stream types. For dvdnav, it now outputs the equivalent of: ... 00:00:00.40 00:00:00.40 00:00:00.40 00:00:00.40 00:00:00.80 00:00:00.80 00:00:00.80 00:00:00.80 00:00:00.80 00:00:00.80 00:00:00.80 00:00:01.20 00:00:01.20 ... which, though less precise, seems more accurate (and works past reset's et al). My hope is to (should these patches eventually be applied) submit another diff that makes these timestamps even more accurate, but this would is an improvement, at least from my perspective. I also am considering another similar patch for EDL timestamps checking, so that EDL's can work with dvdnav (esp. past any MPEG PTs resets). Feedback welcome. Thanks. -roger-

2 8

[PATCH] Fix wrong runtime and average bitrate for VBR MP3 if using libmad.
by Benoît Thébaudeau 25 Mar '12

25 Mar '12

Hi all, The libmad codec interface writes i_bps without taking the VBR case into account. This is fixed by not overwriting i_bps if it has already been computed successfully by the audio demuxer. Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau(a)advansee.com> Best regards, Benoît Thébaudeau

2 3

patch for bmovl
by Emmanuel Anne 07 Mar '12

07 Mar '12

Ok, here is finally a patch for the problem I posted 1 week ago. Finally it's not related to fps, but rather to the size of the video : if the video buffer is aligned its size changes while the bmovl buffer doesn't, which produces a nice crash. Fixed by passing the right flag to vf_get_image Then if you play a video with a broken size (like 540x396), the application communicating via bmovl will send a buffer for a 540 pixels wide buffer and it will be totally distorted because the actual width here is 544 for alignement reasons. So this patch now makes the difference between the width of the source bitmap and the one of the destination bitmap instead of assuming they are always identical. So far all the videos I could test pass without problem (tested on 2 computers !).

2 2