March 2006 - MPlayer-dev-eng - lists.mplayerhq.hu

audio_out.c question
by Mitch Golden 25 Mar '06

25 Mar '06

I am new to this list but I have a question about the code in libao2/audio_out.c. I am running on Linux Fedora Core 4, using KDE. The situation is this: I checked out the CVS head (about a week ago) and built it. Whenever I play an audio file, I notice that it tries first to open the /dev/dsp (OSS driver). If artsd is running, this fails (and I get an annoying popup if I'm running the GUI) and then it opens the alsa driver and plays the audio that way. (For those not on Linux/KDE, you should know that artsd auto-suspends when it's not in use for a while, so it might or might not be running at any given time.) This leads to a big problem: If I play something when artsd is *not* running, the player will grab /dev/dsp, meaning that artsd can't play anything. Worse yet, if I pause the playback when it's playing through OSS, and while it's paused some other application starts up artsd (something as simple as a system beep), gmplayer crashes when I unpause it. It seems to me that the fix is trivial: the order in which the drivers are listed in audio_out.c is wrong. The "wrapper-type" drivers are listed below the "native" drivers, so the native ones are tried first. This seems to me backwards - you should try wrappers before trying native. My suggested ordering has artsd first, then alsa, then oss. Of course this is true on my Linux system, and I don't know what should be done with some of the others. Forgive me if this is something that's been discussed before. If people agree with me, I can make a patch. - Mitch Golden

13 40

Custom input
by Rok 24 Mar '06

24 Mar '06

Hello, I have just made my custom input for mplayer. But I have a problem with dealing with sending commands to it. An input has functions ..._input_init() ..._input_read(), where read() function should return an int. I don't know what to return in read() function for example to achieve MP_CMD_SEEK effect. I have tried to send back te (ASCII) space char which works and pauses the player, but I want to be able to send commands which are listed in input.h file such are MP_CMD_SEEK or MP_CMD_PAUSE... Can anybody help me how this is done? Thank you, Rok

1 0

Missing path for XviD header on Makefile
by Roberto Gordo Saez 24 Mar '06

24 Mar '06

MPlayer cvs source fails to compile when xvid.h header is located on some non standard place (configure --with-xvidincdir does not work). Actually, the problem is on libavcodec Makefile, because it does not use $(XVID_INC). I think that libavcodec/Makefile is missing something like this: ifeq ($(CONFIG_XVID),yes) CFLAGS += $(XVID_INC) endif

3 3

[PATCH] Some iconv fixes
by Björn Sandell 24 Mar '06

24 Mar '06

The fix in mp_msg.c avoids a core dump when iconv_open() fails, the other just makes it possible to compile if USE_ICONV is undefined.

3 2

[PATCH] Add window icon to x11-based vo
by Guillaume POIRIER 23 Mar '06

23 Mar '06

Hi, the attached patch implement $subj. It's basically a rip-off of Danny Milosavljevic's patch sent to thread: Date: Feb 12, 2006 6:59 PM Subject: [MPlayer-dev-eng] window title patch ... except this patch only adds the icon, and doesn't change the title, and the actual icon used is the official icon of MPlayer. Please direct all flames to /dev/null [either you do it or I do it on my machine ;o)] and tell how this patch can be improved, or if it deserves to be merged on CVS. One of the things that aren't too good about that patch is the fact that the xpm icon has been directly generated with imagemagik, so it's quite possible that it may be overly big or that some obscure plate forms will choke on it. One of the other things that isn't too great is that it adds a dependency on libxpm (which means that you need to append "-lXpm" to the build command line to test this patch)... and I know we don't like to add additional dependencies if possible. So maybe it could be a better idea to load the icon with libpng if MPlayer has been compiled with png support? I don't know how easy this could be, but I'm sure it's feasible. Thoughts? Guillaume Please keep Danny in CC as he's the author of this patch, and he is not subscribed. -- I am disillusioned enough to know that no man's opinion on any subject is worth a damn unless backed up with enough genuine information to make him really know what he's talking about. -- H. P. Lovecraft (about the flamewars on FFmpeg and MPlayer-dev mailing lists) http://www.brainyquote.com/quotes/quotes/h/hplovecr278144.html

1 0

Please add 0x2033504D in ffmp3 codecs.conf file
by Andrea Palmatè 23 Mar '06

23 Mar '06

At 00:43 23/03/2006, you wrote: >On Wednesday, 22 March 2006 at 22:46, Andrea Palmatè wrote: > > Since it work correctly, it is possible to add 0x2033504D into > > codecs.conf? >Not without a sample that needs it. any video with mp3 into. Andrea Palmatè http://www.amigasoft.net

2 1

