OK, I've got a rewritten reader based roughly on the QTPixelBufferVCToCGimage sample and have gotten it to work on a 29.97 ProRes movie. Good news is performance has increased dramatically. First a little discussion before I mention my current showstopper.
So-so news is that the YUV to RGB conversion is not parallelized and is a major unwarranted limiting factor. (System cpu utilization is about 50% of max) Offhand I don't see any way to pull the conversion out of the serialized Quicktime portion so that at least my reader threads could run the conversion overlapped. I could conceivably request YUV results and write my own parallelized converter, but that would be a pain and it's not obvious how to tell when this is a good idea, given an arbitrary movie (ie if the codec already produces RGB it would be counterproductive, how to tell?).
I also have major zero-fill problems --- when ingesting footage my app is running as a RAM cache so gobbling huge amounts of RAM is a given. It sure would be nice if pre-zero-fill was moved into a background thread in the kernel, that seems pretty obvious. The way my reader threads overlap, there is full-bore zero-fill activity 100% of the time on one thread or another.
**** Now the show-stopper **** When I try reading a different movie: my code reads all the "interesting times" from the movie; to get a given frame, it does a SetMovieTime with the corresponding interesting time built up into a TimeRecord containing the interesting time, the scale value, and the timebase (as obtained earlier from the movie). So it's all exact integer timing. The interesting times in the movie have some variability, at frame 10 in this particular movie, it is timevalue 201. But, when the VisualContextIMageAvailableCallback is called, I extract the timevalue and it is 200! Since it's waiting for the requested timevalue 201, the reader hangs permanently. It sounds like QT is spoiling the whole point of the interesting-time scheme by internally converting to seconds and back. That's a wreck, how can I prevent that? I can look for timevalue +/- 1 or +/- epsilon but generally that is going to break sooner not later (customer-generated movies
may have pauses, you name it.). If I SetMovieTime for TimeValue=X, the callback should show up with a frame with TimeValue X, that seems pretty fundamental.
Russ
------------------------------
Message: 5
Date: Mon, 16 Jun 2008 23:13:35 -0400
From: "Edward Agabeg" <email@hidden>
Subject: Re: Efficient decoding - replace GetMoviePict?
To: email@hidden
Message-ID:
<email@hidden>
Content-Type: text/plain; charset="utf-8"
QTMovie frameImageAtTime:withAttributes:error: will do the trick very easily.
This method is currently way faster than using any crufty PICT code path and
should get even faster in the future. It also supports a wide variety of
"ImageTypes" that can be requested as output via the attributes passed in.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
QuickTime-API mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quicktime-api/email@hidden
This email sent to email@hidden
