algorithmic@gmx.at

who knows the very very very best hardware solution to get the lowest video latency possible? i have the newest mac-pro machine...

i read everything about uncompressed firewire devices... is there any faster solution, pci or something else?

how can i improve the latency in jitter beside the hardware problem? i simply use jit.gt.grab...

who knows the very very very best hardware solution to get the lowest video latency possible? i have the newest mac-pro machine... 

i read everything about uncompressed firewire devices... is there any faster solution, pci or something else? 

how can i improve the latency in jitter beside the hardware problem? i simply use jit.gt.grab... 

analog-video-input-hardware

Quote: algorithmic@gmx.at wrote on Fri, 04 April 2008 16:30

----------------------------------------------------

> who knows the very very very best hardware solution to get the lowest video latency possible? i have the newest mac-pro machine... 

> i read everything about uncompressed firewire devices... is there any faster solution, pci or something else? 

> how can i improve the latency in jitter beside the hardware problem? i simply use jit.gt.grab... 

Good question. The lowest I got was by plugging a DV camera directly into the computer with a firewire cable, but that's still about 4 frames delay. When using an ADVC-100 the delay increases to about 8.

They say an uncompressed firewire camera should do better. Is that true?

I don't think the latency in Jitter is a problem as long as the low priority thread doesn't take 100% cpu (note: that'll look like 25% per processor on a quad-core machine).

Quote: algorithmic@gmx.at wrote on Fri, 04 April 2008 16:30
----------------------------------------------------
> who knows the very very very best hardware solution to get the lowest video latency possible? i have the newest mac-pro machine... 
>
> i read everything about uncompressed firewire devices... is there any faster solution, pci or something else? 
>
> how can i improve the latency in jitter beside the hardware problem? i simply use jit.gt.grab... 
>
> thanks!
----------------------------------------------------

https://cycling74.com/twiki/bin/view/FAQs/JitterCameras#Do_you_recommend_specific_video

they say nothing about latency on pci hardware...

read this, but it is about one year old:
https://cycling74.com/twiki/bin/view/FAQs/JitterCameras#Do_you_recommend_specific_video

they say nothing about latency on pci hardware...


Quote: algorithmic@gmx.at wrote on Fri, 04 April 2008 17:05

> read this, but it is about one year old:

> they say nothing about latency on pci hardware... 

Hey, thanks for that! Man, how many times did this forum save our little company an R&D division!

Seems like we're getting ourselves a dfg13941e very soon. Btw, it has two composite inputs. Does that mean it supports two cameras simultaneously?

Quote: algorithmic@gmx.at wrote on Fri, 04 April 2008 17:05
----------------------------------------------------
> read this, but it is about one year old:
> https://cycling74.com/twiki/bin/view/FAQs/JitterCameras#Do_you_recommend_specific_video
>
> they say nothing about latency on pci hardware... 
>
----------------------------------------------------

Playing with the dgf13941e now. I did some more accurate latency measurements:

Direct firewire cable from camera: 170 ms

So my conclusion is that the fastest way currently available to get video into a computer still has a 3,5 frames latency. If someone had a different experience I'd love to know.

Quote: Mattijs wrote on Fri, 04 April 2008 17:36

> Quote: algorithmic@gmx.at wrote on Fri, 04 April 2008 17:05

> ----------------------------------------------------

> > read this, but it is about one year old:

> > they say nothing about latency on pci hardware... 

> Hey, thanks for that! Man, how many times did this forum save our little company an R&D division!

> Seems like we're getting ourselves a dfg13941e very soon. Btw, it has two composite inputs. Does that mean it supports two cameras simultaneously?

ADVC-100: 200 ms
Direct firewire cable from camera: 170 ms
DFG/1394 1e: 140 ms

Quote: Mattijs wrote on Fri, 04 April 2008 17:36
----------------------------------------------------
> Quote: algorithmic@gmx.at wrote on Fri, 04 April 2008 17:05
> ----------------------------------------------------
> > read this, but it is about one year old:
> > https://cycling74.com/twiki/bin/view/FAQs/JitterCameras#Do_you_recommend_specific_video
> >
> > they say nothing about latency on pci hardware... 
> >
> ----------------------------------------------------
>
> Hey, thanks for that! Man, how many times did this forum save our little company an R&D division!
>
> Seems like we're getting ourselves a dfg13941e very soon. Btw, it has two composite inputs. Does that mean it supports two cameras simultaneously?
>
> Mattijs
----------------------------------------------------


it's so strange, i got so many different information about the dfg. one guy said that he has a 25ms delay only. how is that possible?

140ms seems to be very slow! with which resolution did you test it? 720x576?

140ms seems to be very slow! with which resolution did you test it? 720x576?
which computer/hardware do you use???

Update: when checking 'use small number of internal buffers' in the settings, the latency of the dfg13941e goes down to 80 ms.

Quote: algorithmic@gmx.at wrote on Mon, 14 April 2008 13:01

> it's so strange, i got so many different information about the dfg. one guy said that he has a 25ms delay only. how is that possible?

On this forum they seem to have done quite some thorough testing:

http://www.vidvox.net/phpBB2/viewtopic.php?t=1942&sid=7ba19a3ec88c231150da463248a548d8

There they never get lower than 2 frames (80 ms) so I guess 25 ms is a bit too optimistic. But I must say I'm pretty impressed by 80 ms..

That's at 720x576 on a MacPro 4 x 2.66 GHz

> 140ms seems to be very slow! with which resolution did you test it? 720x576?

Quote: algorithmic@gmx.at wrote on Mon, 14 April 2008 13:01
----------------------------------------------------
> hi mattijs!
>
> it's so strange, i got so many different information about the dfg. one guy said that he has a 25ms delay only. how is that possible?

On this forum they seem to have done quite some thorough testing:
http://www.vidvox.net/phpBB2/viewtopic.php?t=1942&sid=7ba19a3ec88c231150da463248a548d8

>
> 140ms seems to be very slow! with which resolution did you test it? 720x576?
> which computer/hardware do you use???
>
> thanks!
> philipp
----------------------------------------------------


what do you think about the latency of 80ms regarding lip-syncronisation? is it acceptable?? that's actually the most important for me. 

and one more question: is there a better latency only using 640x480? 

what do you think about the latency of 80ms regarding lip-syncronisation? is it acceptable?? that's actually the most important for me. 
and one more question: is there a better latency only using 640x480? 
thanks!


Quote: algorithmic@gmx.at wrote on Mon, 14 April 2008 13:38

> what do you think about the latency of 80ms regarding lip-syncronisation? is it acceptable??

For lip-synchronization I think this is acceptable. See for example this pretty top-notch 'professional' (or at least expensive) solution I worked with on big media events, 

http://www.vistasystems.net/what_is_spyder/features.asp,

 the latency is not much smaller. And I must say from how it looks I don't really believe this specification.

> and one more question: is there a better latency only using 640x480?

No, I don't see a difference, same for 320 x 240. But I think the jit.qt.grab arguments don't really affect the digitizer, just the resolution at which the object outputs its matrix (am I right?).

Quote: algorithmic@gmx.at wrote on Mon, 14 April 2008 13:38
----------------------------------------------------
> what do you think about the latency of 80ms regarding lip-syncronisation? is it acceptable?? 

For lip-synchronization I think this is acceptable. See for example this pretty top-notch 'professional' (or at least expensive) solution I worked with on big media events, http://www.vistasystems.net/what_is_spyder/features.asp, the latency is not much smaller. And I must say from how it looks I don't really believe this specification.

> and one more question: is there a better latency only using 640x480? 

I have one more question for the experts: did someone manage to connect multiple dfg/1394's (with multiple jit.qt.grab objects)?

When I have two copies of jit.qt.grab (but only one dfg), the second one won't output any info when I send it the getinputlist command. This looks like it's not supported to have two jit.qt.grabs, or at least not with only one device.

I have one more question for the experts: did someone manage to connect multiple dfg/1394's (with multiple jit.qt.grab objects)? 

the box essentially functions like a camera in that it is only addressable by a single grab - 

it only processes from a single port - it just allows you to switch in software which port you want to get data from

Subject: [jitter] Re: analog video input hardware

the box essentially functions like a camera  in that it is only addressable by a single grab - 
it only processes from a single port  - it just allows you to switch in software which port you want to get data from

----- Original Message ----
From: Mattijs Kneppers 
Sent: Monday, April 14, 2008 8:48:56 AM
Subject: [jitter] Re: analog video input hardware

Quote: jamie jewett wrote on Mon, 14 April 2008 20:29

> the box essentially functions like a camera in that it is only addressable by a single grab - 

> it only processes from a single port - it just allows you to switch in software which port you want to get data from

Quote: jamie jewett wrote on Mon, 14 April 2008 20:29
----------------------------------------------------
> I use 2 boxes and 2 grabs - 
>
> the box essentially functions like a camera  in that it is only addressable by a single grab - 
> it only processes from a single port  - it just allows you to switch in software which port you want to get data from
>
> best
> jamie
>


are you happy with your dfg..? i read some posts about interlacing problems using it with 640x480 or 720x576 pal resolution. do you have the same problem? if yes - do you know how solve it?

hi mattjes,
are you happy with your dfg..? i read some posts about interlacing problems using it with 640x480 or 720x576 pal resolution. do you have the same problem? if yes - do you know how solve it?
thanks!


Quote: algorithmic@gmx.at wrote on Fri, 18 April 2008 17:10

> are you happy with your dfg..? i read some posts about interlacing problems using it with 640x480 or 720x576 pal resolution. do you have the same problem? if yes - do you know how solve it?

No more interlacing problems after I found out that it has a built-in feature to throw away odd or even fields, accessible in the screen that opens up after you send the grab object the 'settings' message.

One slight problem is that jitter doesn't support to store these settings in any way. So you'll have to set them manually each time you open the device. But his problem is not specific for the dfg of course, it's a jitter thing.

One more thing to know about the dfg is that you'll need to purchase the mac os driver separately ($50) from a separate company (ASC). I sent a mail asking whether it was possible to install the driver on multiple computers and I got a fast and neat reply:

Yes it's possible. The unlock key is for each DFG, not each Mac.

So you only need one license for each DFG you want to use. Then you can copy the unlock key to any Mac you want and the DFG will be unlocked on it too.

Quote: algorithmic@gmx.at wrote on Fri, 18 April 2008 17:10
----------------------------------------------------
> hi mattjes,
> are you happy with your dfg..? i read some posts about interlacing problems using it with 640x480 or 720x576 pal resolution. do you have the same problem? if yes - do you know how solve it?
> thanks!
----------------------------------------------------

Yes it's possible. The  unlock key is for each DFG, not each Mac.

So you only need one license for each DFG you want to use. Then you can copy the unlock key to any Mac you want and the DFG will be unlocked on it too.
------

thanks so much for you help! i just ordered one :)

