On Fri, Jan 9, 2009 at 19:06, Tero Saarni <[email protected]> wrote: > On Thu, Jan 8, 2009 at 15:37, Bastian Winkler <[email protected]> wrote: >> On Thu, Jan 08, 2009 at 02:59:03PM +0200, Tero Saarni wrote: >>> With the pipeline below it really seems to take all CPU and is just as >>> slow as with Clutter. I suppose videoscale adds some extra overhead >>> too (besides colorspace conversion) that isn't done in software when >>> using ClutterGstVideoSink, but maybe the colorspace conversion >>> dominates cpu wise? >> >> See this thread for details: >> http://thread.gmane.org/gmane.comp.video.gstreamer.devel/20971 >> > > Haven't tested it with clutter yet but the newest gstreamer ffmpeg > plugin release has ffvideoscale element that seems to do much better > job than ffmpegcolorspace. >
I've now finally got around to test Clutter (version 0.6) with ffvideoscale but for my disappointment I see only empty space where video should be. Small warning. I'm just trying to learn, and I'm not actually familiar with the area so this might be crazy talk... :) Libswscale has accelerated MMX implementation only for RGB32 and BGR24 bitmap formats. I believe ClutterGstVideoSink supports RGB32, is this true? For some reason ffvideoscale plugin fails to recorgnize this and falls back to slow implementation. For now I've hardcoded the plugin to choose the accelerated RGB32 implementation. Still I'm left with blank screen. If I change the value that libswscale writes to alpha channel I finally seem to get the picture. By default it sets zero as alpha value. Do they disagree on the definition of the value? Any ideas why? -- Tero -- To unsubscribe send a mail to [email protected]
