CarlR

I would like to be able to record the output from jit.qt.videoout to DV tape via a DV camera over firewire on my Mac. I have set this up in my patch and get an output to a matrix. The max window says it has opened a successful connection but I do not get any video from the FW bus into the camera. The patch seems to recognise the hardware but I get nothing out of the camera in VTR record mode. I have also tried a DV deck and that is the same, picked up by the patch but not streaming video to it.

Am I right in thinking that I should be able to capture my video efforts this way?

jit-qt-videoout-via-fw

Tumble weed. Must be asking the wrong question. :-(

Carl, did you get an answer to this question? I'm interested in knowing if you got it working, and if so, what camera you're using.

Yes all working now just had GL problems in my patch. I used a Sony HDV Deck and an old Sony mini DV camera as well. I think most DV devices will work.

Not sure about the audio side though? Can anybody give some tips for how to stream the audio over the FW bus? Say I had four videos composited and want an equal mix of all the audio.

Still I don't understand why direct FW to FW video is not possible. I am a noob at this but my first naive impression is that it should be possible somehow. Is it a hardware limitation? Is it that the firewire device has to provide information that is cooked into the hardware?

It seems to work on any "DV" device. A computers FW bus is different I guess.

It would be a great feature though. Maybe there is a workaround. Perhaps a wrapper that emulates a DV stream?

Quote: CarlR wrote on Tue, 27 March 2007 15:36

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

> It seems to work on any "DV" device. A computers FW bus is different I guess.

> It would be a great feature though. Maybe there is a workaround. Perhaps a wrapper that emulates a DV stream?

Would definitly be a great feature. Although the conversion to and from DV shouldn't be necessary as firewire camera's don't seem to need that either. Firewire video is a different protocol altogether, right? I hope for a minimal latency :)

Quote: CarlR wrote on Tue, 27 March 2007 15:36
----------------------------------------------------
> It seems to work on any "DV" device. A computers FW bus is different I guess.
>
> It would be a great feature though. Maybe there is a workaround. Perhaps a wrapper that emulates a DV stream?
----------------------------------------------------

yeah it dose not make sense as an app like Final Cut can capture from a DV camera. If one computer had a jit.qt.video (PAL DV) coming out why can't it be grabbed on another?

On Mar 27, 2007, at 5:49 AM, Mattijs Kneppers wrote:

> Still I don't understand why direct FW to FW video is not possible. 

> I am a noob at this but my first naive impression is that it should 

> be possible somehow. Is it a hardware limitation? Is it that the 

> firewire device has to provide information that is cooked into the 

There is no fundamental reason why this is not possible. This 

functionality is however just exploiting QT features for video input 

and output components. I assume it has simply not been a high 

priority for them to code something which negotiates with other 

computers for these tasks. It may be possible through some of the 

other firewire boards, but again, you're going to get better 

performance with uncompressed video (use UYVY or GRGB for half data 

rate) over gigabit ethernet, versus compressing to DV and then 

decompressing DV on the other end. The network protocol we use for 

jit.net.send is published in our SDK documentation, so in theory 

someone could code a QT video input device which could use this 

uncompressed networked stream to get the video into other 

applications, but this is not a current high priority for us.

>
> Still I don't understand why direct FW to FW video is not possible.  
> I am a noob at this but my first naive impression is that it should  
> be possible somehow. Is it a hardware limitation? Is it that the  
> firewire device has to provide information that is cooked into the  
> hardware?

There is no fundamental reason why this is not possible. This  
functionality is however just exploiting QT features for video input  
and output components. I assume it has simply not been a high  
priority for them to code something which negotiates with other  
computers for these tasks. It may be possible through some of the  
other firewire boards, but again, you're going to get better  
performance with uncompressed video (use UYVY or GRGB for half data  
rate) over gigabit ethernet, versus compressing to DV and then  
decompressing DV on the other end. The network protocol we use for  
jit.net.send is published in our SDK documentation, so in theory  
someone could code a QT video input device which could use this  
uncompressed networked stream to get the video into other  
applications, but this is not a current high priority for us.

I have been thinking about a system that takes different video sources from outside (generated by VJ's with their favorite apps, webcams, live camera input) and combines it in one video space. If you say that video over fast ethernet is even better than firewire, I'll try that first.

Quote: jkc wrote on Tue, 27 March 2007 17:36

> On Mar 27, 2007, at 5:49 AM, Mattijs Kneppers wrote:

> > Still I don't understand why direct FW to FW video is not possible. 

> > I am a noob at this but my first naive impression is that it should 

> > be possible somehow. Is it a hardware limitation? Is it that the 

> > firewire device has to provide information that is cooked into the 

> There is no fundamental reason why this is not possible. This 

> functionality is however just exploiting QT features for video input 

> and output components. I assume it has simply not been a high 

> priority for them to code something which negotiates with other 

> computers for these tasks. It may be possible through some of the 

> other firewire boards, but again, you're going to get better 

> performance with uncompressed video (use UYVY or GRGB for half data 

> rate) over gigabit ethernet, versus compressing to DV and then 

> decompressing DV on the other end. The network protocol we use for 

> jit.net.send is published in our SDK documentation, so in theory 

> someone could code a QT video input device which could use this 

> uncompressed networked stream to get the video into other 

> applications, but this is not a current high priority for us.

Quote: jkc wrote on Tue, 27 March 2007 17:36
----------------------------------------------------
>
> On Mar 27, 2007, at 5:49 AM, Mattijs Kneppers wrote:
>
> >
> > Still I don't understand why direct FW to FW video is not possible.  
> > I am a noob at this but my first naive impression is that it should  
> > be possible somehow. Is it a hardware limitation? Is it that the  
> > firewire device has to provide information that is cooked into the  
> > hardware?
>
> There is no fundamental reason why this is not possible. This  
> functionality is however just exploiting QT features for video input  
> and output components. I assume it has simply not been a high  
> priority for them to code something which negotiates with other  
> computers for these tasks. It may be possible through some of the  
> other firewire boards, but again, you're going to get better  
> performance with uncompressed video (use UYVY or GRGB for half data  
> rate) over gigabit ethernet, versus compressing to DV and then  
> decompressing DV on the other end. The network protocol we use for  
> jit.net.send is published in our SDK documentation, so in theory  
> someone could code a QT video input device which could use this  
> uncompressed networked stream to get the video into other  
> applications, but this is not a current high priority for us.
>
> -Joshua 
>
----------------------------------------------------


On Mar 27, 2007, at 9:15 AM, Mattijs Kneppers wrote:

> I have been thinking about a system that takes different video 

> sources from outside (generated by VJ's with their favorite apps, 

> webcams, live camera input) and combines it in one video space. If 

> you say that video over fast ethernet is even better than firewire, 

Better in that it uses less CPU on both sides, but uses significantly 

> I have been thinking about a system that takes different video  
> sources from outside (generated by VJ's with their favorite apps,  
> webcams, live camera input) and combines it in one video space. If  
> you say that video over fast ethernet is even better than firewire,  
> I'll try that first.

Better in that it uses less CPU on both sides, but uses significantly  
more bandwidth.

how about using the firewire link for IP-over-FW networking?

On 27-mrt-2007, at 18:39, Joshua Kit Clayton wrote:

> On Mar 27, 2007, at 9:15 AM, Mattijs Kneppers wrote:

>> I have been thinking about a system that takes different video 

>> sources from outside (generated by VJ's with their favorite apps, 

>> webcams, live camera input) and combines it in one video space. If 

>> you say that video over fast ethernet is even better than 

> Better in that it uses less CPU on both sides, but uses 

how about using the firewire link for IP-over-FW networking?
both my OSX and XP machine can do this.
have not tried it though
-jennek

>
> On Mar 27, 2007, at 9:15 AM, Mattijs Kneppers wrote:
>
>> I have been thinking about a system that takes different video  
>> sources from outside (generated by VJ's with their favorite apps,  
>> webcams, live camera input) and combines it in one video space. If  
>> you say that video over fast ethernet is even better than  
>> firewire, I'll try that first.
>
> Better in that it uses less CPU on both sides, but uses  
> significantly more bandwidth.
>
> -Joshua
>


On Mar 27, 2007, at 10:00 AM, jennek geels wrote:

> how about using the firewire link for IP-over-FW networking?

> both my OSX and XP machine can do this.

Less bandwidth than gigabit ethernet, but technically should work.

> how about using the firewire link for IP-over-FW networking?
> both my OSX and XP machine can do this.

jit.qt.videoout via FW