On 21/06/2007 8:41 Pm, "Brad Ford" <email@hidden> wrote:
On Jun 21, 2007, at 7:06 AM, Mike Kluev wrote:
I am new to Sequence Grabber APIs and don't currently see
the big picture.
There isn't really good documentation. Following the examples is your
best bet.
What is the best way to grab each frame of the recorded video?
I found SGDataProc (along with MungGrab sample and its flavors).
I also found some (minimal) documentation on VideoBottles.
Which way is more efficient or better in other respects and why?
Ideally I need uncompressed frames (just raw pixels).
Ideally I need this on 10.3+
It looks like VideoBottles is better for me because it sits
before SGDataProc in the chain and has the image not yet
compressed. While SGDataProc is fed with compressed pixels,
that I'll have to decompress again. Is this correct? If to
use VideoBottles what exact callback do I need to use to
have access to raw pixels?
In practice, SGDataProc gets better performance than the
VideoBottles.
Can you rationally explain why?
I can't, but when I tried VideoBottles, they didn't seem to work very
well. I was also advised (by another Apple Engineer) to steer away
from them in any case, so I think you can just take it as read that
you should avoid them, and that performance will be worse.
If you request an uncompressed format for output, then
the data proc will deliver you uncompressed data.
How do I request uncompressed data? I want just raw pixels
(i.e. baseAddr, rowBytes and image width and height). Will
my request be always honored, or will it be treated as just
"please do your best"? BTW, how do I know rowBytes? It's
not part of the ImageDescription handle.
I believe you'll just get the native format by default if you don't
specify a compressor for the sequence grabber.
If you set up a decompression session, and force the frames in in
your SGDataProc, you can then use the pixelbuffer in the
Decompression session tracking callback.
when you set up the decompression session, you can force some
pixelbuffer attributes/cheap conversion, such as RGBA, which can make
display, or drawing on the frames slightly easier.
You can get row bytes from the pixelbuffer with
CVPixelBufferGetBytesPerRow.
Look at WhackedTV for example.
Some prefer to
have the Sequence Grabber deliver pixels in the native format, then
decompress them using modern API's,
Why? Isn't that more work?
Possibly because if you set a Sequence Grabber compressor, although
it seems to be slightly more efficient (there was a post asking why
this should be so, but no-one replied), if you then try and use the
frames for preview display, they will have visual artefacts. At least
that's been my experience. You can see this in WhackedTV by changing
the compressor in the video settings.
Apple Pixlet Video is the worst (it has a strange bluish cast, due to
a known issue), but all of them don't appear as clean as if you grab
the frames in native format for preview display, and then compress
and save those frames separately, like CaptureAndCompressIPBMovie does.
such as ICMDecompressionSession.
But it's 10.4+, no?
possibly yes.
Please have a look at two modern examples, CaptureAndCompressIPBMovie
and WhackedTV. Both use the SGDataProc.
Yes, I've already looked at WhackedTV. Will look at the other one
shortly.
CaptureAndCompressIPBMovie is the best one. This uses a separate
compression session.
WhackedTV will show the visual artefacts I mentioned above if you
change the compressor.
That might actually work fine for you, as you only want the native
format, and you should get marginally better performance.
If you want to display and compress the frames though, go for
CaptureAndCompressIPBMovie
As for "anything else", I looked at the performance (CPU load) of
quite a lot of video apps when establishing a reasonable baseline for
my own.
There seems to be at least one more possible approach to sequence
grabbing, which is used by Security Spy. This doesn't seem to use the
SGDataProc, but gets blinding performance, even when doing motion
detection over the images. The next best approaches (essentially
WhackedTV, sans compression, although QTQuartzPlayer is actually more
efficient than that for preview) consume at least half as much CPU
again, at least in preview mode.
I've never been able to work out exactly Security Spy manages it though.
Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
QuickTime-API mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40ucl.ac.uk
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
QuickTime-API mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
