On Fri, 15 Aug 2014 00:23:29 +0200 Massimo Maiurana <[email protected]> said:
> Carsten Haitzler (The Rasterman), il 14/08/2014 17:27, ha scritto: > > > vlc bug. see phab ticket for details. > > > > Yeah, now it works, thanks :) > > But the reason why I wanted to try vlc plugin failed, the little problem > seems to be elsewhere. I try to describe it. > > As I said in the previous mail, I see some artifacts when playing a clip > in rage which contains images that are bright red, and there is much > contrast with surrounding pixels. It is as pixels were grouped together > and set at the same color. I thought it could be plugin related, but now > I realized this happens with every plugin, just only when rage goes > fullscreen. When it is at original size the clip looks the same as with > other players. > > I guess an image would explain better the problem, so I'm attaching one. > It contains two images representing the same part of the same video, > both belonging to a fullscreen window, but one is how it is displayed by > rage (with any plugin) and the other is how it looks in vlc (it's the > same in mplayer). well first - you're using vlc. vlc is an external binary using shm segments to share frames with the calling process (rage - emotion deals with it all). the generic module deals with external binaries in rgba colorspace. videos come (in almost all cases) in yuv colorspace. not rgba. they have u and v often at a lower resolution (1/4 resolution - s that means u and v cover 2x2 or 2x1 or even 4x4 y pixels). y is greyscale, u and v are "color". so what you see is pure red agains another color with a lower res. youa re seeing vlc's own yuv to rgb color conversion - in software. and when it does that it doesn't interpolate u and v (as this is a far more expensive conversion). the "vlc" you see on the screen directly is having the yuv data directly to hardware and the hardware is interpolating the u and v for you - so its blurry instead of blocky. evas's software yuv->rgba does exactly the same because its far faster. gstreamer1 and xine use yuv color directly and thus in software rendering use evas's own yuv-> rgb (and rgba scaler of course). with gl they actually upload the yuv data directly to gl textures and have gl shaders do the work. now here comes the rub. i seem to have found that the yuv rendering in gl is not enabling interpolation for u and v - just for y! fixed in git now. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
