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