Fixrobert

I want to use jit.qt.videoout to read qt movies. If I'm using DV format for my movies will they be readed directly without decompression / re-compression ? Or is it better to keep them in photo jpeg format for fast reading ?

(I don't want to use the "direct to voc" possibility because I'm using a poly~ object that encapsulate multiple jit.qt.movie for fast access wich will complicate the send of "direct to voc" instructions, I think)

best-codec-with-jit-qt-videoout

first, if you're reading in DV footage, you should know that your 

ability to use nontraditional playback rates (fast, slow or reversed) 

will put a severe strain on your system and general framerate- DV is a 

temporal codec, and finding those keyframes will mung up the works.

second, jit.qt.videout is solely for using nonstandard playback 

methods- to an old matrox system, or out through the firewire port. 

it's not a reading object, it's a playback object.

third, you'd be best using a jit.qt.movie @adapt 1 @colormode uyvy 

running into a jit.gl.videoplane [contextname] @colormode uyvy 

@transform_reset 2 set for optimized dv playback, even if you're using 

On Jan 27, 2009, at 11:23 PM, FXRobert wrote:

> I want to use jit.qt.videoout to read qt movies. If I'm using DV 

> format for my movies will they be readed directly without 

> decompression / re-compression ? Or is it better to keep them in 

