Ah... I think I get what you are saying now. The display link will run
as fast as it needs to keep up the refresh rate of the monitor (i.e.
v-sync), and is in fact unrelated to video... it can be used as my
main render thread for the OpenGL scene, and would even be appropriate
as a render loop for OpenGL even if I didn't have want to have video?

I was working under the assumption that the display link would only
make the callback at frames per second of the video.. which I guess
was a stupid assumption to make as at no point in time have I told the
display link specifically about the video file!

Cheers!

Craig

Thursday, December 8, 2005, 7:04:33 PM, you wrote:

FD> Are you rendering to the screen? Because in that case the display
FD> link will drive you to render as fast as makes sense (when you try to
FD> render faster than the refresh rate of the display you just tax your
FD> app unnecessarily - a big NO NO).

FD> Frank

FD> On Dec 8, 2005, at 11:00 AM, Craig Edwards wrote:

>> Hi Frank,
>>
>> Thanks for the reply.
>>
>> Unfortunately, in this instance I can't restrict myself to render just
>> from the display link thread. As I have an OpenGL scene which must be
>> rendered as fast as possible, the video is just being embedded into
>> the scene as a texture assigned to one of many objects within the
>> scene - the other objects need to be updated and rendered  
>> independent of
>> the video, in fact sometimes video isn't playing in the scene at all.
>>
>> Since this is the case I guess the display link callback is the wrong
>> way to go about this. I was hoping to use the display link callback to
>> prepare the next frame as an OpenGL texture ready for the main render
>> thread to use. This is what I've been attempting to do, but it  
>> gives me this flicker.
>>
>> I have seen an example (QTValuePak) of drawing a QuickTime movie  
>> into a GWorld and
>> then using UpdateMovie()/MovieTask() along with glSubTexImage2D to
>> update the frame texture rendering faster than the frame rate of the
>> video, it appears to render as fast as the v-sync of the monitor which
>> is what I'm after. I'm going to attempt this approach instead..
>> unless of course Core Video can emulate such an approach?
>>
>> Cheers.
>>
>> Craig
>>
>> Thursday, December 8, 2005, 5:05:15 PM, you wrote:
>>
>> FD> You need to refactor your code to render just from the display
>> link
>> FD> thread, otherwise you will not get any proper rendering. The whole
>> FD> purpose of the display link is to properly drive the rendering
>> at the
>> FD> appropiate frame rate.
>>
>> FD> Frank
>>
>> FD> On Dec 8, 2005, at 3:34 AM, Craig Edwards wrote:
>>
>>>> Hi,
>>>>
>>>> I am attempting to use QuickTime (NewMovieFromProperties(..)) and
>>>> Core Video to get video frames and then
>>>> rendering these frames into my main OpenGL scene (i.e. onto a quad
>>>> along with other
>>>> OpenGL objects being animated/rendered). I am rendering the main
>>>> OpenGL
>>>> scene as fast as possible using the main application thread (while
>>>> loop with [NSApp
>>>> nextEventMatchingMask...] and using the display link callback to
>>>> obtain the video frames.
>>>>
>>>> I do have this "working", based on the documentation and samples on
>>>> the website, but the video flickers like crazy on playback. Is it a
>>>> requirement of
>>>> Core Video to render the CVOpenGLTextureRef video frame inside the
>>>> display
>>>> link callback, and only flush the OpenGL buffer on each new video
>>>> frame? From what I can see all the samples appear to do this?
>>>>
>>>> This is how I am using core video, but it gives me
>>>> the flickering on playback
>>>>
>>>> Instance variables of interest..
>>>>
>>>> CVOpenGLTextureRef m_frameBuffer[3];
>>>> NSLock* m_frameUpdateLock;
>>>>
>>>> I call this method in the display link callback (this is how I  
>>>> get me
>>>> video frames)...
>>>>
>>>> - (CVReturn) getFrameFromTime:(const CVTimeStamp*) syncTimeStamp
>>>> {
>>>>     // Autorelease pool for this thread
>>>>     NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
>>>>
>>>>     // Check for new frames
>>>>     if(QTVisualContextIsNewImageAvailable(m_qtTextureContext,
>>>> syncTimeStamp))
>>>>     {
>>>>          int nextFrameIdx = m_currentFrameIdx+1;
>>>>
>>>>          if(nextFrameIdx >= 3)
>>>>          {
>>>>              nextFrameIdx = 0;
>>>>          }
>>>>
>>>>          CVOpenGLTextureRelease(m_frameBuffer[nextFrameIdx]);
>>>>
>>>>          // Get the new frame texture
>>>>        
>>>> QTVisualContextCopyImageForTime(m_qtTextureContext, NULL,
>>>> syncTimeStamp, &m_frameBuffer[nextFrameIdx]);
>>>>
>>>>          [m_frameUpdateLock lock];
>>>>
>>>>          // Update index
>>>>          m_currentFrameIdx = nextFrameIdx;
>>>>
>>>>         [m_frameUpdateLock unlock];
>>>>     }
>>>>
>>>>     [pool release];
>>>>
>>>>     return kCVReturnSuccess;
>>>> }
>>>>
>>>> Then in my main render thread, I render the frame like so...
>>>>
>>>> - (void) renderFrame
>>>> {
>>>>     [m_frameUpdateLock lock];
>>>>
>>>>     CVOpenGLTextureRef currentFrame = m_frameBuffer
>>>> [m_currentFrameIdx];
>>>>
>>>>     .
>>>>     .
>>>>     Use 'currentFrame' to get texture target/id, texture bind,
>>>> render to quad etc..
>>>>     .
>>>>     .
>>>>
>>>>     // Give time to QT for frame rendering
>>>>     QTVisualContextTask(m_qtTextureContext);
>>>>
>>>>     [m_frameUpdateLock unlock];
>>>> }
>>>>
>>>> Do I need to copy the data from the current CVOpenGLTextureRef
>>>> (which is just a CV pixel buffer?) and update
>>>> an OpenGL texture using glTexSubImage2D(..) which I have already
>>>> created?
>>>>
>>>> Is the CVOpenGLTextureRef is being destroyed after its
>>>> first display, is this why I get the flicker? It seems unlikely,
>>>> since
>>>> I check if currentFrame is NULL and it never occurs...
>>>>
>>>> Any pointers, samples, documentation etc on how I can get Core Video
>>>> to render outside the display link callback without the flicker  
>>>> would
>>>> be greatly appreciated.
>>>>
>>>> Thanks.
>>>>
>>>> Craig
>>>>
>>>>  _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Quartz-dev mailing list      (Quartz-dev@list...)
>>>> Help/Unsubscribe/Update your Subscription:
>>>> http://lists.apple.com/mailman/options/quartz-dev/fdoepke%
>>>> 40apple.com
>>>>
>>>> This email sent to fdoepke@appl...
>>

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartz-dev mailing list      (Quartz-dev@list...)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartz-dev/subscriber%40opensubscriber.com

This email sent to subscriber@open...