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.
And how big would latency be with those patches?
Greetings, Marius.
ps.: an additional (but off topic) question, what is the difference between video, movie and film in this context?
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.
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
marius schebella wrote:
hi cgc,
thank you, for your posting, I think i am coming along now
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.
the hw-acceleration has to be used by the package in order to work (no-na). in most (if not all) cases, hw-acceleration means 3D-hw-acceleration and not pixel-processing. Gem is openGL-based which means, that it will use hw-acceleration (to do 3d-things and to display images, but not to do pixel-based effects). however, things like blending to (moving) images can be done in openGL (alpha-blending) pdp has these openGL-packages, which will give you some acceleration too, but i m not sure, whether you will have any benefit when doing image-processing (i don't know about textures). but i think, pdp has mmx support, so image-processing will be much faster. with gridflow i really don't know, but i guess you will have no hw-acceleration at all (but might have MMX also)
latency actually is of importance, since the video should be like a mirror to the performer. but some ms are ok.
well, with 20fps you are getting latencies bigger than 50ms very fast (this is just 1 frame!)
I think all my questions are answered, only if there is a preferred graphic card, to be used?
if you want openGL-hw-acceleration try nvidia- or the new radeon-cards.
mfg.a.rd IOhannes
I think all my questions are answered, only if there is a preferred graphic card, to be used?
if you want openGL-hw-acceleration try nvidia- or the new radeon-cards.
I wonder how fast these two mainstream brands handle texture upload on different OS'es.
It may not be very optimized in the driver since this operation is rarely used during gameplay, but it's a potential bottleneck for video processing. I expect major performance differences here.
Did anyone compare nVidia vs ATI on different OS's on this aspect?
j#|@
I wonder how fast these two mainstream brands handle texture upload on different OS'es.
It may not be very optimized in the driver since this operation is rarely used during gameplay, but it's a potential bottleneck for video processing. I expect major performance differences here.
Did anyone compare nVidia vs ATI on different OS's on this aspect?
We actually have fairly extensive data on this.
Starting with OSX 10.2 all textures can be uploaded using DMA resulting in 0% CPU time for the transfer. Plus 10.2 can handle non-power-of-two texture sizes and YUV pixels for even more efficiency. This applies for both ATI Radeon (not Rage) and Nvidia Geforce hardware on OSX. Of course GEM fully supports these features. ;)
Windows does not feature any of these enhancements in it's standard OpenGL implementation, so significant CPU time can be spent handling the texture uploads. There might be some vendor specific extensions to enable fast texturing, but to my knowledge none of them have been implemented in GEM. Windows will be getting system wide support for using video as textures, unfortunately it will be for Direct3D and won't be released until 2005 or 2006 (as part of the Longhorn GDI).
Linux is closer to Windows than OSX as far as drivers go with Nvidia hardware, so you can expect similar texturing performance.
I can post measured performance data between Win32 and OSX GEM if you are interested.
cgc
j#|@
On Tue, 9 Sep 2003, chris clepper wrote:
I wonder how fast these two mainstream brands handle texture upload on different OS'es.
Did anyone compare nVidia vs ATI on different OS's on this aspect?
We actually have fairly extensive data on this.
8<
Thanks, very interesting info!
I can post measured performance data between Win32 and OSX GEM if you are interested.
Your observations are clear enough for me. Unfortunatly I don't consider switching to OSX...
j#|@
has anyone experience with live video processing on windows or linux? or is everybody using Mac and OSX?
marius.
----- Original Message ----- From: "chris clepper" cgc@humboldtblvd.com To: "Johannes Taelman" Johannes.Taelman@UGent.be Cc: PD-list@iem.at Sent: Tuesday, September 09, 2003 10:21 PM Subject: Re: [PD] system requirements video
I wonder how fast these two mainstream brands handle texture upload on different OS'es.
It may not be very optimized in the driver since this operation is rarely used during gameplay, but it's a potential bottleneck for video processing. I expect major performance differences here.
Did anyone compare nVidia vs ATI on different OS's on this aspect?
We actually have fairly extensive data on this.
Starting with OSX 10.2 all textures can be uploaded using DMA resulting in 0% CPU time for the transfer. Plus 10.2 can handle non-power-of-two texture sizes and YUV pixels for even more efficiency. This applies for both ATI Radeon (not Rage) and Nvidia Geforce hardware on OSX. Of course GEM fully supports these features. ;)
Windows does not feature any of these enhancements in it's standard OpenGL implementation, so significant CPU time can be spent handling the texture uploads. There might be some vendor specific extensions to enable fast texturing, but to my knowledge none of them have been implemented in GEM. Windows will be getting system wide support for using video as textures, unfortunately it will be for Direct3D and won't be released until 2005 or 2006 (as part of the Longhorn GDI).
Linux is closer to Windows than OSX as far as drivers go with Nvidia hardware, so you can expect similar texturing performance.
I can post measured performance data between Win32 and OSX GEM if you are interested.
cgc
j#|@
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
everybody using Mac and OSX?
no, i have a setup with : linux pd.37 gem pdp pidip with a bt878 wintv input card ati radeon 8500
everything is fine, but i have color space problem with pdp. i use the second head for displaying gem / pdp fullscreen 800x600. i'm not using 3d objects, just live feed and libquicktime.
patrick
Hey All,
Anyhow have any suggestions on storing 2D data in PD?
I'll be working with a very large video clip and using gem to jump around to create the effect of having multiple clips. So I need to store the clip # and in and out frames for each clip in a nice way.
I'm currently thinking about two arrays one for in the other for out. Only problem I forsee is the anoyance of getting the in and outs into PD in the first place... the ideal would be to load a catDV or finalcut log file and extract the in and out points. This would be a simple parser... I just wanted to check if anyone has already found a good solution for this...
If not I'll write something and release it sometime. Would be really nice to do it all in PD... ;) *shudder*
Ben
PS: I do my installations on linux, my daily PD hacking on windows. If I had my choice I would use a g5 with the radeon 9800... if I could ever afford such a luxury!
has anyone experience with live video processing on windows or linux? or is everybody using Mac and OSX?
marius.
----- Original Message ----- From: "chris clepper" cgc@humboldtblvd.com To: "Johannes Taelman" Johannes.Taelman@UGent.be Cc: PD-list@iem.at Sent: Tuesday, September 09, 2003 10:21 PM Subject: Re: [PD] system requirements video
I wonder how fast these two mainstream brands handle texture upload
on different OS'es.
It may not be very optimized in the driver since this operation is
rarely used during gameplay, but it's a potential bottleneck for video processing. I expect major performance differences here.
Did anyone compare nVidia vs ATI on different OS's on this aspect?
We actually have fairly extensive data on this.
Starting with OSX 10.2 all textures can be uploaded using DMA resulting in 0% CPU time for the transfer. Plus 10.2 can handle non-power-of-two texture sizes and YUV pixels for even more efficiency. This applies for both ATI Radeon (not Rage) and Nvidia Geforce hardware on OSX. Of course GEM fully supports these features. ;)
Windows does not feature any of these enhancements in it's standard OpenGL implementation, so significant CPU time can be spent handling the texture uploads. There might be some vendor specific extensions to enable fast texturing, but to my knowledge none of them have been implemented in GEM. Windows will be getting system wide support for using video as textures, unfortunately it will be for Direct3D and won't be released until 2005 or 2006 (as part of the Longhorn GDI).
Linux is closer to Windows than OSX as far as drivers go with Nvidia hardware, so you can expect similar texturing performance.
I can post measured performance data between Win32 and OSX GEM if you are interested.
cgc
j#|@
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 9 Septembre 2003 18:55, ben@ekran.org a écrit :
Anyhow have any suggestions on storing 2D data in PD?
With the "coll" object from the cyclone library. If you're familiar with Max, you probably already used it before.
the ideal would be to load a catDV or finalcut log file and extract the in and out points. This would be a simple parser...
Good idea! But I would do it on Linux with Kino and parse SMIL or ELI files. (Unless GEM for Linux doesn't support DV or other types of video files)
Marc
Hi Chris, Johannes, list
On 10/9/03 6:21 AM, "chris clepper" cgc@humboldtblvd.com wrote:
Starting with OSX 10.2 all textures can be uploaded using DMA resulting in 0% CPU time for the transfer. Plus 10.2 can handle non-power-of-two texture sizes and YUV pixels for even more efficiency. This applies for both ATI Radeon (not Rage) and Nvidia Geforce hardware on OSX. Of course GEM fully supports these features. ;)
Windows does not feature any of these enhancements in it's standard OpenGL implementation, so significant CPU time can be spent handling the texture uploads. There might be some vendor specific extensions to enable fast texturing, but to my knowledge none of them have been implemented in GEM.
Yes... Microsoft is try to get openGL to quietly rot on the PC. I've done some testing with nVidia's Pixel Data Range extension for Windows (which allow AGP texture transfers using asynchronous DMA) but (surprisingly) the performance improvements were not at all spectacular so I didn't implement them in GEM. This extension is also available for Linux when using recent nVidia drivers. http://oss.sgi.com/projects/ogl-sample/registry/NV/pixel_data_range.txt
I haven't seen reports from anyone (except nVidia) getting significant improvmements using that extension. It's probably time I played with it again though, as texture upload certainly is an enormous bottleneck for Gem...
Windows will be getting system wide support for using video as textures, unfortunately it will be for Direct3D and won't be released until 2005 or 2006 (as part of the Longhorn GDI).
I'm no windows zealot so I'm not going to start a platform battle... but DirectX 9 has the ability to "directly" use video as textures and indeed does so by default when building media graphs in DirectShow. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwmt/html/ vmr_d3d.asp
I don't believe that there are YUV texture formats but I think that AGP DMA transfer does get used... does anyone know more? It's hard to get this info out of DirectShow/DirectX.
Longhorn is supposed to bring Quartz-Extreme style "everything is a texture", "everything is done on the GPU" to replace the old GDI interface but video playback is already being done with the 3d pipeline.
Daniel
On Tue, 9 Sep 2003, IOhannes m zmoelnig wrote:
but i think, pdp has mmx support, so image-processing will be much faster. with gridflow i really don't know, but i guess you will have no hw-acceleration at all (but might have MMX also)
GridFlow has MMX support, but it doesn't do a very appreciable difference, maximum 30%, at least with my setup. Either I'm not well using MMX or I'm using the main CPU too well. =) Of course improving the MMX situation is on my TODO list, along with 666 other things.
Mathieu Bouchard http://artengine.ca/matju
-
ben＠ekran.org -
cgc＠humboldtblvd.com -
chris clepper
-
Daniel Heckenberg -
IOhannes m zmoelnig -
Johannes Taelman -
Marc Lavallée -
marius schebella -
Mathieu Bouchard -
patrick