HD performance with jit.qt.movie in @window direct mode


    Jun 18 2007 | 8:56 pm
    SUMMARY:
    movie playback of 1080p content is substantially lower quzlity using jit.qt.movie @window direct mode than it is using the quicktime playing in fullscreen playback mode.
    machine in question: intel mac mini, 1.67 mhz, current system, current max/jit
    STEPS TO REPRODUCE
    i used the 1080p ratatouille movie trailer here: http://www.apple.com/trailers/disney/ratatouille/ i used quicktime player to export it as a quicktime movie, codec MJPEG A, quality high, no fast start.
    i played it with the following patch:
    Expected results:
    Video smooth like butter.
    Actual results:
    the resulting compressed movie played back seamlessly with the quicktime player, but when using the following patch, playing it back into a jit.window using @window direct, quality was stuttery and teary.

    • Jun 19 2007 | 12:14 am
      I've had the same problems with the same setup as you. In the end it seemed the best way to play back HD movies was to use Applescript to control QuickTime player from Max.
    • Aug 30 2007 | 8:49 am
      Joshua,
      I read the video, then press 'window boobah' and without enabling the metro, the video starts playing and is being displayed properly in the window. That's intended behaviour, right?
      Then, when I set the window to fullscreen or move the window to another screen, the window stops updating (but the sound continues playing). Only when I switch on the metro the window starts being updated again. And when I switch the metro off it continues being updated properly. Seems a little buggy.
      Anyway, I noticed no hiccups of any kind, neither in the small window or fullscreen.
      Mattijs
      Max 4.6.3, Jitter 1.6.3, Mac OS 10.4.10, Quicktime 7.2.0, Quad Intel 2.66
    • Aug 30 2007 | 7:50 pm
      > use Applescript to control QuickTime player from Max.
      Oh ! interesting ! is it hard to do ?
    • Aug 30 2007 | 8:25 pm
      Compare it to straight quicktime player, there are framerate hiccups
      (whose size ad frequency vary with your performance settings and
      window update intervals), but they are there. I believe this is
      because of low priority queues needing to be serviced interrupting/
      blocking drawing, but I am speculating about the cause. However, I
      have seen this on all systems I work with, from Octo Mac Pros with
      Quadro FX 4500's to Powerbooks.
      It is not as bad with uncompressed media, and much more noticeable
      with higher compressed video (h.264), and again I believe this is
      because decompression and drawing happen serially in the same thread
      (again, speculation), but regardless of the cause, it is there
      regardless of codecs.
      And it gets worse when playing that video to a GL world without
      direct to window, even with YUV.
      On Aug 30, 2007, at 4:49 AM, Mattijs Kneppers wrote:
      >
      > Joshua,
      >
      > I read the video, then press 'window boobah' and without enabling
      > the metro, the video starts playing and is being displayed properly
      > in the window. That's intended behaviour, right?
      >
      > Then, when I set the window to fullscreen or move the window to
      > another screen, the window stops updating (but the sound continues
      > playing). Only when I switch on the metro the window starts being
      > updated again. And when I switch the metro off it continues being
      > updated properly. Seems a little buggy.
      >
      > Anyway, I noticed no hiccups of any kind, neither in the small
      > window or fullscreen.
      >
      > Mattijs
      >
      > Max 4.6.3, Jitter 1.6.3, Mac OS 10.4.10, Quicktime 7.2.0, Quad
      > Intel 2.66
      >
      > --
      > SmadSteck - http://www.smadsteck.nl
      > Hard- and software for interactive audiovisual sampling
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Sep 07 2007 | 2:01 am
      Quote: Kyred wrote on Thu, 30 August 2007 13:50
      ----------------------------------------------------
      > > use Applescript to control QuickTime player from Max.
      >
      > Oh ! interesting ! is it hard to do ?
      ----------------------------------------------------
      The script looks like this:
      tell application "Finder"
      open ("/Users/me/Documents/Video/MyVideo.mov" as POSIX file)
      end tell
      tell application "QuickTime Player"
      set looping of document 1 to true
      present document 1 scale screen
      end tell
      You can use the tap.applescript external to launch it.
      Jean-Marc
    • Sep 07 2007 | 6:23 am
      But with this method, should you want to queue more than one movie
      back to back, as separate files, dont you get the weird QT window
      pop over? Can you queue movies seamlessly back to back without
      leaving fullscreen at the end of one movie?
      Curious , as I have not had the chance to try this in any capacity,
      if the above is possible, I wish I knew a few days ago! :)
      ======
      Back to jitter land,
      Jitter 1.6.3/Max 4.6.3
      I have a patch (attached to this mail) I am using for a performance,
      an incredibly paired down/simple qt/gl patch, on a quad 2.5 Ghz G5
      with 8GB of ram and NVidia Quadro FX 4500. It cues with movies with
      19 jit.qt.movies with @preroll 1, @unique 1, @colormode uyvy, @adapt
      1 and @loop 0.
      Only one movie plays at a time, and bangs are gated and switched
      'around' all others so only one is active. All movies are stopped
      untill needed. I have one GL object, a slab, @automatic 0. I use a
      uyvy2rgba shader and a simple 'fade to color' custom shader. I have
      playback issues if the shaders are not in the pipeline as well, just
      so you know.
      There are no ui objects. not even an fpsgui. Main timing is triggered
      by a qmetro 2.
      Playing DVCProHD (that is, 1280x720p@60Hz) footage with this simple
      of a patch will continuously stutter. Very visibly.
      Direct to window leads to even worse performance (oddly enough). if
      I follow the direct to window noaccel route in fullscreen, I get
      consistent very low frame rates in full screen, regardless of menubar
      being visible or windows being overlayed. Playback seems somewhat
      better, but still not in any way shape or form 'right' in a windowed
      mode. Replacing 'fullscreen' with a rect message that still takes up
      the full screen still results in impressive stuttering for such a
      machine. I have this behavior on the quad and on my macbook pro.
      For reference, I have benchmarked the drives (they are 90% empty) and
      there is more than sufficient disk througput.
      Movies can be long, but nothing but playback at rate 1 occurs. this
      is simply sending 'start' to the movies.
      I have confirmed that Quicktime and Final Cut can play back these
      clips to the same size output (second monitor) without any visible
      framerate drops, hiccups or glitches.
      Converting to UYVU seemed to somewhat improve the situation, but
      stuttering still happens.
      I have attached a version of the patch with cuing missing. I feel as
      though I havent gotten a straight answer from anyone about this when
      I send a patch, except the 'it works for me'. Maybe Im better at
      seeing stuttering?
      I know this topic is a little sore, so apologies Cycling, I really
      hope this is not seen as a nagging/get your shit together/etc sort of
      a rant, I am attaching the patch in an attempt to isolate or identify
      any strategies I (and others) can use to, in the real world, on real
      systems in real patches, get top performance with Jitter for high
      quality playback.
      I feel i should note that, myself withstanding, other people working
      with me have noted the stuttering, but deem it somewhat acceptable
      (so we are sticking with Jitter for its flexibility and ease to
      change cues/timing etc). So it isnt "just me".
      Ive also played back these files with the movie and slab help files
      with the @adapt 1 added to jit.qt.movie, and see the same stuttering
      behavior.
      I do not expect or want any immediate fixes for this either, im
      simply curious at this point what the response will be. Again,
      apologies for bringing /extending this sore topic. Thanks in advance.
      p.s. Yes, I am aware that other codecs might free the CPU and
      scheduler to do more, but, at this point, I dont think that is much
      the issue?
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Sep 12 2007 | 7:03 pm
      Anyone care to comment?
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Sep 13 2007 | 9:21 am
      Hi vade, the attachment doesn't show up on the forum :/
      Could you post the attachment via the forum or upload the patch somewhere and post the link?
      Thanks,
      Mattijs
    • Sep 13 2007 | 1:32 pm
      hello vade, for a playback project last year we made a basic app with
      jitter for mixing two pal quicktime files (720*576). we tried
      everything we could think of and everything that people on the list
      suggested, but it kept stuttering. the ammount of pixels we used with
      two files are roughly the same as you do with one file. if you work
      on lower resolution the stuttering will probably dissapear......;-(
      we are also very interested to know what causes these playback
      problems and it would be great to know when they are scheduled to be
      solved.
      best lucas
    • Sep 13 2007 | 1:51 pm
      Hi Vade,
      Yes I'd love to comment but, without wanting to sound too bitter,
      ever since my last attempt at doing proper fullscreen pal dv mixing
      ("Pmac quad 4xdv playback trouble" thread sept. 2006) and failing
      miserably I have given up all hope of doing such a thing in jitter.
      I've kept an archive of the recurring discussions surrounding this
      topic and to my knowledge no one, except maybe dekam, dunno, has
      managed to come to an agreeable result or solution (= proper
      stutterless and 'artifact-less' playback when fullscreen mixing two
      or more streams of DVPAL or higher resolution material). I've done
      some more testing since last september, mainly looking for other
      software solutions, and I've found that the problems I was
      encountering were definetely not hardware related (harddrive speeds,
      graphic cards, etc.). Software like Catalyst (http://www.samsc-
      pm.com/) or Pandora (http://coolux.de/) has no problems doing similar
      stuff with similar hardware setups. So my conclusion is that it must
      be a problem somewhere inside jitter, and I'm waiting for the next
      grand update to see if anything has changed .. In the mean time i'll
      have a look at your patch and report back. Could you possibly put
      some testing material online ? (.mov)
      best, Gideon.
      On 12-sep-2007, at 21:03, vade wrote:
      > Anyone care to comment?
    • Sep 13 2007 | 6:09 pm
      All I can say at this point is that we take these complaints
      seriously and are investigating some possible solutions. We can't
      commit to anything at this point and Max 5 is currently our biggest
      priority. Since we aren't a fixed architecture, dedicated video
      mixing application, it's not as easy for us to revisit our threading
      model as some of the examples used in comparison. I will say that the
      performance is noticeably better than many other programmable
      interactive media software environments, but there's several things
      we can do to try and make this better. Thanks for your feedback.
      -Joshua
    • Sep 13 2007 | 7:23 pm
      Thanks Joshua. Sorry for harping/dragging this back up. I think the
      issue is really comes down to what people can expect Jitter to do -
      and there is some confusion about that very expectation ( I myself am
      guilty). We all know Jitter was not designed explicitly for Mixing
      HD, and inherits a legacy of non video us and architecture, but there
      is no clear delineation, and it seems like users have had mixed
      signals about this very topic.
      I dont think anyone expects an immediate fix, nor wants it, but is
      more confused about what to realistically expect.
      I am however very encouraged by your remarks and anxiously look
      forward to late next year when more 2.0 news might be available (yes
      I am speculating on that date - I know 2.0 is not even in development :)
      Thanks,
      On Sep 13, 2007, at 2:09 PM, Joshua Kit Clayton wrote:
      >
      > All I can say at this point is that we take these complaints
      > seriously and are investigating some possible solutions. We can't
      > commit to anything at this point and Max 5 is currently our biggest
      > priority. Since we aren't a fixed architecture, dedicated video
      > mixing application, it's not as easy for us to revisit our
      > threading model as some of the examples used in comparison. I will
      > say that the performance is noticeably better than many other
      > programmable interactive media software environments, but there's
      > several things we can do to try and make this better. Thanks for
      > your feedback.
      >
      > -Joshua
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Sep 13 2007 | 8:39 pm
      But, at a risk of repeating myself, I'd like to mention that there is always the possibility of recording all necessary parameters (including movie times) of your real time performance or mixing patch and making an 'offline' render later. The render will contain no hiccups.
      Mattijs
    • Sep 13 2007 | 10:11 pm
      Well, that kind of defeats the realtime nature of Jitter eh? I could
      just use aftereffects then no?
      ;)
      On Sep 13, 2007, at 4:39 PM, Mattijs Kneppers wrote:
      >
      > But, at a risk of repeating myself, I'd like to mention that there
      > is always the possibility of recording all necessary parameters
      > (including movie times) of your real time performance or mixing
      > patch and making an 'offline' render later. The render will contain
      > no hiccups.
      > Mattijs
      > --
      > SmadSteck - http://www.smadsteck.nl
      > Hard- and software for interactive audiovisual sampling
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Sep 14 2007 | 3:22 pm
      Hehe, 3D studio max is what I had in mind, talking about non-realtime.. ;)
      But seriously, performing in low-res but realtime with jitter (thus adding some 'groove' and 'vibe' and 'feeling') and rendering back non-realtime in hi-res can be very interesting if the final product is to be used in a non-realtime production.
      Of course it would be utterly ideal if Jitter had the same constant realtime playback performance as quicktime does.
      Mattijs
      Quote: vade wrote on Fri, 14 September 2007 00:11
      ----------------------------------------------------
      > Well, that kind of defeats the realtime nature of Jitter eh? I could
      > just use aftereffects then no?
      >
      > ;)
      >
      > On Sep 13, 2007, at 4:39 PM, Mattijs Kneppers wrote:
      >
      > >
      > > But, at a risk of repeating myself, I'd like to mention that there
      > > is always the possibility of recording all necessary parameters
      > > (including movie times) of your real time performance or mixing
      > > patch and making an 'offline' render later. The render will contain
      > > no hiccups.
      > > Mattijs
      > > --
      > > SmadSteck - http://www.smadsteck.nl
      > > Hard- and software for interactive audiovisual sampling
      >
      > v a d e //
      >
      > www.vade.info
      > abstrakt.vade.info
      >
      >
      >
      >
      >
      >
      ----------------------------------------------------
    • Sep 19 2007 | 7:54 pm
      Hello, does anybody have experience with 1080i input via a Decklink
      Intensity card?
      We are using a MacPro 2.66 with 3GB RAM with a Decklink Intensity
      card. We have a very basic patch using jit.qt.grab sending the image
      directly to a videoplane.
      The framerate we get is around 22 fps, even if we put several slabs
      between the jit.qt.grab and the videoplane. So it looks like it has
      to do with system/hardware limitations.
      Are there any tricks to speed this up, is there a faster/better way
      to get the grabbed image into the videoplane?
      Best Lucas
    • Sep 20 2007 | 9:43 am
      here's something for the wishlist - honestly, I'd like to see jitter
      use ffmpeg (like mplayer) for more support of codecs and cross-
      platform capability, plus what I think is better performance and
      handling of dropped frames.
      of course, maybe that's a dream... ffmpeg is not the easiest library
      to use, but it works pretty darn well when it does
      ...and then there could be a linux version sometime in the future...
      cheers
      evan
      On Sep 14, 2007, at 4:22 PM, Mattijs Kneppers wrote:
      >
      > Hehe, 3D studio max is what I had in mind, talking about non-
      > realtime.. ;)
      >
      > But seriously, performing in low-res but realtime with jitter (thus
      > adding some 'groove' and 'vibe' and 'feeling') and rendering back
      > non-realtime in hi-res can be very interesting if the final product
      > is to be used in a non-realtime production.
      >
      > Of course it would be utterly ideal if Jitter had the same constant
      > realtime playback performance as quicktime does.
      >
      > Mattijs
      >
      > Quote: vade wrote on Fri, 14 September 2007 00:11
      > ----------------------------------------------------
      >> Well, that kind of defeats the realtime nature of Jitter eh? I could
      >> just use aftereffects then no?
      >>
      >> ;)
      >>
      >> On Sep 13, 2007, at 4:39 PM, Mattijs Kneppers wrote:
      >>
      >>>
      >>> But, at a risk of repeating myself, I'd like to mention that there
      >>> is always the possibility of recording all necessary parameters
      >>> (including movie times) of your real time performance or mixing
      >>> patch and making an 'offline' render later. The render will contain
      >>> no hiccups.
      >>> Mattijs
      >>> --
      >>> SmadSteck - http://www.smadsteck.nl
      >>> Hard- and software for interactive audiovisual sampling
      >>
      >> v a d e //
      >>
      >> www.vade.info
      >> abstrakt.vade.info
      >>
      >>
      >>
      >>
      >>
      >>
      > ----------------------------------------------------
      >
      >
      > --
      > SmadSteck - http://www.smadsteck.nl
      > Hard- and software for interactive audiovisual sampling
    • Sep 04 2013 | 2:58 pm
      Hello,
      I'm resurrecting this because it has been a few years and two versions of Max later and this seems to continue being an issue. Trying to play two 1080p videos using jit.qt.movie gives bad results with the videos stuttering. Exactly the same two videos play simultaneously and completely smooth using standalone QuicktimePlayer. I've also tried all sort of different suggestions found here in the forums without any improvement (including using OpenGL). The videos are compressed using Photo JPEG, as suggested by some here in the forums as the best format for Jitter. I also tried using ProRes. For a video installation we had to abort the idea of using Max and resorted to using ArraySync by NaSoLab. It would be nice to be able to use Max instead, though.
      Best,
      Hector
    • Sep 04 2013 | 3:06 pm
      Hello, have you tried the HAP codec?
    • Sep 04 2013 | 5:50 pm
      another option to jit.gl.hap is to use the 64 bit max6 jit.qt.movie.
      the 64 bit version of direct-to-window should perform better than the 32 bit version.
      you might even want to try h264 codec with this, if you're not frequently jumping around in time, or changing speed.
      if you don't want direct-to-window, jit.gl.hap is your best bet.