January 2013 - 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

Re: [MPlayer-dev-eng] MPlayer fails to build with live-2012.08.20
by Ross Finlayson 22 Apr '13

22 Apr '13

> Does adding > #define RTSPCLIENT_SYNCHRONOUS_INTERFACE 1 > to the configure test also fixes this problem? It probably will. I should warn you, though, that the synchronous "RTSPClient" interface is considered deprecated, and will eventually be removed. You should plan on updating your LIVE555 interface code to use the new asynchronous interface instead (as VLC did a couple of years ago). Ross Finlayson Live Networks, Inc. http://www.live555.com/

2 2

[PATCH] Add option to set heartbeat command execution interval
by Android Jack 30 Mar '13

30 Mar '13

Hi ! Attached is a patch which adds a command line option named "-heartbeat-interval", which takes an integer >= 1 representing the delay in seconds between each execution of the command specified with the (existing) "-heartbeat-cmd" option, avoiding to hardcode this to 30 seconds. I used "-heartbeat-cmd" option to implement a very simple keepalive functionality in my application which, in my case, kills mplayer in case of absence of an RTP stream. Being able to specify command execution interval, makes it much more responsive to RTP stream interruption. I find it simple (at least, so it seems to me ;-)) to add to mplayer, and think it could be useful to someone else, so here it is. This is my first submission to a BIG project, and have tried to comply with submitting rules ... so be understanding with me :-)

2 5

Re: [MPlayer-dev-eng] [PATCH] Better double frame rate output and frame limit option.
by Vicente Sendra 24 Mar '13

24 Mar '13

> Testing HD ts and m2ts with this and just -framedrop I can't > find any > regressions. Ok, i'm really happy to hear that. > Being able to field step is nice, is it possible to > implement the same > for vdpau:deint=2 ? I thought that the only way of adding frames were the filters tfields and yadiff, but as you say, vdpau adds them too. I'm taking a look at vo_vdpau.c and it seems it has the same problem that was present in tfields and yadiff, it calls flip_page with no timing in function video_to_output_surface(). New option fpslimit is not going to work as expected with this VO, it will detect a frame limit equal to real frame limit/2, and it will drop frames in pairs, because main loop will process full frames, not fields (as it's done now in tfields and yadiff). I need to study it deeper, but i think it can be done. Call stack for one frame (2 fields) is something like this (deinterlace mode): filter_video -draw_image --video_to_output_surface ---flip_page flip_page We have to avoid ---flip_page and queue a frame like in tfields and yadiff, then modify video_to_output_surface to output just one field on each call. New call stack should be something like this: (field 1) filter_video -draw_image --video_to_output_surface ---vf_queue_frame flip_page (field 2) vf_output_queued_frame -video_to_output_surface flip_page vf_queue_frame should handle both frames queued from vo (vo_vdpau) and vf (tfields, yadif) same applies to vf_output_queued_frame. Any Ideas?, suggestions are welcome.

4 14

[PATCH] Fix libdvdcss on OS/2
by Dave Yeo 09 Mar '13

09 Mar '13

