jit.qt.movie major bug/issues / feature request

    May 02 2010 | 10:08 am
    So I just finished a project that required using jit.qt.movie to playback 23.98 FPS footage at a smooth rate when projected onto a second monitor/projector. It became apparent fairly late in the project that the most simple playback patch, using jit.qt.movie, was not as smooth as simply playing back the movie in quicktime itself. It would introduce a very subtle, and yet, VERY noticable "jitter" (go figure, -it's an accurate term for what seemed to be the playback of qt.movie) This was extremely surprising, as one would imagine simple, smooth video playback would be the most basic requirement of jit.qt.movie. @unique 1 or @unique 0 didn't help, nor did rendering directly to the window- although that one isn't really an acceptable solution. The reason why I didn't notice this jitter initially is because my FPS-meter maintained a constant 24+ FPS throughout, but when I later compared it against the original footage in the Quicktime program, it was obvious there was an issue. This is going straight from a qmetro > Jit.qt.movie > jit.gl.videoplane as the test patch.
    Now, 23.98 FPS is way, way below the maximum range of detectable, or at least "acceptable to where you can't tell the difference" motion in our vision systems (simple stuff being around 30, fast motion at 60+), which means that the most subtle jitteriness in playback will become apparent at 23.98 FPS.
    The workaround (with help from Luke DuBois, thank you Luke!) involved creating a dummy movie of increasing timecode that generated a new number every frame, and only triggering the renderer after the dummy movie passed through a jit.change. This worked pretty well for a single 23.98 movie, but when I had multiple movies playing at once poly~ or javascript style, it felt like some were getting rendered with different levels of smoothness. The timecode file that ended up working was very specific- upon trying several driving sources, it had to be a particular data rate, resolution, etc for the render-generator to work ok. I think it was around 280 x 30 pixels photojpeg low res generating new code for an hour and 20 mins- not a big file.
    Can this be solved? Any ideas what would be causing the issue? I would suggest as a feature request of qt.movie to include an attribute that turns on an internal driving source that uses a jit.change object to notify the renderer, but I dunno if that would be an acceptable solution for when multiple movies have to be played at once, perhaps at different speeds.
    My second issue was that user interface elements- whether they be sliders, number boxes, etc- even qlim'd, would make playback jittery- i had to have the bpatcher interface set to a -completely- non-moving UI screen during playback to ensure smooth performance. In short, the performance worked out. But, damn. those workarounds are sort of ...not long term solutions.
    Brian Chasalow

    • May 02 2010 | 11:46 am
      Had the same problem months ago. I had to play some high quality movie produced by my client. It was not possible to play it as smooth as inside the quicktimeplayer. I tryed many, many things out and wasted my time. (vades patches, UYVY shader,... )
      I am very interested in the "increasing timecode" solution brian. perhaps you can post a smal demonstration patch.
      Finaly i solved the problem by using open frameworks as a videoplayer controlled from max with osc. since the version 006 the videoplayer works like charm.
      The of videoplayer is open source, so perhaps someone can write an alternative to the jit.qt.movie object or it can be used as "inspiration" to make the jit.qt.movie better !
      That would be realy great. angy
    • May 02 2010 | 12:07 pm
      I hope and guess that Jitter on the Mac will soon allow smooth H.264 playback by implementing the Video Decode Acceleration framework recently provided by Apple:
    • May 02 2010 | 3:51 pm
      I should say- the timecode solution was the answer I came up with for multiple movies, whereas the original solution courtesy of Luke was to trigger the renderer from a jit.change, so that the movie would only be rendered if a new frame was required. thus the idea was,
      qmetro > jit.qt.movie > jit.change > t b L erase > jit.gl.render
      and the list branch off the "t b L erase" went to my jit.gl.videoplane
      maybe ill make an example patch of this in a few. the problem with this is that if you have multiple movies playing, and one of them is triggering the renderer, if your trigger movie goes black while the other movies are still playing, your renderer will just STOP because the jit.change doesnt see change in the movie.
      test it out with the jit.change example, see if it works for you, then create a dummy timecode movie essentially the length of your movie- if the timecode loops it's not the end of the world, but i found that the looping of the timecode caused a minor stutter. perhaps a clever use of the loadram command would fix that.
      (and make sure your trigger movie is @unique 1 and @loop 1 or your trigger movie will cease to trigger your renderer eventually, learned that one the hard way. not sure if the unique 1 is necessary, but i used it)
      curious to hear your experiences. Brian Chasalow
    • May 02 2010 | 8:32 pm
      I should mention- i was playing back PhotoJPEG at med-high quality to do reactive movie rate adjustment on the fly (though 90% of the time it was at rate 1 until certain sections), so one might assume H264 playback as mentioned is useful but unrelated.
      Also- this was repeatable using a MacBook Pro, mac mini, desktop, etc. Same 23.98 footage jittery across all.
    • Jun 08 2013 | 12:25 pm
      It seems this problem is not solved. Any news ? Any tricks ? It was not a real problem fro my previous projects but this time it is... thx.