[PATCH] X264_* & X264_* vars broken
by Derek E. Lewis 23 Mar '06

23 Mar '06

Users who install XviD or x264 into non-default locations will experience broken builds when building libavcodec/, as ffmpeg does not use XVID_INC, XVID_LIB, X264_INC, and X264_LIB. XVID_INC and friends are specified using --with-xvid* --with-x264*, giving a user an impulse to use those configure options over --with-extra*. I've relocated the homes of $_ld_x264 and $_ld_xvid to EXTRA_LIBS. We may consider to remove all instances of *_INC and *_LIB in the future, as it leaves too much room for inconsistency between MPlayer and ffmpeg. Derek E. Lewis dlewis(a)solnetworks.net http://riemann.solnetworks.net/~dlewis

2 2

[BUG] [FIX?] wrong osd_show_text behaviour
by Jonas Jermann 23 Mar '06

23 Mar '06

Hi The current osd_show_text behaviour seems wrong: o The text is positioned strangely (too much on the right) o The last 2 char's are cut I traced the problem down to mplayer.c: MP_CMD_OSD_SHOW_TEXT uses set_osd_msg(OSD_MSG_TEXT,1,osd_duration,"%64s",cmd->args[0].v.s); so the text is saved as a "right alligned char[65]" iirc (or not?). In void set_osd_msg(int id, int level, int time, char* fmt, ...): ... va_start(va,fmt); vsnprintf(msg->msg, 63, fmt, va); va_end(va); So this would explain the 2 char cut. Iirc the fmt takes the "visual" size whereis vsnprintf takes the real length (usually +1), so this should be 65 instead of 63. Or even better: 64 and %63s in set_osd_msg, as the osd message string was declared as char[64] iirc. Anyway, I'm still not happy: To me it seems that this was introduced to right allign the text to a fixed size of 64, but once the text is rendered the char's won't have equal width, so will this work at all? Besides the text would need to be shown right alligned in the sub.c code, not left alligned as it seems to be done in sub.c: initial position x=20 (that doesn't make any sense to me, to right allign a string and then left allign the rendered one). The allignment should be done in the sub.c code only anyway and not by adding spaces to the initial string. So I vote for this change: -set_osd_msg(OSD_MSG_TEXT,1,osd_duration,"%64s",cmd->args[0].v.s); +set_osd_msg(OSD_MSG_TEXT,1,osd_duration,"%s",cmd->args[0].v.s); -vsnprintf(msg->msg, 63, fmt, va); +vsnprintf(msg->msg, 64, fmt, va); (I'm still not 100% sure if this should be 63, 64 or 65 here and what to do with trailing \0, etc ... ;) Maybe there are still problems with this solution, but at least change the ugly solution to a "working" (not bugged) solution. With Best Regards Jonas Jermann

2 1

[PATCH] ppc fix for realvideo in mkv
by Emanuele Giaquinta 23 Mar '06

23 Mar '06

Hi, This patch fixes the longstanding issue of realvideo decoding in mkv on ppc, it is an endianness issue. -- Emanuele Giaquinta

6 10

Re: [MPlayer-cvslog] CVS: main/libmpcodecs dec_video.c, 1.165, 1.166 ve_divx4.c, 1.20, 1.21 ve_lavc.c, 1.134, 1.135 ve_libdv.c, 1.15, 1.16 ve_nuv.c, 1.9, 1.10 ve_qtvideo.c, 1.18, 1.19 ve_raw.c, 1.7, 1.8 ve_vfw.c, 1.21, 1.22 ve_x264.c, 1.48, 1.49 ve_xvid.c, 1.32, 1.33 ve_xvid4.c, 1.25, 1.26 vf.c, 1.124, 1.125 vf.h, 1.29, 1.30 vf_1bpp.c, 1.5, 1.6 vf_2xsai.c, 1.4, 1.5 vf_bmovl.c, 1.14, 1.15 vf_boxblur.c, 1.6, 1.7 vf_crop.c, 1.18, 1.19 vf_cropdetect.c, 1.13, 1.14 vf_decimate.c, 1.3, 1.4 vf_del
by Michael Niedermayer 22 Mar '06

22 Mar '06

Hi On Tue, Mar 21, 2006 at 10:26:47PM +0100, Michael Niedermayer CVS wrote: [...] > Log Message: > passing pts through the filter layer (lets see if pts or cola comes out at the end) everyone who maintains a filter or encoder go and check if the pts are correct, i just quickly converted all filters, either by passing pts unchanged or outputing unknown (MP_NOPTS_VALUE) later obviously isnt correct but better then wrong pts, and my goal was fixing the API not fixing 100 filters [...] -- Michael

3 2