hi cgc,
thank you, for your posting, I think i am coming along now
-) Operating system Linux -) video pack GEM, maybe pdp, ... -) video source DV camera or analog camera coming via capture card (composite?) -) HD, RAM It should be possible to load the pre-recorded media into the RAM. (3-5 minutes for each of the five files). I have not checked, if there is a RAM video player at all! -) CPU I know that 800 MHz with a G4 are something different than with a Pentium. Still, I am glad to read that a lot is done by the hardware (graphic card) and an average PC with 1GHz+ should do it. latency actually is of importance, since the video should be like a mirror to the performer. but some ms are ok. I think all my questions are answered, only if there is a preferred graphic card, to be used?
Marius.
----- Original Message ----- From: cgc@humboldtblvd.com To: "marius schebella" marius.schebella@chello.at Cc: PD-list@iem.at Sent: Monday, September 08, 2003 8:31 PM Subject: Re: [PD] system requirements video
Quoting marius schebella marius.schebella@chello.at:
Hi,
what hardware requirements do I need to process live-video? I want to mix the data of a live video input with realtime processed videos and need a quality which is high enough to be displayed an a wall by a video beamer (600*800 ???). Do I only need a faster graphic-card (mine has 16MB), or also a fast cpu, RAM, etc.? (Some concrete suggestions of models/types of cards, how fast exactly?). Another calculation I need to process is adding 5 (or 6) pre-recorded videos into one in real time using parts of the videos, and/or overlays.
We need more information to accurately answer your question. Can you
specify
the following:
- Operating system
- video package (GEM/gridflow/pdp)
- live video source (DV/webcam/capture card)
- type of video card
- CPU, RAM ,HD
- birth date, drivers license or other state issued ID number, favorite
color ;)
In general the faster stuff you have and the more of it the better. There aren't any absolute specs for any of this so you'll have to scale
accordingly,
but here's a few general comments:
- We have been getting very good results with DV camera input using GEM on
OSX.
any recent G4 800mhz+ will grab the input and display it on screen.
- scaling the video is 'free' using GEM since it's done entirely in
hardware. i
think pdp has gl scaling and possibly other hardware accelerations.
- using openGL you can use the video card to composite multiple clips with
alpha
blending
- playing multiple clips will put a big strain on the hard drive. the
best
solution is to have multiple drives for the video and RAID if possible.
- resolution of the CPU based capture and processing varies with speed and
type
of CPU. Under 800mhz is probably limited to 320x240 for decent frame
rates,
while 1ghz+ boxes should be able to do 640x480. various optimizations
like SSE
and Altivec and hardware acceleration also impact the final throughput
greatly.
And how big would latency be with those patches?
Depending on the OS, capture device and machine, it could be as low as a
few ms.
One of the GEM devs Daniel Heckenberg wrote a paper on OSx as a low
latency
real-time video capture system. In general long latencies in visual data
is not
as off-putting as audio ones. If the delay gets too long then just set up
some
trippy rave style feedback system and put your brain in neutral for
awhile.
Greetings, Marius.
ps.: an additional (but off topic) question, what is the difference between video, movie and film in this context?
There's not really any difference in this context. In GEM video is live capture, films and movies are clips on the hard drive. In Quicktime the
term
movie is used to describe objects containing a mixture of video, audio,
text and
interactive elements.
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list