[MPlayer-users] Bicubic scaling in vo_gl - does it ever work?
mosgalin at VM10124.spb.edu
Mon Jun 19 13:26:32 CEST 2006
Hi Reimar D?ffinger!
On 2006.06.19 at 11:11:28 +0200, Reimar D?ffinger wrote next:
> Well, the algorithm actually is bicubic spline IIRC... I have to admit I
> don't know the differences between those methods, like "natural bicubic
> spline", no idea what that "natural" means...
Hehe, I love wikipedia so much. Nowadays you don't have to browse
through big paper books to get the answer.. Not to mention there is no
Anyway, it's just simple condition:
> You can easily change the coefficients in gl_common.c, store_weights
> function, w0 - w3 are the coefficients.
> None of the values may become negative though (and the sum must be 1).
Thanks, maybe I'll try playing with it. If current problem will go away,
> > Btw, according to manpage lscale/cscale should work with yuv=4, but they
> > just give a very broken picture withc hardly resembles original image..
> You need five texture units for that to work, probably you get a warning
> that you do not have enough somewhere...
> Please try the attached patch, I read that some cards/implementations
But there should be 16 TMUs on this card... I'll try to look for warning
> have trouble with GL_REPEAT textures.
> I don't like it much since it slows down the shader a bit, but it's not
There is something I meant to ask. Why does the speed of the shader
matter? Unlike games, there is no reason to be "as fast as possible", as
long as you do 25 or 30 fps you should be fine. It's called shader for a
reason, AFAIK video card calculates it completely independent from the
cpu / system memory / bus transfers, so it's not like you are wasting
precious cpu time which can be used for video filters. Can you ever
notice that shader is "slow"? I thought that it's the matter of just
getting desired fps so there are no slowdowns, you shouldn't even be
able to notice if the shader is faster than that. Am I missing
More information about the MPlayer-users