Forums > Jitter

Best codec with jit.qt.videoout

January 28, 2009 | 4:23 am

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


January 28, 2009 | 2:41 pm

completely wrong thing to do.

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.

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

>
> 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


January 28, 2009 | 4:04 pm

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


January 28, 2009 | 4:15 pm

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:

>
> 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


January 28, 2009 | 6:30 pm

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

> 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:

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

> 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.

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

My favorite codec resource website is:

http://codecs.onerivermedia.com/

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

-Joshua


January 28, 2009 | 7:03 pm

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.

thanks for setting me straight on this.


January 28, 2009 | 8:56 pm

thank you Joshua (the second one)

One thing I don’t understand :
You said

"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."

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~…

Thank’s you both


February 2, 2009 | 5:55 pm

Hello again,

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"

– Pasted Max Patch, click to expand. –

Any idea ?


Viewing 8 posts - 1 through 8 (of 8 total)