Ive written a de-interlace shader as well, which de-interlaces on the 

Ive used/tested it with 1080i input with the Intensity card and it 

works just fine, although If you *really* look careful I think i have 

a slightly off by one issue where I move the image down a pixel, but 

its barely noticeable and looks better than interlacing artifacts imo.

On Apr 18, 2008, at 11:46 AM, expjektor wrote:

> thanks so much for you help! i just ordered one :)

Ive written a de-interlace shader as well, which de-interlaces on the  
GPU:

Ive used/tested it with 1080i input with the Intensity card and it  
works just fine, although If you *really* look careful I think i have  
a slightly off by one issue where I move the image down a pixel, but  
its barely noticeable and looks better than interlacing artifacts imo.

>
> thanks so much for you help! i just ordered one :)


have you tested the latency of the Intensity card ?

i am very interested in this information :-)

have you tested the latency of the Intensity card ?
i am very interested in this information :-)

http://createdigitalmotion.com/2007/05/08/real-time-uncompressed-hd-mixing-on-the-cheap-with-decklink-intensity/

last I checked, around 3 to 5 frames, or 100 - 166ms~

On Apr 18, 2008, at 6:15 PM, videomasta wrote:

> have you tested the latency of the Intensity card ?

> i am very interested in this information :-)

>
> hey vade,
>
> have you tested the latency of the Intensity card ?
> i am very interested in this information :-)
>
> thanx in advance


