Jeremy Wagner

I'm stumped again and thought I'd throw another query down the void. Here's the problem:

I've devised an elaborate patch that connects a painter to a gallery space so that his painting progress can be projected at the gallery while certain metrics from his performance are turned into sound. The whole thing works perfectly except for the video data being sent between jit.net.* objects.

I knew going into this project that bandwidth would be an issue (there's a DSL bottleneck) so I took steps to avoid this very problem--I was sure to send frames only when the image has changed and no more than once every four seconds, I compressed the matrices using jit.argb2brgb before sending, I'm using the standard 320x240 resolution--but I still get a significant time lag of up to 40 seconds for each frame to come through! Moreover, the delay increases as the frames build up a sizeable backlog.

Any ideas on how I can thin the data stream further without significant loss of resolution?

Alternately, I could render the sound and video locally at the artist's studio and then send a compressed version to the gallery several minutes later. Unfortunately, I have absolutely no idea how to do this either.

I'm stumped again and thought I'd throw another query down the void.  Here's the problem:  

I've devised an elaborate patch that connects a painter to a gallery space so that his painting progress can be projected at the gallery while certain metrics from his performance are turned into sound.  The whole thing works perfectly except for the video data being sent between jit.net.* objects.  

I knew going into this project that bandwidth would be an issue (there's a DSL bottleneck) so I took steps to avoid this very problem--I was sure to send frames only when the image has changed and no more than once every four seconds, I compressed the matrices using jit.argb2brgb before sending, I'm using the standard 320x240 resolution--but I still get a significant time lag of up to 40 seconds for each frame to come through!  Moreover, the delay increases as the frames build up a sizeable backlog.

Any ideas on how I can thin the data stream further without significant loss of resolution?  

Alternately, I could render the sound and video locally at the artist's studio and then send a compressed version to the gallery several minutes later.  Unfortunately, I have absolutely no idea how to do this either.

video-latency-over-network

You might be better off with jit.broadcast or jit.qt.broadcast ? Not 

certain, but its an alternative to look at

On Sep 11, 2007, at 1:26 AM, Jeremy Wagner wrote:

> I'm stumped again and thought I'd throw another query down the 

> I've devised an elaborate patch that connects a painter to a 

> gallery space so that his painting progress can be projected at the 

> gallery while certain metrics from his performance are turned into 

> sound. The whole thing works perfectly except for the video data 

> I knew going into this project that bandwidth would be an issue 

> (there's a DSL bottleneck) so I took steps to avoid this very 

> problem--I was sure to send frames only when the image has changed 

> and no more than once every four seconds, I compressed the matrices 

> using jit.argb2brgb before sending, I'm using the standard 320x240 

> resolution--but I still get a significant time lag of up to 40 

> seconds for each frame to come through! Moreover, the delay 

> increases as the frames build up a sizeable backlog.

> Any ideas on how I can thin the data stream further without 

> Alternately, I could render the sound and video locally at the 

> artist's studio and then send a compressed version to the gallery 

> several minutes later. Unfortunately, I have absolutely no idea 

You might be better off with jit.broadcast or jit.qt.broadcast ? Not  
certain, but its an alternative to look at
On Sep 11, 2007, at 1:26 AM, Jeremy Wagner wrote:

>
> Hello List,
>
> I'm stumped again and thought I'd throw another query down the  
> void.  Here's the problem:
>
> I've devised an elaborate patch that connects a painter to a  
> gallery space so that his painting progress can be projected at the  
> gallery while certain metrics from his performance are turned into  
> sound.  The whole thing works perfectly except for the video data  
> being sent between jit.net.* objects.
>
> I knew going into this project that bandwidth would be an issue  
> (there's a DSL bottleneck) so I took steps to avoid this very  
> problem--I was sure to send frames only when the image has changed  
> and no more than once every four seconds, I compressed the matrices  
> using jit.argb2brgb before sending, I'm using the standard 320x240  
> resolution--but I still get a significant time lag of up to 40  
> seconds for each frame to come through!  Moreover, the delay  
> increases as the frames build up a sizeable backlog.
>
> Any ideas on how I can thin the data stream further without  
> significant loss of resolution?
>
> Alternately, I could render the sound and video locally at the  
> artist's studio and then send a compressed version to the gallery  
> several minutes later.  Unfortunately, I have absolutely no idea  
> how to do this either.
>
> Here's hoping,
>
>
> --
> Jeremy Wagner
> ----UofM----
> Minneapolis, MN

We are currently working on a school project where we want to send some camerainput over a wireless network. We have a 54 Mbit WIFI setup and a 320x240 feed of up to 20 frames per second. We use two windows xp laptops where one of them is connected by firewire to the camera.

We've experienced the same problem as posted by 'wagne342',

resulting in 17 seconds of lag between signal input and output.

This was the case when usimg jit.net.send and the complementary jit.net.recv.

We tried jit.net.broadcast but it resulted in an unreliable video stream, locking up all the time. If it didn't lock up, it still had a 4 second delay.

Regardless of the compression, tweaking of framerate metros, qmetros or other variables, it continues to run into major latency and an unstable signal.

If anyone could give a hint or solution how to reliably compress and/or send the signal, we would be more than grateful.

We've experienced the same problem as posted by 'wagne342',
resulting in 17 seconds of lag between signal input and output.
This was the case when usimg jit.net.send and the complementary jit.net.recv.

We tried jit.net.broadcast but it resulted in an unreliable video stream, locking up all the time. If it didn't lock up, it still had a 4 second delay. 

If your sending over the internet there isn't much you can do to improve delay besides decreasing the amount of data being sent or using compression. H.264 is best for decreasing the amount of bits being sent but the computers decoding and encoding the data will be under considerable load. For LAN I've used jit.qt.broadcast on a wireless n network and have had quite good results < 10ms latency with 480x320 30ish fps using compression. Keep in mind that wifi G is not 54 Mbps, at best maybe 20 Mbps. Do some calculations to determine the bitrate of your video and make sure it's within the full bandwidth of your network. Backlogging of data will inevitably lead to poor performance.

If your sending over the internet there isn't much you can do to improve delay besides decreasing the amount of data being sent or using compression.  H.264 is best for decreasing the amount of bits being sent but the computers decoding and encoding the data will be under considerable load.  For LAN I've used jit.qt.broadcast on a wireless n network and have had quite good results < 10ms latency with 480x320 30ish fps using compression.  Keep in mind that wifi G is not 54 Mbps, at best maybe 20 Mbps.  Do some calculations to determine the bitrate of your video and make sure it's within the full bandwidth of your network.  Backlogging of data will inevitably lead to poor performance.


also, the uyvy half-the-bandwidth colorspace trick work over network too.

On Dec 13, 2007 8:20 PM, Tyler Nitsch wrote:

> If your sending over the internet there isn't much you can do to improve

> delay besides decreasing the amount of data being sent or using compression.

> H.264 is best for decreasing the amount of bits being sent but the

> computers decoding and encoding the data will be under considerable load.

> For LAN I've used jit.qt.broadcast on a wireless n network and have had

> quite good results < 10ms latency with 480x320 30ish fps using compression.

> Keep in mind that wifi G is not 54 Mbps, at best maybe 20 Mbps. Do some

> calculations to determine the bitrate of your video and make sure it's

> within the full bandwidth of your network. Backlogging of data will

On Dec 13, 2007 8:20 PM, Tyler Nitsch  wrote:

>
> If your sending over the internet there isn't much you can do to improve
> delay besides decreasing the amount of data being sent or using compression.
>  H.264 is best for decreasing the amount of bits being sent but the
> computers decoding and encoding the data will be under considerable load.
>  For LAN I've used jit.qt.broadcast on a wireless n network and have had
> quite good results < 10ms latency with 480x320 30ish fps using compression.
>  Keep in mind that wifi G is not 54 Mbps, at best maybe 20 Mbps.  Do some
> calculations to determine the bitrate of your video and make sure it's
> within the full bandwidth of your network.  Backlogging of data will
> inevitably lead to poor performance.
>

https://cycling74.com/forums/index.php?t=msg&goto=104277

On Dec 14, 2007 1:00 PM, yair reshef wrote:

> also, the uyvy half-the-bandwidth colorspace trick work over network too.

> On Dec 13, 2007 8:20 PM, Tyler Nitsch wrote:

> > If your sending over the internet there isn't much you can do to improve

> > delay besides decreasing the amount of data being sent or using compression.

> > H.264 is best for decreasing the amount of bits being sent but the

> > computers decoding and encoding the data will be under considerable load.

> > For LAN I've used jit.qt.broadcast on a wireless n network and have had

> > quite good results < 10ms latency with 480x320 30ish fps using compression.

> > Keep in mind that wifi G is not 54 Mbps, at best maybe 20 Mbps. Do some

> > calculations to determine the bitrate of your video and make sure it's

> > within the full bandwidth of your network. Backlogging of data will

On Dec 14, 2007 1:00 PM, yair reshef  wrote:

> also, the uyvy half-the-bandwidth colorspace trick work over network too.
>
>
> On Dec 13, 2007 8:20 PM, Tyler Nitsch  wrote:
>
> >
> > If your sending over the internet there isn't much you can do to improve
> > delay besides decreasing the amount of data being sent or using compression.
> >   H.264 is best for decreasing the amount of bits being sent but the
> > computers decoding and encoding the data will be under considerable load.
> >  For LAN I've used jit.qt.broadcast on a wireless n network and have had
> > quite good results < 10ms latency with 480x320 30ish fps using compression.
> >  Keep in mind that wifi G is not 54 Mbps, at best maybe 20 Mbps.  Do some
> > calculations to determine the bitrate of your video and make sure it's
> > within the full bandwidth of your network.  Backlogging of data will
> > inevitably lead to poor performance.
> >
>
>

Does anyone tried to use one fw camera towards two computer, using a 

firewire hub ? Or any other solution to use the same dv input with two 

Does anyone tried to use one fw camera towards two computer, using a  
firewire hub ? Or any other solution to use the same dv input with two  
computer in the same time ?
Thanks.
Eric


you could import it on one computer and send it over to the second one with

jit.net.send/receive; offcourse therefor you should have enough bandwith,

but the current Gb interfaces that shouldn't be a problem.

On Dec 14, 2007 9:02 PM, Eric Vernhes wrote:

> Does anyone tried to use one fw camera towards two computer, using a

> firewire hub ? Or any other solution to use the same dv input with two

you could import it on one computer and send it over to the second one with
jit.net.send/receive; offcourse therefor you should have enough bandwith,
but the current Gb interfaces that shouldn't be a problem.

On Dec 14, 2007 9:02 PM, Eric Vernhes  wrote:

> Does anyone tried to use one fw camera towards two computer, using a
> firewire hub ? Or any other solution to use the same dv input with two
> computer in the same time ?
> Thanks.
> Eric
>

so RCA or s-video out of the camera to splitter to 1394 imaging boxes -

allows me to switch between 3 sources and get 2 high speed inputs -

you could then either use these 2 inputs to 2 machines or 2 inputs into one machine

an additional feature is that you can switch between the 3 inputs on a single box via software.

I have found this to be an extremely fast and reliable set-up providing good quality results - 

another thing to remember is that devices like these or a DV camera use a significant amount of your firewire bandwidth, thus if you have an external firewire sound interface or hard-drive your bus can get pretty jammed up -

to counter this you might consider using your card slot to get an additional FW bus or to go esata with external drives...

when I was trying to figure this out I remember reading that jit.send/receive was not working real well...

your mileage may vary but this has proved a robust set-up for me

Sent: Monday, December 17, 2007 3:42:43 AM

Subject: Re: [jitter] one dv input, two computer

you could import it on one computer and send it over to the second one with jit.net.send/receive; offcourse therefor you should have enough bandwith, but the current Gb interfaces that shouldn't be a problem.

Does anyone tried to use one fw camera towards two computer, using a

firewire hub ? Or any other solution to use the same dv input with two

so RCA or s-video out of the camera to splitter to 1394 imaging boxes - 

allows me to switch between 3 sources and get 2 high speed inputs - 

I have found this to be an extremely fast and reliable set-up providing good quality results - 
it's not an inexpensive option though...

another thing to remember is that devices like these or a DV camera use a significant amount of your firewire bandwidth, thus if you have an external firewire sound interface or hard-drive your bus can get pretty jammed up - 

to counter this you might consider using your card slot to get an additional FW bus  or to go esata with external drives...

----- Original Message ----
From: david vandenbogaerde 
Sent: Monday, December 17, 2007 3:42:43 AM
Subject: Re: [jitter] one dv input, two computer

Does anyone tried to use one fw camera towards two computer, using a
firewire hub ? Or any other solution to use the same dv input with two
computer in the same time ?
Thanks.
Eric

your solution is indeed much more robust.

I have been using the way I mentioned several times and haven't had very big

issues up until now, however i must agree in the fact that jit.net.send/receive

is far from stable and definitely not optimal for cpu usage in some cases.

The reason i use this methodology is especially because i'm processing live

input on one computer sending it to another one that is playing 'static'

video and then combining both to be shown live. Live + static footage on one

Would you have any reference to you firewire imaging boxes? these sound

interesting and could be another step to a more professional setup.

On Dec 17, 2007 2:15 PM, jamie jewett wrote:

> so RCA or s-video out of the camera to splitter to 1394 imaging boxes -

> allows me to switch between 3 sources and get 2 high speed inputs -

> you could then either use these 2 inputs to 2 machines or 2 inputs into

> an additional feature is that you can switch between the 3 inputs on a

> I have found this to be an extremely fast and reliable set-up providing

> it's not an inexpensive option though...

> another thing to remember is that devices like these or a DV camera use a

> significant amount of your firewire bandwidth, thus if you have an external

> firewire sound interface or hard-drive your bus can get pretty jammed up -

> to counter this you might consider using your card slot to get an

> additional FW bus or to go esata with external drives...

> when I was trying to figure this out I remember reading that jit.send/receive

> your mileage may vary but this has proved a robust set-up for me

> Sent: Monday, December 17, 2007 3:42:43 AM

> Subject: Re: [jitter] one dv input, two computer

> you could import it on one computer and send it over to the second one

> with jit.net .send/receive; offcourse therefor you

> should have enough bandwith, but the current Gb interfaces that shouldn't be

> On Dec 14, 2007 9:02 PM, Eric Vernhes wrote:

> > Does anyone tried to use one fw camera towards two computer, using a

> > firewire hub ? Or any other solution to use the same dv input with two

I have been using the way I mentioned several times and haven't had very big
issues up until now, however i must agree in the fact that jit.net.send/receive
is far from stable and definitely not optimal for cpu usage in some cases.

The reason i use this methodology is especially because i'm processing live
input on one computer sending it to another one that is playing 'static'
video and then combining both to be shown live. Live + static footage on one
pc just is too much...

Would you have any reference to you firewire imaging boxes? these sound
interesting and could be another step to a more professional setup.

On Dec 17, 2007 2:15 PM, jamie jewett  wrote:

> I am using 2 1394imaging boxes -
>
> so RCA or s-video out of the camera to splitter to 1394 imaging boxes -
>
> allows me to switch between 3 sources and get 2 high speed inputs -
>
> you could then either use these 2 inputs to 2 machines or 2 inputs into
> one machine
>
> an additional feature is that you can switch between the 3 inputs on a
> single box via software.
>
>
> I have found this to be an extremely fast and reliable set-up providing
> good quality results -
> it's not an inexpensive option though...
>
> another thing to remember is that devices like these or a DV camera use a
> significant amount of your firewire bandwidth, thus if you have an external
> firewire sound interface or hard-drive your bus can get pretty jammed up -
>
> to counter this you might consider using your card slot to get an
> additional FW bus  or to go esata with external drives...
>
> when I was trying to figure this out I remember reading that jit.send/receive
> was not working real well...
>
> your mileage may vary but this has proved a robust set-up for me
>
> best
> jamie
>
>
>
> ----- Original Message ----
> From: david vandenbogaerde 
> Sent: Monday, December 17, 2007 3:42:43 AM
> Subject: Re: [jitter] one dv input, two computer
>
> you could import it on one computer and send it over to the second one
> with jit.net .send/receive; offcourse therefor you
> should have enough bandwith, but the current Gb interfaces that shouldn't be
> a problem.
>
>
>
> On Dec 14, 2007 9:02 PM, Eric Vernhes  wrote:
>
> > Does anyone tried to use one fw camera towards two computer, using a
> > firewire hub ? Or any other solution to use the same dv input with two
> > computer in the same time ?
> > Thanks.
> > Eric
> >
>
>
>
>
>

the converter boxes are as recommended by cycling 74 - 

http://www.theimagingsource.com/en/products/converters/dfg13941e/overview/

you have to buy the mac drivers separately from:

http://www.outcastsoft.com/ASCDFG1394.html

I am using 2 of these and the example patch 43jYourVeryOwnSlab.pat to mix 2 live feeds with 2 pre-recorded - 

doing pretty well on a 2.4 ghz macbook pro 4gig ram and everything else current...

you might have a look - though obviously it will depend on the overhead from what ever other processing you are doing...

Sent: Monday, December 17, 2007 9:32:41 AM

I have been using the way I mentioned several times and haven't had very big issues up until now, however i must agree in the fact that jit.net.send/receive is far from stable and definitely not optimal for cpu usage in some cases.

The reason i use this methodology is especially because i'm processing live input on one computer sending it to another one that is playing 'static' video and then combining both to be shown live. Live + static footage on one pc just is too much...

Would you have any reference to you firewire imaging boxes? these sound interesting and could be another step to a more professional setup.

I have found this to be an extremely fast and reliable set-up providing good quality results -

another thing to remember is that devices like these or a DV camera use a significant amount of your firewire bandwidth, thus if you have an external firewire sound interface or

hard-drive your bus can get pretty jammed up -

when I was trying to figure this out I remember reading that 

jit.send/receive was not working real well...

the converter boxes are as recommended by cycling 74 - 
http://www.theimagingsource.com/en/products/converters/dfg13941e/overview/

you have to buy the mac drivers separately from:
http://www.outcastsoft.com/ASCDFG1394.html 

I am using 2 of these and the example patch 43jYourVeryOwnSlab.pat to mix 2 live feeds with 2 pre-recorded - 
doing pretty well on a 2.4 ghz macbook pro 4gig ram and everything else current...

you might have a look  - though obviously it will depend on the overhead from what ever other processing you are doing...

----- Original Message ----
From: david vandenbogaerde 
Sent: Monday, December 17, 2007 9:32:41 AM
Subject: Re: [jitter] one dv input, two computer

your solution is indeed much more robust. 

I have been using the way I mentioned several times and haven't had very big issues up until now, however i must agree in the fact that jit.net.send/receive is far from stable and definitely not optimal for cpu usage in some cases. 

On Dec 17, 2007 2:15 PM, jamie jewett <
jewett18@yahoo.com> wrote:

another thing to remember is that devices like these or a DV camera use a significant amount of your firewire bandwidth, thus if you have an external firewire sound interface or
 hard-drive your bus can get pretty jammed up - 

when I was trying to figure this out I remember reading that 
jit.send/receive was not working real well...

----- Original Message ----
From: david vandenbogaerde 
To: 
Sent: Monday, December 17, 2007 3:42:43 AM
Subject: Re: [jitter] one dv input, two computer

I've had good luck with this converter box. Class compliant too! 

http://www.canopus.com/products/ADVC55/index.php

I've had good luck with this converter box. Class compliant too! 
http://www.canopus.com/products/ADVC55/index.php


Video Latency Over Network