I've been looking at this and have been coming to the same conclusion.
You could pack the yuv (444, 422, 420, whatever) data in an arbitrary
way into an RGBA texture and use shaders to translate to real RGBA. This
would avoid the multi-texturing, but I imagine you'd still have to munge
the data to get it into a format that's convenient to read by shader (so
probably not the memcpy, or equivalent).

A fall-back would require multi-texturing though, and I agree that this
is probably best off in the clutter-gst layer. Implementing this at the
cogl level will likely over-complicate a lot of code and restrict
expandability.

--Chris

On Tue, 2008-07-01 at 14:31 -0400, Kashyap Ashwin wrote:
> Is this even possible to do without memcopying data around? I420 is
> planar and then the Cb, Cr are subsampled. So reconciling the difference
> with RGBA seems to be impossible. Does any one have any ideas on how
> this can be done without memcopy and without multi-texture?
> 
> With multi-texturing, you need to setup three textures in order to pull
> it off. This is more suitable to do in a higher layer like the
> clutter-gst-video-sink, don't you think?
> 
> http://www.fourcc.org for general info on color space conversions.
> http://www.fourcc.org/source/YUV420P-OpenGL-GLSLang.c for a
> multi-texture example. 
> 
> -Ashwin
> 
> 
> > -----Original Message-----
> > From: Matthew Allum [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, July 01, 2008 12:57 PM
> > To: Jason Tackaberry
> > Cc: clutter
> > Subject: Re: [clutter] Comments about new texture-from-pixmap feature
> > 
> > On Mon, 2008-06-30 at 22:55 -0400, Jason Tackaberry wrote:
> > > On Mon, 2008-06-30 at 11:46 -0400, Jason Tackaberry wrote:
> > > > This assumes though that clutter does hardware-accelerated
> colorspace
> > > > conversion of YUV frames via fragment programs.  I'm curious on
> which
> > > > cards/chipsets is this supported right now?
> > >
> > > Actually, does clutter_texture_set_from_yuv_data() do anything right
> > > now?  I was curious about the fragment program (if any) clutter
> used,
> > > and what kind of software fallback existed, but looking at COGL I
> got
> > > the impression this was a TODO?
> > >
> > 
> > We hope to get clutter_texture_set_from_yuv_data() fixed up in some
> form
> > for Clutter 0.8. Its the last remaining niggle really. Patches warmly
> > welcomed.
> > 
> >   == Matthew
> > 
> > --
> > To unsubscribe send a mail to [EMAIL PROTECTED]
> 

-- 
To unsubscribe send a mail to [EMAIL PROTECTED]

Reply via email to