Re: wineqtdecoder: initial commit of the video decoder using Mac OS/X QuickTime Framework
Aric Stewart <aric(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. -- Alexandre Julliard julliard(a)winehq.org
On Nov 30, 2010, at 6:52 AM, Alexandre Julliard wrote:
Aric Stewart <aric(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/C...>. (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/CaptureAndCompressIPBMovi...>. 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
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<aric(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/C...>. (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/CaptureAndCompressIPBMovi...>. 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
participants (3)
-
Alexandre Julliard -
Aric Stewart -
Ken Thomases