Choppier DV PAL video via OpenGL


    Feb 28 2006 | 1:43 pm
    Hi,
    hopefully I can get some help here on this matter.
    When comparing a dv pal movie (yes, PhotJPEG has the same results) which is played out via jit.gl.videoplane and the same movie played out via jit.qt.movie?s "@window foo", the opengl variant looks much more jerky.
    It gets most obvious with movements in the scenes.So for example moving clouds on a sky are no more acceptable as a background projection.
    I am attaching a comparison patch, so if anyone has an idea what is wrong I would be glad to hear.
    P.S.: Using H264 the error gets more pronounced.
    Thanks
    Bernd
    OSX 10.4.5
    QT 7.04
    Latest Max/MSP/Jitter
    G5 DC 2.3GHz
    -----

    • Mar 01 2006 | 5:26 am
      would it be related to the nature of texturing ? I guess the videoplane
      object is a wrapper that decode the movie and attach the matrix to a texture
      and bind it to a plane mesh ..... right ?
      William
    • Mar 01 2006 | 7:58 pm
      On Feb 28, 2006, at 9:26 PM, William Wong wrote:
      > On 2/28/06, Bernd wrote:
      > When comparing a dv pal movie (yes, PhotJPEG has the same results)
      > which is played out via jit.gl.videoplane and the same movie played
      > out via jit.qt.movie?s "@window foo", the opengl variant looks much
      > more jerky.
      >
      > It gets most obvious with movements in the scenes.So for example
      > moving clouds on a sky are no more acceptable as a background
      > projection.
      Not able to see much differences on my powerbook, however, for
      optimal results, you should use the same qmetro 33 to drive your
      display, rather than 50ms. This could easily account for some
      jerkiness as the 33 and 50 ms metros can alternatingly double and
      skip frames.
      > P.S.: Using H264 the error gets more pronounced.
      As previously mentioned, H.264 is more expensive to decompress. Would
      recommend you avoid, batch converting to Photo JPEG or DV25/DVCPro 50
      (DVCPro 50 has much better color sampling and image quality, though
      at greater CPU expense than Photo JPEG).
      -Joshua
    • Mar 01 2006 | 9:37 pm
      The qmetro 20/33 differnce just happened when stripping down the patch.
      Using 33 all the time doesn?t change the behaviour.
      Btw. 40 would be appropriate for PAL but this also doesn?t change anything.
      Did you really compare with PAL sources? I have the impression that with NTSC DV the picture isn?t that jerky.
      Is there a chance that rendering on the cpu could improve the jerky movies? I forgot, what was the message for rendering Cg-wise?
      Thanks
      Bernd
    • Mar 01 2006 | 10:01 pm
      perhaps you are seeing the difference between 25fps and 29.97? Pal
      (25) looks much more like film, but "jerky" is a qualitative
      statement, so Im uncertain what you are referring to..
      v a d e //
      www.vade.info
      abstrakt.vade.info
      I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I
      LIVE! I LIVE! I LIVE! I LIVE!
      You will not be saved by the Holy Ghost. You will not be saved by the
      God Plutonium.
      In fact, YOU WILL NOT BE SAVED!
    • Mar 01 2006 | 10:05 pm
      On Mar 1, 2006, at 1:37 PM, Bernd wrote:
      > Did you really compare with PAL sources? I have the impression that
      > with NTSC DV the picture isn?t that jerky.
      I don't have any PAL footage. If you post a link to example footage,
      we can investigate further, however there's no reason I can think of
      that the behavior would be markedly different, aside from the reduced
      color sampling possibly requiring 2 axes of interpolation for DV PAL
      internal to the QT codec. There is nothing different about NTSC vs
      PAL as far as Jitter itself is concerned. If you could experiment by
      taking your footage and converting it to other codecs to determine if
      it is the codec. I tested with DV25 NTSC and did not notice any
      perceptible difference between direct to window and playback via
      jit.gl.videoplane in your patch.
      > Is there a chance that rendering on the cpu could improve the jerky
      > movies? I forgot, what was the message for rendering Cg-wise?
      There is no codec rendering on the GPU. It all happens on the CPU.
      The rendered image is then used as a texture. I'm not sure what
      you're referring to w/r/t "rendering Cg-wise".
      Basically, there is no other thing I can think of to improve
      performance here in Jitter (as you're using colormode uyvy and
      jit.gl.videoplane), aside from using a more efficient codec like
      Photo JPEG (as recommended *several* times, Bernd...please consider
      batch converting your footage to maximize performance, or use direct
      to window mode).
      -Joshua
    • Mar 01 2006 | 10:42 pm
      For example download the "Deep Sea 3D" excerpt at
      Then convert it to DV PAL / DV NTSC / PhotpJPEG 75%
      Load and and compare.
      Here the differnce between direct to window and opengl is really obvious with all codecs (tried it also on a powerbook G4, same behaviour).
      If you have movements all over the screen, the video is not as smooth as when played direct out(and it seems that the disk is more often active, but this could be also a bit of delusion).
      Sorry, I mixed up the native shader functionality via Cg with this thread.
      Bernd
    • Mar 01 2006 | 10:52 pm
      If this is the case, then there's nothing in the current version
      which will change this, aside from perhaps disabling the window's
      sync attribute.
      If you want the improved performance, please use direct to window.
      This is simply a choice you have to make. There's no further
      optimization settings.
      -Joshua
    • Mar 01 2006 | 11:08 pm
      I have already tried with sync 0/1 but also no difference.
      So, hoping for the next release...
      Thanks anyway,
      Bernd
    • Mar 02 2006 | 5:42 am
      > There is no codec rendering on the GPU. It all happens on the CPU.
      > The rendered image is then used as a texture. I'm not sure what
      > you're referring to w/r/t "rendering Cg-wise".
      I am really confused if there is no hardware acceleration in our graphic
      cards to decode and display a video...
      I believe most modern graphics card have a video engine to decode and
      display video.
      That's what i guess the reason of video playback directly onto a window (no
      3d involved and so the video is output directly) and a videoplane (3d
      involved and so the video image has to be stay back for texturing before
      rendering out) are different.
      Am I right ?
      William