Sent a revised patch using the ICMDecompression apis just before seeing your e-mail. So I figured out that part.

I will have to look into the pixel buffer copying improvement once the base framework is in place.

thanks!
-aric


On 11/30/10 10:33 AM, Ken Thomases wrote:
On Nov 30, 2010, at 6:52 AM, Alexandre Julliard wrote:

Aric Stewart<a...@codeweavers.com>  writes:

---
configure                             |    8 +-
configure.ac                          |    5 +
dlls/wineqtdecoder/Makefile.in        |   11 +
dlls/wineqtdecoder/main.c             |  135 +++++++++
dlls/wineqtdecoder/qtvdecoder.c       |  536
+++++++++++++++++++++++++++++++++
dlls/wineqtdecoder/version.rc         |   26 ++
dlls/wineqtdecoder/wineqtdecoder.spec |    4 +
7 files changed, 724 insertions(+), 1 deletions(-)
create mode 100644 dlls/wineqtdecoder/Makefile.in
create mode 100644 dlls/wineqtdecoder/main.c
create mode 100644 dlls/wineqtdecoder/qtvdecoder.c
create mode 100644 dlls/wineqtdecoder/version.rc
create mode 100644 dlls/wineqtdecoder/wineqtdecoder.spec

This is showing many deprecated function warnings even on Leopard. We
should try to avoid that in new code.

Aric,

The DecompressSequenceBeginS takes a CGrafPort or GWorld.  These are QuickDraw 
concepts and are very, very obsolete.  DecompressSequenceBeginS should be 
deprecated, itself, since it depends on them, but doesn't appear to be.  The 
documentation on this whole area is terrible.  Apple seems to have blackholed 
even the documentation of the more modern APIs.  (You can still get it from 
within Xcode 3.2.x if you go into preferences and subscribe to the Leopard 
docset.  But it seems largely gone from their website.)

As is often the case, the headers provide what documentation there is.  
According to the headers 
(/System/Library/Frameworks/QuickTime.framework/Headers/ImageCompression.h), 
the replacement is ICMDecompressionSessionCreate() and friends, also in that 
header.  (That header has both old APIs and new.  You want the ones introduced 
with Mac OS X 10.4 or later, or QuickTime 7 or later.)

The ICMDecompression... functions feed you CVPixelBuffer objects through a callback.  Those are 
documented 
here<http://developer.apple.com/library/mac/#documentation/QuartzCore/Reference/CVPixelBufferRef/>.
  (Take note of the "Derived from" info at the top of that page.  If you feel that 
CVPixelBuffer is missing some important API, it may be provided by the base classes.)

The ICMDecompression... API seems kind of asynchronous in nature, but I think 
you can force it to fully decompress frames immediately via the frameTime 
parameter to ICMDecompressionSessionDecodeFrame().  The flags field of 
ICMFrameTimeRecord can include icmFrameTimeDecodeImmediately.

The next thing that might be useful are some techniques to avoid doing the pixel copying 
manually.  Depending on the output format you require (This->outputDepth and 
This->rowBytes), you may be able to create a CGBitmapContext to wrap the output buffer.  
Then, you can create a CGImage from the CVPixelBuffer, and draw the image into the context. 
 (The modern Mac APIs don't really have blit operations, they copy and/or convert images by 
drawing.)  Some of these techniques are illustrated in this sample 
code:<http://developer.apple.com/library/mac/#samplecode/CaptureAndCompressIPBMovie/>.
  Actually, it sort of does the reverse.  It wraps the CVPixelBuffer in the bitmap context 
and draws onto it, but the principle is similar.

I hope that helps.

-Ken



Reply via email to