firewire-webcam-latency-and-cpu-use

I just recieved an Unibrain Fire-i digital board camera today. I bought it for exactly the same reasons. I've been playing with it for about three hours now, and still have alot of questions, but here are my first impressions:

The 30fps rate is terrific. Until now, I've been using a 15fps USB webcam (with considerable success...) and this is much better. Also, the reactions to lighting conditions are incomparably better. When the USB webcam shows nothing but a basically black screen, this camera delivers a sharply contrasted picture. When I set both cameras to 15fps to compare latency, the Fire-i still outperforms the USB webcam considerably; apparently the decompression-stage of the USB dataflow contributes to latency. Since I've been using the USB camera for performances, I have become good at setting up the optimal lighting and using the optimal settings (shutter speed plays a big role). I get similar performance with the Fire-i with considerably less light; say 100W compared to 2000W, although the contrast suffers.

On my PC (3GHz, mobile P4) I notice only some advantage in CPU use. Using 15fps on both cameras, Max uses 17% in one test for the USB and about 14% for (apparently) the same resolution for the firewire. I need to search more for solutions, because as of now, Jitter isn't able to load the formats for the camera, so I call them by number and am not exactly sure which are which. Using the Unibrain software, the difference between color-modes are minimal, including the black and white Y_MONO mode. CPU usage is more affected by resolution than by frame-rate, although both create proportional changes in CPU-use. In Jitter, however, the various modes create extreme differences, between 90% and 17% (!) and mode 2 (a color mode at apparently 640x480 is the lowest, while black and white is the highest. As I stated, I have to get into this now to find out exactly what it is that I am facing.

I'll post what I find, but am very happy with the purchase. The little plastic lense-adjuster doesn't fit the lense, however...

I just recieved an Unibrain Fire-i digital board camera today.  I bought it for exactly the same reasons.  I've been playing with it for about three hours now, and still have alot of questions, but here are my first impressions:

The 30fps rate is terrific.  Until now, I've been using a 15fps USB webcam (with considerable success...) and this is much better. Also, the reactions to lighting conditions are incomparably better.  When the USB webcam shows nothing but a basically black screen, this camera delivers a sharply contrasted picture.  When I set both cameras to 15fps to compare latency, the Fire-i still outperforms the USB webcam considerably; apparently the decompression-stage of the USB dataflow contributes to latency.  Since I've been using the USB camera for performances, I have become good at setting up the optimal lighting and using the optimal settings (shutter speed plays a big role).  I get similar performance with the Fire-i with considerably less light; say 100W compared to 2000W, although the contrast suffers.

On my PC (3GHz, mobile P4) I notice only some advantage in CPU use.  Using 15fps on both cameras, Max uses 17% in one test for the USB and about 14% for (apparently) the same resolution for the firewire.  I need to search more for solutions, because as of now, Jitter isn't able to load the formats for the camera, so I call them by number and am not exactly sure which are which.  Using the Unibrain software, the difference between color-modes are minimal, including the black and white Y_MONO mode.  CPU usage is more affected by resolution than by frame-rate, although both create proportional changes in CPU-use.  In Jitter, however, the various modes create extreme differences, between 90% and 17% (!) and mode 2 (a color mode at apparently 640x480 is the lowest, while black and white is the highest.  As I stated, I have to get into this now to find out exactly what it is that I am facing. 

I'll post what I find, but am very happy with the purchase.  The little plastic lense-adjuster doesn't fit the lense, however...


remember to set unique to true, else you bang more then needed.

on my e6400 xp i get 5-6% cpu with y800 640 480 with [unique 1] and 18% without.

i use the jit.dx.grab help patch, i also killed the pwindow preview.

> I just recieved an Unibrain Fire-i digital board camera today. I bought it for exactly the same reasons. I've been playing with it for about three hours now, and still have alot of questions, but here are my first impressions:

> The 30fps rate is terrific. Until now, I've been using a 15fps USB webcam (with considerable success...) and this is much better. Also, the reactions to lighting conditions are incomparably better. When the USB webcam shows nothing but a basically black screen, this camera delivers a sharply contrasted picture. When I set both cameras to 15fps to compare latency, the Fire-i still outperforms the USB webcam considerably; apparently the decompression-stage of the USB dataflow contributes to latency. Since I've been using the USB camera for performances, I have become good at setting up the optimal lighting and using the optimal settings (shutter speed plays a big role). I get similar performance with the Fire-i with considerably less light; say 100W compared to 2000W, although the contrast suffers.

