Forums > Jitter

jit.qt.movie performance? – again…

May 27, 2006 | 7:19 pm

Hi all.

I know that this topic has been up and down the list a couple of hundred times. Nevertheless, I couldn’t find the right answers yet…

I am trying to get the best performance for playing back simultaneously four different Quicktime movies at a time. The patch should be able to re-size and re-position each video file individually right before it starts playing.

All of my quicktimes are compressed to PhotoJPEG@75%, size 768×576. (Btw: I am dealing with hundreds of video files, so it is not possible to load the files into RAM;)

I tried – unsuccessfully – different methods of getting the four video streams – with a decent 25 fps – onto the screen:
using gl.gl.render and four videoplanes –> too slow (~ 11fps);
using named matrices (like in the Jitter Tutorial 16) –> the same;
using jit.qt.movie connected to jit.window –> slightly better performance (~15fps),
and switching colormode to uyvy gives me another slight improvement, but still not good enough.

Using the jit.qt.movie direct-to-window function and four different jit.windows seems to work best so far. If the size of the jit.window is the same (or even larger!) than the size of the video file (768×576), all four videos are running at their full frame rate. But if I reduce the size of a jit.window (which I unfortunately have to do sometimes), the frame rate drops drastically (CPU…)

Am I right that it in this case has to do with some sort of interpolation (or going back to calculating a matrix instead of ‘not-bothering’ in direct mode?)??

Is there a way to get around this? (e.g. if I run four files simultaneously in Quicktime, they play smoothly even when I change their size…)

I am using Jitter 1.5.2, on a G5 dual 2.0, 1.5GB RAM, RAID0, NVIDIA GeForce6800GT

Thanks for your help!

Cheers,
Holger


May 27, 2006 | 8:40 pm

having some patches to look at would be beneficial, so we can see if
there are any bugs, or further optimizations to make.

v a d e //

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


May 27, 2006 | 9:45 pm

On May 27, 2006, at 12:19 PM, Holger Stenschke wrote:

> I tried – unsuccessfully – different methods of getting the four
> video streams – with a decent 25 fps – onto the screen:
> using gl.gl.render and four videoplanes –> too slow (~ 11fps);
> using named matrices (like in the Jitter Tutorial 16) –> the same;
> using jit.qt.movie connected to jit.window –> slightly better
> performance (~15fps),
> and switching colormode to uyvy gives me another slight
> improvement, but still not good enough.

If you’re using four windows, all with the default @sync, it would
explain the 15fps figure above. Every window with @sync diminishes
the framerate by an integer factor of the video devices frequency.
For four outputs @30fps, I would recommend using projectors/monitors
which support a native frequency of 120hz, or where possible use two
dual-monitor spanning windows with a frequency of 60hz.

In UYVY mode, I’m able to easily playback 4 DV or photo JPEG files
with a single window at full resolution and 30fps or higher, on a G5
with similar specifications you mention, using jitter-examples/video/
uyvy/uyvy-4dv-vidplane.pat. ARGB mode will be markedly slower.

As for the direct to window problems with downsampling. Everything is
out of our hands when this option is on, and QT may be using their
expensive, but high quality downsampling function.

Hope this helps.

-Joshua


May 27, 2006 | 10:52 pm

Hi Joshua, would you be so kind as to explain why multiple windows
result fps drop like that – Id love to know a bit more why this is
under the hood. Is this jitter specific?

ie: if I have 4 movies all 30 fps on 4 windows on the same screen,
why do I need to have a 120Hz output device, shouldnt I force all my
windows to draw at the same time, ie: supply the same sync signal to
them? This is common in professional video devices to have a separate
external sync ‘input’, to force drawing to occur simultaneously.

I assumed that the @sync attribute was only for vertical blanking for
GL, so that the video would be drawn in sync with the display device.
Why does having multiple windows effect the FPS that drastically?

v a d e //

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


May 27, 2006 | 11:11 pm

On May 27, 2006, at 3:52 PM, vade wrote:

> Hi Joshua, would you be so kind as to explain why multiple windows
> result fps drop like that – Id love to know a bit more why this is
> under the hood. Is this jitter specific?
>

VBL sync. Discussed on the list before (search archives). Each one
waits for the VBL sync to swap rather than all swapping
simultaneously. It may be possible to address this issue in a future
version, but this is the way it works now.

> ie: if I have 4 movies all 30 fps on 4 windows on the same screen,
> why do I need to have a 120Hz output device, shouldnt I force all
> my windows to draw at the same time, ie: supply the same sync
> signal to them? This is common in professional video devices to
> have a separate external sync ‘input’, to force drawing to occur
> simultaneously.

This would be useful for each device to swap at the same time to
prevent "tearing" across mulitple displays, but not within one display.

> I assumed that the @sync attribute was only for vertical blanking
> for GL, so that the video would be drawn in sync with the display
> device. Why does having multiple windows effect the FPS that
> drastically?

jit.window also draws with opengl.

-Joshua


May 27, 2006 | 11:51 pm

Thanks, that clears it up 100% for me.

v a d e //

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


May 30, 2006 | 3:16 pm

Thanks for all your help!

I found out that the main problem of the performance decrease was the AVID-compression (photo-JPEG 75%) of the videofiles. I still could not figure out which setting caused the problem… I will post it in case I will ever find it…

Anyway DV-PAL works pretty well now.

Thanks again.
Holger


May 30, 2006 | 3:34 pm

Holger Stenschke wrote:
> Thanks for all your help!
>
> I found out that the main problem of the performance decrease was the AVID-compression (photo-JPEG 75%) of the videofiles. I still could not figure out which setting caused the problem… I will post it in case I will ever find it…
>
I had the same problem with AVID photoJPEG A as well. I re-encoded in
QT 7.0 pro in medium quality (MJPEG) and with four videos running at
720×480 I get a respectable 20 FPS using the 4-dv-videoplane method
running 4 jit.xfades and jit.slides.
> Anyway DV-PAL works pretty well now.
>
Can you encode into dv-pal through Avid xpress pro hd?
> Thanks again.
> Holger
>



ken
May 30, 2006 | 5:03 pm

AVID compression is not a QuickTime standard. It is built for the
Avid system and not really made to be used outside of it. In general,
it�s best to stay away from codecs based on turnkey systems of any sort.
Ken
ken@kennethfeinstein.com
http://www.kennethfeinstein.com


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