Forums > Jitter

Call for submissions Cimatics07

April 6, 2007 | 12:13 pm



sm
April 6, 2007 | 3:18 pm


April 6, 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 – 1400×1050 (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


April 6, 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 – 1400×1050 (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 //

http://www.vade.info
abstrakt.vade.info


April 6, 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


April 6, 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


April 6, 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


April 6, 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 //

http://www.vade.info
abstrakt.vade.info


April 6, 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


April 6, 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


Viewing 10 posts - 1 through 10 (of 10 total)