Most efficient way to use jit.qt.movie + OpenGL

Feb 21, 2006 at 10:29pm

Most efficient way to use jit.qt.movie + OpenGL

Hi,

I thought this should be of interest for a lot of users here.

My question is, what is the most efficient (CPU/GPU-wise) way to play back 4 simultaneous movies WITHOUT hiccups (not PhotoJPEG, it?s DV and yes I know I know PhotoJpeg is more efficient but there is no time to convert all those movies).
I tried ALOT and could find no REAL theoretical/practical solution what would be best. My starting patch for discussion is below (think it as 4 times).

Variation1 (as in the patch):

1) Use individual qmetros for jit.gl.render and jit.qt.movie
2) Use @out_name in jit.qt.movie

Variation2

1) Use one “Master” qmetro to bang everything (in the right? order t b b b erase)
2) Use direct connection to jit.gl.slab from jit.qt.movie

Variation3

1) Use jit.qt.movie -> jit.gl.texture -> jit.gl.gridshape -> jit.gl.videoplane

To be honest I couldn?t manage this without a loss in quality of the picture.

Anyhow, here is the starting patch for discussion:

#P toggle 177 32 15 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 176 63 57 196617 qmetro 20;
#P window linecount 2;
#P newex 174 89 249 196617 jit.qt.movie @adapt 1 @colormode uyvy @autostart 0 @loop 0 @loopreport 1 @preroll 1 @out_name vid1;
#P toggle 50 53 15 0;
#P window linecount 1;
#P message 127 206 81 196617 jit_matrix vid1;
#P newex 126 268 242 196617 jit.gl.slab test1 @colormode uyvy @color1. 1. 1. 1.;
#P newex 69 298 333 196617 jit.gl.videoplane test1 @scale 1.25 1. 1. @depth_enable 0 @automatic 1;
#P newex 122 247 210 196617 jit.gl.slab test1 @inputs 4 @colormode uyvy;
#P newex 49 84 57 196617 qmetro 20;
#P newex 50 118 58 196617 t b b erase;
#P newex 34 330 315 196617 jit.gl.render test1 @ortho 2 @depth_enable 0 @erase_color 0 0 0 1;
#P connect 1 0 0 0;
#P connect 1 2 0 0;
#P connect 7 0 2 0;
#P connect 2 0 1 0;
#P connect 5 0 4 0;
#P connect 6 0 3 0;
#P connect 3 0 5 0;
#P connect 1 1 6 0;
#P connect 9 0 8 0;
#P connect 10 0 9 0;
#P window clipboard copycount 11;

#24543
Feb 21, 2006 at 11:19pm

Did you look at the uyvy-4dv-vidplane.pat Jitter example? Here’s a
summary:

1. use uyvy colormode for all movies
2. make sure that @highquality is enabled for all movies (can be set
before hand inside QT Player Pro if desired)
3. make sure that @unique is enabled for all movies
4. eithger use jit.gl.slab->jit.gl.videoplane or 4 instances of
jit.gl.videoplane with blend enable and various alpha values to blend
between them. Make sure that you use @colormode uyvy for jit.gl.slab
or jit.gl.videoplane (if sending directly).

On a fast dual processor G5 (2.0 Ghz or higher), you should be able
to play 4 DV streams at 30fps. Not likely on anything less than that.
As far as hiccups, you may not be able to avoid this when switching
clips without multiple instances of jit.qt.movie preloaded in
advance. As always you need to make sure you don’t have too much low
priority processing to ensure optimum framerate. There is no
advantage to using a named output matrix.

The last suggestion to improve performance is to use 4 separate
drives, one for each media file.

Here’s a simple variant of your patch, if you want to use slab. I
would *definitely* recommend batch converting to PhotoJPEG, however.
How much time could it take? The performance benefits are noticeable.

Good luck.

-Joshua

