March 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

A bit more liberal parsing of <font> tags in .srt files?
by Szokovacs Robert 21 May '12

21 May '12

Hi, A lot of .srt subtitle files I encounter on the net is deemed incorrect by the current mplayer, so the <font> tag is displayed as if it was part of the script. (example: http://www.tvsubtitles.net/download-204587.html, some color= misses the quotes around the value.) My itch is scratched by the attached patch, but it doesn't care about the case when the quotes are missing and there are more than one subtags are present (<font color=red size=2> won't be parsed), so if there is interest, I'm hereby volunteering to refactor subassconvert_subrip() so it will accept whitespaces wherever possible. As far as I could tell, there is no official specification for .srt format, so I think it's good policy to accept anything we can parse unambiguously. Also, since the conversion takes place when loading the subtitle not while playback is ongoing, some speed sacrifice is acceptable. br Szo

7 13

[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

Remove internal mp3lib forked copy
by Diego Biurrun 25 Apr '12

25 Apr '12

Our mp3lib copy is buggy, redundant, unmaintained and has not been the default MP3 decoder since May 8th last year. There is no need for extending the deprecation period. I have removed it from my local tree and I want to push that commit soon. Diego

4 8

[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