[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