#P window setfont “Sans Serif” 9.;
#P window linecount 4;
#P comment 458 382 261 196617 alternately , you could avoid slab ,
and use 4 instances of jit.gl.videoplane with alpha channels and
blending enabled. see jit.gl.videoplane-xfade.pat in the Jitter
examples for a 2 way example;
#P window linecount 1;
#P message 401 309 127 196617 read 43j-fourwaymix.jxs;
#P window linecount 2;
#P newex 380 266 241 196617 jit.qt.movie 720 480 @colormode uyvy
@autostart 0 @loop 0 @loopreport 1 @preroll 1 @unique 1;
#P newex 314 231 241 196617 jit.qt.movie 720 480 @colormode uyvy
@autostart 0 @loop 0 @loopreport 1 @preroll 1 @unique 1;
#P number 229 80 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P user jit.fpsgui 110 461 60 196617 0;
#P window linecount 1;
#P message 511 82 121 196617 read dvducks.mov , start;
#P newex 109 519 156 196617 jit.window test1 @size 640 480;
#P window linecount 2;
#P newex 248 194 243 196617 jit.qt.movie @adapt 1 @colormode uyvy
@autostart 0 @loop 0 @loopreport 1 @preroll 1 @unique 1;
#P toggle 182 80 15 0;
#P window linecount 1;
#P newex 182 108 57 196617 qmetro 20;
#P window linecount 2;
#P newex 182 150 243 196617 jit.qt.movie @adapt 1 @colormode uyvy
@autostart 0 @loop 0 @loopreport 1 @preroll 1 @unique 1;
#P window linecount 1;
#P newex 182 392 269 196617 jit.gl.videoplane test1 @scale 1.33 1. 1.
@depth_enable 0;
#P newex 182 354 210 196617 jit.gl.slab test1 @inputs 4 @colormode uyvy;
#P newex 110 178 50 196617 t b erase;
#P newex 110 436 315 196617 jit.gl.render test1 @ortho 2
@depth_enable 0 @erase_color 0 0 0 1;
#P window linecount 3;
#P comment 425 331 261 196617 without a shader , this will use multi-
texturing’s default multiplication or use a shader like the one from
the four way mix tutorial , 43;
#P fasten 6 0 2 0 187 138 115 138;
#P connect 2 1 1 0;
#P connect 2 0 1 0;
#P connect 1 0 11 0;
#P connect 7 0 6 0;
#P connect 10 0 5 0;
#P fasten 6 0 5 0 187 137 187 137;
#P connect 15 0 3 0;
#P connect 5 0 3 0;
#P connect 3 0 4 0;
#P connect 12 0 6 1;
#P connect 10 0 8 0;
#P fasten 6 0 8 0 187 129 253 129;
#P connect 8 0 3 1;
#P connect 10 0 13 0;
#P fasten 6 0 13 0 187 129 319 129;
#P connect 13 0 3 2;
#P connect 10 0 14 0;
#P fasten 6 0 14 0 187 129 385 129;
#P connect 14 0 3 3;
#P window clipboard copycount 17;

#71136
Feb 22, 2006 at 8:05am

Thanks Joshua for your explanations and the example.

Two more things to ask:

1) My basic patch led to the conclusion that I wanted to mix the 4 movies on one screen (jit.window). In fact they should go to 4 different jit.windows (screens) on different monitors.

So the question: Is there a difference when using one “Master” qmetro for all render contexts or is it not relevant to have multiple qmetros.

2) is there a performance penalty when sending jit.qt.movie?s output through a outlet of a patch to an inlet of another patch (in opposite to using @out_name).

As always, thanks a lot.

Bernd

#71137
Feb 22, 2006 at 9:07am

If you are going to loop the 4 videos you might be better to preload
them in advance using loadram, If yout ram is large enought. Else the
seperate qt.movies takes up alot of bandwith to and from your HD.

#71138
Feb 22, 2006 at 1:34pm

Ah, and I forgot to ask a third one:

When getting the time for a jit.qt.movie is it more efficient to trigger the gettime message with the same qmetro (i.e. every 20ms [t b gettime] compared to a gettime message that comes from another qmetro every 200ms (and probably interferes with the faster 20ms “playout” thread) ?

Thanks

Bernd

#71139
Feb 22, 2006 at 1:45pm

Naturally, executing the “gettime” function takes some time, and the
less you send the message, the less time, overall, it will take. Why not
use a qlim object to thin out the data from 20ms to 200ms or so, and
trigger the gettime message that way, instead of having a 2nd qmetro?

jb

#71140
Feb 22, 2006 at 7:56pm

On Feb 22, 2006, at 12:05 AM, Bernd wrote:

> 1) My basic patch led to the conclusion that I wanted to mix the 4
> movies on one screen (jit.window). In fact they should go to 4
> different jit.windows (screens) on different monitors.
>
> So the question: Is there a difference when using one “Master”
> qmetro for all render contexts or is it not relevant to have
> multiple qmetros.

