[MPlayer-dev-eng] Re: Resampling
Anders Johansson
ajh at atri.curtin.edu.au
Wed Oct 31 14:36:37 CET 2001
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 at thot.banki.hu
> http://esp-team.scene.hu
>
> --__--__--
>
> Message: 3
> Date: Tue, 30 Oct 2001 19:28:54 +0300
> From: Nick Kurshev <nickols_k at mail.ru>
> To: mplayer-dev-eng at mplayer.dev.hu
> Subject: [MPlayer-dev-eng] Fastmemcpy to be continued
> Reply-To: mplayer-dev-eng at 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 at mail.ru>
> To: mplayer-dev-eng at mplayerhq.hu
> Subject: [MPlayer-dev-eng] new rgb2rgb stuff
> Reply-To: mplayer-dev-eng at 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 at thot.banki.hu>
> To: mplayer-dev-eng at mplayer.dev.hu
> Subject: Re: [MPlayer-dev-eng] new rgb2rgb stuff
> Reply-To: mplayer-dev-eng at 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 at thot.banki.hu
> http://esp-team.scene.hu
>
> --__--__--
>
> Message: 6
> Date: Tue, 30 Oct 2001 20:42:09 +0300
> From: Nick Kurshev <nickols_k at mail.ru>
> To: mplayer-dev-eng at mplayer.dev.hu
> Subject: Re: [MPlayer-dev-eng] new rgb2rgb stuff
> Reply-To: mplayer-dev-eng at 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 at thot.banki.hu
> > http://esp-team.scene.hu
> > _______________________________________________
> > MPlayer-dev-eng mailing list
> > MPlayer-dev-eng at 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 at mplayerhq.hu>
> From: <gabucino at mplayer.dev.hu>
> Subject: [MPlayer-dev-eng] configure
> Reply-To: mplayer-dev-eng at 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 at 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 at thot.banki.hu>
> To: mplayer-dev-eng at mplayer.dev.hu
> Subject: Re: Re: [MPlayer-dev-eng] new rgb2rgb stuff
> Reply-To: mplayer-dev-eng at 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 at thot.banki.hu
> http://esp-team.scene.hu
>
> --__--__--
>
> Message: 9
> Date: Tue, 30 Oct 2001 21:14:50 +0300
> From: Nick Kurshev <nickols_k at mail.ru>
> To: mplayer-dev-eng at mplayerhq.hu
> Subject: [MPlayer-dev-eng] swscale question
> Reply-To: mplayer-dev-eng at 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 at mail.ru>
> To: mplayer-dev-eng at mplayer.dev.hu
> Subject: Re: [MPlayer-dev-eng] new rgb2rgb stuff
> Reply-To: mplayer-dev-eng at 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 at thot.banki.hu
> > http://esp-team.scene.hu
> > _______________________________________________
> > MPlayer-dev-eng mailing list
> > MPlayer-dev-eng at 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 at thot.banki.hu>
> To: mplayer-dev-eng at mplayer.dev.hu
> Subject: Re: Re: [MPlayer-dev-eng] new rgb2rgb stuff
> Reply-To: mplayer-dev-eng at 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 at thot.banki.hu
> http://esp-team.scene.hu
>
> --__--__--
>
> Message: 12
> Date: Tue, 30 Oct 2001 19:39:35 +0100
> From: Jesus Climent <data at polinux.upv.es>
> To: mplayer-dev-eng at mplayer.dev.hu
> Subject: [MPlayer-dev-eng] What is this=
> Reply-To: mplayer-dev-eng at 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 at mail.ru>
> To: mplayer-dev-eng at mplayer.dev.hu
> Subject: Re: [MPlayer-dev-eng] What is this=
> Reply-To: mplayer-dev-eng at 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 at 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 at atri.curtin.edu.au Bentley WA, 6102. o
______________________________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rsamp.tar.gz
Type: application/octet-stream
Size: 5438 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20011031/db132a18/attachment.obj>
More information about the MPlayer-dev-eng
mailing list