Hence the name DISPLAY link :)
Frank
On Dec 8, 2005, at 11:23 AM, Craig Edwards wrote:
> 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...
opensubscriber is not affiliated with the authors of this message nor responsible for its content.