July 2002 - MPlayer-dev-eng - lists.mplayerhq.hu

[PATCH] OSD Menu
by Alban Bedel 24 Jul '02

24 Jul '02

Hi, i wanted to do this since a while. I simple osd menu. Here is the first hack wich consist of 3 menus. A generic one where each entry is bound to a command. A 'jump to' menu to choose another entry in the playlist. And a fileselector to load a file or a playlist. All this is very primitive atm but it's usable :) To use it you need to add a few lines to your input.conf like this : 8 menu up 5 menu down 4 menu cancel 6 menu ok Then run mplayer -menu some_movies .... The menu will show up when you press any of the keys you choose. Albeu

4 5

machine lockup due to xv driver
by Nilmoni Deb 24 Jul '02

24 Jul '02

This is in reference to my earlier post in http://mplayerhq.hu/pipermail/mplayer-users/2002-July/018457.html My investigattion shows that till cvs 2002/7/19, things are ok but the cvs of 2002/7/20 is consistently leading to machine lockup when mplayer is run with "-vo xv". I found out (after 10 manual resets, the hard way) that this is due to the changes made for audio and video equalizer handling. Here's the tests I ran. Test1 ----- - get cvs of 2002/7/19 - version of mplayer.c is 1.527 - update these files manually: video_out.c (1.53), video_out.h (1.37), vo_xv.c (1.105) This one has no problems. Test2 ----- Do everything in test1 and also update mplayer.c to v1.528. This one caused hard lockup. This means the changes in mplayer.c _alone_ (between v1.527 and v1.528) are triggerring the savage driver bug. It may be working with mga g400 [x]mga,xv,xvidix and radeon xv,xvidix etc. but its failing with the prosavage km133 xv. So I commented out line 1387 of mplayer.c (cvs version v1.528), which is: set_video_eq( v_hw_equ_cap ); This change made the lockup problem go away which means something in the function set_video_eq( int cap ) is going wrong and causing the lockup. While this new problem may be hard to solve, if left unattended, users of km133 prosavage video (and other similar chipsets) will be stuck forever. I am ready to test out each revision (at the cost of manual resets!!), only if somebody is ready to address the issue. Here's a part of the output of xvinfo on my system: number of attributes: 5 "XV_COLORKEY" (range 0 to 16777215) client settable attribute client gettable attribute (current value is 66046) "XV_BRIGHTNESS" (range -128 to 127) client settable attribute client gettable attribute (current value is 0) "XV_CONTRAST" (range 0 to 255) client settable attribute client gettable attribute (current value is 128) "XV_SATURATION" (range 0 to 255) client settable attribute client gettable attribute (current value is 128) "XV_HUE" (range -180 to 180) client settable attribute client gettable attribute (current value is 0) Compare this with the initial values (in video_out.c) int vo_gamma_brightness=-101; int vo_gamma_saturation=-101; int vo_gamma_contrast=-101; int vo_gamma_hue=-101; Obviously, vo_gamma_saturation and vo_gamma_contrast are outside their permitted range. Could this be the problem ? thanks - Nil

5 5

Re: How to call *windows* functions in a cygwin c program
by Sylvain Petreolle 24 Jul '02

24 Jul '02

No, this is a bit more complicated. The project is a video player that has been started on Linux. To have _all_ codecs recognized and played with, it makes use of windows DLLs, through windows emulation project parts. Since emulating windows DLLs/functions under cygwin is a nonsense, I looked after a way to compile it with cygwin win32 API calls. --- John Morrison <john.r.morrison(a)ntlworld.com> a écrit : > If all you need is to read some registry values check out the > virtual (not sure if that's the right description) filesystem > > /proc/registry/... > > It gives you read only access to the windows registry. If you > want to write I'm sure other people would appreciate the patch ;) > ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 1

machine lockup due to xv driver
by Nilmoni Deb 24 Jul '02

24 Jul '02

