Hi all, since i'm new to video (and will be so for a while...) i'd need a few hints from you pixel pros:
The project will be a long-term video installation of an analyzed video camera image which controls sound synthesis.
- which linux/PD/GEM etc. components would i need for video in and analysis?
- any experiences concerning long-term (several months) video and audio
stuff with PD under linux?
- which (cheap!) video-in device should be used?
many thanks, Thomas
On Tue, 18 Mar 2003, Thomas Grill wrote:
The project will be a long-term video installation of an analyzed video camera image which controls sound synthesis.
we've done that one...
- which linux/PD/GEM etc. components would i need for video in and analysis?
- any experiences concerning long-term (several months) video and audio
stuff with PD under linux?
i haven't done it with jMax instead of PD, but I think the experience is still relevant...
in Générique (http://www.pfoac.com/intro/artistes/ACe.html) we used GridFlow 0.4.0 in jMax 2.5.1. the only issue we've had is slight memory leaks... something like 16 or 32 bytes per frame... the system would crash after a week or so. I fixed those and then it ran continuously for two weeks (the rest of the show) and it could have run for much longer according to our extrapolations.
while it's important to run stable software, you cannot escape physical realities, eg. power outage. it's good practice to make it easy to restart the computer and the programs (we failed to do that on that occasion and we learned the hard way!).
- which (cheap!) video-in device should be used?
USB cameras are low-bandwidth and so can't accomodate big resolutions. Even if you get 240*320, then if it is YUV-4:2:0, then 2 out of 3 YUV color channels are encoded at 120*160 (!!!)
We like analog cameras. Find the right shop for buying those (probably not "consumer electronics" shops). Then use a capture card such as a PCI BTTV. You can get 480*640 @ 30 fps and such.
Mathieu Bouchard http://artengine.ca/matju
- which (cheap!) video-in device should be used?
USB cameras are low-bandwidth and so can't accomodate big resolutions. Even if you get 240*320, then if it is YUV-4:2:0, then 2 out of 3 YUV color channels are encoded at 120*160 (!!!)
actually using 4:2:0 chroma samples (Cb,Cr) are swapped every other line, so each chroma channel is effectively 160*60. 4:2:2 chroma is subsampled at a 2:1. this is really a trivial amount of data loss and you look at it everyday and never notice. DVD and PAL DV25 is 4:2:0, NTSC DV is 4:1:1, broadcast TV is 4:2:2 and so is HDTV. the Y is the really critical data as far as clarity goes. as long as the processing is 4:2:2 everything is usually ok.
We like analog cameras. Find the right shop for buying those (probably not "consumer electronics" shops). Then use a capture card such as a PCI BTTV. You can get 480*640 @ 30 fps and such.
yet another example of 4:2:2 ;)
cgc
On Tue, 18 Mar 2003, chris clepper wrote:
actually using 4:2:0 chroma samples (Cb,Cr) are swapped every other line, so each chroma channel is effectively 160*60. 4:2:2 chroma is subsampled at a 2:1. this is really a trivial amount of data loss and you look at it everyday and never notice. DVD and PAL DV25 is 4:2:0, NTSC DV is 4:1:1, broadcast TV is 4:2:2 and so is HDTV. the Y is the really critical data as far as clarity goes. as long as the processing is 4:2:2 everything is usually ok.
I thought I had understood the "4:2:0" notation, but now I'm completely confused. Do you have (a link to) a good explanation of it?
Mathieu Bouchard http://artengine.ca/matju
I thought I had understood the "4:2:0" notation, but now I'm completely confused. Do you have (a link to) a good explanation of it?
Here's a pretty good glossary of video terms: http://www.dvdmadeeasy.com/glossary/special.html
cgc
Le lun 24/03/2003 à 16:52, chris clepper a écrit :
I thought I had understood the "4:2:0" notation, but now I'm completely confused. Do you have (a link to) a good explanation of it?
Here's a pretty good glossary of video terms: http://www.dvdmadeeasy.com/glossary/special.html
And here's a technical reference: http://www.fourcc.org/fccyuv.htm
On Mon, 24 Mar 2003, chris clepper wrote:
I thought I had understood the "4:2:0" notation, but now I'm completely confused. Do you have (a link to) a good explanation of it?
Here's a pretty good glossary of video terms: http://www.dvdmadeeasy.com/glossary/special.html
Ok, according to that I had it right. if Y is 240*320, then U is 120*160 and V is 120*160. There's no 60*160 involved...
... unless you have interlacing as well (which I assume is *not* the case. I know incoming video is, but isn't that deinterlaced before the input card gives a frame ?)
Mathieu Bouchard http://artengine.ca/matju
Ok, according to that I had it right. if Y is 240*320, then U is 120*160 and V is 120*160. There's no 60*160 involved...
if both U and V are 1/2 the samples of Y then the format is 4:2:2. 4:2:0 looks like*:
row1 : YYUYYU row1 : YYVYYV row3 : YYUYYU row4 : YYVYYV
for every 4 Y samples there are two samples of U or V and they alternate every row. the 0 means that the U and V are both vertically and horizontally subsampled unlike 4:2:2 (YUYV) or 4:1:1 (YYUYYV), which are only horizontally subsampled. so effectively there are only 1/2 the vertical samples of U and V in 4:2:0. how those are reconciled into 4:2:2 is left to the decoding/decompression method. UV data can be either copied or averaged or some sort of interpolation can take place....
... unless you have interlacing as well (which I assume is *not* the case. I know incoming video is, but isn't that deinterlaced before the input card gives a frame ?)
if the incoming video is interlaced then the interlacing might always be a factor. depending on the computer format you are using for storage the fields could be kept intact rather than deinterlaced progressive images, a raw DV stream for example keeps the fields.
*the page Marc Lavallée linked to http://www.fourcc.org/fccyuv.htm lists the 4:2:0 formats as planar but that might not be the way 4:2:0 is actually stored in DV. anyone know for certain if DV stores packed or planar data? i'm fairly certain that it's packed. another link: http://www.dvcentral.org/DV-Beta.html
cgc
I modified those tools: http://www.ferzkopp.net/Software/libbgrab/ It's fairly easy to add the FUDI protocol to any C program. That what I did for this installation: http://beambeat.ath.cx/ I'm not the artist here, "only" the programmer... ;-) The motion detection application is based on "difftrigger". I prefer this approach to plugins because it's easier to program and modify C applications, and because it's stable. It's also easy to show a fullscreen application on a second monitor using a dual-head Xfree setup. -- Marc
Le mar 18/03/2003 à 04:30, Thomas Grill a écrit :
Hi all, since i'm new to video (and will be so for a while...) i'd need a few hints from you pixel pros:
The project will be a long-term video installation of an analyzed video camera image which controls sound synthesis.
- which linux/PD/GEM etc. components would i need for video in and analysis?
- any experiences concerning long-term (several months) video and audio
stuff with PD under linux?
- which (cheap!) video-in device should be used?
many thanks, Thomas
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
-
chris clepper -
Marc Lavallée -
Mathieu Bouchard -
Thomas Grill