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

[PATCH] A-V sync & Sub delay messages OSD
by Marcin Juszkiewicz 09 Mar '02

09 Mar '02

Hi all It's my 1st patch to mplayer. It is made as "cvs diff -c" (I can send you unified tomorrow - sorry). This patch change displaying "A-V sync" and "sub delay" messages to be visible with "osdlevel=1" for a moment. I made it because they was visible only in osdlevel=2 (time counter) which I don't like, but yesterday I have a movie with too badly synchronized subtitles which I had to synchronize few times during watching. Pressing z/x works but I don't get any info when not using osd with time counter. BTW. indenting scheme used in mplayer sources isn't too much readable ;) -- Marcin Juszkiewicz mailto:marcinj@netbox.pl

2 1

[PATCH] DOCS/bugreports.html
by Diego Biurrun 08 Mar '02

08 Mar '02

Oops, I just sent the mail before attaching the patch - sorry. Hi Gabucino and team! I just finished "porting" Daniel Egger's version of bugreports.html. The patch has no cosmetic changes to HTML tags and should satisfy your requirements. It is basically your version of the file with Daniel's text and my corrections. Please apply this patch. Let me know if you want any modifications. Regards Diego --- /usr/src/mplayer/DOCS/bugreports.html Tue Jan 8 18:38:24 2002 +++ bugreports.html Thu Mar 7 02:57:15 2002 @@ -7,112 +7,122 @@ How to report bugs? -First, try the latest CVS, maybe your bug is already fixed. CVS download -instructions (easy) can be found on our homepage. +First of all please try the latest CVS version of mplayer as your bug might +already be fixed there. CVS instructions can be found on our homepage. -If it didn't help: read <A HREF="documentation.html#D">Appendix D</A>, and other docs. If your problem isn't -known or isn't solved by our instructions, then report the bug: +If this did not help please refer to <A HREF="documentation.html#D">Appendix D</A> +and the rest of the documentation. If your problem is not known or not solvable by +our instructions, then please report the bug. -Where? +Where to report bugs? Subscribe to the mplayer-users mailing list:     <A HREF="http://mplayerhq.hu/mailman/listinfo/mplayer-users">http://mplayerhq.hu/mailman/listinfo/mplayer-users</A> -and send your bugreport to: +and send your bug report to:     <A HREF="mailto:mplayer-users@mplayerhq.hu">mplayer-users(a)mplayerhq.hu</A> -We won't CC: so please subscribe!!! +Please note that we will not individually CC (carbon-copy) people so it's a good +idea to subscribe to actually receive your answer. -Don't send bugreports private, directly to author's address!!! -We are working together on code, so everyone is interested in it. -BTW many times other users know the solution (system config probs, -bad drivers etc), even when we think it's a bug in our code. -The language of this list is ENGLISH! +Please don't send bug reports privately to individual developers. This is +community work and thus there might be several people interested in it. +Also sometimes other users already experienced your troubles and have a +solution in hand how to circumvent a problem even if it's a bug in mplayer +code. +The language of this list is English. -Please describe your problem in details, examples etc, and don't -forget to include these: +Please describe your problem as detailed as possible with examples etc. +and don't forget to include this valuable information: -What? +What to report? -1. The system info what we always want: +System Information <UL> -<LI>linux distribution -examples:<UL> - <LI>RedHat 7.1 - <LI>Slackware 7.0 + devel packs from 7.1 ...</UL> +<LI>Your Linux distribution or operating system e.g.: + <UL> + <LI>Red Hat 7.1 + <LI>Slackware 7.0 + devel packs from 7.1 ... + </UL> <LI>kernel version: <CODE>uname -a</CODE> <LI>libc version: <CODE>ls -l /lib/libc[.-]*</CODE> <LI>X version: <CODE>X -version</CODE> -<LI>gcc and ld version: +<LI>gcc and ld versions: <CODE>gcc -v ld -v</CODE> <LI>binutils version: <CODE>as --version</CODE> </UL> -2. Hardware & drivers: +Hardware & drivers <UL> -<LI>CPU info: +<LI>CPU info (this works on Linux only): <CODE>cat /proc/cpuinfo</CODE> -<LI>video card manufacturer and model - examples: <UL> - <LI>ASUS V3800U chip: nVidia TNT2 Ultra pro 32MB SDRAM - <LI>Matrox G400 DH 32MB SGRAM</UL> -<LI>video driver type&version - examples:<UL> - <LI>X built-in driver - <LI>nvidia 0.9.623 - <LI>Utah-GLX CVS 2001-02-17 - <LI>DRI from X 4.0.3</UL> -<LI>sound card type & driver - examples: <UL> - <LI>Creative SBLive! Gold with OSS driver from oss.creative.com - <LI>Creative SB16 with OSS drivers of kernel - <LI>GUS PnP with ALSA OSS emulation</UL> -<LI>if you are unsure, attach output of lspci -v +<LI>Video card manufacturer and model, e.g.: + <UL> + <LI>ASUS V3800U chip: nVidia TNT2 Ultra pro 32MB SDRAM + <LI>Matrox G400 DH 32MB SGRAM + </UL> +<LI>Video driver type & version, e.g.: + <UL> + <LI>X built-in driver + <LI>nVidia 0.9.623 + <LI>Utah-GLX CVS 2001-02-17 + <LI>DRI from X 4.0.3 + </UL> +<LI>Sound card type & driver, e.g.: + <UL> + <LI>Creative SBLive! Gold with OSS driver from oss.creative.com + <LI>Creative SB16 with kernel OSS drivers + <LI>GUS PnP with ALSA OSS emulation + </UL> +<LI>if in doubt include <CODE>lspci -vv</CODE> output on Linux systems </UL> -For compiling problems/errors +For compilation problems/errors -3. these files: +Please include these files: <UL><LI>configure.log <LI>config.h <LI>config.mak <LI>libvo/config.mak </UL> -For playback problems: +For playback problems -3. Output of mplayer at verbose level 1 (-v) +Please include the output of mplayer at verbosity level 1 <CODE>    mplayer -v [options] filename &> mplayer.log</CODE> - -4. If the problem is specific to one or a few files, - then please upload that file to: -<CODE>   ftp://mplayerhq.hu/MPlayer/incoming/</CODE> - Also upload a small .txt file with the same name as your file, - describing the problem! - Usually first 1-5 MB of the file is enough to reproduce - the problem, but first you should try it: -<CODE>   dd if=yourfile of=smallfile bs=1k count=1024</CODE> - (it will cut first 1MB of 'yourfile' and save to 'smallfile') - Then try again on this small file, and if bug still exists - then it's enough to upload this small file. - NEVER send such files via mail! Upload it, and send only - the path/filename of the file on the FTP. - If the file is accessible on the net, then sending the - _exact_ URL is enough! -5. For crashes (segfault, SIGILL, signal 4 etc): +If your problem is specific to one or more files, then please upload the +offender(s) to: -If you have coredump of the crash, see 5.a, else see 5.b: +    <A HREF="ftp://mplayerhq.hu/MPlayer/incoming/">ftp://mplayerhq.hu/MPlayer/incoming/</A> -5.a: Please print us coredump (if it was created). +Also upload a small .txt file having the same base name as your file, +which describes the problem you're having with the particular file. +Usually the first 1-5 MB of a file are enough to reproduce the problem, +but to be on the sure side we ask you to to: +<CODE>    dd if=yourfile of=smallfile bs=1k count=1024</CODE> -Howto: -please create following command file: +It will take the first megabyte of 'your-file' and write +it to 'small-file'. +Then try again on this small file and if the bug still shows up +your sample is sufficient for us. +Please do not ever send such files via mail! Upload it, +and send only the path/filename of the file on the FTP-server. +If the file is accessible on the net, then sending the +exact URL is sufficient. + +For crashes + +If you have a core dump of the crash continue reading the next paragraph, otherwise skip it. + +How to extract meaningful information from a core dump + +Please create following command file: <CODE>disass $eip-32 $eip+32 printf "eax=%08lX\n",$eax @@ -125,41 +135,45 @@ printf "esi=%08lX\n",$esi </CODE> -Then simply execute following command line: -    <CODE>gdb mplayer --core=core -batch --command=command_file >mplayer.bug</CODE> +Then simply execute the following on your command line: +    <CODE>gdb mplayer --core=core -batch --command=command_file > mplayer.bug</CODE> -5.b.: run MPlayer in gdb: -Re-compile mplayer with debugging code enabled: -./configure --enable-debug -make - -[at root/user shell prompt:] -    <CODE># gdb mplayer</CODE> -[at gdb prompt:] -    <CODE>> run -v [options-to-mplayer] filename</CODE> - ... (wait until it will crash) -    <CODE>> bt</CODE> -    <CODE>> disass $eip-32 $eip+32</CODE> -Send us the full output of the above things! - - -In general: - -If something is big (logs etc) then it's better to upload to the ftp -(gzipped), and include only path/filename in the bugreport! - -I know what am I doing... - -If you created a proper bugreport following the above steps, and you are -sure it's mplayer bug, not compiler's problem or broken file, you've already -readed through docs and you didn't find the solution, your sound drivers are ok, -then you may want to subscribe to the mplayer-advusers list and send your -bugreport there to get better and faster answer. But BE WARNED: if you post -newbie or rtfm-type questions there, you'll be immediatelly banned, instead or -getting answered!!! So don't flame us, subscribe -advusers only if you really -know what are you doing and you feel you as advanced mplayer user or developer. -(and about how to subscribe: find it out! if you're really an advanced user, -it shouldn't be a problem for you...) +How to conserve information about a reproducible crash +Re-compile mplayer with debugging code enabled: +<CODE>    ./configure --enable-debug +    make</CODE> +and then run mplayer within gdb using: +<CODE>    gdb mplayer</CODE> + +You're now within gdb. Type: +<CODE>    run -v [options-to-mplayer] filename</code> +and reproduce your crash. As soon as you did it, gdb will +return you to the command line prompt where you'll enter +<CODE>    bt +    disass $eip-32 $eip+32</CODE> +and send the complete output to us. + +General note + +If something is quite big (logs for instance) then it's better to upload +it to the FTP-server in a compressed format (gzip and bzip preferred) and +include only the path and filename in your bug report. + +I know what I am doing... + +If you created a proper bug report following the steps above and you are +confident it's a mplayer bug, not a compiler problem or broken file, +you've already read the documentation and you couldn't find a solution, +your sound drivers are OK, then you might want to subscribe to the +mplayer-advusers list and send your bug report there to get a better and +faster answer. +Please be advised that if you post newbie questions or questions answered +in the manual there, you'll be ignored or flamed instead of getting an +appropriate answer. +So don't flame us and subscribe to -advusers only if you really know +what you are doing and feel like being an advanced mplayer user or +developer. If you meet these criteria it shouldn't be difficult to find +out how to subscribe... </BODY>

