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