Thanks for the responses and information. However, I just don't buy
that
the price of modernity is doggy video performance. The CPU, the
memory bus,
the I/O bandwidth, everything about newer machines is ten times
faster than
it was a few years ago. It doesn't add up.
For example, take the TFT displays. I happen to be on a job using a
high-speed
video camera, and so was able to point it at the screen of this here
12" powerbook.
I ran the openGL "texture range" demo, which, if there are no
occluding windows,
will "write to the screen" at 100 hz or more. Of course, the actual
screen pixels
won't change at that rate. With the high-speed camera I can see that
the TFT display
changes at a 60 hz rate, with no ghosting. This is better
performance than most CRT's.
Further, about a year ago I tried the following experiment. Point a
video camera at
your hand on the mouse, including the display in the view. Write a
bar representing
the mouse position "directly to the screen", using a pixel address
obtained via
GetDeviceList(), or a CGDirect call. You will observe no perceptable
lag between
the physical mouse, and the bar on the screen. However, the quartz
mouse cursor,
at least in 10.3, lags several frames behind the physical mouse.
This shows that
the graphics display can be instantaneous on a human time scale, it's
just human
programming that is slowing it down.
The video-in is harder to test, because the source is closed, and
nothing is documented,
it's hard to bypass quicktime. But just on the face of it, how fast
is firewire? How fast
is USB2? Seven frames of lag? Come on! It's all too easy to dump
on quicktime,
I'll just say that I basically agree with every rant that's appeared
in the newsgroups.
In fairness, latency probably is not a priority in quicktime. For
every scientist,
video artist, or VJ, there are probably a hundred guys using imovie
to make videos of
their two-year-old's birthday party. Still, I think paying attention
to low-level video
performance would make the higher level stuff run better.
I have played a little bit with quartz composer, it's pretty neat.
It's got a Max MSP type
interface, and really shows off the power of the graphics chip.
However, the video-in
still has that doggy 1/4 second lag. My real question about quartz
composer is,
how hard is it to add your own modules? People get bored of video
effects really
quickly unless they're good, and/or interactive. We have to be able
to easily add in
new stuff.
Maybe I should buy a linux box with a PCI card, but it seems a shame,
at my home base,
I'm surrounded by G5's. They must be good for something!
Thanks, and sorry for the length of this rant,
rob
On Jun 8, 2006, at 1:16 PM, Mark Asbach wrote:
Hi Rob,
Thanks for the example code, everything helps. I was interested
in your comment,
"the Macbook is much faster than the Powerbook", can you be more
specific?
I'm looking for an excuse to buy a mactel, and went to a store
recently, but was
a little disappointed. The only video app which was easily
accessible was something
called "photobooth", it ran at 15 fps max, with stutters, and had
a video latency of
at least 1/4 second. Of course, that program may have extra
buffering, etc.
Hm. Well, regarding latency, you really won't be able to get very
far with current hardware because of the way imaging devices are
attached (USB, FireWire). Since part of the design goals of
previous times (synchronization to video clocks of incoming signals
and/or outgoing signals) are not applicable to current hardware.
These days you have TFT displays that refresh portions of the
screen at intervals not strictly related to the clock signal on a
DVI or VGA cord and (even more problematic) not controllable or
even detectable from the machine. On the input side, you oftentimes
have camera CCDs that are read by a microcontroller that moves the
data over a digital bus at later times and has to share the bus
with other devices. This means that there is a 1 frame delay until
a USB or FireWire device even starts communicating. There is no
interrupt driven direct access to the data in the buffers and
sometimes (think core image) the data has to be moved even one
device further (GPU), back to the CPU and forth to the GPU again.
Depending on the processing pipeline.
So there is really only the option to use frame grabber cards and a
CRT display if you intend to go towards minimum latency.
What current hardware provides in sense of "much faster than the
Powerbook" is the amount of processing and throughput that you can
have. There is no substantial additional delay or reduced
throughput to the simple 'acquire -> present' variant if you go for
modifying your images. What you can do with Core Image is immense.
Further, current fast software video decoders use altivec to do
the required
byte swapping quickly and in parallel. It is my understanding
that any intel SSE replacement
is half the speed of altivec on a clock cycle basis, there are no
appropriate byte swapping
instructions, and it is harder to use. So in what sense can the
mactel machines be "faster"?.
Depending on what you do, your code will benefit from the faster
video chipsets in the MacBook Pro or iMac for example. Regarding
image processing, the current CPUs are not magnitudes faster,
compared with good hand crafted G4 or G5 assembler. The increased
bus bandwidth makes a difference if you process large amounts of data.
When developing, you will notice that tools like compilers, etc.
are really more snappy than on PPC. They can't make use of AltiVec
and are the domain that has always been faster on intel.
There seem to be a few
PCI express frame grabber cards available, but for many thousands
of dollars, in
contrast to the less than 100 dollars for which you can get a
standard PCI frame grabber
card for a linux box.
If you're in need of low latency, just by a cheap linux machine
with a PCI card. You won't be able to beat that with any other
solution (regarding latency). However, if you want to play with the
video material, I'd recommend to go for an intel mac. Did you ever
use the QuartzComposer? The possibilities with Core Image and Core
Video are amazing. In principle it would be possible to do the same
with GLSL on linux, but in practice I found that all the
uninteresting parts of that (interfacing to the GPU, moving image
data, general house keeping) are very tedious and error prone. Your
time might be better invested in playing with all those new toys
that really work without hassle on OS X than in fiddling with
driver details, kernel interfaces, etc.
Mark
--
Dipl.-Ing. Mark Asbach Tel +49 (0)241 80-27677
Institute of Communications Engineering Fax +49 (0)241 80-22196
RWTH Aachen University, Germany http://www.ient.rwth-aachen.de
_______________________________________________
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