got my brandnew DFG today... so far so good. but how do you reach the 80ms latency?? i just tested it and the latency is about 120ms. i also checked the "use small number of internal buffer box" but it doesn't change anything. 

could you tell me the exact setting you use please? tips and tricks?

hi mattjes
got my brandnew DFG today... so far so good. but how do you reach the 80ms latency?? i just tested it and the latency is about 120ms. i also checked the "use small number of internal buffer box" but it doesn't change anything. 
could you tell me the exact setting you use please? tips and tricks?
thanks in advance,
philipp.


Quote: algorithmic@gmx.at wrote on Mon, 28 April 2008 17:10

> got my brandnew DFG today... so far so good. but how do you reach the 80ms latency?? i just tested it and the latency is about 120ms. i also checked the "use small number of internal buffer box" but it doesn't change anything. 

> could you tell me the exact setting you use please? tips and tricks?

Hi philipp, how did you test the latency?

Quote: algorithmic@gmx.at wrote on Mon, 28 April 2008 17:10
----------------------------------------------------
> hi mattjes
> got my brandnew DFG today... so far so good. but how do you reach the 80ms latency?? i just tested it and the latency is about 120ms. i also checked the "use small number of internal buffer box" but it doesn't change anything. 
> could you tell me the exact setting you use please? tips and tricks?
> thanks in advance,
> philipp.
----------------------------------------------------

