Re: Efficient decoding - replace GetMoviePict?

CGContextSelectFont()

for any real time imaging under 10.3 / 10.4 +/ - 10.5 (it's "better" in 10.5, but it still uses up way too many CPU cycles compared to older obsolete text drawing API's).

If your drawing text into a CG Context, your wasting an ungodly amount of CPU time in the call to CGContextSelectFont(), which has to be set each time you get a context.

By ungodly, I mean well over 60% of the CPU usage (multi core cores PPC / x86) was being used under 10.3 / 10.4 just for that single function when blitting 30 fps ARGB32 video to screen. We had to switch back to ATSUI text drawing to work around it. And the fact that there are no retained font settings for a CGContext (unlike QuickDraw / GWorlds) means it has to be set each time you draw, so there is no way to work around it except abandon it if you care about performance.

HTH..

Milton J. Aupperle

President

ASC - Aupperle Services and Contracting

Mac Software (Drivers, Components and Application) Specialist

#1005 - 815 14th Avenue. S.W.

Calgary Alberta T2R0N5

1-(403)-229-9456

email@hidden

www.outcastsoft.com

On 14-Jun-08, at 12:08 PM, Jean-Daniel Dupas wrote:

Le 14 juin 08 à 19:44, Russ a écrit :

My app retrieves the decompressed images from QT movies as fast as possible (>realtime), and I have long-standing working code using GetMoviePict and QDPictDrawToCGContext. However, performance is poor and when I look at it with Shark it is clear why --- the codec is only a small portion of the time per frame. (The case I'm interested in especially is HD ProRes on 8-core machines.) There is a NewGWorld call within GetMoviePict, and that image is then erased. After the codec runs, the pict is rerendered into the CGContext. Each of those single-threaded operations takes several longer than the codec run (which is easy to see---all 8 cores fire up to decode as expected.) Since newly-allocated storage is used within GetMoviePict, there are a fantastic number of zero-fill faults throughout as well. The codec is maybe 10% of the time per frame, a mediocre balancing result.

Is there a more efficient access path? Ideally I'd want to be able to supply recycled storage for the codec to render the image into directly. I'm not sure if there is Core Video stuff that can be used for this, or it is just yet another wrapper around the same slow stuff. If there is a way, a pointer to a code sample would be appreciated. Note that I'm looking for a generic movie-reading approach that works for any codec and source, not something I have to build specially based on reading and decoding the contents of a particular movie.

Alternatively, is there a way to grab the bits directly from the Pict, and avoid the second rerendering stage?

In the ideal world, I'd like to give the codec the output surface format (ie a storage-efficient 24b/pixel form) to eliminate the reformating operation I currently have to perform as well. OpenGL has this right!

Or is all of this the impetus for "Quicktime X"?

This sample code may give you some starting points about the modern way to extract image from a Movie:

http://developer.apple.com/samplecode/QTPixelBufferVCToCGImage/listing1.html

References:
	>Efficient decoding - replace GetMoviePict? (From: Russ <email@hidden>)
	>Re: Efficient decoding - replace GetMoviePict? (From: Jean-Daniel Dupas <email@hidden>)