[PD] system requirements video

[cgc at humboldtblvd.com]

Quoting marius schebella <marius.schebella at 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.