i connected the analog (svhs) output of a g4 powerbook to the dfg on a macbookpro running max/jitter jit.grab... on the powerbook runs a small patch in max/jitter playing a qtvideo sending it to the svhs output via jit.window. i also put a jit.matrixset delay to simulate the dfg-latency on this patch. so i just compare the dfg's input on the macbookpro's jit.grab with the simulated delay on the powerbook. with 2 frames (80ms) on the jit.matrixset delay patch i can still see a delay, then with 3 frames seem to be simultaneously...

do you think this testing method is not accurate? :)

the strange thing is that i cannot really recognize a difference between my old sony dv-cam and the dfg, maybe 1 frame only...

ok,
i connected the analog (svhs) output of a g4 powerbook to the dfg on a macbookpro running max/jitter jit.grab... on the powerbook runs a small patch in max/jitter playing a qtvideo sending it to the svhs output via jit.window. i also put a jit.matrixset delay to simulate the dfg-latency on this patch. so i just compare the dfg's input on the macbookpro's jit.grab with the simulated delay on the powerbook. with 2 frames (80ms) on the jit.matrixset delay patch i can still see a delay, then with 3 frames seem to be simultaneously...
do you think this testing method is not accurate? :)

hey everybody who's interested in latency times!

finally i tested several videoboards and i think that i found the best solution for realtime live camera input - and that's in my oppinion the only acceptable solution regarding lip-synchronisation: 

the "blackmagic decklink intensity pro card" has definitely the lowest latency with about 60ms when using just normal SD material (720x576 PAL). (but note that the latency is increasing using hd source, about 160-180ms.)

the "dfg1394" firewire box with its 100-120ms latency was NOT convincing!!

for everyone who uses a PC and a camera with an SDI output, check this: 

http://www.dvs.de/de/produkte/video-boards/centaurus-ii-lt.html

those cards are very expensive (about 4000 euro) but should have a latency of only 40ms.

