On Fri, Nov 21, 2003 at 04:39:13PM +0800, Selwyn Tang wrote: > Hi all, > > It seems to me that a RGB16 image cannot be rendered to a YUY2 surface. > Looking at rgba_to_dst_format(), I found the conversion from RGBA to > YUY2 not implemented. But there are macros at src/gfx/convert.h > converting RGB to YUV (Y/CB/CR_FROM_RGB).
Those are just to convert the color values. Even those are a poor implementation since they use floating point arithmetic. I wrote them btw :) > Why is it not implemented? It's not as simple as RGB<->RGB conversions. The biggest problem with YUV formats is chroma sub-sampling. I hacked around with this stuff at some point but I didn't have the time/energy to finish what I started. I should try to find that stuff and commit it. Slow/bad code is better that no code :) > Is > it because of the calculations required rather than the simple > bit-shifts among RGBs? That's not really a problem. > Another problem is that I cannot play a video on a YUY2 window surface, > which is, in turn, on an ARGB layer. The error message is "only copying > blits supported for YUV in software" at generic.c line 3311. I guess > there should be no problem playing the video to a YUY2 surface. There > should be no conversion required and the performance should be better. > Since that surface is on an ARGB layer, is it also not implemented to > blit the YUY2 surface on an ARGB layer? Exactly. That would require conversion to ARGB. > Strange enough, I have no > problem playing the video to an ARGB window surface on an ARGB layer. No conversion required (except by the video decoder part which converts YUV to RGB). > When playing back an mpeg-1 file using libmpeg3, I find 3 threads > running, two of which takes up 50% and 40% of the cpu time on my epia-m > C3 1G system. Is such huge cpu usage due to pixel format conversions? Or > is it due to the mpeg decoding? How can I tell? Depends on how well the decoder is optimized. I just ran a quick test with mplayer + libavcodec + some xvid file. CPU usage was ~25% with sw color space conversion and ~5% with hw conversion.. libmpeg3 probably isn't well optimized. It's quite easy to use though which is why the video provider uses it, I think :) -- Ville Syrj�l� [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-users" as subject.