4 11

R: MPlayer-dev-eng digest, Vol 1 #584 - 9 msgs - Re: programming specs for the G400, specifically brightness/contrast (Arpi)
by Bisiach Paolo 08 Mar '02

08 Mar '02

Hi Arpi, I got this answer from Petr Vandrovec [VANDROVE(a)vc.cvut.cz] I hpe can be useful... On 24 Jan 02 at 10:29, Bisiach Paolo wrote: > Is there a possibility to hard-encode those settings in source code ? We > don't need to tune tvout parameters on the fly, modifying the source code > &recompiling would be great fo us. Look at maven_init_TVdata() function in matroxfb_maven.c. Register pair 0x0E/0x0F contains black level, 0x10/0x11 blank level, 0x1E/0x1F white level (they are 10 bit registers, 8 MSB in register 0x0E, and 2 LSB in 0x0F)... 0x35 contains sync level, 0x3C VBI blank level. 0x20 and 0x22 are CR and CB gain (saturation). 0x25 controls tint (hue). 0x0B is CB burst level, 0x0C is CR burst level. 0x09 is burst width. 0x08 is hsync width, 0x2C is front porch. So increasing value in registers 0x0E/0x0F should help you. Currently PAL white level is 0x89/0x03 (== 0x227), and you can go up to 0xFF/0x03 (== 0x3FF). Take a look at http://platan.vc.cvut.cz/~vana/maven/reg007F.htm, there is equation which Windows driver uses for computing 0x0E/0x0F and 0x1E/0x1F from contrast and brightness. Petr -----Messaggio originale----- Da: mplayer-dev-eng-request(a)mplayer.dev.hu [mailto:mplayer-dev-eng-request@mplayer.dev.hu] Inviato: venerdì 8 marzo 2002 12.05 A: mplayer-dev-eng(a)mplayerhq.hu Oggetto: MPlayer-dev-eng digest, Vol 1 #584 - 9 msgs Send MPlayer-dev-eng mailing list submissions to mplayer-dev-eng(a)mplayerhq.hu To subscribe or unsubscribe via the World Wide Web, visit http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng or, via email, send a message with subject or body 'help' to mplayer-dev-eng-request(a)mplayerhq.hu You can reach the person managing the list at mplayer-dev-eng-admin(a)mplayerhq.hu When replying, please edit your Subject line so it is more specific than "Re: Contents of MPlayer-dev-eng digest..." Today's Topics: 1. Re: programming specs for the G400, specifically brightness/contrast (Arpi) 2. new filter layer (Charles Henrich) 3. Re: does -mf work? (Gabucino) 4. Re: does -mf work? (Charles Henrich) 5. Re: new filter layer (Arpi) 6. Re: Re: [MPlayer-dev-eng] [PATCH] DOCS/bugreports.html (Daniel Egger) 7. tested new direct rendering (Gabucino) 8. Re: Re: [MPlayer-dev-eng] [PATCH] DOCS/bugreports.html (Daniel Egger) 9. Re: does -mf work? (Gabucino) --__--__-- Message: 1 Date: Fri, 8 Mar 2002 07:56:56 +0100 From: Arpi <arpi(a)thot.banki.hu> To: mplayer-dev-eng(a)mplayer.dev.hu Subject: Re: [MPlayer-dev-eng] programming specs for the G400, specifically brightness/contrast Reply-To: mplayer-dev-eng(a)mplayerhq.hu Hi, > The vidix EQ does not work on the G400 (BES). I have "#deinfed" the > MGA_EQUALIZER macro but I get a picture that is shaded green on the > top half and purple on the bottom half (or is it the other way > around?) and adjusting the brightness and/or contrast has no effect. > > The whole mechanism looks pretty simple so I want to try to fix it, > but how do I know which registers are to be programmed with what > values to adjust brightness and contrast? There is some code there to > do it, but it's obviously got a problem. > > Is there a programming spec for the G400 around somewhere? Where did ftp.mplayerhq.hu > the values in the current implementation come from? eq works in mga_vid kernel module afaik, so you can borrow code from that A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu --__--__-- Message: 2 Date: Thu, 7 Mar 2002 23:28:42 -0800 From: Charles Henrich <henrich(a)sigbus.com> To: mplayer-dev-eng(a)mplayerhq.hu Subject: [MPlayer-dev-eng] new filter layer Reply-To: mplayer-dev-eng(a)mplayerhq.hu Will it require any re-write of the demuxer layer? -Crh Charles Henrich Eon Entertainment henrich(a)msu.edu http://www.sigbus.com:81/~henrich --__--__-- Message: 3 Date: Fri, 8 Mar 2002 08:30:12 +0100 From: Gabucino <gabucino(a)mplayer.dev.hu> To: mplayer-dev-eng(a)mplayer.dev.hu Subject: Re: [MPlayer-dev-eng] does -mf work? Reply-To: mplayer-dev-eng(a)mplayerhq.hu --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Charles Henrich didn't RTFM : > > > Loading DLL: 'm3jpeg32.dll' Segmentation fault (core dumped) > > sig11 in codec, as we discussed on IRC (bad files?) > Will regrab the libraries and retry, but I can play mjpeg files okay.. bad (or unsupported) _jpeg_ files.. --=20 Gabucino "I think the developers placed this bug intentionally, so the GUI won't run on specific systems. They are Debian-lovers, I see this from the docs." -- = lama --DocE+STaALJfprDB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8iGiEAq6GhkS0XDcRAl3dAJ9O5VKcJ6QEOB1nsMLWybS3Y9kk/ACfRo52 OC+OFAxCx+4pRrOI3ImfpHE= =lU1Z -----END PGP SIGNATURE----- --DocE+STaALJfprDB-- --__--__-- Message: 4 Date: Thu, 7 Mar 2002 23:52:45 -0800 From: Charles Henrich <henrich(a)sigbus.com> To: mplayer-dev-eng(a)mplayer.dev.hu Subject: Re: [MPlayer-dev-eng] does -mf work? Reply-To: mplayer-dev-eng(a)mplayerhq.hu > > > > Loading DLL: 'm3jpeg32.dll' Segmentation fault (core dumped) > > > sig11 in codec, as we discussed on IRC (bad files?) > > Will regrab the libraries and retry, but I can play mjpeg files okay.. > bad (or unsupported) _jpeg_ files.. Just standard jpegs as come out of ImageMagick?? -Crh Charles Henrich henrich(a)msu.edu http://www.sigbus.com:81/~henrich --__--__-- Message: 5 Date: Fri, 8 Mar 2002 09:27:30 +0100 From: Arpi <arpi(a)thot.banki.hu> To: mplayer-dev-eng(a)mplayer.dev.hu Subject: Re: [MPlayer-dev-eng] new filter layer Reply-To: mplayer-dev-eng(a)mplayerhq.hu Hi, > Will it require any re-write of the demuxer layer? no. it affects just the codecs layer (possible without any modification of codecs but to get all new features work they need slight modification) and the mplayer core (codec selection and colorspace selection and libvo init) A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu --__--__-- Message: 6 Subject: Re: Re: [MPlayer-dev-eng] [PATCH] DOCS/bugreports.html From: Daniel Egger <degger(a)fhm.edu> To: mplayer-dev-eng(a)mplayer.dev.hu Date: 08 Mar 2002 08:34:28 +0100 Reply-To: mplayer-dev-eng(a)mplayerhq.hu Am Don, 2002-03-07 um 19.16 schrieb Gabucino: > couldn't set fonts, couldn't make tables (I suppose they can be done, > but haven't found) That's the trick: There's no need to. IMHO you care too much about things you shouldn't and in DocBook you won't be able to change anything without a stylesheet which is the right thing to do(tm). -- Servus, Daniel --__--__-- Message: 7 Date: Fri, 8 Mar 2002 09:47:03 +0100 From: Gabucino <gabucino(a)mplayer.dev.hu> To: MPlayer-dev-eng <mplayer-dev-eng(a)mplayerhq.hu> Subject: [MPlayer-dev-eng] tested new direct rendering Reply-To: mplayer-dev-eng(a)mplayerhq.hu --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable $subject with Gladiator, 1000 frames, 1 mga buffers VIDEO: [DIV3] 640x368 24bpp 25.00 fps 992.7 kbps (121.2 kbyte/s) divx4 dr AVE BENCHMARKs: VC: 16.852s VO: 0.015s A: 0.000s Sys: 0.594s =3D 1= 7.462s divx4 dr (-vo mga because mga_common.c isn't #included in xmga, 4 mga buffe= rs) AVE BENCHMARKs: VC: 21.497s VO: 0.014s A: 0.000s Sys: 0.603s =3D 2= 2.114s divx4 nodr AVE BENCHMARKs: VC: 17.587s VO: 5.560s A: 0.000s Sys: 0.580s =3D 2= 3.728s divxds dr AVE BENCHMARKs: VC: 14.320s VO: 0.014s A: 0.000s Sys: 0.729s =3D 1= 5.062s divxds dr (-vo mga because mga_common.c isn't #included in xmga, 4 mga buff= ers) AVE BENCHMARKs: VC: 20.524s VO: 0.015s A: 0.000s Sys: 0.652s =3D 2= 1.191s divxds nodr AVE BENCHMARKs: VC: 16.377s VO: 5.554s A: 0.000s Sys: 0.664s =3D 2= 2.594s odivx (dr not implemented here) AVE BENCHMARKs: VC: 13.249s VO: 4.191s A: 0.000s Sys: 0.592s =3D 1= 8.033s ffdivx (dr not implemented here) AVE BENCHMARKs: VC: 9.760s VO: 4.193s A: 0.000s Sys: 0.585s =3D 1= 4.538s --=20 Gabucino "I think the developers placed this bug intentionally, so the GUI won't run on specific systems. They are Debian-lovers, I see this from the docs." -- = lama --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8iHqHAq6GhkS0XDcRApEiAJ9DnHkbxC9senwzS+aWTd3p9EuVUACePHRO SnLUgKl9CzkBj8OeS+HuxHw= =u03C -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- --__--__-- Message: 8 Subject: Re: Re: [MPlayer-dev-eng] [PATCH] DOCS/bugreports.html From: Daniel Egger <degger(a)fhm.edu> To: mplayer-dev-eng(a)mplayer.dev.hu Date: 08 Mar 2002 10:05:49 +0100 Reply-To: mplayer-dev-eng(a)mplayerhq.hu Am Fre, 2002-03-08 um 02.09 schrieb Diego Biurrun: > Daniel, this is your call. Can you help out here? I had a look at > your docbook example. Looks nice, but I must admit I have no idea > where to go from there. How can I generate HTML and do stuff to this? Try to get the DocBook tools. Most linux distributions come with it and using Debian you'll be able to install it with: apt-get install docbook-utils. After installation a db2html will convert the file to html but it looks pretty boring without any DSSSL and/or CSS script. > Can you point me at some basic manuals I assume you want to know about the tags. Check out www.docbook.org and download the docbook guide there. It will explain which tags exist and how to use them. It should be possible to figure the rest out by having a look at the provided example though I might watch out for a tutorial if you like. > and explain to Gabucino how to create tables and do some more funky things? Tables can be created using the <table> tag and creating <tgroup>s within which would translate to <tr> tags in HTML. Unlike HTML where it was (and unfortunately still is) quite common to use tables for formatting purposes this is pretty impossible in DocBook; the tables are only formal and thus probably not of much of for this doc-project. -- Servus, Daniel --__--__-- Message: 9 Date: Fri, 8 Mar 2002 11:33:04 +0100 From: Gabucino <gabucino(a)mplayer.dev.hu> To: mplayer-dev-eng(a)mplayer.dev.hu Subject: Re: [MPlayer-dev-eng] does -mf work? Reply-To: mplayer-dev-eng(a)mplayerhq.hu --1UWUbFP1cBYEclgG Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Charles Henrich didn't RTFM : > > > > > Loading DLL: 'm3jpeg32.dll' Segmentation fault (core dumped) > > > > sig11 in codec, as we discussed on IRC (bad files?) > > > Will regrab the libraries and retry, but I can play mjpeg files okay.. > > bad (or unsupported) _jpeg_ files.. > Just standard jpegs as come out of ImageMagick?? Yes. Try #1: file ~/grab/01.jpg=20 /home/gabucino/grab/01.jpg: JPEG image data, JFIF standard 1.01, aspect rat= io, "xwdump=CB=99=C5=B0", 0 x 0 convert ~/grab/01.jpg a.jpg xv a.jpg -> ok, nice, etc cp a.jpg b.jpg cp a.jpg c.jpg mencoder \*.jpg -mf on:w=3D800:h=3D600 -vc mjpeg -> completes OK mplayer test.avi -fps 1 -> whoopps, all green pictures... mencoder \*.jpg -mf on:w=3D800:h=3D600 -vc ffmjpeg -> completes OK mplayer test.avi -fps 1 -> whoopps, all green pictures... mencoder \*.jpg -mf on:w=3D800:h=3D600 -vc m3jpeg Loading DLL: 'm3jpeg32.dll' ICDecompressGetFormatSize ret: 40 Called unk_MessageBeep Called unk_GetActiveWindow Called unk_DialogBoxParamA Segmentation fault Try #2: file ~/grab/11.jpg /home/gabucino/grab/11.jpg: JPEG image data, JFIF standard 1.01, resolution (DPI), "xwdump=CB=99=C5=B0", 1 x 1 convert ~/grab/11.jpg a.jpg xv a.jpg -> ok, nice, etc cp a.jpg b.jpg cp a.jpg c.jpg mencoder \*.jpg -mf on:w=3D800:h=3D600 -vc mjpeg -> completes OK mplayer test.avi -fps 1 -> whoopps, all green pictures... mencoder \*.jpg -mf on:w=3D800:h=3D600 -vc ffmjpeg -> completes OK mplayer test.avi -fps 1 -> *ALL OK* So: 1. ImageMagick doesn't make JPEGs parsible for mainconcept mjpeg ! (BTW, if it wasn't parsible after ImageMagick, it also wasn't parsible _before_ it) 2. MainConcept supported 0 out of 2 JPEG formats. 3. ffmjpeg supported 1 out of 2 JPEG formats. --=20 Gabucino "I think the developers placed this bug intentionally, so the GUI won't run on specific systems. They are Debian-lovers, I see this from the docs." -- = lama --1UWUbFP1cBYEclgG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8iJNfAq6GhkS0XDcRAgyIAJoDaaQT92CpixYj2hPdnDcDL61M5wCgteBf +uempJB+qkAYJG1KORPdJlc= =K8vG -----END PGP SIGNATURE----- --1UWUbFP1cBYEclgG-- --__--__-- _______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng(a)mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng End of MPlayer-dev-eng Digest