finally i tested several videoboards and i think that i found the best solution for realtime live camera input - and that's in my oppinion the only acceptable solution regarding lip-synchronisation: 
the "blackmagic decklink intensity pro card" has definitely the lowest latency with about 60ms when using just normal SD material (720x576 PAL). (but note that the latency is increasing using hd source, about 160-180ms.)
the "dfg1394" firewire box with its 100-120ms latency was NOT convincing!! 

for everyone who uses a PC and a camera with an SDI output, check this: 
http://www.dvs.de/de/produkte/video-boards/centaurus-ii-lt.html
those cards are very expensive (about 4000 euro) but should have a latency of only 40ms.

But when it comes to laptops, the DFG seems to be the best solution.

By the way, ever tried the Miglia Alchemy pci card? I don't think they make it anymore, but it's cheap. Not sure about performance though...

> By the way, ever tried the Miglia Alchemy pci card? I don't think 

> they make it anymore, but it's cheap. Not sure about performance 

It worked great on the G5 (except the quad, which had PCI-express). 

There's just one thing that I remember is that you needed to enter the 

serial number in order to make it work, otherwise it would output a 

> By the way, ever tried the Miglia Alchemy pci card? I don't think  
> they make it anymore, but it's cheap. Not sure about performance  
> though...

It worked great on the G5 (except the quad, which had PCI-express).  
There's just one thing that I remember is that you needed to enter the  
serial number in order to make it work, otherwise it would output a  
green image after a few minutes.

I've been using the DFG for quite some time. I discovered that if you use a "real" analog camera (such as an 8mm camcorder) as opposed to using the analog output of a digital camera performance improves substatially. Go figure why...

Using grayscale will also improve speed. I mainly do motion tracking, so color is not a necessity.

Just started using a Canopus advc55 and having trouble initializing jit.grab.

The Canopus doesn't seem to recognized, only the isight?

Jit.grab sees my Canon Xl1 no problem, any hints?

Hello, 
Just started using a Canopus advc55 and having trouble initializing jit.grab.
The Canopus doesn't seem to recognized, only the isight?
Jit.grab sees my Canon Xl1 no problem, any hints?
Macbook Pro 2.33, max 4.6 and 5.
All the best,
Stuart

----- Original Message ----
From: qfwfqduo 
Sent: Thursday, May 1, 2008 10:18:58 PM
Subject: [jitter] Re: analog video input hardware

Using grayscale will also improve speed. I mainly do motion tracking, so color is not a necessity. 

Quote: vade wrote on Fri, 18 April 2008 23:23

> Ive written a de-interlace shader as well, which de-interlaces on the 

Hi vade, I'm curious what your shader does. Unfortunately it doesn't show up on the forum. Could you perhaps send it again in a zip?

Quote: vade wrote on Fri, 18 April 2008 23:23
----------------------------------------------------
> Ive written a de-interlace shader as well, which de-interlaces on the  
> GPU:
>
>
>

https://cycling74.com/pipermail/jitter/2008-April/014851.html

Quote: robtherich wrote on Wed, 07 May 2008 19:43

Quote: robtherich wrote on Wed, 07 May 2008 19:43
----------------------------------------------------
> https://cycling74.com/pipermail/jitter/2008-April/014851.html
----------------------------------------------------

anybody use an intensity blackmagic capture card on a Windows machine. Curious on the setup used and card performance. These things look nice!

anybody use an intensity blackmagic capture card on a Windows machine.  Curious on the setup used and card performance.  These things look nice!

About using two DFG's: I would be interested to know at what resolution you use them. As far as I can see it's not possible to use two DFG's at 720x576 with YUV color mode on one firewire bus.

Using indexed color mode though, two of them should be able to get to work simultaneously at this resolution. Did you try this?

I don't have two DFG's yet (but I will in a few days). Right now I'm trying with one DFG and one Canopus ADVC-100. That works fine at 360x288 but at 720x576, the DFG's grab gives an incomprehensible error (error: jit.qt.grab: error -536870181 setting vdig compression type) when I try to open it, even if the ADVC is not active but just connected.

