I have tried it but with little success. The code can render memory buffer into OpenGL context but I can only see garbage on the output. I think it is color conversion issue. I am sharing the link to code for your review.
Thanks On Thu, Oct 6, 2011 at 1:25 AM, vade <dokt...@mac.com> wrote: > 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/nisar.med%40gmail.com > > This email sent to nisar....@gmail.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
