December 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

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

[PATCH 0/7] stream ftp: Support longer file names
by Alexander Strasser 27 Jan '13

27 Jan '13

Due to the concerns raised recently about long file names with stream ftp, this series aims to make longer ones possible. After the first 6 patches are applied it is finally possible to change the command buffer size which is mainly responsible for the supported file name length. I increase that size in patch 7. But I still had some problems with very long file names at some point when testing here locally. But I could use much longer names than are supported now. Seems to be a server problem but I am not very sure about it. So testing is very welcome especially with long names and with different FTP servers at the remote end. I also would welcome code reviews on this. Alexander Strasser (7): stream ftp: readline: Fix off-by-one error stream ftp: readline: Always initialize output parameter buf stream ftp: readline: Always try to read complete lines stream ftp: Only send QUIT command if connected stream ftp: Create buffers before opening control connection stream ftp: Allocate command buffer on-heap stream ftp: Increase command buffer size stream/stream_ftp.c | 96 ++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 69 insertions(+), 27 deletions(-) -- 1.7.10.2.552.gaa3bb87

9 100

how to enable hardware acceleration video decoding based on stagefright of android ?
by lean fu 14 Jan '13

14 Jan '13

hi list: ffmpeg 0.10 or later has "libstagefright.cpp" providing hardware acceleration on android , and there's an building script at " ffmpeg/tool/build_libstagefright" for compiling this feature , but unfortunate, 'configure' of mplayer don't support "--enable-libstagefright-h264" , i have to modify config.h and config.mak to add some stagefright related macro manually. and change the 'name' member of ff_libstagefright_h264_decoder from "libstagefright_h264" to "h264". after these changes, when play a file contains h264, procedure will call into 'Stagefright_decode_frame'. but the picture looks abnormal , sometimes appears full blue(or green) screen,for some 1080p files,even throw fatal errors. had somebody get the stagefright features works successfully? and is there some more simple way that i can integrate the stagefright feature into my android port of mplayer ? thanks !

3 3