r35807 seems to have broke compilation on OS/2 due to OS/2 having direct.h and it being unconditionally checked for. One possible fix, Index: libdvdcss.c =================================================================== --- libdvdcss.c (revision 35820) +++ libdvdcss.c (working copy) @@ -238,7 +238,7 @@ */ if( psz_cache == NULL || psz_cache[0] == '\0' ) { -#if HAVE_DIRECT_H +#if defined (HAVE_DIRECT_H) && defined (HAVE_WIN_H) typedef HRESULT( WINAPI *SHGETFOLDERPATH ) ( HWND, int, HANDLE, DWORD, LPTSTR ); Dave

6 14

Re: [MPlayer-dev-eng] [PATCH] Better double frame rate output and frame limit option.
by Vicente Sendra 04 Mar '13

04 Mar '13

Finally, i finished all my test for the new system. //////////////////////////////////////// New fpslimit option //////////////////////////////////////// The new option fpslimit has this syntax: -fpslimit <option1:option2..> -options: mode=<0 .. 2> working mode, 0(default) disables frame limit 1 fixed frame limit 2 automatic frame limit detection fastdrop=<0.0 .. 10.0> makes some extra drops if > 0 min=<value> lower limit for fps (set to max in mode 1) max=<value> upper limit for fps start=<value> starting limit for fps (set to max in mode 1) In mode 1 the system simply drops frames trying to limit output frame rate to specified value ("max"). In mode 2 the system calculates a max frame rate based on vflip time. Roughly speaking, it lowers max frame rate if vflip time gets big, and raises frame rate if if vflip time is low and video frame rate is higher than max frame rate. ("min" and "max" options limit the calculated value, and "start" sets the initial value, if not specified or 0, no limits are applied. If "start" is not set a value is calculated from video frame rate and average frame rate output). It takes a few seconds to get the right value. Fastdrop reacts in a fast way to vflip time, triggering extra frame drops, it makes the system react faster, highly recommended for either mode 1 or 2, makes fps limit precision (specified or calculated) less important. Higher values trigger a frame drop faster, normaly should be set to 1. Mode 1 can be used in all vo drivers, but must be used for vo drivers where vflip generates a wait in almost all frames (vsync enabled, but no buffering), mode 2 would drop lots of frames. Also, for these drivers, fastdrop option must not be used. Example (no buffering) : -fpslimit mode=1:max=60 Example (with buffering):-fpslimit mode=1:fastdrop=1:max=60 (fastdrop is optional, but recommended) Mode 2 should be used for vo drivers that do not delay vflip to next vertical refresh (vsync enabled, but buffering allows to return immediately). Example (no buffering) : do not use Example (with buffering):-fpslimit mode=2:fastdrop=1:max=60 (fastdrop is optional, but recommended) //////////////////////////////////////// New framedrop logic //////////////////////////////////////// -Works even with no sound. -Drops frames by sync or fpslimit. -Works for all frames, read and interpolated (created by vf) //////////////////////////////////////// New double frame rate output //////////////////////////////////////// -Accurate timing for frames created by video filters In correct-pts mode frame time is set by video filter. to make this work video filter needs to know video frame time, this is supplied by new control option: VFCTRL_SET_FRAMETIME. In normal mode frame time is calculated taking into account the number of frames created by video filter(s) and video frame time. (vf_num_queued_frames function returns number of frames created for each read frame). In both modes, filters that add frames always queue them (previously this only happened in correct-pts mode). Changes were needed in decode_video function(dec_video.c) to avoid the message: "Too many buffered pts" This happens with vanilla mplayer. When framedropping dropped some frames, pts values accumulated in the buffer. I think there are two things here that are not perfect (but at least not worse than before): -Why generate_video_frame function (correct-pts mode) calls this function like this: decode_video(sh_video, start, in_size, drop_frame, pts, NULL); And not like this (like in normal mode): decode_video(sh_video, start, in_size, drop_frame, sh_video->pts, &full_frame); The problem is full_frame should be used to check if frame is complete and not an interlaced frame. Right now it works as vanilla code, but i think it's not ok, because if we call this function with drop_frame <> 0 with an incomplete frame we'll get a return value of null and, in this case makes generate_video_frame return with a -1 (and -1 should only be returned for full dropped frames). -I've got errors in correct-pts mode with mpeg2 files: "mpeg_decode_postinit() failure" followed by a lot of erros. //////////////////////////////////////// Filter yadif compatible with new double frame rate output //////////////////////////////////////// Added internal field: buffered_frametime Added handling of VFCTRL_SET_FRAMETIME //////////////////////////////////////// Filter tfields compatible with new double frame rate output //////////////////////////////////////// - vf_tfields.c Added internal fields: buffered_frametime, do_deinterlace Added control function Added handling of : VFCTRL_SET_FRAMETIME, VFCTRL_GET_DEINTERLACE, VFCTRL_SET_DEINTERLACE Added mode 5 for this filter, like mode 1, but just skips filtering VFCTRL_SET_DEINTERLACE is only allowed in mode 1,5. A question here: can the filter configuration (video output size) be changed on the fly, so we can allow this in all modes?. //////////////////////////////////////// mplayer.c //////////////////////////////////////// I know it's a big patch. Some notes: For easy testing/debugging I've added some outputs like this (should be removed when done): time sleeping: mp_msg(MSGT_CPLAYER, MSGL_INFO, "Frametime_sleep : %3.3f ", (*time_frame)*1000); time between frames: mp_msg(MSGT_CPLAYER, MSGL_INFO, "Wait until: : %5.3f\n", dif_flip*1000); Information for fpslimit + mp_msg(MSGT_CPLAYER, MSGL_INFO, "Frametime_error I:%d T:%3.3f F:%3.3f E:%3.3f FD:%3.3f IO:%d \n", + interpolated, fpsl_target_frametime*1000, frame_time*1000, fpsl_frametime_error*1000, vflip_frame_time_usage_fastdrop*1000, int_frames_output); dropped frames: mp_msg(MSGT_CPLAYER, MSGL_INFO, "DROPPED INT. FRAME by VOUT \n"); checking pts: mp_msg(MSGT_CPLAYER, MSGL_INFO, "PTS: %3.3f \n", sh_video->pts); mp_msg(MSGT_CPLAYER, MSGL_INFO, "PTSdec: %3.3f , %3.3f \n",pts, sh_video->pts); frame stats: + if (sh_video->timer > 0.5) + saddf(line, &pos, width, "%2.3f %2.1f %3.3f ", + vflip_min_time*1000, + vflip_frame_time_usage*1000, + vout_frame_time_avg*1000); Global variables marked with //- can be changed to local once we finish debugging. I think there are enough comments to understand the new parts, but don`t hesitate to ask me if you don't, I'll try to explain it asap. Also, tell me if there is something that should be changed/corrected/done in another way, any suggestions are welcome. I'm very interested in testing this as much as possible, as far as i tested, it works as vanilla code with fpslimit disabled. New double frame rate output works in both modes (correct-pts and normal) but i could not test mpeg2 streams in correct-pts because of the errors i said previously. All the work has been done over 35196 and then updated to r35689.

3 4

[PATCH] af_volnorm: make it work with float audio data
by Giorgio Vazzana 02 Mar '13

02 Mar '13

Hi, MPlayer decodes some common audio formats in floatle, for example: ========================================================================== Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 44100 Hz, 2 ch, floatle, 192.0 kbit/6.80% (ratio: 23999->352800) Selected audio codec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio)) ========================================================================== ========================================================================== Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 44100 Hz, 2 ch, floatle, 0.0 kbit/0.00% (ratio: 0->352800) Selected audio codec: [ffvorbis] afm: ffmpeg (FFmpeg Vorbis) ========================================================================== but af_volnorm doesn't seem to work with float audio data. The attached patch fixes this, assuming float samples are in the range [-1.0f, 1.0f] (is there any codec that uses a different range?) I have used it locally for about a month now, so I thought I'd send it upstream. Other minor things I noticed looking at libaf/a_volnorm.c: * the SIL_S16 and SIL_FLOAT constants should probably be lowered by a factor of 5, from (MAX*0.01) to (MAX*0.002), to avoid the 'step' effect that is present when a video starts with a very quiet audio track * there is a mixture of double constants and float variables, converting all the constants to float might speed things up * some formulae, for example the ones used to compute s->mul, can be simplified * some code is duplicated, for example the part that computes the rms value of a audio chunk; a macro could be used * method*_int16 could use a lrintf() in the scale loop Regards, Giorgio Vazzana

2 4

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