> On my PC (3GHz, mobile P4) I notice only some advantage in CPU use. Using 15fps on both cameras, Max uses 17% in one test for the USB and about 14% for (apparently) the same resolution for the firewire. I need to search more for solutions, because as of now, Jitter isn't able to load the formats for the camera, so I call them by number and am not exactly sure which are which. Using the Unibrain software, the difference between color-modes are minimal, including the black and white Y_MONO mode. CPU usage is more affected by resolution than by frame-rate, although both create proportional changes in CPU-use. In Jitter, however, the various modes create extreme differences, between 90% and 17% (!) and mode 2 (a color mode at apparently 640x480 is the lowest, while black and white is the highest. As I stated, I have to get into this now to find out exactly what it is that I am facing.

> I'll post what I find, but am very happy with the purchase. The little plastic lense-adjuster doesn't fit the lense, however...

remember to set unique to true, else you bang more then needed.
on my e6400 xp i get 5-6% cpu with y800 640 480 with [unique 1] and 18% without.
i use the jit.dx.grab help patch, i also killed the pwindow preview.

On 5/2/07, Dayton  wrote:
>
> Strange that you write this today...
>
> I just recieved an Unibrain Fire-i digital board camera today.  I bought it for exactly the same reasons.  I've been playing with it for about three hours now, and still have alot of questions, but here are my first impressions:
>
> The 30fps rate is terrific.  Until now, I've been using a 15fps USB webcam (with considerable success...) and this is much better. Also, the reactions to lighting conditions are incomparably better.  When the USB webcam shows nothing but a basically black screen, this camera delivers a sharply contrasted picture.  When I set both cameras to 15fps to compare latency, the Fire-i still outperforms the USB webcam considerably; apparently the decompression-stage of the USB dataflow contributes to latency.  Since I've been using the USB camera for performances, I have become good at setting up the optimal lighting and using the optimal settings (shutter speed plays a big role).  I get similar performance with the Fire-i with considerably less light; say 100W compared to 2000W, although the contrast suffers.
>
> On my PC (3GHz, mobile P4) I notice only some advantage in CPU use.  Using 15fps on both cameras, Max uses 17% in one test for the USB and about 14% for (apparently) the same resolution for the firewire.  I need to search more for solutions, because as of now, Jitter isn't able to load the formats for the camera, so I call them by number and am not exactly sure which are which.  Using the Unibrain software, the difference between color-modes are minimal, including the black and white Y_MONO mode.  CPU usage is more affected by resolution than by frame-rate, although both create proportional changes in CPU-use.  In Jitter, however, the various modes create extreme differences, between 90% and 17% (!) and mode 2 (a color mode at apparently 640x480 is the lowest, while black and white is the highest.  As I stated, I have to get into this now to find out exactly what it is that I am facing.
>
> I'll post what I find, but am very happy with the purchase.  The little plastic lense-adjuster doesn't fit the lense, however...
>


thanks for your answers, it's been helpful

I think my 1,67 G4 should handle this webcam for realtime 

- can you estimate the latency in the fastest camera driver mode ; is it linked to cpu speed ?

thanks for your answers, it's been helpful
I think my 1,67 G4 should handle this webcam for realtime 
just 2-3 questions :
- what's UYVY or GRGB
- can you estimate the latency in the fastest camera driver mode ; is it linked to cpu speed ?


a matrix is comprised of 4 planes of information. usually we are

dealing with ARGB, which stands for alpha red green and blue. passing

a matrix from the cpu to the graphic card (a.k.a gpu) is a costly

UYVY allows the programmer to halves the data being sent by using a

different colorspace, discarding the alpha channel and placing other

but, i don't think uyvy has anything to do with latency performance.

for a better explanation, goto the colorspace chapter in the tutorials.

> thanks for your answers, it's been helpful

> I think my 1,67 G4 should handle this webcam for realtime

> - can you estimate the latency in the fastest camera driver mode ; is it linked to cpu speed ?

