October 2001 - MPlayer-dev-eng - lists.mplayerhq.hu

15-bit samples
by Nick Kurshev 04 Nov '01

04 Nov '01

Hello, Arpi! Do you have some movies on your FTP decoding of which produces 15-bit output? If yes - give me URL please. Best regards! Nick

3 9

postprocess rocks
by Arpi 03 Nov '01

03 Nov '01

Hi, Check this with and without postprocess: ftp.mplayerhq.hu/MPlayer/incoming/BP_Parade_X_FINAL_Video-Thl.mpeg it's very blocky and interlaced mpeg video. with -pp 0x20033 it's perfect, without pp is unwatchable. great work! really! A'rpi / Astral & ESP-team -- mailto:arpi@thot.banki.hu http://esp-team.scene.hu

4 11

mencoder - code men to divx4 or so
by Arpi 02 Nov '01

02 Nov '01

Hi, Just finished mencoder. It needs some cosmetic (commandline options, error handling etc) but the core works. It encodes everything (mplayer-playable files) to AVI file, using stream copy or converting to divx4 video or pcm/vbrmp3 audio. Requirements: - divx4linux lib - libmp3lame (lame 3.89 beta) It uses the same codebase as mplayer.c, with some differences: - not uses libao and libvo, but requires libvo/aclib.c (fastmemcpy) and libvo2/img_format.c - not uses subtitle stuff (find_sub.c, subreader.c) TODO: - add it to the Makefile - anyone interested? :) (i'm too lazy :) - source a-v sync correction - i'll do it soon - variable fps support (progressive ntsc mpeg2) - i'll do it - commandline interface - should be designed first - 2-pass encoding - more codecs (ogg audio, vfw video etc) - audio and video from different files A'rpi / Astral & ESP-team -- mailto:arpi@thot.banki.hu http://esp-team.scene.hu

1 1

GUI menu shifted!
by Bertrand BAUDET 01 Nov '01

01 Nov '01

Hi, I'm having the mplayer GUI right click menu display shifted, see the screenshot: ftp://mplayerhq.hu/MPlayer/incoming/gui_menu_shifted.png I'm using a Matrox Graphics, Inc. MGA G400 AGP I also put on the ftp the xdpyinfo output ftp://mplayerhq.hu/MPlayer/incoming/gui_menu_shifted_xdpyinfo.out What else specific info do I need to provide? Bertrand _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1

Re: Resampling
by Anders Johansson 01 Nov '01

01 Nov '01

Hi, I managed to get the up and down-sampling into the same function with not too much overhead - unfortunately I don't understand why it works very irritating. Have a look at it. I have made the output buffer size dynamic and changed the circular queue so it executes a lot faster now. I anticipated problems with the synchronisation. What technique are you using to sync the video to the audio? are you using a SW phase locked loop or something like that? I have noticed some kind of motion blur that I guess is caused by jitter in the image sync on DVDs. I am sure this could be made less noticeable. I also have a question: I need to know ho long filters I can use. I guess it is a good idea not to have the filter parameters cashed out from the L2 cash. How many bytes can I use before this starts to become a problem? Cheers, //Anders > Hi, > > > I have managed to get the down-sampling to run - it is not funny at > > all. It will have to reside in a separate function (can not be mixed > > with the up-sampling since the circular queue management is completely > > different and it also needs pre-filtering of the incoming data). I > > will create an example or add it directly to mplayer once the current > > version is added to mplayer. That way my code will be consistent with > > mplayers buffer management - and no one will need to re write it. Is > > that ok with you? > yes. please send me the code, i'll integrate to mplayer and you can continue > development there. > > i have to change it a bit, because mplayer's playback design: > 1. ask soundcard how many samples can be played immediately, with no > blocking (buffer space) -> N > 2. decode at least N samples > 3. send N samples to the soundcard > > I think the best place for your code would be dec_audio.c. > but it will cause timing problems - should be workarounded. > > > In the meantime I will focus on optimising the filter parameters. I > > think I have found a way to minimise the quantisation error by using > > a type of genetic algorithm to tweak the filter parameters (really fun > > stuff). > > > > By the way would it be interesting to add other sound features to > > mplayer? I could do stuff like synthetic 4-6 channel stereo (synthesise > > the missing channels from available data) or perhaps effects (room > > expansion, pitch shifting (for karaoke), church effect etc)? Just an > > idea. > > I'm interested. > > What about slower/faster playback with constant pitch? > Would be usefull for 24<->25 or maybe 30<->25 fps conversion. > > > A'rpi / Astral & ESP-team > > -- > mailto:arpi@thot.banki.hu > http://esp-team.scene.hu > > --__--__-- > > Message: 3 > Date: Tue, 30 Oct 2001 19:28:54 +0300 > From: Nick Kurshev <nickols_k(a)mail.ru> > To: mplayer-dev-eng(a)mplayer.dev.hu > Subject: [MPlayer-dev-eng] Fastmemcpy to be continued > Reply-To: mplayer-dev-eng(a)mplayerhq.hu > > This is a multi-part message in MIME format. > > --Multipart_Tue__30_Oct_2001_19:28:54_+0300_081f8e30 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > > Hello! > > I've done still one P3 related improvement. > So everyone who have P3 and desire - simply test it performace > and apply if it works faster for you. > > Best regards! Nick > --Multipart_Tue__30_Oct_2001_19:28:54_+0300_081f8e30 > Content-Type: application/octet-stream; > name="aclib.c.bz2" > Content-Disposition: attachment; > filename="aclib.c.bz2" > Content-Transfer-Encoding: base64 > > QlpoOTFBWSZTWfIKJhUAAxhfgH2we////3/v//S/7//+YAx99xnMADj04Ym9HWbMvDyd1d3d6MF6 > G9vZt2iaGRAiNR4jUyepP0m0m01DQjQ2iMjQyAD1NNA0NAaaECNAIAiZGiHqNkmTQAGjQDQyaGQZ > BiBKaaJNPKekGgGg000NDaR6hpoANADQABJqQkxGommUxPU9QMgDAgBoAGgNAA0A4Gg0yGmjQwgZ > DQwRoaZNGgGQYgADQSJCMiaBJtqaCNTEMmTU81NGm1GkfoUYCMNAT09TSQDSEA0ABSJFZDp5lLLL > JdgcAA7gmC2ntCREjit6+vkrxW9draJ0oXqrPrdLXAqQu9S+Os+r814PhzlIWr6BZNxp5WoNc4jQ > iB/R0n+1fU2r0nc3gy33fIdD7p4MqoSdSwxvMH8nVrDHrURKVVUP8w02N/dey9M5edROlJbo1jul > wO8BAK71RABIogAPQCWSMQiMe8Wlh6jcw0mR5c6AGcuXP/ReJVRoqVRUpVV5hETj/MOTLBllO/3b > 7jyv3N0DeNadPyYBnydc8DWDys+ljpbGQlELU33Oi+1Ny2sIqZtI1cnZg5oqzWZHYmlpmidkwCWC > iBcczWIUOdSpbDvtbrm3PDP2PRm4yq28cK2WAd/USSJx9J6+jlhePelYPcsxaPE4MMX4rrGL3Xtm > YqWfL/LBWVWvBC1Wdth6zJ9fh6kS+3G+rjNcM+x1ZQ8WsRYlYsdoXvP+GHh8fNW3nJF9uWYh6tG0 > ubA7YFZCZzn5mtNgW+2dvZ+OcOQbZX2RN7LII/OGCzwW+xRc4v4LZkQZPyPOAienVd6xff0XNh66 > vcaN6jHtTskriYhOQ4q8JHkjIyEKB5uRKHn1bf4Xdtq2wC7d30tKb8Z0gM2J3ZQ8vdbiFERDbypT > aM/Mtw3Gx8Gtj2OtXGukT5HlzbWlZSlpTTipxAO3VbzcNlNc0vuftjqq18DyWZtASwYb5jbHPE4Q > GL7KCowhOMFura0oMd72NCKvFSLii2qYwfIgQLwukS4oyx/r5tmdI0W5Wbde2xdMnV7tJjpnLNLR > krTKGsH1q4t2YOrrBilXXt4/q8q36Wq2eyKjB1ExjyfQ0BikR01yDw6Iyt1DCEoZ9UnoSDBSqqk9 > xOjm3Yb3djAdOkfHwiSNEWkRwAd7YHHwwuqaX9dXs4BaNZ3H8mcpH0NQP1ABSEofTJIhoMu3rmAi > gAuUBEb93Ovk4Q4y4OZPyj9P4uUDIy1TnQgQXmJlw4gOIDF2aImObkBtpq8oeJDvwWFbzNogaCON > TQ+7u+ddXB5M/CRj5PAu/efxU7nJUvwTQw4gQ6W2rW7OveiW12mIaYhh8PiWpr7/UIMG0qQqSFTM > WqT8EBrzAyICDIQxgwoNqpoyuHofoGh9Xgt6cWPH51EbWvRi4g2+99FhjOz5aOTfhYlLny82CcZR > Hf1CA3BmZrWLBWLh8zRa+l07rlVMl2SO6Okf7ANkbSwo4NbdAI3Ru6dzOBWepFRiq5UXqYaoze20 > 2L17WVaCmgAnYI7m31tn1GSMg6Oy2NsIBDyRwpcAuQ9dcbVY3PAjhwG1zwWAH1VlRuGFw3Yg4IBG > vuQXfiFIu2A2kTkYGQa3Jvec0MUi8WRQCCKbfbDo1rBgVVK5OxuQKkkdLTWnKV3uJM+8trnhCg4u > funVPeCjgYeNgx7ivR9V41HpoGiDWDbyKLT5PWDqcsJzAcPJ2s969g9RLRTDtDB0K9C+skbWbOSs > uvDqcNuHBGIgsbvatQB11GL1ip14TedTxWhwgXkRRN8yhXEzxD22axyzOwSXma19FLyfrZAw+AB2 > STKC+3kOBI5VRfzWKguaFtZ/TR4i5DgNu/MkpCMzpQsUPtRqmj9S/LPhRIbbPKPkc9pmhWISJlUX > QGTKpdYJksZAqRqEX7Gx3mQ938dlo1wxI7IdDoRngeGBt1aUHpaRvEt64kw7aGecXoSfdFnvSql6 > PR0rwVKJVkMiwRSKkLffXgv+Unps+CWx8Jm2aK8NUYx0vCVTibz5c6gcGxocbMwb/jWG0TZS1EnB > C8b2K12vRwGgcdb44KviEnozhfKT8RPFQAsQe6g9OHElhmcE/PZHBqKu26xrEXLdB6pXQNyRrfpc > pkJSGeZoVeMWbFtkc22BFuRp1FikU1OhW+GYlVCspsmoJkD2nuRgdKDpjN4osDNqFI78Sy1YKmOW > pCrSgEqpQol6L2kvIL0KxjE9OCybms7G8MHL6AouT/2UtzPRaWw0NIjO7KYUSQQyHegFa1ooHETs > HHUuY2Hhg5mkkHOrQbk7TNzQ4vOoIc22xaY8cWpcoWTi4Oj0gtrj/g9Z0VYIhtk17WsHMrhSYhV6 > ihELXFj0cOiVFrSSqRiyWJbyCRPMNLtxvxssacAjpkYqyCBV4smLSfUIXJWFgiGUzxRExgRkKTMj > WgQW+MyYxbAnBemIfapBjJE+E0PiDmkTYTzpOKJiKS+XV1xOvJZcbTBl2WXXk92TODFJgj75abxi > WkkzoGVIrruhAQAvtY4Frs1GyNM45Cc1mNU7Ag0UUgKXCFMYAE2VHTXiUGoc4Y8kKGpTJ7i0FrlQ > 2nYtxuIpLmOre8jMmHMpae9MPF3WmiF+d2mVscQE/dU1duvzuJhfWQBzZTPx+dnZKK5vtKfkomUx > AYWlIksspKgMfEOFdIKCoFKN0nqlEufsySeiYzlDjPJtx1gVukELhF0WYuDo62kPkuS1oZwQhqDX > E38uEBhomCFBIbLB4r05+5cl5JSOOK3EMw7re02EQxD0GTDDFEnOj1pSM4vBkTRWAsj2MZMFFixT > Xo6NwTS1N6y95pkisZaIzyVDFHRshPQ1CMHWR3WleEQEG1nyxDwg5gnVyjNTsMqcl+1q6RSEX05j > l0S29VESVVDGtLYyS18xqwnjAxQGiS2FbE1saTKBOdCN0cCh/C5QUDXdvlaWpyEscwEXpdemAnw2 > V8kRSUQXviBo6hM1X8JX9aLTM+M/FMYIxGEKvO7sVoSO8RCKAKOraQyp2JyYwiiJSXFq1utalsi1 > yYtswxaq/wAiWTp93AS9xqiozNKDa0gMsSwXVNSRnA1xMXkGMiy7MhN1/oFz172YKB6WfFmTR1IX > KBhPXrhaMVgi0Yter2PQgqKdiZC5hFmvGwhhi0lyvsoNoJoO0jdK6AJ0sQ2xOMwFoVSbGBmX2qSB > 49SdKDIicNihhBvl0NKRM4b+wEiYpAYPzbLrvBQylsHEJpprYkeGauGVuYiOek7y84hLBRGpGs2R > 4i3H4TB1V7bQBWt2B2fc59fZZ33kpwXH0xlkb5bjvRNI7EGTozJhZoJXRTMO5AxmjKDelIoBzgDv > ubJl5KlCoqqLA2kaIs4mQo55iuqJv7d0j7JQEhS5UgBbMdmGgsuKajJOUprYZNUVFOVx4PL7JFqt > V7Xtc2e5FG6PEA3nzZCCc11wXt3wozei4guXAhAhrU2aqkHqaiFRAw1Yx01aQ0BrMO4RM0VYEGMS > GimCsXVMTQq6kmLluDsyWGzgz5GUufBkxu6FGZGy+xw4fhC5lrOYQOJIC8RFt5GAD8DKjVhD5WtF > RDoF99PZO6mIQqB/gt0SLEFSGZY8F+k204aSsyrFnnLMG5lKquHIuFizmBcr66rerFScHLdvZIiI > a34LgyHLnN+hwKOIpVd+wwN1GwrfYauSNjE2Bi5WxxSpTfbTdRqPSwhdI4rDMcda+rmaELILDmnv > glMZ3tSGJIwmnCztv2oOhvx7DzeLTs9e8JwDC7O4rtL3NDK+ZtuO/04csRMZPXFuZc5cxX7VgOVS > u8a//maTTqL64qNGC5BsM7lJnjuUShoXNG33e2lQSMaLS0RKAL2GgaJGrM5W9P1EtK6QHo5W0sab > UGV8yD5pZShpwJHL51UIJgDEwcJogZBnfAPg2CzVz3HtJKUjog/sXckU4UJDyCiYVA== > > --Multipart_Tue__30_Oct_2001_19:28:54_+0300_081f8e30-- > > --__--__-- > > Message: 4 > Date: Tue, 30 Oct 2001 20:16:43 +0300 > From: Nick Kurshev <nickols_k(a)mail.ru> > To: mplayer-dev-eng(a)mplayerhq.hu > Subject: [MPlayer-dev-eng] new rgb2rgb stuff > Reply-To: mplayer-dev-eng(a)mplayerhq.hu > > Hello! > > I've perform changes to replace old rgb15to16mmx stuff with new one from postproc subfolder. > I've found that modified by me files also can be modified for using MMX, MMX2, 3DNOW optimized > versions of rgb24to32 and rgb32to24. > So if their author still participate with mplayer then let they'll perform corresponded changes. > (Simply I have no possibility to test every vo driver). > > >From other side - if it needed - it would be possible to implement any rgbXXtoYY function. > But I guess that 16 to 32 convertion is meaningless same as 16 to 24. But 32(24) to 16 could be > usefull. > > Best regards! Nick > > --__--__-- > > Message: 5 > Date: Tue, 30 Oct 2001 19:22:23 +0200 (CEST) > From: Arpi <arpi(a)thot.banki.hu> > To: mplayer-dev-eng(a)mplayer.dev.hu > Subject: Re: [MPlayer-dev-eng] new rgb2rgb stuff > Reply-To: mplayer-dev-eng(a)mplayerhq.hu > > Hi, > > > I've perform changes to replace old rgb15to16mmx stuff with new one from postproc subfolder. > > I've found that modified by me files also can be modified for using MMX, MMX2, 3DNOW optimized > > versions of rgb24to32 and rgb32to24. > > So if their author still participate with mplayer then let they'll perform corresponded changes. > > (Simply I have no possibility to test every vo driver). > > > > >From other side - if it needed - it would be possible to implement any rgbXXtoYY function. > > But I guess that 16 to 32 convertion is meaningless same as 16 to 24. But 32(24) to 16 could be > > usefull. > > it has sense if we plan to support oldy 16bpp codecs (cram), and > uncompressed video. 24->15/16 has sense if it does some dithering. > > > A'rpi / Astral & ESP-team > > -- > mailto:arpi@thot.banki.hu > http://esp-team.scene.hu > > --__--__-- > > Message: 6 > Date: Tue, 30 Oct 2001 20:42:09 +0300 > From: Nick Kurshev <nickols_k(a)mail.ru> > To: mplayer-dev-eng(a)mplayer.dev.hu > Subject: Re: [MPlayer-dev-eng] new rgb2rgb stuff > Reply-To: mplayer-dev-eng(a)mplayerhq.hu > > Hello, Arpi! > On Tue, 30 Oct 2001 19:22:23 +0200 (CEST), you wrote: > > > Hi, > > > > > I've perform changes to replace old rgb15to16mmx stuff with new one from postproc subfolder. > > > I've found that modified by me files also can be modified for using MMX, MMX2, 3DNOW optimized > > > versions of rgb24to32 and rgb32to24. > > > So if their author still participate with mplayer then let they'll perform corresponded changes. > > > (Simply I have no possibility to test every vo driver). > > > > > > >From other side - if it needed - it would be possible to implement any rgbXXtoYY function. > > > But I guess that 16 to 32 convertion is meaningless same as 16 to 24. But 32(24) to 16 could be > > > usefull. > > > > it has sense if we plan to support oldy 16bpp codecs (cram), and > > uncompressed video. 24->15/16 has sense if it does some dithering. > > > But video bandwidth? > > > > A'rpi / Astral & ESP-team > > > > -- > > mailto:arpi@thot.banki.hu > > http://esp-team.scene.hu > > _______________________________________________ > > MPlayer-dev-eng mailing list > > MPlayer-dev-eng(a)mplayerhq.hu > > http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng > > > > > Best regards! Nick > > --__--__-- > > Message: 7 > Date: Tue, 30 Oct 2001 18:42:31 +0100 > To: MPlayer-dev-eng <mplayer-dev-eng(a)mplayerhq.hu> > From: <gabucino(a)mplayer.dev.hu> > Subject: [MPlayer-dev-eng] configure > Reply-To: mplayer-dev-eng(a)mplayerhq.hu > > > --k1lZvvs/B4yU6o8G > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > Yo. (Poncso!) > > glib-config --cflags isn't used (?) properly in ./configure, for > example with the following setup, MPlayer won't compile: > > --($:~/mplayer/src)-- gtk-config --cflags > -I/usr/include/gtk-1.2 -I/usr/local/include/glib-1.2 > --I/usr/local/lib/glib/include > --(gabucino@woodstock)-(90/pts)-(Gabucino rulez!)-- > --($:~/mplayer/src)-- glib-config --cflags > -I/usr/include/glib-1.2 -I/usr/lib/glib/include > > =2E.because glib was recompiled to /usr/include, but since gtk+ was compiled > before (yes it's bad) it knows about the previous status. > > Only $_gtkinc is included in the include patch. Including $_glibinc too > would probably solve this (but it would get longer then..). > > --=20 > Gabucino > (afaik..) > > --k1lZvvs/B4yU6o8G > 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 > > iD8DBQE73uaHAq6GhkS0XDcRApruAJ4ts7TvSkycq61hQYMx/YjyyfukawCgtNoH > GAyks4DySN5CYBqvbpBhPmk= > =bKur > -----END PGP SIGNATURE----- > > --k1lZvvs/B4yU6o8G-- > > --__--__-- > > Message: 8 > Date: Tue, 30 Oct 2001 19:40:50 +0200 (CEST) > From: Arpi <arpi(a)thot.banki.hu> > To: mplayer-dev-eng(a)mplayer.dev.hu > Subject: Re: Re: [MPlayer-dev-eng] new rgb2rgb stuff > Reply-To: mplayer-dev-eng(a)mplayerhq.hu > > Hi, > > > Hello, Arpi! > > On Tue, 30 Oct 2001 19:22:23 +0200 (CEST), you wrote: > > > > > Hi, > > > > > > > I've perform changes to replace old rgb15to16mmx stuff with new one from postproc subfolder. > > > > I've found that modified by me files also can be modified for using MMX, MMX2, 3DNOW optimized > > > > versions of rgb24to32 and rgb32to24. > > > > So if their author still participate with mplayer then let they'll perform corresponded changes. > > > > (Simply I have no possibility to test every vo driver). > > > > > > > > >From other side - if it needed - it would be possible to implement any rgbXXtoYY function. > > > > But I guess that 16 to 32 convertion is meaningless same as 16 to 24. But 32(24) to 16 could be > > > > usefull. > > > > > > it has sense if we plan to support oldy 16bpp codecs (cram), and > > > uncompressed video. 24->15/16 has sense if it does some dithering. > > > > > But video bandwidth? > > all rgb codecs can do 15bpp, most of them 16bpp too. > so it has no sense of writting 24->15/16, unless you do something extra, > for example dithering. > > if you're already on optimization, what about these: ? > - optimizing yv12->rgb24 without scaling (yuv2rgb()) (only 16/32 is optimized) > - optimizing subtitle renderer (libvo/osd.c) > > > A'rpi / Astral & ESP-team > > -- > mailto:arpi@thot.banki.hu > http://esp-team.scene.hu > > --__--__-- > > Message: 9 > Date: Tue, 30 Oct 2001 21:14:50 +0300 > From: Nick Kurshev <nickols_k(a)mail.ru> > To: mplayer-dev-eng(a)mplayerhq.hu > Subject: [MPlayer-dev-eng] swscale question > Reply-To: mplayer-dev-eng(a)mplayerhq.hu > > Hello, Michael! > > I've looking on your code and have some question for you: > 1. For what reason you've added "normal" asm optimization? > #endif > //NO MMX just normal asm ... > asm volatile( > "xorl %%eax, %%eax \n\t" // i > "xorl %%ebx, %%ebx \n\t" // xx > "xorl %%ecx, %%ecx \n\t" // 2*xalpha > "1: \n\t" > "movzbl (%0, %%ebx), %%edi \n\t" //src[xx] > "movzbl 1(%0, %%ebx), %%esi \n\t" //src[xx+1] > For what cpu it's optimized (pent, pent-mmx, ppro or k6, k7)? > IMHO we should not ignore optimizing possibilities of gcc which > produces enough optimized code for targeted architectures. > (Even if you've win 1-2% on your cpu it doesn't mean that > we'll get the same speedup on every cpu). > >From other side - togheter withh gcc exists other compilers which > can produce better code that gcc now, but I hope that in the > future gcc will be improved enough for that. > > 2. Althrough your code was enough well scheduled but first lines could be scheduled > better (in addition they are first thing which watch everyone) : > > --- swscale.old Tue Oct 30 18:58:42 2001 > +++ swscale.c Tue Oct 30 20:53:27 2001 > @@ -113,10 +113,10 @@ > #define FULL_YSCALEYUV2RGB \ > "pxor %%mm7, %%mm7 \n\t"\ > "movd %6, %%mm6 \n\t" /*yalpha1*/\ > - "punpcklwd %%mm6, %%mm6 \n\t"\ > - "punpcklwd %%mm6, %%mm6 \n\t"\ > "movd %7, %%mm5 \n\t" /*uvalpha1*/\ > + "punpcklwd %%mm6, %%mm6 \n\t"\ > "punpcklwd %%mm5, %%mm5 \n\t"\ > + "punpcklwd %%mm6, %%mm6 \n\t"\ > "punpcklwd %%mm5, %%mm5 \n\t"\ > "xorl %%eax, %%eax \n\t"\ > "1: \n\t"\ > > > Friendly! Nick > > --__--__-- > > Message: 10 > Date: Tue, 30 Oct 2001 21:17:10 +0300 > From: Nick Kurshev <nickols_k(a)mail.ru> > To: mplayer-dev-eng(a)mplayer.dev.hu > Subject: Re: [MPlayer-dev-eng] new rgb2rgb stuff > Reply-To: mplayer-dev-eng(a)mplayerhq.hu > > Hello, Arpi! > On Tue, 30 Oct 2001 19:40:50 +0200 (CEST), you wrote: > > > Hi, > > > > > Hello, Arpi! > > > On Tue, 30 Oct 2001 19:22:23 +0200 (CEST), you wrote: > > > > > > > Hi, > > > > > > > > > I've perform changes to replace old rgb15to16mmx stuff with new one from postproc subfolder. > > > > > I've found that modified by me files also can be modified for using MMX, MMX2, 3DNOW optimized > > > > > versions of rgb24to32 and rgb32to24. > > > > > So if their author still participate with mplayer then let they'll perform corresponded changes. > > > > > (Simply I have no possibility to test every vo driver). > > > > > > > > > > >From other side - if it needed - it would be possible to implement any rgbXXtoYY function. > > > > > But I guess that 16 to 32 convertion is meaningless same as 16 to 24. But 32(24) to 16 could be > > > > > usefull. > > > > > > > > it has sense if we plan to support oldy 16bpp codecs (cram), and > > > > uncompressed video. 24->15/16 has sense if it does some dithering. > > > > > > > But video bandwidth? > > > > all rgb codecs can do 15bpp, most of them 16bpp too. > > so it has no sense of writting 24->15/16, unless you do something extra, > > for example dithering. > > > > if you're already on optimization, what about these: ? > ;) > > - optimizing yv12->rgb24 without scaling (yuv2rgb()) (only 16/32 is optimized) > > - optimizing subtitle renderer (libvo/osd.c) > > > Send me please internal representations of these formats (YUY2, YV12, other yuv related) and I'll try to do that. > > > > A'rpi / Astral & ESP-team > > > > -- > > mailto:arpi@thot.banki.hu > > http://esp-team.scene.hu > > _______________________________________________ > > MPlayer-dev-eng mailing list > > MPlayer-dev-eng(a)mplayerhq.hu > > http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng > > > > > Best regards! Nick > > --__--__-- > > Message: 11 > Date: Tue, 30 Oct 2001 20:31:58 +0200 (CEST) > From: Arpi <arpi(a)thot.banki.hu> > To: mplayer-dev-eng(a)mplayer.dev.hu > Subject: Re: Re: [MPlayer-dev-eng] new rgb2rgb stuff > Reply-To: mplayer-dev-eng(a)mplayerhq.hu > > Hi, > > > > if you're already on optimization, what about these: ? > > ;) > > > - optimizing yv12->rgb24 without scaling (yuv2rgb()) (only 16/32 is optimized) > > > - optimizing subtitle renderer (libvo/osd.c) > > > > > Send me please internal representations of these formats (YUY2, YV12, other yuv related) and I'll try to do that. > > they all are implemented already in C - just optimize :) > > but, if you're interested: > > YV12: > 3 planes, a w*h sized Y and two (w/2)*(h/2) sized U and V planes. > 2x2 rgb pixels are constructed using 2x2 Y, 1 U and 1 V bytes. > (U and V are common for the 4 pixels) > > I420(==IYUV) is teh same, but has U and V planes swapped. > > YUY2, UYVY, etc: > packed format, 4 bytes (2 Y, 1 V and 1 U byte) for 2 pixels (common U,V). > 2x1 rgb pixels are constructed from 2x1 Y, 1 U 1 V bytes. > > > A'rpi / Astral & ESP-team > > -- > mailto:arpi@thot.banki.hu > http://esp-team.scene.hu > > --__--__-- > > Message: 12 > Date: Tue, 30 Oct 2001 19:39:35 +0100 > From: Jesus Climent <data(a)polinux.upv.es> > To: mplayer-dev-eng(a)mplayer.dev.hu > Subject: [MPlayer-dev-eng] What is this= > Reply-To: mplayer-dev-eng(a)mplayerhq.hu > > > --SUOF0GtieIMvvwua > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > > Checking for libffmpeg.so ... no > > Grepping in the whole DOCS dir and in the list (I have archives > for more than 5 months) does not give me any clue. > > I will check in the configure file to try to guess, though. > > Jesse:wq > > --SUOF0GtieIMvvwua > 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 > > iD8DBQE73vPmOQfOjGPewLYRAo2nAJ4yVSjqxgIhuAlxLPokavXRbY/EAwCfbQYa > f9MtdcrjQccNDjC2lZPJc6Q= > =YnQU > -----END PGP SIGNATURE----- > > --SUOF0GtieIMvvwua-- > > --__--__-- > > Message: 13 > Date: Tue, 30 Oct 2001 22:00:15 +0300 > From: Nick Kurshev <nickols_k(a)mail.ru> > To: mplayer-dev-eng(a)mplayer.dev.hu > Subject: Re: [MPlayer-dev-eng] What is this= > Reply-To: mplayer-dev-eng(a)mplayerhq.hu > > Hello, Jesus! > On Tue, 30 Oct 2001 19:39:35 +0100, you wrote: > > > > > Checking for libffmpeg.so ... no > > > > Grepping in the whole DOCS dir and in the list (I have archives > > for more than 5 months) does not give me any clue. > > > > I will check in the configure file to try to guess, though. > > > It's new possibility to compile mplayer with dynamically linked ffmpeg stuff. > I've added it not long ago. > So now you can omit libavcodec stuff in mplayer but if you have installed > libffmpeg.so you'll get the same features. > > Jesse:wq > > > > > Best regards! Nick > > > --__--__-- > > _______________________________________________ > 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 -- ______________________________________________________________________ Anders Johansson Room 314,113 Australian Telecommunications .-_|\ Visiting Research Associate Research Institute (ATRI) / \ telephone: +61 8 9266 3268 Curtin Uni of Technology P_.-._/ e-mail: ajh(a)atri.curtin.edu.au Bentley WA, 6102. o ______________________________________________________________________

2 1

DGA: Double buffering
by Sven Herzberg 31 Oct '01

31 Oct '01

hi, i've got a question about vo_dga: When I play a Movie mplayer says: ... vo_dga: Not enough memory for double buffering! ... What kind of memory don't I have enough of? -- sven

2 1

swscale question
by Nick Kurshev 31 Oct '01

31 Oct '01

Hello, Michael! I've looking on your code and have some question for you: 1. For what reason you've added "normal" asm optimization? #endif //NO MMX just normal asm ... asm volatile( "xorl %%eax, %%eax \n\t" // i "xorl %%ebx, %%ebx \n\t" // xx "xorl %%ecx, %%ecx \n\t" // 2*xalpha "1: \n\t" "movzbl (%0, %%ebx), %%edi \n\t" //src[xx] "movzbl 1(%0, %%ebx), %%esi \n\t" //src[xx+1] For what cpu it's optimized (pent, pent-mmx, ppro or k6, k7)? IMHO we should not ignore optimizing possibilities of gcc which produces enough optimized code for targeted architectures. (Even if you've win 1-2% on your cpu it doesn't mean that we'll get the same speedup on every cpu).

3 5

What is this=
by Jesus Climent 31 Oct '01

31 Oct '01

Checking for libffmpeg.so ... no Grepping in the whole DOCS dir and in the list (I have archives for more than 5 months) does not give me any clue. I will check in the configure file to try to guess, though. Jesse:wq

4 4

Resampling
by Anders Johansson 30 Oct '01

30 Oct '01

Hi, > did you use the method described on dsp-dimension? > No I used http://www.dspguru.com/ and some previous knowledge on polyphase filter design. > yes, i've also seen a strange thing, possibel cause of this. > you only increment source data pointer by 1, but for >2x downsampling > it requires increment by 2 or more. > > ok. i think it can be easily converted to MMX, so speed won't be problem. > > > A'rpi / Astral & ESP-team I have managed to get the down-sampling to run - it is not funny at all. It will have to reside in a separate function (can not be mixed with the up-sampling since the circular queue management is completely different and it also needs pre-filtering of the incoming data). I will create an example or add it directly to mplayer once the current version is added to mplayer. That way my code will be consistent with mplayers buffer management - and no one will need to re write it. Is that ok with you? In the meantime I will focus on optimising the filter parameters. I think I have found a way to minimise the quantisation error by using a type of genetic algorithm to tweak the filter parameters (really fun stuff). By the way would it be interesting to add other sound features to mplayer? I could do stuff like synthetic 4-6 channel stereo (synthesise the missing channels from available data) or perhaps effects (room expansion, pitch shifting (for karaoke), church effect etc)? Just an idea. Cheers, //Anders

3 2

loader/demuxer bugs on big-endian systems
by Martin Decky 30 Oct '01

30 Oct '01

Hello arpi, I have to report severe bugs according the new loaders/demuxers in the /libmpdemux directory. On big-endian systems (Linux and Solaris on Sparc, IRIX on MIPS) the header of MPEG and AVI files is read in a wrong way, with swapped high- and low-order bytes and therefore the player interprets it wrong. I know that the code is brand new, I'm just reminding you not to forget the big/little-endian case. Martin Decky

1 0