Best codec with jit.qt.videoout


    Jan 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

    • Jan 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
    • Jan 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
    • Jan 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
    • Jan 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:
      > 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.
      My favorite codec resource website is:
      It hasn't been updated that much in recent years, but has good info and sample images, file sizes, etc. for many codecs.
      -Joshua
    • Jan 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.
    • Jan 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
    • Feb 02 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"
      Any idea ?