first question,
a matrix is comprised of 4 planes of information. usually we are
dealing with ARGB, which stands for alpha red green and blue. passing
a matrix from the cpu to the graphic card (a.k.a gpu) is a costly
process. a bottleneck.
UYVY allows the programmer to halves the data being sent by using a
different colorspace, discarding the alpha channel and placing other
information into it.
but, i don't think uyvy has anything to do with latency performance.
for a better explanation, goto the colorspace chapter in the tutorials.

On 5/6/07, gael paradis  wrote:
>
> thanks for your answers, it's been helpful
> I think my 1,67 G4 should handle this webcam for realtime
> just 2-3 questions :
> - what's UYVY or GRGB
> - can you estimate the latency in the fastest camera driver mode ; is it linked to cpu speed ?
>


typically DV and firewire sources have 4 to 7 frame latency. 4 frame 

under 10.4, 7 frame under 10.3 (apple fixed some things under the 

On May 6, 2007, at 11:20 AM, yair reshef wrote:

> a matrix is comprised of 4 planes of information. usually we are

> dealing with ARGB, which stands for alpha red green and blue. passing

> a matrix from the cpu to the graphic card (a.k.a gpu) is a costly

> UYVY allows the programmer to halves the data being sent by using a

> different colorspace, discarding the alpha channel and placing other

> but, i don't think uyvy has anything to do with latency performance.

> for a better explanation, goto the colorspace chapter in the 

>> thanks for your answers, it's been helpful

>> I think my 1,67 G4 should handle this webcam for realtime

>> - can you estimate the latency in the fastest camera driver mode ; 

typically DV and firewire sources have 4 to 7 frame latency. 4 frame  
under 10.4, 7 frame under 10.3 (apple fixed some things under the  
hood apparently).

> first question,
> a matrix is comprised of 4 planes of information. usually we are
> dealing with ARGB, which stands for alpha red green and blue. passing
> a matrix from the cpu to the graphic card (a.k.a gpu) is a costly
> process. a bottleneck.
> UYVY allows the programmer to halves the data being sent by using a
> different colorspace, discarding the alpha channel and placing other
> information into it.
> but, i don't think uyvy has anything to do with latency performance.
> for a better explanation, goto the colorspace chapter in the  
> tutorials.
>
> On 5/6/07, gael paradis  wrote:
>>
>> thanks for your answers, it's been helpful
>> I think my 1,67 G4 should handle this webcam for realtime
>> just 2-3 questions :
>> - what's UYVY or GRGB
>> - can you estimate the latency in the fastest camera driver mode ;  
>> is it linked to cpu speed ?
>>

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

i tried today both the dfg connected to an analog source and a

unibrain, on the same bus (not that it matters) and i got a very

slight advantage to the unibrain. both are excellent compared to

my method of checking latency hasn't improved.

Video Wall and Data Wall PCI Plug-in RGB Capture Card from Datapath

> typically DV and firewire sources have 4 to 7 frame latency. 4 frame under

> 10.4, 7 frame under 10.3 (apple fixed some things under the hood

> On May 6, 2007, at 11:20 AM, yair reshef wrote:

> for a better explanation, goto the colorspace chapter in the tutorials.

> - can you estimate the latency in the fastest camera driver mode ; is it

didnt see this before
JitterCameras < FAQs < TWiki
https://cycling74.com/twiki/bin/view/FAQs/JitterCameras

i tried today both the dfg connected to an analog source and a
unibrain, on the same bus (not that it matters) and i got a very
slight advantage to the unibrain. both are excellent compared to
analog grabbers i use before.

also,
Video Wall and Data Wall PCI Plug-in RGB Capture Card from Datapath
http://www.datapath.co.uk/visRGBPRO.htm

On 5/6/07, vade  wrote:
> typically DV and firewire sources have 4 to 7 frame latency. 4 frame under
> 10.4, 7 frame under 10.3 (apple fixed some things under the hood
> apparently).
>
>
> On May 6, 2007, at 11:20 AM, yair reshef wrote:
>
> first question,
> a matrix is comprised of 4 planes of information. usually we are
> dealing with ARGB, which stands for alpha red green and blue. passing
> a matrix from the cpu to the graphic card (a.k.a gpu) is a costly
> process. a bottleneck.
> UYVY allows the programmer to halves the data being sent by using a
> different colorspace, discarding the alpha channel and placing other
> information into it.
> but, i don't think uyvy has anything to do with latency performance.
> for a better explanation, goto the colorspace chapter in the tutorials.
>
> On 5/6/07, gael paradis  wrote:
>
> thanks for your answers, it's been helpful
> I think my 1,67 G4 should handle this webcam for realtime
> just 2-3 questions :
> - what's UYVY or GRGB
> - can you estimate the latency in the fastest camera driver mode ; is it
> linked to cpu speed ?
>
>
>
> v a d e //
>
> www.vade.info
> abstrakt.vade.info
>
>
>
>
>
>


Oh, nice! I must have missed that camera update on the faq. That is 

Is it possible we can get some capture card information up there as 

well? Id love to put the BMD intensity and other cards mentioned on 

perhaps ill post something on dactilde~. No time! no time!

On May 6, 2007, at 3:31 PM, yair reshef wrote:

> i tried today both the dfg connected to an analog source and a

> unibrain, on the same bus (not that it matters) and i got a very

> slight advantage to the unibrain. both are excellent compared to

> my method of checking latency hasn't improved.

> Video Wall and Data Wall PCI Plug-in RGB Capture Card from Datapath

>> typically DV and firewire sources have 4 to 7 frame latency. 4 

>> 10.4, 7 frame under 10.3 (apple fixed some things under the hood

>> On May 6, 2007, at 11:20 AM, yair reshef wrote:

>> a matrix is comprised of 4 planes of information. usually we are

>> dealing with ARGB, which stands for alpha red green and blue. passing

>> a matrix from the cpu to the graphic card (a.k.a gpu) is a costly

>> UYVY allows the programmer to halves the data being sent by using a

>> different colorspace, discarding the alpha channel and placing other

>> but, i don't think uyvy has anything to do with latency performance.

>> for a better explanation, goto the colorspace chapter in the 

Oh, nice! I must have missed that camera update on the faq. That is  
very useful information.

Is it possible we can get some capture card information up there as  
well? Id love to put the BMD intensity and other cards mentioned on  
this list up there.

perhaps ill post something on dactilde~.  No time! no time!

> didnt see this before
> JitterCameras < FAQs < TWiki
> https://cycling74.com/twiki/bin/view/FAQs/JitterCameras
>
> i tried today both the dfg connected to an analog source and a
> unibrain, on the same bus (not that it matters) and i got a very
> slight advantage to the unibrain. both are excellent compared to
> analog grabbers i use before.
>
> my method of checking latency hasn't improved.
>
> also,
> Video Wall and Data Wall PCI Plug-in RGB Capture Card from Datapath
> http://www.datapath.co.uk/visRGBPRO.htm
>
>
> On 5/6/07, vade  wrote:
>> typically DV and firewire sources have 4 to 7 frame latency. 4  
>> frame under
>> 10.4, 7 frame under 10.3 (apple fixed some things under the hood
>> apparently).
>>
>>
>> On May 6, 2007, at 11:20 AM, yair reshef wrote:
>>
>> first question,
>> a matrix is comprised of 4 planes of information. usually we are
>> dealing with ARGB, which stands for alpha red green and blue. passing
>> a matrix from the cpu to the graphic card (a.k.a gpu) is a costly
>> process. a bottleneck.
>> UYVY allows the programmer to halves the data being sent by using a
>> different colorspace, discarding the alpha channel and placing other
>> information into it.
>> but, i don't think uyvy has anything to do with latency performance.
>> for a better explanation, goto the colorspace chapter in the  
>> tutorials.
>>
>> On 5/6/07, gael paradis  wrote:
>>
>> thanks for your answers, it's been helpful
>> I think my 1,67 G4 should handle this webcam for realtime
>> just 2-3 questions :
>> - what's UYVY or GRGB
>> - can you estimate the latency in the fastest camera driver mode ;  
>> is it
>> linked to cpu speed ?
>>
>>
>>
>> v a d e //
>>
>> www.vade.info
>> abstrakt.vade.info
>>
>>
>>
>>
>>
>>

firewire webcam latency and cpu use