jurgen

call-for-submissions-cimatics07

here's johnny with a couple of 'highend' questions

The application i'm working on is an A/B bus video mixer at very high 

- 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 

- And finally an optional custom dome correction shader via 

- Mixing is being done via cross fading the color/blendmode of the 

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 poly~ movie engine uses an embedded 'qmetro 20' which is toggled 

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 

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.

I have plenty of cpu left (50%) and the movies (being compressed) 

aren't taxing the disks - the bottleneck feels like its at the 

I've tweaked the max performance options and it has an effect, but 

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 

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!

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)

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!

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 

On Apr 6, 2007, at 12:58 PM, dekam wrote:

> here's johnny with a couple of 'highend' questions

> The application i'm working on is an A/B bus video mixer at very 

> - 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 

> - And finally an optional custom dome correction shader via 

> - Mixing is being done via cross fading the color/blendmode of the 

> 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 poly~ movie engine uses an embedded 'qmetro 20' which is 

> 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 

> 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.

> I have plenty of cpu left (50%) and the movies (being compressed) 

> aren't taxing the disks - the bottleneck feels like its at the 

> I've tweaked the max performance options and it has an effect, but 

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!

> 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
>
>
>
>
>
>

you could try using fixed-width fonts(i think 'monaco' on os x, maybe 

you could try using fixed-width fonts(i think 'monaco' on os x, maybe  
'courier' on both platforms?).

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 

> 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 

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

what kind of drive setup are you using for testing ? i'm almost 

what happens if you skip the slab and the dome shader, same playback 

> ever tried the Sheervideo codec? I was thinking of going down that 

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% ?

> ever tried the Sheervideo codec?  I was thinking of going down that  
> road next


Ah. Of course, that makes sense about the poly~, the whole A/B mixer 

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 

> 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 

>> 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!

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?

> 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
>
>

that was the first place i looked, but a single channel on its own in 

playing off the internal sata bays (1 movie playing per drive) 

> what kind of drive setup are you using for testing ? i'm almost 

> what happens if you skip the slab and the dome shader, same 

> playback trouble ? photojpeg quality at 60% ?

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

> 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


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 ..

> that was the first place i looked, but a single channel on its own 

> playing off the internal sata bays (1 movie playing per drive) 

> compressed read datarate is under 25MB/s

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 ..

> 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


Call for submissions Cimatics07