1 0

tested new direct rendering
by Gabucino 08 Mar '02

08 Mar '02

$subject with Gladiator, 1000 frames, 1 mga buffers VIDEO: [DIV3] 640x368 24bpp 25.00 fps 992.7 kbps (121.2 kbyte/s) divx4 dr AVE BENCHMARKs: VC: 16.852s VO: 0.015s A: 0.000s Sys: 0.594s = 17.462s divx4 dr (-vo mga because mga_common.c isn't #included in xmga, 4 mga buffers) AVE BENCHMARKs: VC: 21.497s VO: 0.014s A: 0.000s Sys: 0.603s = 22.114s divx4 nodr AVE BENCHMARKs: VC: 17.587s VO: 5.560s A: 0.000s Sys: 0.580s = 23.728s divxds dr AVE BENCHMARKs: VC: 14.320s VO: 0.014s A: 0.000s Sys: 0.729s = 15.062s divxds dr (-vo mga because mga_common.c isn't #included in xmga, 4 mga buffers) AVE BENCHMARKs: VC: 20.524s VO: 0.015s A: 0.000s Sys: 0.652s = 21.191s divxds nodr AVE BENCHMARKs: VC: 16.377s VO: 5.554s A: 0.000s Sys: 0.664s = 22.594s odivx (dr not implemented here) AVE BENCHMARKs: VC: 13.249s VO: 4.191s A: 0.000s Sys: 0.592s = 18.033s ffdivx (dr not implemented here) AVE BENCHMARKs: VC: 9.760s VO: 4.193s A: 0.000s Sys: 0.585s = 14.538s -- Gabucino "I think the developers placed this bug intentionally, so the GUI won't run on specific systems. They are Debian-lovers, I see this from the docs." -- lama

1 0

new filter layer
by Charles Henrich 08 Mar '02

08 Mar '02

Will it require any re-write of the demuxer layer? -Crh Charles Henrich Eon Entertainment henrich(a)msu.edu http://www.sigbus.com:81/~henrich

2 1

programming specs for the G400, specifically brightness/contrast
by Brian J. Murrell 08 Mar '02

08 Mar '02

The vidix EQ does not work on the G400 (BES). I have "#deinfed" the MGA_EQUALIZER macro but I get a picture that is shaded green on the top half and purple on the bottom half (or is it the other way around?) and adjusting the brightness and/or contrast has no effect. The whole mechanism looks pretty simple so I want to try to fix it, but how do I know which registers are to be programmed with what values to adjust brightness and contrast? There is some code there to do it, but it's obviously got a problem. Is there a programming spec for the G400 around somewhere? Where did the values in the current implementation come from? Thanx, b. -- Brian J. Murrell

2 1

XviD stuff
by Christoph Lampert 07 Mar '02

07 Mar '02

Hi, once again no correct quoting, sorry. Ar'pi wrote something like: > XviD should concentrate on encoding, not decoding. We are, but to be a "codec" you need "co" and "dec". And it's stupid work implementing new features like B-frames if there is no open source way of decoding them. I doubt that many people in the windows world use ffmpeg, so both project have their right of existence. Somebody else (sorry, sorry!!! I can't read the mail while writing, stupid system) wrote something like: > I never had success using XviD for decoding with MPlayer. Strange... I had, by simply replacing libdivxdecore with libxvidcore. But since ffmpeg is faster, Ar'pi is right. There is no real need for using XviD with mplayer at the moment. Still it's always good to have an alternative and some competition... Sorry, I have to fly (take that literally ;-) gruel ________________________________________________________________ Keine verlorenen Lotto-Quittungen, keine vergessenen Gewinne mehr! Beim WEB.DE Lottoservice: http://tippen2.web.de/?x=13

1 0

Re: Re: [MPlayer-dev-eng] XviD
by Wächter Clemens 07 Mar '02

07 Mar '02

On Thu, 7 Mar 2002, Michael Niedermayer wrote: > > Michael > > PS: i only have 1 divx5 avi at the moment, does anyone know a url with a > few > more samples (i dont use windoz anymore and divx5 encoding doesnt work in > > linux yet afaik) I don't have any url neither but if you want to I could try and remove the dusts from my M$ Windoze installation and encode something for you and upload it anywhere you want to. If you want to with parameters you name and with the material you want to. Doing so will be hell for me but if I can help the development of a divx5 linux encoder/decoder/whatever this semms to be acceptable. Contact me if you want me to do that. Clemens __________________________________________________________________ Gesendet von Yahoo! Mail - http://mail.yahoo.de Ihre E-Mail noch individueller? - http://domains.yahoo.de

1 0

[PATCH] Detect current screen size.
by daniel carter 07 Mar '02

07 Mar '02

There have been a number of complaints on -users lately, that when playing fullscreen, mplayer displays at the size of the virtual desktop, and not the current screen resolution. I can imagine there are some cases when you might want the current behaviour, but i expect 99% of users would prefer mplayer to detect the current monitor resolution when playing fullscreen. The senario i personally have is that i run my desktop at 1024x768. I am now using the GPL tool "nvtv" to dynamically turn on TV-Out. Doing so switches my screen resolution to 800x600 or less. When i then run mplayer -fs it does not display at fullSCREEN resolution (800x600) but instead displays fullVIRTUAL-DESKTOP resoltion (1024x768) thus obscuring much of the movie from the screen. The current workaround is tedious use of the screenw and screenh commandline options Accordinly i have attached a patch that changes the detection of the resolution of the X Server. It uses a function in the xf86 VidMode interface to detect the current monitor resolution. Please let me know how you find the patch. I have tried to comply with the preferences of the mplayer developers regarding patch submission. Regards, dan carter. Index: libvo/x11_common.c =================================================================== RCS file: /cvsroot/mplayer/main/libvo/x11_common.c,v retrieving revision 1.54 diff -u -r1.54 x11_common.c --- libvo/x11_common.c 7 Mar 2002 11:57:33 -0000 1.54 +++ libvo/x11_common.c 7 Mar 2002 13:19:24 -0000 @@ -69,6 +69,7 @@ #ifdef HAVE_XF86VM XF86VidModeModeInfo **vidmodes=NULL; +XF86VidModeModeLine modeline; #endif void vo_hidecursor ( Display *disp , Window win ) @@ -214,6 +215,17 @@ XFree(screens); } else +#endif +#ifdef HAVE_XF86VM + { + int clock; + XF86VidModeGetModeLine( mDisplay,mScreen , &clock , &modeline ); + if (! vo_screenwidth) + vo_screenwidth=modeline.hdisplay; + + if (! vo_screenheight) + vo_screenheight=modeline.vdisplay; + } #endif { if (! vo_screenwidth)

2 2

vo_udp.c udp streaming support
by Dirk 07 Mar '02

07 Mar '02

This is the first hack and was only tested with Linux so far... everything belongs to main/libvo/ of current CVS version... just start mplayer -vo udp movie and (for example) mtvp udp:1234 and you'll see what it does.. port 1234 is still hardcoded via #define in libvo/vo_udp.c... Dirk =================================================================== RCS file: /cvsroot/mplayer/main/libvo/Makefile,v retrieving revision 1.30 diff -u -r1.30 Makefile --- Makefile 9 Feb 2002 01:30:35 -0000 1.30 +++ Makefile 7 Mar 2002 11:22:10 -0000 @@ -3,7 +3,7 @@ LIBNAME = libvo.a -SRCS=aspect.c aclib.c osd.c font_load.c video_out.c vo_null.c vo_pgm.c vo_md5.c vo_mpegpes.c x11_common.c vo_yuv4mpeg.c $(OPTIONAL_SRCS) img_format.c sub.c +SRCS=aspect.c aclib.c osd.c font_load.c video_out.c vo_null.c vo_udp.o vo_pgm.c vo_md5.c vo_mpegpes.c x11_common.c vo_yuv4mpeg.c $(OPTIONAL_SRCS) img_format.c sub.c OBJS=$(SRCS:.c=.o) ifeq ($(VIDIX),yes) Index: video_out.c =================================================================== RCS file: /cvsroot/mplayer/main/libvo/video_out.c,v retrieving revision 1.42 diff -u -r1.42 video_out.c --- video_out.c 22 Feb 2002 18:00:38 -0000 1.42 +++ video_out.c 7 Mar 2002 11:22:10 -0000 @@ -66,6 +66,7 @@ // // Externally visible list of all vo drivers // +extern vo_functions_t video_out_udp; extern vo_functions_t video_out_mga; extern vo_functions_t video_out_xmga; extern vo_functions_t video_out_x11; @@ -159,6 +160,7 @@ // &video_out_odivx, &video_out_pgm, &video_out_md5, + &video_out_udp, &video_out_mpegpes, &video_out_yuv4mpeg, #ifdef HAVE_VESA

2 2