pl, I have already tried a hack. I re-enabled the set_video_eq function call in mplayer.c (v1.528), but commented out the blocks for saturation and contrast in the set_video_eq function definition. Still, I got the lockup. Also, as I have said already, the _only_ thing that triggers the lockup is the set_video_eq function call in mplayer.c (v1.528). The vo_xv.c (v1.105) works just fine. So I think my initial guess about wrong values of xv attributes being the cause of lockup may be wrong. Can somebody explain what the function set_video_eq in mplayer.c does ? Just explain the lines in any one block such as: mp_cmd = (mp_cmd_t *)calloc( 1,sizeof( *mp_cmd ) ); mp_cmd->id=MP_CMD_BRIGHTNESS; mp_cmd->name=strdup( "brightness" ); mp_cmd->args[0].v.i=vo_gamma_brightness; mp_cmd->args[1].v.i=1; mp_input_queue_cmd( mp_cmd ); thanks - Nil > It is a problem. I reported the bug on the -cvs mailing list as it was > triggered with nvidia drivers. Pontscho commited a quick workaround for > nvidia but the initialization does not seem fixed :/ > > You might try replacing in libvo/vo_xv.c: > if(!port_value && use_reset) continue > by a > if(port_value < -100 || port_value > 100) continue; > > This should prevent out of range values from being sent to your xv > driver > which should ignore them instead of crashing. > > -- > Best regards, > pl

1 0

simple rawdv support
by Alexander Neundorf 24 Jul '02

24 Jul '02

Hi, I managed to get a libdv based demuxer and decoder for raw dv files working for mplayer. I have only one type of dv camera here, and thereby only one type of dv files. It plays dv files as created by dvgrab --format raw. The patch is against cuurent cvs, created using diff -rbupP. Bye Alex

1 0

How showing JPEG files?
by Lim Seok Woo 24 Jul '02

24 Jul '02

Hi... How showing JPEG files?

1 0

configure X check issue
by Gabucino 24 Jul '02

24 Jul '02

Just compiled XFree86 3.3.5 for my notebook, and I noticed that I had to ln -s /usr/X11R6/lib/libX11.so.6 /usr/X11R6/lib/libX11.so ln -s /usr/X11R6/lib/libXext.so.6 /usr/X11R6/lib/libXext.so to have my X detected by MPlayer ./configure Is it all right this way? -- Gabucino / Worshipping Niedermayer 4ever /

4 6

Worm Klez.E immunity
by adiss96 23 Jul '02

23 Jul '02

1 0

Matrox Mystique donation
by Diego Biurrun 23 Jul '02

23 Jul '02

Hi! There was a feature request by Davide Decicco on -users some weeks ago about adding Matrox Mystique support to mga_vid: http://mplayerhq.hu/pipermail/mplayer-users/2002-May/016003.html http://mplayerhq.hu/pipermail/mplayer-users/2002-June/016328.html Apparently Davide uploaded those specs to mphq. I have a card lying around here that I can donate to anybody willing to implement this. It is an 8MB PCI card with an MGA-1064SG-D (Hurricane) chipset. If somebody is interested, say so here and tell me your postal address in private. Diego

1 0

[PATCH] Reverse vop order in command line
by Fabian Franz 23 Jul '02

23 Jul '02

Hi! [Short Desc] This patch reverses the order of the vop-filters, when the command line is parsed... So the right direction for the applying of the video-filters is again: left-to-right... I hope this is usefully ... [Long] I myself did not realise that the order of the -vop-filters was right-to-left until i read the attached mail ... I read: "[mplayer-dev-eng] -vop scale" > On Thursday 18 July 2002 01:03, Felix Buenemann wrote: > Btw. I'm still for changing specification order of -vop, because it's fully > unatural now, (most) people think and write from left to right, so even > when you know that the order is reversed, you always start shuffling around > with the curser to get it all right. > I know it's already quite late for this, but I think it's worth the change > and many(?) users do this wrong, too. I asked Arpi about this long time > ago, he agreed but never changed it... (I had a go at it myself back then, > but failed miserably for some obscure reason ;) and decided to make a patch. As this is my first patch to mplayer i read the http://www.mplayerhq.hu/DOCS/tech/patches.txt several times and checked it. And first of all i had to find a suitable location for my patch ... I think that the vop-filters are accessed in the reverse order, because new filters specifically to the codecs are added to the end and those have to be executed first ... Correct me if i'm wrong ... So the only suitable and easy to find place was there, where the command line is parsed ... And, because the -loop-option is parsed there as well, I decided to place my code there ... I also tried to look through the file to find suitable parsing-code ... What I didn't know was, how it is with memory checking after malloc or calloc ... Sometimes it is checked, sometimes it is not... As I need a calloc in my code, I don't know how to handle this ... I hope you understand and like my first patch ... And then I wanted to say: MPlayer is really great work! Best wishes, Fabian

5 6