Thread-topic: DecompressSequenceFrameS() in secondary thread
User-agent: Microsoft-Entourage/11.3.2.061213
On Fri, 24 Aug 2007 18:39:28, "Roni Music" <email@hidden> wrote:
> I'm using DecompressSequenceFrameS() to decompress and display video
> in a secondary thread.
> I'm setting it up pretty much as the TN2044 describes with the
> differences that the the destination port is not a GWorld but a window
> using windowPort obtained by GetWindowPort(windowRef);
>
> I then call DecompressSequenceFrameS() whenever there is a frame to
> be displayed.
>
> Everything works fine with the exception that when I resize the
> window, the main thread and display thread "hangs" as if both are
> waiting for each other to release a lock (see stack trace below).
>
> It's a Carbon app and I want to avoid Cocoa since it is a cross
> platform application.
>
> I have tried to call LockPortBits(windowPort) before
> DecompressSequenceFrameS() and UnlockPortBits(windowPort) after, but
> that doesn't change anything.
>
> I know many QuickTime calls are not thread safe but
> DecompressSequenceFrameS() is not marked as such.
What's your source of thread safety information of QT APIs?
> If what I'm trying to do is not the correct way, what should I do
> instead?
> I really need to have the display in another thread.
>
> Would using an offscreen GWorld and CopyBits() work better?
CopyBits (QuickDraw) is not thread safe!
You might try ICMDecompressionSessionCreate etc instead of elder
DecompressSequence APIs, though I am not sure. In this date and
age it's sometimes hard to say what's thread safe and what's not.
Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