Changing DFG settings (such as switching to indexed mode) has no effect when the grab is at 720 x 576 and an ADVC-100 is connected (but not active). The DFG's grab simply won't output any image. I hope this will be different when my second digitizer is not a ADVC-100 but also a DFG.

> Sent: Monday, April 14, 2008 8:48:56 AM

> Subject: [jitter] Re: analog video input hardware

> I have one more question for the experts: did someone manage to connect multiple dfg/1394's (with multiple jit.qt.grab objects)? 

> When I have two copies of jit.qt.grab (but only one dfg), the second one won't output any info when I send it the getinputlist command. This looks like it's not supported to have two jit.qt.grabs, or at least not with only one device.

Using indexed color mode though, two of them should be able to get to work simultaneously at this resolution. Did you try this? 

I don't have two DFG's yet (but I will in a few days). Right now I'm trying with one DFG and one Canopus ADVC-100. That works fine at 360x288 but at 720x576, the DFG's grab gives an incomprehensible error (error: jit.qt.grab: error -536870181 setting vdig compression type) when I try to open it, even if the  ADVC is not active but just connected. 

Quote: jamie jewett wrote on Mon, 14 April 2008 20:29
----------------------------------------------------
> I use 2 boxes and 2 grabs - 
>
> the box essentially functions like a camera  in that it is only addressable by a single grab - 
> it only processes from a single port  - it just allows you to switch in software which port you want to get data from
>
> best
> jamie
>
>
> ----- Original Message ----
> From: Mattijs Kneppers 
> Sent: Monday, April 14, 2008 8:48:56 AM
> Subject: [jitter] Re: analog video input hardware
>
>
> I have one more question for the experts: did someone manage to connect multiple dfg/1394's (with multiple jit.qt.grab objects)? 
>
> When I have two copies of jit.qt.grab (but only one dfg), the second one won't output any info when I send it the getinputlist command. This looks like it's not supported to have two jit.qt.grabs, or at least not with only one device.
>
> Mattijs
>
>
>
>
----------------------------------------------------


Hello Mattijs, last year we used 3 DFG's in conjunction with a winXP 

PC with two extra FW cards. Each DFG went to a separate FW bus. It did 

not work well at the time. The machine kept on crashing with high 

resolutions, no matter what we tried. In the end we used 3 laptops, 

Let us know how it works for you and in what config.

On May 11, 2008, at 6:04 PM, Mattijs Kneppers wrote:

> About using two DFG's: I would be interested to know at what 

> resolution you use them. As far as I can see it's not possible to 

> use two DFG's at 720x576 with YUV color mode on one firewire bus.

> Using indexed color mode though, two of them should be able to get 

> to work simultaneously at this resolution. Did you try this?

> I don't have two DFG's yet (but I will in a few days). Right now I'm 

> trying with one DFG and one Canopus ADVC-100. That works fine at 

> 360x288 but at 720x576, the DFG's grab gives an incomprehensible 

> error (error: jit.qt.grab: error -536870181 setting vdig compression 

> type) when I try to open it, even if the ADVC is not active but 

> Changing DFG settings (such as switching to indexed mode) has no 

> effect when the grab is at 720 x 576 and an ADVC-100 is connected 

> (but not active). The DFG's grab simply won't output any image. I 

> hope this will be different when my second digitizer is not a 

> Quote: jamie jewett wrote on Mon, 14 April 2008 20:29

>> the box essentially functions like a camera in that it is only 

>> it only processes from a single port - it just allows you to 

>> switch in software which port you want to get data from

>> Sent: Monday, April 14, 2008 8:48:56 AM

>> Subject: [jitter] Re: analog video input hardware

>> I have one more question for the experts: did someone manage to 

>> connect multiple dfg/1394's (with multiple jit.qt.grab objects)?