Hi Using a PS3 eye on Mas osX 10.6 :
- with the macam program, out of PD, the response of the camera is
very fast,
- inside GEM, (pix_video) the latency is half a second, as much as
with DV camcorders.
I know this seems to be a recurring issue : Anyone has a way to get a quick response with pix_video in GEM OsX ? Any solution in pdp ? Is it necessary to switch to linux, DC cameras and complex drivers ? Any hint ? JmA
have you tried the latest cvs build of the macam driver?
http://sourceforge.net/projects/webcam-osx/files/
J
On Wed, Oct 13, 2010 at 2:38 AM, Jean-Marie Adrien <jma@jeanmarie-adrien.net
wrote:
Hi Using a PS3 eye on Mas osX 10.6 :
- with the macam program, out of PD, the response of the camera is very
fast,
- inside GEM, (pix_video) the latency is half a second, as much as with DV
camcorders.
I know this seems to be a recurring issue : Anyone has a way to get a quick response with pix_video in GEM OsX ? Any solution in pdp ? Is it necessary to switch to linux, DC cameras and complex drivers ? Any hint ? JmA
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
also, william got better results with rgba
On Wed, Oct 13, 2010 at 12:01 PM, Jaime Oliver jaime.oliver2@gmail.comwrote:
have you tried the latest cvs build of the macam driver?
http://sourceforge.net/projects/webcam-osx/files/
J
On Wed, Oct 13, 2010 at 2:38 AM, Jean-Marie Adrien < jma@jeanmarie-adrien.net> wrote:
Hi Using a PS3 eye on Mas osX 10.6 :
- with the macam program, out of PD, the response of the camera is very
fast,
- inside GEM, (pix_video) the latency is half a second, as much as with DV
camcorders.
I know this seems to be a recurring issue : Anyone has a way to get a quick response with pix_video in GEM OsX ? Any solution in pdp ? Is it necessary to switch to linux, DC cameras and complex drivers ? Any hint ? JmA
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Jaime E Oliver LR
www.jaimeoliver.pe
858 750 0924 (cel) 858 202 1522 (home)
Native color space will always be faster since it avoids a conversion step. A lot of webcams and industrial cams are RGB based. Video cameras are all YUV.
On Wed, Oct 13, 2010 at 3:02 PM, Jaime Oliver jaime.oliver2@gmail.comwrote:
also, william got better results with rgba
On Wed, Oct 13, 2010 at 12:01 PM, Jaime Oliver jaime.oliver2@gmail.comwrote:
have you tried the latest cvs build of the macam driver?
http://sourceforge.net/projects/webcam-osx/files/
J
On Wed, Oct 13, 2010 at 2:38 AM, Jean-Marie Adrien < jma@jeanmarie-adrien.net> wrote:
Hi Using a PS3 eye on Mas osX 10.6 :
- with the macam program, out of PD, the response of the camera is very
fast,
- inside GEM, (pix_video) the latency is half a second, as much as with
DV camcorders.
I know this seems to be a recurring issue : Anyone has a way to get a quick response with pix_video in GEM OsX ? Any solution in pdp ? Is it necessary to switch to linux, DC cameras and complex drivers ? Any hint ? JmA
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Jaime E Oliver LR
www.jaimeoliver.pe
858 750 0924 (cel) 858 202 1522 (home)
-- Jaime E Oliver LR
www.jaimeoliver.pe
858 750 0924 (cel) 858 202 1522 (home)
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi chris
Im glad you jumped in. Concerning the topic would the following
theory make sense ?
it seems that video capture and video tracking do not adress the same
purposes :
- video capture allows 10 frames of latency to ensure that frame
transfer is correct to the machine for later uses (post production,
montage). This is the major usage now of video, because of DV
camescopes and so on.
- whereas video tracking requires 1 frame of latency maximum, to
produce real time responses. This is a emergent need, that seems to
be covered by other softwares.
Im trying to crawl to the second point.
For instance, in pidip, it seems that there is a IE1394 object that
processes DV type signals with a long latency, like pix_video does in
GEM, and there is another object pdp_DC1394, that would be quicker,
and could thus interface DC uncompressed industrial cameras without
sticking them into the DVlike process, on Linux at least.
Does this make sense ? Any DC pix_video object in GEM on MAC with 1 frame of latency ? DC1394 available on MAC or only on LINUX ?
sorry for the verbose cheers JMA
Le 13 oct. 10 à 22:56, chris clepper a écrit :
Native color space will always be faster since it avoids a
conversion step. A lot of webcams and industrial cams are RGB
based. Video cameras are all YUV.On Wed, Oct 13, 2010 at 3:02 PM, Jaime Oliver
jaime.oliver2@gmail.com wrote: also, william got better results with rgbaOn Wed, Oct 13, 2010 at 12:01 PM, Jaime Oliver
jaime.oliver2@gmail.com wrote: have you tried the latest cvs build of the macam driver?http://sourceforge.net/projects/webcam-osx/files/
J
On Wed, Oct 13, 2010 at 2:38 AM, Jean-Marie Adrien <jma@jeanmarie- adrien.net> wrote: Hi Using a PS3 eye on Mas osX 10.6 :
- with the macam program, out of PD, the response of the camera is
very fast,
- inside GEM, (pix_video) the latency is half a second, as much as
with DV camcorders.
I know this seems to be a recurring issue : Anyone has a way to get a quick response with pix_video in GEM OsX ? Any solution in pdp ? Is it necessary to switch to linux, DC cameras and complex drivers ? Any hint ? JmA
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
-- Jaime E Oliver LR
www.jaimeoliver.pe
858 750 0924 (cel) 858 202 1522 (home)
-- Jaime E Oliver LR
www.jaimeoliver.pe
858 750 0924 (cel) 858 202 1522 (home)
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
On 2010-10-14 10:09, Jean-Marie Adrien wrote:
Hi chris Im glad you jumped in. Concerning the topic would the following theory make sense ?
it seems that video capture and video tracking do not adress the same purposes :
- video capture allows 10 frames of latency to ensure that frame
transfer is correct to the machine for later uses (post production, montage). This is the major usage now of video, because of DV camescopes and so on.
- whereas video tracking requires 1 frame of latency maximum, to produce
which of course is not true at all. it's like saying that audio capture for use with real time processing requires a latency of 1 sample.
real time responses. This is a emergent need, that seems to be covered by other softwares.
1 frame can be quite long, whereas 10 frames can be way shorter.
Im trying to crawl to the second point. For instance, in pidip, it seems that there is a IE1394 object that processes DV type signals with a long latency, like pix_video does in GEM, and there is another object pdp_DC1394, that would be quicker, and could thus interface DC uncompressed industrial cameras without sticking them into the DVlike process, on Linux at least.
Does this make sense ?
in Gem you don't have different objects for different grabbing APIs. e.g. you would use [pix_video] for grabbing from your dv1394 consumer camera, from your analog capture card and from IDC.
Any DC pix_video object in GEM on MAC with 1 frame of latency ? DC1394 available on MAC or only on LINUX ?
on OSX, Gem uses QuickTime for about everything concerned with image acquisition (thus all the problems with OSX10.6). so on OSX this means: if QuickTime provides support for IIDC, then you get IIDC in Gem; if QuickTime does not support GiG-E, then you don't have GiG-E in Gem
on linux there is no grand unified image acquisition API, so there are a number of different backends for the various APIs (thus: Gem has explicit support for GiG-E and IIDC cameras on linux; it only has implicit support (if at all) for those cameras on OSX)
and finally: the old rule-of-thumb was, that you get the best latency with analog grabber cards you put into your PCI/express slot.
fgmsdr IOhannes
Iohannes Thanks a lot for the bright info. 1 frame versus 10 frames latency was meant as 40ms versus 500ms latency at 25fps. 40ms is already long for musical instrument real time feeback, and 500ms is the huge latency of the wiener philharmoniker ! (conductor speaking). Would you recommand a specific analog grabber card that works fine with Mac ? JmAdrien
Le 14 oct. 2010 à 10:45, IOhannes m zmoelnig zmoelnig@iem.at a écrit :
On 2010-10-14 10:09, Jean-Marie Adrien wrote:
Hi chris Im glad you jumped in. Concerning the topic would the following theory make sense ?
it seems that video capture and video tracking do not adress the same purposes :
- video capture allows 10 frames of latency to ensure that frame
transfer is correct to the machine for later uses (post production, montage). This is the major usage now of video, because of DV camescopes and so on.
- whereas video tracking requires 1 frame of latency maximum, to produce
which of course is not true at all. it's like saying that audio capture for use with real time processing requires a latency of 1 sample.
real time responses. This is a emergent need, that seems to be covered by other softwares.
1 frame can be quite long, whereas 10 frames can be way shorter.
Im trying to crawl to the second point. For instance, in pidip, it seems that there is a IE1394 object that processes DV type signals with a long latency, like pix_video does in GEM, and there is another object pdp_DC1394, that would be quicker, and could thus interface DC uncompressed industrial cameras without sticking them into the DVlike process, on Linux at least.
Does this make sense ?
in Gem you don't have different objects for different grabbing APIs. e.g. you would use [pix_video] for grabbing from your dv1394 consumer camera, from your analog capture card and from IDC.
Any DC pix_video object in GEM on MAC with 1 frame of latency ? DC1394 available on MAC or only on LINUX ?
on OSX, Gem uses QuickTime for about everything concerned with image acquisition (thus all the problems with OSX10.6). so on OSX this means: if QuickTime provides support for IIDC, then you get IIDC in Gem; if QuickTime does not support GiG-E, then you don't have GiG-E in Gem
on linux there is no grand unified image acquisition API, so there are a number of different backends for the various APIs (thus: Gem has explicit support for GiG-E and IIDC cameras on linux; it only has implicit support (if at all) for those cameras on OSX)
and finally: the old rule-of-thumb was, that you get the best latency with analog grabber cards you put into your PCI/express slot.
fgmsdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2010-10-14 12:38, Jma/celeonet wrote:
Iohannes Thanks a lot for the bright info. 1 frame versus 10 frames latency was meant as 40ms versus 500ms latency at 25fps. 40ms is already long for musical instrument real time feeback, and 500ms is the huge latency of the wiener philharmoniker ! (conductor speaking).
in this case, i would talk about ms rather than frames.
Would you recommand a specific analog grabber card that works fine with Mac ?
no idea. i have been using bttv/connexant based grabber cards very successfully on linux and w32.
fgmasdr IOhannes
Would you recommand a specific analog grabber card that works fine with Mac ?
no idea. i have been using bttv/connexant based grabber cards very successfully on linux and w32.
still DC camera ( like Unibrain camera ) give uncompressed signal, so they have very low latency...
these cameras are supported generally on Mac OSX through quicktime ( with pix_video or pdp_ieee1394 that uses quicktime too ).
on linux, cameras are supported by different APIs and thus different objects ( pdp_ieee1394, pdp_v4l, pdp_v4l2 or pdp_dc1394 ) depending on your type of cameras....
and there is nothing like video for capture and video for real-time, the driver acts exactly the same whatever is your purpose.. ( how can a driver knows what you want to do of the video hey ? )
ciao, sevy
fgmasdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, Oct 14, 2010 at 1:30 PM, ydegoyon@gmail.com ydegoyon@gmail.comwrote:
still DC camera ( like Unibrain camera ) give uncompressed signal,
so they have very low latency...
these cameras are supported generally on Mac OSX through quicktime ( with pix_video or pdp_ieee1394 that uses quicktime too ).
on linux, cameras are supported by different APIs and thus different objects ( pdp_ieee1394, pdp_v4l, pdp_v4l2 or pdp_dc1394 ) depending on your type of cameras....
Hi Yves and list, I didn't know anything about pdp_dc1394. I'm on ubuntu lucid (10.4) and pd-extended 0.42 and the object doesn't exist. Should I compile pdp in order to get this object? When I worked with IIDC camera on linux and pd (a unibrain one) I used coriander to get it as a standard v4l device (by using vloopback module), and it worked like a charm! But maybe I should try pdp_dc1394 (if I found it!) cheers husk
Husk 00 wrote:
On Thu, Oct 14, 2010 at 1:30 PM, ydegoyon@gmail.com mailto:ydegoyon@gmail.com <ydegoyon@gmail.com mailto:ydegoyon@gmail.com> wrote:
still DC camera ( like Unibrain camera ) give uncompressed signal, so they have very low latency... these cameras are supported generally on Mac OSX through quicktime ( with pix_video or pdp_ieee1394 that uses quicktime too ). on linux, cameras are supported by different APIs and thus different objects ( pdp_ieee1394, pdp_v4l, pdp_v4l2 or pdp_dc1394 ) depending on your type of cameras....Hi Yves and list, I didn't know anything about pdp_dc1394. I'm on ubuntu lucid (10.4) and pd-extended 0.42 and the object doesn't exist. Should I compile pdp in order to get this object? When I worked with IIDC camera on linux and pd (a unibrain one) I used coriander to get it as a standard v4l device (by using vloopback module), and it worked like a charm! But maybe I should try pdp_dc1394 (if I found it!) cheers husk
ola,
yes it's not compiled in pd-extended, you have to get pidip sources and install libdc1394-22-dev.. and then compile pidip.
this is something lluis did recently that was never included in pd-extended.. neither in pure:dyne packages.
ciao, sevy
-- when Art become pratical we call it technology.
When Technology become useless we call it Art
www.estereotips.net http://www.estereotips.net
On Thu, Oct 14, 2010 at 1:53 PM, ydegoyon@gmail.com ydegoyon@gmail.comwrote:
ola,
yes it's not compiled in pd-extended, you have to get pidip sources and install libdc1394-22-dev.. and then compile pidip.
this is something lluis did recently that was never included in pd-extended.. neither in pure:dyne packages.
ciao, sevy
Good to know, thanks! husk
--
when Art become pratical we call it technology.
When Technology become useless we call it Art
www.estereotips.net http://www.estereotips.net
if it helps...
I have now used the ps3eye in Linux with multiple machines and really excellent results with low latency in Gem and pdp/pidip. Yes you do have to compile the driver for it but it really isn't too bad. I posted directions for how I do this at:
http://bear24rw.blogspot.com/2009/11/ps3-eye-driver-patch.html
http://bear24rw.blogspot.com/2009/11/ps3-eye-driver-patch.htmlin my comment dated May 9, 2010. I can confirm that this works with the last few versions of ubuntu at least. Just did it again for another machine last week even. Doesn't seem to be any complications with the compile process once you have the steps down.
-john
On Thu, Oct 14, 2010 at 6:54 AM, Husk 00 husk00@gmail.com wrote:
On Thu, Oct 14, 2010 at 1:53 PM, ydegoyon@gmail.com ydegoyon@gmail.comwrote:
ola,
yes it's not compiled in pd-extended, you have to get pidip sources and install libdc1394-22-dev.. and then compile pidip.
this is something lluis did recently that was never included in pd-extended.. neither in pure:dyne packages.
ciao, sevy
Good to know, thanks! husk
--
when Art become pratical we call it technology.
When Technology become useless we call it Art
www.estereotips.net http://www.estereotips.net
-- when Art become pratical we call it technology.
When Technology become useless we call it Art
www.estereotips.net
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2010-10-14 12:38, Jma/celeonet wrote:
Would you recommand a specific analog grabber card that works fine with Mac ?
A few years ago exactly the same issue led me to finally switch to Linux. At that time it seemed that I couldn't do what you want to do on a Mac. I don't imagine the situation has changed much, good frame-grabbers are used in industrial control and other specialised applications, and that certainly is not Apple territory.
Maybe there are other usb or firewire options available now with enough quality and reasonable latency. The latency you speak of is specific to DV, as you say it is a protocol designed for reliable transfer from camera/tape to computer .. this was very important to Apple and Sony at the time.
Note the sample rate of video is the frame rate. Unless you go for rather expensive very high frame-rate capture devices, which are certainly available, the camera will only be capturing each pixel every 40ms, and even if you processed that information line by line it would be difficult to get any reasonable analysis before a whole frame was present. This leads to unavoidable latencies much longer than audio ones.
Simon
On Thu, Oct 14, 2010 at 6:38 AM, Jma/celeonet jma@jeanmarie-adrien.netwrote:
Would you recommand a specific analog grabber card that works fine with Mac ? JmAdrien
Does SD and HD analog capture and looks great. I had pretty low latency with them as well. Plus, multiple ones can be installed in a MacPro.
I used a lot of industrial cams at one point and gave them up because they looked awful compared to very cheap consumer gear. The equivalent of a $600 HDV cam and Blackmagic Intensity in the IIDC world would cost at least 10x. And there is no IIDC cam that would even approach the image of what a Canon 5d into the Intensity would give you.
Yeah, I was just asking Jaime about this last week. Setting color to RGBA made it go from unusable to perfect on my 10.6 Pd vanilla setup.
On Wed, Oct 13, 2010 at 3:02 PM, Jaime Oliver jaime.oliver2@gmail.com wrote:
also, william got better results with rgba
On Wed, Oct 13, 2010 at 12:01 PM, Jaime Oliver jaime.oliver2@gmail.com wrote:
have you tried the latest cvs build of the macam driver?
http://sourceforge.net/projects/webcam-osx/files/
J
On Wed, Oct 13, 2010 at 2:38 AM, Jean-Marie Adrien jma@jeanmarie-adrien.net wrote:
Hi Using a PS3 eye on Mas osX 10.6 :
- with the macam program, out of PD, the response of the camera is very
fast,
- inside GEM, (pix_video) the latency is half a second, as much as with
DV camcorders.
I know this seems to be a recurring issue : Anyone has a way to get a quick response with pix_video in GEM OsX ? Any solution in pdp ? Is it necessary to switch to linux, DC cameras and complex drivers ? Any hint ? JmA
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Jaime E Oliver LR
www.jaimeoliver.pe
858 750 0924 (cel) 858 202 1522 (home)
-- Jaime E Oliver LR
www.jaimeoliver.pe
858 750 0924 (cel) 858 202 1522 (home)
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
chris clepper -
Husk 00 -
IOhannes m zmoelnig -
Jaime Oliver -
Jean-Marie Adrien -
Jma/celeonet
-
John Harrison -
Simon Wise -
William Brent -
ydegoyon＠gmail.com