You are right about the 2vuy format not being appropriate for direct output, however, you can work around that.
If you implement a custom QCOutputImageProvider , you can use the - (BOOL) renderWithCGLContext:(CGLContextObj)cgl_ctx forBounds:(NSRect)bounds What I do in my decklink code is get the IDeckLinkVideoinputImage from the callback, make a CVPixelbufferRef out of it with CVPixelBufferCreateWithBytes and then I make a CVOpenGLTextureRef out of it with CVOpenGLTextureCacheCreateWithImage. If you init the CVOpenGLTextureCache with the same context as the QCPlugin's, the textures created will be valid. The output texture can then be rendered to OpenGL, "fast path", as CV will take care of sorting out the 2vuy format conversions to a proper texture (using either a shader, or via the appropriate texture extensions). Now, you simply draw that CVOpenGLTextureRef when the above function is called on your QCOutputImageProvider, which is as I understand it, is rendered to an FBO with the appropriate format. So you would support QCPluginPIxelFormat BGRA and ARGB, because you are rendering out to that, but internally you are 2vuy. Basically. Init a: CVopenGLTextureCache with an appropriate CGLContextObj from your QCPlugin Context when you get a new frame IDeckLinkVideoInputFrame->CVPIxelBufferRef (via CVCReatePIxelBufferWithBytes) -> CVOpenGLTextureRef (via CVOpenGLTextureCacheCreateWithImage ) When you get the renderWithCGLContext: draw the texture. Done! Just be sure to appropriately call CVOpenGLTextureCacheFlush every now and then. Additionally, you *can* specify format conversions via CV, but I have found that they are slow. :).The only gotcha with this approach is you are providing *only* a texture, not handing off a CVPixelBuffer,Ref which, should the next patch inline from your provider request, would be suboptimal. If you could provide a pixel buffer, QC would handle uploading a texture for you, should the next patch request it, if the next patch requests a pixel buffer, it just hands off the one you provide. However, if you hand off a texture, and the next patch requests a pixel buffer, QC has to download to main memory, and hand off the pixel buffer, which is slower. But, really, no one should be using pixel buffers anymore, unless you have a really good reason like OpenCV processing or something. :P Tom Butterworth has some nice custom image provider classes that can output a PixelBufferRef or a OpenGLTexture depending on what is requested. To be honest, I've not looked into how he managed that or what the magic combination of advertised features are, but should you really need/want to optimize that stage, it is possible. I actually think the v002 movie player has that code come to think of it. Hope that helps. Good luck! On Oct 5, 2011, at 3:55 PM, nisar....@gmail.com wrote: > You guessed it right and my first approach was to develop a provider but QC > was raising an exception whenever it called the outputImageProvider... > function. I got overwhelmed and decided to choose an easier approach, but yes > you are right I should follow the right approach. > > Another reason for switching to consumer was the input image pixel format > which is 2yuv... (from decklink) and the QCPlugin supports RGBA type formats > and I don't have a clue how to make the conversion. > > I also saw your movieloader patch and its code which can be a great help so > will try again tomorrow. > > Thanks > Nisar > *** This Message Has Been Sent Using BlackBerry Internet Service from > Mobilink *** > > From: vade <dokt...@me.com> > Date: Wed, 05 Oct 2011 15:44:11 -0400 > To: Nisar Ahmed<nisar....@gmail.com> > Cc: Christopher Wright<christopher_wri...@apple.com>; quartzcomposer-dev list > list<quartzcomposer-dev@lists.apple.com> > Subject: Re: Drawing inside QC Plugin using CIContext > > It looks like you are outputting an image from a decklink card (I am assuming > this is going to be for a digitizer / video input replacement?) > > Assuming my assumption is correct, why not output the CVPIxelBufferRef ? It > looks like you create one from the decklink IDeckLinkVideoInputFrame handler > in your decklink callback, and make the patch be a provider, rather than a > consumer and use the factory method > > outputImageProviderFromBufferWithPixelFormat:pixelsWide:pixelsHigh:baseAddress:bytesPerRow:releaseCallback:releaseContext:colorSpace:shouldColorMatch, > or a custom QCPLuginOutputImageProvider class you implement and just output > an image :) > > QC will handle everything else you need and you can additionally use image > filters, CI Filters and GLSL shaders on your output image. > > > > > On Oct 5, 2011, at 12:08 PM, Nisar Ahmed wrote: > >> Yes you are correct, I added this and it worked but..... >> >> //Creating image from a CVImageBufferRef >> (Format=PAL) >> image = [[CIImage alloc] initWithCVImageBuffer:pixelBuffer]; >> >> //Resizing width and height of image to match input port's >> width and height >> width = [image extent].size.width*(self.inputWidth/2.0); >> height = [image extent].size.height*(self.inputHeight/2.0); >> >> glViewport(self.inputX, self.inputY, width, height); >> glMatrixMode(GL_MODELVIEW); >> glLoadIdentity(); >> >> glMatrixMode(GL_PROJECTION); >> glLoadIdentity(); >> glOrtho(0, width, 0, height, -1.0, 1.0); >> [ciContext drawImage:image inRect:CGRectMake(0, 0, width, >> height) fromRect:[image extent]]; >> >> Now I can see correct image inside. BUT the whole of QC View background is >> painted in White and it's no more transparent like in other consumer >> patches. The image in question is in PAL format. >> >> I have also attached a screen shot for reference >> >> Thank you >> Nisar >> >> >> >> On Wed, Oct 5, 2011 at 8:27 PM, Christopher Wright >> <christopher_wri...@apple.com> wrote: >>> Now I am a little confused about inRect and fromRect parameters of >>> drawImage since the coordinate system is different and which OpenGL >>> function should I include or remove from this function for it to work. >>> >>> I can only see a blank screen on top right corner of QC View >> >> You'll probably want to change the Projection matrix, since QC will have it >> set to something you probably aren't interested in. >> >> -- >> Christopher Wright >> christopher_wri...@apple.com >> >> >> <Screen shot 2011-10-05 at 9.07.16 PM.png> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/quartzcomposer-dev/doktorp%40mac.com >> >> This email sent to dokt...@mac.com > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/quartzcomposer-dev/doktorp%40mac.com > > This email sent to dokt...@mac.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