Note that performance slows down for multiple windows with sync
enabled. As previously mentioned on the list, divide the monitor
refresh rate by the number of windows with sync enabled–e.g. for 4
windows @ 30 fps, you’ll need a monitor refresh rate of 120 hz(fps).
This is often not a possibility. If you are limited to a 60 hz(fps),
you should not use more than two instances of jit.window with sync
enabled (the default). You can sometimes span a window across two
monitor outputs without problem if they are both on the same card.
Another solution is to use a 1280×960 output and send to a quad
splitter box, or four converters which can take a subrectangle (see
Johnny DeKam’s posts on this subject). Otherwise, you should use two
machines to get four outputs. This is probably desirable anyways, as
bandwidth to a second card (unless PCI-E) is poor.

As for the qmetro being global or movie specific, it should not much
matter from a performance standpoint, however a single qmetro might
simplify your patcher logic.

> 2) is there a performance penalty when sending jit.qt.movie?s
> output through a outlet of a patch to an inlet of another patch (in
> opposite to using @out_name).

No.

-Joshua

#71141
Feb 26, 2006 at 11:44pm

… picking up an old thread:

The dvducks.mov example movie is compressed in DV/DVCPRO – NTSC,
720×480.

Question is:
Does the other DV formats (DVPRO – PAL, DVCPRO50, …) also have the
same advantage using the uyvy colour-mode? Is there an optimal DV
compression? And what about frame size … could I for instance go
576×384 or 480×320 and get even faster results?

In the quest for more frames per second
~Carl Emil

#71142
Feb 27, 2006 at 7:44am

Well, DV pal has a nicer color space imo, its 4:2:0 vs 4:1:1 in NTSC
which means colors wont bleed and text will stay sharp, basically it
looks better if you start off with an uncompressed/clean source. You
can do a test yourself and take some uncompressed footage and encode
it to different codecs.

Heres a pixel sampling link that explains it: http://www.adamwilt.com/
DV-FAQ-tech.html#colorSampling – but note there are some caveats with
transcoding/generational loss, etc.

Now, DV-NTSC and DV-PAL is a video standard, but DV-25, DV-50 etc are
codecs – you can definitely play with the frame size – smaller frame
means smaller matrix in jitter which means less data to process each
‘frame’, thus higher frame rates. UYVY is a good mode to use if you
use openGL, as it results in lower bandwidth to the video card (YUV
chroma is half sampled, irc, compared to RGB). although slightly
unintuitive, sometimes lowering the frame rate of your source clip
results in faster overall processing, esp. if you do many jitter ‘fx’
in serial.

v a d e //

http://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!

#71143
Feb 27, 2006 at 6:20pm

Thanks Vade for the very precise answer.

> Heres a pixel sampling link that explains it: http://
> http://www.adamwilt.com/DV-FAQ-tech.html#colorSampling
DV makes more sense now. This one helped too:

http://www.dvcollections.com/support_dvcompress.html

> You can do a test yourself and take some uncompressed footage and
> encode it to different codecs.
I tried that and it seems like PAL 640×480 is a bit slower than NTSC
720×480 which makes sense according to the colour information you
mentioned.

> Well, DV pal has a nicer color space imo, its 4:2:0 vs 4:1:1 in
> NTSC which means colors wont bleed and text will stay sharp
I don’t know about that, I couldn’t se any notable difference in
sharpness on text nor photo when comparing PAL and NTSC. Perhaps the
colours in PAL are a bit more fresh, but that’s it. Comparing NTSC
720×480 and photo-jpeg in 400×300 i found that they look equally
blurred but NTSC+UYVY is still faster and has a smaller file size. I
saw almost no visible difference comparing NTSC 720×480 and NTSC
640×480, but I squeezed out a couple of extra frames per second using
640×480.

It seems like this works best for me:
Format: NTSC (DV/DVCPRO)
Frame-size: 640×480
Frame-rate: 25
Pixel aspect: Square
Scan mode: progressive
Field dominance: none
Audio: no track!

Please respond if you think there is a better video format for
jit.qt.movie + opengl.

~Carl Emil

#71144
Sep 14, 2008 at 12:45pm

how do you do when several movies have different fps ?
logically i’ll think to set the metro to the highest with @unique 1.
or do you use one metro for each movie and one with the higest speed for the render ?

thx.

#71145

You must be logged in to reply to this topic.