> (I don't want to use the "direct to voc" possibility because I'm 

> using a poly~ object that encapsulate multiple jit.qt.movie for fast 

> access wich will complicate the send of "direct to voc" 

first, if you're reading in DV footage, you should know that your  
ability to use nontraditional playback rates (fast, slow or reversed)  
will put a severe strain on your system and general framerate- DV is a  
temporal codec, and finding those keyframes will mung up the works.

second, jit.qt.videout is solely for using nonstandard playback  
methods- to an old matrox system, or out through the firewire port.   
it's not a reading object, it's a playback object.

third, you'd be best using a jit.qt.movie @adapt 1 @colormode uyvy   
running into a jit.gl.videoplane [contextname] @colormode uyvy  
@transform_reset 2 set for optimized dv playback, even if you're using  
a poly~ to manage multiple files.

>
> Hello list,
>
> I want to use jit.qt.videoout to read qt movies. If I'm using DV  
> format for my movies will they be readed directly without  
> decompression / re-compression ? Or is it better to keep them in  
> photo jpeg format for fast reading ?
>
> (I don't want to use the "direct to voc" possibility because I'm  
> using a poly~ object that encapsulate multiple jit.qt.movie for fast  
> access wich will complicate the send of "direct to voc"  
> instructions, I think)
>
> thank's for help


I don't need "fast, slow and reverse", just displaying movies via the fire wire link and a dv camera.

I do use the jit.videoplane method (though I didn't know about the transform_reset 2 argument wich I gonna study)

I just want (in fact, I was asked to) to offer the user of the patch the possibity of diffusing via dv in case of failure of the vga system during a world tour in "non-well-equiped venues".

So, even if it is wrong thing to do, you didn't tell me what will be the best compression format to do it with the best performance. (It might exist anyway because my user use to do it with final cut pro...)

it's my experience that firewire tends to more easily fail than the 

video out on macintoshes. but YMMV. not sure which is the best codec 

to use; i have not used jit.qt.videout since the dark days of os 9. 

my guess is that DV/NTSC will be ok, but this is not tested.

On Jan 28, 2009, at 11:04 AM, FXRobert wrote:

> I don't need "fast, slow and reverse", just displaying movies via 

> I do use the jit.videoplane method (though I didn't know about the 

> transform_reset 2 argument wich I gonna study)

> I just want (in fact, I was asked to) to offer the user of the patch 

> the possibity of diffusing via dv in case of failure of the vga 

> system during a world tour in "non-well-equiped venues".

> So, even if it is wrong thing to do, you didn't tell me what will be 

> the best compression format to do it with the best performance. (It 

> might exist anyway because my user use to do it with final cut pro...)

it's my experience that firewire tends to more easily fail than the  
video out on macintoshes.  but YMMV.  not sure which is the best codec  
to use; i have not used jit.qt.videout since the dark days of os 9.   
my guess is that DV/NTSC will be ok, but this is not tested.

>
> Hello Joshua
>
> I don't need "fast, slow and reverse", just displaying movies via  
> the fire wire link and a dv camera.
>
> I do use the jit.videoplane method (though I didn't know about the  
> transform_reset 2 argument wich I gonna study)
>
> I just want (in fact, I was asked to) to offer the user of the patch  
> the possibity of diffusing via dv in case of failure of the vga  
> system during a world tour in "non-well-equiped venues".
>
> So, even if it is wrong thing to do, you didn't tell me what will be  
> the best compression format to do it with the best performance. (It  
> might exist anyway because my user use to do it with final cut pro...)
>
> thank's


On Jan 28, 2009, at 8:04 AM, FXRobert wrote:

jit.qt.videoout is unrelated to codec. It takes *uncompressed* jitter 

matrices and then compresses them to send out as DV over firewire, or 

any matrox/decklink/etc video output board. For this reason, it can be 

computationally expensive, and generally less preferable to displaying 

via VGA/DVI, unless you have special requirements and don't mind the 

If however, you just want to stream compressed DV files out over 

firewire without any processing of the image, you will get very good 

performance by using jit.qt.movie's "voc" attribute. The codec you 

should use would be DV in this case, or if you have a matrox/decklink/ 

etc video output card, there will typically be a device specific codec 

which probably would work best. (I've never personally used 

jit.qt.movie's "voc" attribute with these cards, however, so I can't 

jit.qt.movie's "voc" and jit.qt.videoout are both covered in 

https://cycling74.com/docs/max5/tutorials/jit-tut/jitterchapter22.html

In order to support this, you will have to copy the image rendered in 

OpenGL, back to a Jitter matrix on the CPU and then send to 

jit.qt.videoout. This sort of thing will bring your framerate down 

significantly, and again, I wouldn't recommend it unless you have 

special requirements and don't mind the computational penalty.

So the basic answer to what I perceive to be your problem, would be 

ditch any notions about jit.qt.videoout, and recommend that whomever 

is using your patch in the absence of a VGA/DVI connection, use a VGA 

to analog video conversion device. (Or DVI to HDMI device, which for 

recording realtime streams seems like it would be the best/high 

quality approach, done with another computer that has an HDMI decklink 

In general, people recommend time and time again, Photo JPEG 75% as 

the typically best balance between CPU performance, HD performance, 

and image quality. However, things like H. 264 which minimize disk 

access cost, but increase CPU performance cost might be better for 

specific needs. And requirements of an alpha channel or not might lead 

Btw, Joshua G., the DV codec does *not* use temporal compression. HDV 

does, H.264 does, MPEG variants do, but DV does not. Why is it so much 

slower than PhotoJPEG to decompress, despite them both intraframe, DCT 

based, I can't speak for. Perhaps not as high a priority to optimize 

as JPEG, or perhaps the data layout or subtleties of the data encoding 

Which codecs are best for which purposes is a *big* discussion. I 

would highly recommend searching the Jitter forum archives further if 

you want to find out more about other people's real world experience 

http://www.google.com/search?q=jitter+codecs+site%3Acycling74.com

It hasn't been updated that much in recent years, but has good info 

and sample images, file sizes, etc. for many codecs.

> I don't need "fast, slow and reverse", just displaying movies via  
> the fire wire link and a dv camera.

jit.qt.videoout is unrelated to codec. It takes *uncompressed* jitter  
matrices and then compresses them to send out as DV over firewire, or  
any matrox/decklink/etc video output board. For this reason, it can be  
computationally expensive, and generally less preferable to displaying  
via VGA/DVI, unless you have special requirements and don't mind the  
computational penalty.

If however, you just want to stream compressed DV files out over  
firewire without any processing of the image, you will get very good  
performance by using jit.qt.movie's "voc" attribute. The codec you  
should use would be DV in this case, or if you have a matrox/decklink/ 
etc video output card, there will typically be a device specific codec  
which probably would work best. (I've never personally used  
jit.qt.movie's "voc" attribute with these cards, however, so I can't  
be certain. Perhaps someone else has.)

jit.qt.movie's "voc"  and jit.qt.videoout are both covered in  
reasonable detail in tutorial 22:

> I do use the jit.videoplane method (though I didn't know about the  
> transform_reset 2 argument wich I gonna study)
>
> I just want (in fact, I was asked to) to offer the user of the patch  
> the possibity of diffusing via dv in case of failure of the vga  
> system during a world tour in "non-well-equiped venues".

In order to support this, you will have to copy the image rendered in  
OpenGL, back to a Jitter matrix on the CPU and then send to  
jit.qt.videoout. This sort of thing will bring your framerate down  
significantly, and again, I wouldn't recommend it unless you have  
special requirements and don't mind the computational penalty.

So the basic answer to what I perceive to be your problem, would be  
ditch any notions about jit.qt.videoout, and recommend that whomever  
is using your patch in the absence of a VGA/DVI connection, use a VGA  
to analog video conversion device. (Or DVI to HDMI device, which for  
recording realtime streams seems like it would be the best/high  
quality approach, done with another computer that has an HDMI decklink  
card.)

> So, even if it is wrong thing to do, you didn't tell me what will be  
> the best compression format to do it with the best performance. (It  
> might exist anyway because my user use to do it with final cut pro...)

In general, people recommend time and time again, Photo JPEG 75% as  
the typically best balance between CPU performance, HD performance,  
and image quality. However, things like H. 264 which minimize disk  
access cost, but increase CPU performance cost might be better for  
specific needs. And requirements of an alpha channel or not might lead  
you to other codecs.

Btw, Joshua G., the DV codec does *not* use temporal compression. HDV  
does, H.264 does, MPEG variants do, but DV does not. Why is it so much  
slower than PhotoJPEG to decompress, despite them both intraframe, DCT  
based, I can't speak for. Perhaps not as high a priority to optimize  
as JPEG, or perhaps the data layout or subtleties of the data encoding  
in the DV datastream are to blame.

Which codecs are best for which purposes is a *big* discussion. I  
would highly recommend searching the Jitter forum archives further if  
you want to find out more about other people's real world experience  
with codecs, output devices, etc.

It hasn't been updated that much in recent years, but has good info  
and sample images, file sizes, etc. for many codecs.

On Jan 28, 2009, at 1:30 PM, Joshua Kit Clayton wrote:

> Btw, Joshua G., the DV codec does *not* use temporal compression. 

> HDV does, H.264 does, MPEG variants do, but DV does not. Why is it 

> so much slower than PhotoJPEG to decompress, despite them both 

> intraframe, DCT based, I can't speak for. Perhaps not as high a 

> priority to optimize as JPEG, or perhaps the data layout or 

> subtleties of the data encoding in the DV datastream are to blame.

> Btw, Joshua G., the DV codec does *not* use temporal compression.  
> HDV does, H.264 does, MPEG variants do, but DV does not. Why is it  
> so much slower than PhotoJPEG to decompress, despite them both  
> intraframe, DCT based, I can't speak for. Perhaps not as high a  
> priority to optimize as JPEG, or perhaps the data layout or  
> subtleties of the data encoding in the DV datastream are to blame.

thanks for setting me straight on this. 


"In order to support this, you will have to copy the image rendered in 

special requirements and don't mind the computational penalty."

Why using a Jitter matrix after rendering and not disabling OpenGL and link directly the jit.qt.movie to a jit.qt.videoout ?

Anyway, I will try the "voc" message to jit.qt.movie even if I feel lazy implement it in a poly~...

"In order to support this, you will have to copy the image rendered in 
OpenGL, back to a Jitter matrix on the CPU and then send to 
jit.qt.videoout. This sort of thing will bring your framerate down 
significantly, and again, I wouldn't recommend it unless you have 
special requirements and don't mind the computational penalty."

Anyway, I will try the "voc" message to jit.qt.movie even if I feel  lazy implement it in a poly~...

finaly got a dv camera to test the all thing.

the "direct to dv" of jit.qt.movie seems to be the right thing for me because of the "voc_sound_mode" message than doesn't exist for jit.qt.videoout and I've got a sound offset if "sound remains in default device", has said in the help file.

what about the "codecquality" instruction? It is describe in the jit.qt.videoout help file but doesn't seems to existe for jit.qt.movie.

If I send a "getcodecquality" message to jit.qt.movie, "codecquality normal" is printed in the max window.

but, if I send a "codecquality $1" message with the menu, "getcodecquality" gives "codecquality max" and I can't find any message to get back to "codecquality normal"

finaly got a dv camera to test the all thing.
the "direct to dv" of jit.qt.movie seems to be the right thing for me because of the "voc_sound_mode" message than doesn't exist for jit.qt.videoout and I've got a sound offset if "sound remains in default device", has said in the help file.

The question is :
what about the "codecquality" instruction? It is describe in the jit.qt.videoout help file but doesn't seems to existe for jit.qt.movie.

If I send a "getcodecquality" message to jit.qt.movie, "codecquality normal" is printed in the max window.
but, if I send a "codecquality $1" message with the menu, "getcodecquality" gives "codecquality max" and I can't find any message to get back to "codecquality normal"

Best codec with jit.qt.videoout