Call for submissions Cimatics07


    Apr 06 2007 | 12:13 pm

    • Apr 06 2007 | 3:18 pm
    • Apr 06 2007 | 4:58 pm
      here's johnny with a couple of 'highend' questions
      first some background...
      The application i'm working on is an A/B bus video mixer at very high
      res - 1400x1050 (sxga+)
      - I'm using standard methods for high res playback, except for
      colormode is not uyvy (more on this later)
      - I have a poly~ movie playback engine, triggering is working great.
      - From the jit.qt.movie object(s) it goes straight to gpu into a
      series of jit.gl.slab effects chain.
      - And finally an optional custom dome correction shader via
      jit.gl.shader and a videoplane.
      - Mixing is being done via cross fading the color/blendmode of the
      two videoplanes.
      The app works as expected, except a couple of issues, one of which is
      only when reaching the upper limit of resolution
      (ie 720p playback works great, but sxga+ is dropping frames)
      This is all on a quad Macpro with ATI XT1900 - pretty super.
      The issues/questions are this:
      The poly~ movie engine uses an embedded 'qmetro 20' which is toggled
      per instance of playback
      i'm wondering if this might be one source of dropped frames at high-
      res? there was mention earlier of using an audio rate clock as an
      alternative for tighter timing - can someone provide an example? or
      any other alternative suggestions here?
      The other issue is a noticeable difference in display from direct to
      window drawing, in the form of subtle banding (colorspace issues)
      since the chain is running on the gpu in RGBA, this was unexpected,
      and i wonder if there is any advice or strategy for fixing the problem?
      Obviously codec has come into play here, so far photojpeg and Apple
      IC have performed best, but aren't quite hitting the mark. can
      anyone tell me - what are the native colorspaces of these codec? if
      they are YUV than perhaps this is where the banding is occurring (yuv
      to rgba translation) some of the effects shaders aren't behaving
      properly in uyvy which is one reason i'm avoiding it.
      Additional notes:
      I have plenty of cpu left (50%) and the movies (being compressed)
      aren't taxing the disks - the bottleneck feels like its at the
      decompression->gpu stage.
      I've tweaked the max performance options and it has an effect, but
      nothing helps enough.
      Both problems ~might~ disappear once we get the machine onsite where
      they have a fiber channel NAS waiting (then we can use uncompressed
      rgba movies) but we want this to run without this option.
      Its oh-so very close to working perfectly... it just needs some
      tweaking in just the right spots.
      I know i may have answered my own questions more or less, but I
      wanted to run this past the gurus and see if there are any other
      options to explore - thanks for your help!
      --deKam
    • Apr 06 2007 | 5:20 pm
      Hi im hardly a guru, but my first suggestion would be is if you are
      using multiple qmetros for your timing, slave them to one clock
      source using the setclock and clock messages like :
      I have a clocker object powering a clock named v001.Clock , which is
      referenced by all of my line, delay, metro, etc objects that use
      timing, and it does help if you have enough clock sources. Not sure
      if that will help you here but it wont hurt to have all of the
      qmetros referencing the same timing source.
      As for the color banding, that is rather odd. I do know that
      Quicktime has historically had sub par color matching in its codecs,
      especially with the DV codec and its gamma settings, but this sounds
      like something else all together.. Have you tried matching the color
      between direct to window and your render chain sans any slab effects?
      Perhaps its a shader doing a little something behind your back?
      Sounds like a fun project, im helping someone build something similar
      - fun fun!
      Good luck.
      On Apr 6, 2007, at 12:58 PM, dekam wrote:
      > here's johnny with a couple of 'highend' questions
      >
      > first some background...
      > The application i'm working on is an A/B bus video mixer at very
      > high res - 1400x1050 (sxga+)
      > - I'm using standard methods for high res playback, except for
      > colormode is not uyvy (more on this later)
      > - I have a poly~ movie playback engine, triggering is working great.
      > - From the jit.qt.movie object(s) it goes straight to gpu into a
      > series of jit.gl.slab effects chain.
      > - And finally an optional custom dome correction shader via
      > jit.gl.shader and a videoplane.
      > - Mixing is being done via cross fading the color/blendmode of the
      > two videoplanes.
      >
      > The app works as expected, except a couple of issues, one of which
      > is only when reaching the upper limit of resolution
      > (ie 720p playback works great, but sxga+ is dropping frames)
      >
      > This is all on a quad Macpro with ATI XT1900 - pretty super.
      >
      > The issues/questions are this:
      >
      > The poly~ movie engine uses an embedded 'qmetro 20' which is
      > toggled per instance of playback
      > i'm wondering if this might be one source of dropped frames at high-
      > res? there was mention earlier of using an audio rate clock as an
      > alternative for tighter timing - can someone provide an example?
      > or any other alternative suggestions here?
      >
      > The other issue is a noticeable difference in display from direct
      > to window drawing, in the form of subtle banding (colorspace
      > issues) since the chain is running on the gpu in RGBA, this was
      > unexpected, and i wonder if there is any advice or strategy for
      > fixing the problem?
      >
      > Obviously codec has come into play here, so far photojpeg and Apple
      > IC have performed best, but aren't quite hitting the mark. can
      > anyone tell me - what are the native colorspaces of these codec?
      > if they are YUV than perhaps this is where the banding is occurring
      > (yuv to rgba translation) some of the effects shaders aren't
      > behaving properly in uyvy which is one reason i'm avoiding it.
      >
      > Additional notes:
      > I have plenty of cpu left (50%) and the movies (being compressed)
      > aren't taxing the disks - the bottleneck feels like its at the
      > decompression->gpu stage.
      >
      > I've tweaked the max performance options and it has an effect, but
      > nothing helps enough.
      >
      > Both problems ~might~ disappear once we get the machine onsite
      > where they have a fiber channel NAS waiting (then we can use
      > uncompressed rgba movies) but we want this to run without this option.
      >
      > Its oh-so very close to working perfectly... it just needs some
      > tweaking in just the right spots.
      >
      > I know i may have answered my own questions more or less, but I
      > wanted to run this past the gurus and see if there are any other
      > options to explore - thanks for your help!
      >
      > --deKam
      >
      >
      >
      >
      >
      >
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Apr 06 2007 | 5:28 pm
      Hi,
      you could try using fixed-width fonts(i think 'monaco' on os x, maybe
      'courier' on both platforms?).
      hth,
      nesa
    • Apr 06 2007 | 5:56 pm
      thanks vade
      hmm - well, there are only two qmetros running at any given time, the
      way that the poly~ movie works, only the active instance is turned
      on. (so technically its a monophonic poly~ :) which is all about
      preloading the movies instead of using a 'read' command. i do often
      use a 'masterclock' for timing - usually its a single reference that
      I 'send blackburst' and pick up as needed.
      i was thinking more along the lines of scheduler priority timing
      stuff.
      > As for the color banding, that is rather odd. I do know that
      > Quicktime has historically had sub par color matching in its
      > codecs, especially with the DV codec and its gamma settings, but
      > this sounds like something else all together.. Have you tried
      > matching the color between direct to window and your render chain
      > sans any slab effects? Perhaps its a shader doing a little
      > something behind your back? Sounds like a fun project, im helping
      > someone build something similar - fun fun!
      ever tried the Sheervideo codec? I was thinking of going down that
      road next
      -deKam
    • Apr 06 2007 | 6:07 pm
      hey deKam,
      what kind of drive setup are you using for testing ? i'm almost
      certain the bottleneck is there ..
      what happens if you skip the slab and the dome shader, same playback
      trouble ? photojpeg quality at 60% ?
      best, gid
      On 6-apr-2007, at 19:56, dekam wrote:
      > ever tried the Sheervideo codec? I was thinking of going down that
      > road next
    • Apr 06 2007 | 6:08 pm
      Ah. Of course, that makes sense about the poly~, the whole A/B mixer
      thing ;)
      Ive played with it a bit, but nothing scientific. What happens if you
      load a tiff with colorbars into one of the channels, and compare to
      direct to window?
      On Apr 6, 2007, at 1:56 PM, dekam wrote:
      > thanks vade
      >
      > hmm - well, there are only two qmetros running at any given time,
      > the way that the poly~ movie works, only the active instance is
      > turned on. (so technically its a monophonic poly~ :) which is all
      > about preloading the movies instead of using a 'read' command. i
      > do often use a 'masterclock' for timing - usually its a single
      > reference that I 'send blackburst' and pick up as needed.
      >
      > i was thinking more along the lines of scheduler priority timing
      > stuff.
      >
      >> As for the color banding, that is rather odd. I do know that
      >> Quicktime has historically had sub par color matching in its
      >> codecs, especially with the DV codec and its gamma settings, but
      >> this sounds like something else all together.. Have you tried
      >> matching the color between direct to window and your render chain
      >> sans any slab effects? Perhaps its a shader doing a little
      >> something behind your back? Sounds like a fun project, im helping
      >> someone build something similar - fun fun!
      >
      > ever tried the Sheervideo codec? I was thinking of going down that
      > road next
      >
      > -deKam
      >
      >
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Apr 06 2007 | 6:27 pm
      that was the first place i looked, but a single channel on its own in
      qt player doesn't drop frames,
      playing off the internal sata bays (1 movie playing per drive)
      compressed read datarate is under 25MB/s
      -dekam
      > hey deKam,
      >
      > what kind of drive setup are you using for testing ? i'm almost
      > certain the bottleneck is there ..
      > what happens if you skip the slab and the dome shader, same
      > playback trouble ? photojpeg quality at 60% ?
      >
      > best, gid
    • Apr 06 2007 | 7:16 pm
      mmyes.. the quicktime player vs. jitter comparison has never worked
      for me. it would be interesting to see how the jitter app performs
      without the slab and shader, but with the two videoplanes ..
      On 6-apr-2007, at 20:27, dekam wrote:
      > that was the first place i looked, but a single channel on its own
      > in qt player doesn't drop frames,
      > playing off the internal sata bays (1 movie playing per drive)
      > compressed read datarate is under 25MB/s