jit.qt.movie performance? – again…
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!
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.
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 //
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
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
jit.window also draws with opengl.
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.
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.
I am playing back video in Max using qt.movie and am finding that the CPU performance is pretty bad.
Playing back a 1280×720 clip keeps the CPU at 55%-60%. Is this normal? I would think that this should not
be a big deal, I am running things on a pretty fast machine…
Model Name: MacBook Pro
Processor Name: Intel Core i7
Processor Speed: 2.5 GHz
Total Number of Cores: 4
Memory: 8 GB
Graphics: AMD Radeon HD 6770M
I have pasted my test patch below. Any ideas why it is hogging so much CPU power?
----------begin_max5_patcher---------- 1639.3oc4asrbihCEcs8WAE0rzSJj3k8rpmcylopYeWckRFjIpaLhAjcR2c0 +6id.XgCOjeDGSlEgjHIPGcz4p68BR+b9L60zWvk1V+g0mslM6mymMSVjnfY U++L6snWhRQkxlYynIIoX6Eppn6XoXF664X0yvljwrs9RUs4HVzSjrjGKvQL UC.KgO3rvJPdE5Tes4VHwxdgt9q+Nzyt44Tf1hY3hGwYn0ox9xoptrcaIYbL HQG3PgJjoJUT3ulOWbYggCyL7ybLTC.F9EI9s4nnfZ45z63eMJKwDBXUn3p+ xgH.vp5tYCMikwo.YU+YAAkZ20vG18vW6gTR9g7g.3f3LXkuRXOrIuLYGoWB vdA+GCH.Xfbxeo7pqeORfSj.5d9GdcIf7mIYwzmuXF.Dt5.CDzmF3TFmWOcd t0eS2Sv+SJ563hdGob13wsHVA4EiFutdxwa3PZd22TIuNF4iKEsTwK7VSRw6 wEkDZl1CYlMJOWq3YZ2hfL+JU9fBVzTDISUDnonB7dR88G1TJpfyTLNMsqPM LeYYfspR9D375aslFWtzUvbd.IAF5JUOdK0HR9jcRJM5a3XsUH4ya43LRVdA tDmwPrJbzTcLdCZWJ6wtIq10uAEg68l6b5ZlcRAIllI.Qq6TTbc2w0H9RIhu 9fQ1hLTdG2bIebrqbMpPvqUdDf0Uxnzz1U0LUxMFPYDtlEyHJvBcZdnjs4ER +WZcjxgySkQEzzzVOJUM66nlX9rcD9YRL6I4yRmJ4MmjWOEX2vQwjDbIqcYL TRY6RZ4rVWFpak2p7gr1aawmRQwRmWZUNr2s9L287jd0BBpWWqs09wV7A58X +xn9VCreq+dWyeV8xjUVZmIYtEWVhRvcxl6ooVNCRkiSitRZbk7p5uAq5mFA mIMBOcZz8pRiCnIEFiCwg5Aa1GM5BTQXnB3xE9f+vxQXvsiHut5w06XL95JW r8qaHPRU8Ei9wLlm+4XidEG3QzsawskJMRn+BkEmhs1HRfHhtKiYwKvp.ih0 adJISU6wSjaJRV2dM7dHMXnJrlkAJ+XJQm6.5rvq95dN2FcFuSW2DTX+FlKL UtUYfpja9iJ2fmvJcCj33oPrvaDw1+JgEbzzREerBt6rPVXfelZ9GJimDn90 PS..+yT451KA6996wNAyNPuWlm65EPWpbfGLlqa2fopu6gHTgB0Jl9CbwCao 6uvXgBUoGrRlAj5JX4.qQ3LUchOJi9afKjJc.ZTou+nwUFNUEmpdzdX5.3HM Oc8j+B5WesW5H3BcLWGrhLwtaoyCdJyEL9UZ9I37vDGHPWvgDU.fki5+v6LU Td8Rvd2FiSITtLyuJxxOzL41pdICGiLuzUah+lG7ao8MkQLJFPfiyovJtWSV Q7ByrJo6Jhv12njRRnVLpUYNNhrgDoBqSugq2s9nWb0okKhRiA7BU+xaL9DB uc4h3dOmKB.5oVDSOWDv.o9d+jJxsKvNobkGGxBqQeegFS3JpFTGax.R0oZz HaRo79cP1h2DzInU8g5AxMpV0M7+ih0nTLp3BSmqRbpHZOmQiX18iX5bh.Gu PdzQOIN2QSKF.+Xxi7vvuvXH8CDuE6ZhLbThD7Q88Kbg7HP2v1.dz4C32XQr iF9Wl3UzPvVeBEixYV.qOwiZBWjaM7KaP66+aRhhUQ4CCCzn8gbY4e0CK8F4 QBwXEM6QlK6cdA8VoEgzP4UG9l9gTECopOTbaGAFju8gOou3CszyWvVRAh56 leqxPSQdUCWq1bQLtjQxZ1fCetQDcT6dhDG2d+Dn9D7khPcTacBizBmJhASO D6L8f7DjkgSOH6N8fLOYctmswgbGSGuqXFZBlCuevrugRCH39BylnM7tizyS OGfSu04fSOGfPSc.J1oSGI5euv7zyah3a1eUg7VRbNkm0UUzwtKcD436UscL 7j4Bz9+fpcXIvYkbOsI9u134MmD7LUoc2Ls4YpyoNleeuvro9l.92UP1DVFb +vxlZOe+DzxJSQr2UBxVeYt9YSvtDsGG+HuKvQrGEue.x5cLU585GqhK87CL 94S3D1T8cBhA5795zjT5ZTZ0AIo4d6Xu6O+.IVczbjyDseSHpSpywBfpyqyq i7q0LeeKf0pMuZB+0S1u5fCYJbfdF.miv7aId.F.G3MCMtlPNmIZTJoiNdRB fbzwR5nijzqONR8cTj38yul+eqEtv8B -----------end_max5_patcher-----------
what is the codec/length/resolution of the movie ?
Res: 1280 × 720
Codec: Apple ProRes 422 (HQ), Timecode
if i run a 22 sec prores 442 movie i get 59% a photojpeg does the same for 35%
you are aware that 59% cpu on your system is actually ±15% of the total power of your system (=400%) (maybe it even less because of multithreading stuff)
you are aware that there is the gpu-route that many claims to be faster …
----------begin_max5_patcher---------- 1909.3oc2ZksaiaCE8Y6uBAM8wTCQpEK0VTj9CTf9ReIXfAsEsMynEGIZmjN X92KWzBksDkbphhSGfQAlTj7xCu2ycQ76ymYtN8EbtowuX7fwrYee9rYhl3M Lq32yLiQurIBkKdMyiw3jil2I6gPwwxl+Mb7A5q+dYGGPzM6II6Vkg2PkSuu 0Bq6L.AhmVxerbgkwWKmqPwDkt9weFVNMq2sIMJMCJmAfXLpOpF71zDZBJFK lh+HifhpkjLV6Tb1JbBZcj3MrJ5K4XLIIBSEaAPQioGorlnud.KWUSRB07NC Sw+arf4j+Q7N7sT0DJGtXFs4M9i4y4OtafvaLNOGsCWJ8T7KB3yLCiB0.tPn .QfBX0Ftvk8C21AWaydwrF3BrKb45.Cva.LRvOyj3KvhGIzE6hVjGgVab+VR D1XylEGe8zqvrcqQKhXZkKd7k7d0Eg19KB7APOHGsf5zHAffwB1XR+pcQq36 liY3qWqBN5.4IRHN8PDJAabOMCkjuMMKlgV4XpAreTzySAEc0ZWackfHPGHF inYjWlF.jiTaOju6HQCd.7bjTbVU.heoAY6ZUiFdLMnv1nT1jTJYmPYUhrrm G7+ZE7vUeRnHJIMQAh7rElYv.ACtq8EZKcCqd0npi+kiSY8TQJUsOP+n8dlJ kvkiboEmd0O.MDzt8qvMvTlEfbBBX+yKnEmWC6HlAwHgin0njc0m0LAl86lq +DSivv9C3jPiSoQZsNDG8ABmSt95YaGM6hOJeTg3HzqFPKKKsdskpUvkBLQK 2IvGNVdfZp.8dALcEICSMNjY5L.dTIr3HII5HZFfyxO8wyTZ+zSLdReINKqn A8zqv.79zaEQMVqy7w2VQOApMkBf8nwoLMlOcfHYroE2mlhcSdE8Q1ZOZ7Je 3wx9DcQb5IBKLVlqHlGWi6iRS4VWoYTCfw8BexwogXCd1BF2iBQGDcbLg7zQ rAn+zWYgrvfTaq.8Xpym0.coo63ASTLea1i27Mb3vhHZcZVHNqw65dmxCf9v 7bWVjCq+BmBBNoZL+YanrGXH43WTBgdqfvvqEf5Pdm7QxzW2mZ7S5zGckgPq BWNt57T54+o2Q4SQjXsFotVByyffJej1Z8Q5A+7fIcoqr8XTT9lLLNQuBims zMITD.dgwVG5JcDT0eiyBQInaMjoImU2acPfacfBcwp.rG2JGNhrEcE9nANe itcuWQkWE6d8FD.mq9f2ZDiSRcSfyJfhBrfMEjH7IbVdyT7mYhNbPo4YJCgC fOJI+8tqpIRhrIPUSY3Sjxw6W0JJiAkTFNxqSGGFdw2yT1I6Pad4PqBGUfrd hHC7bjAq6qnkw8EEkx8mp.aLbiE6OI475WT0cHdK5XDckJ9AfKZs+snM3NGb qrayL2kQBSS3BQiQxatb4dPvSzjsn3MRPGZYv4r8ww70nLNpVX4.K6jllF0r qpCRl5OJgvB2ASIRgkk.cYmj3CYBCJkERZXtmQ+kFE0Xpj8bpkdBYm0avOSB o6EykJTxdcxgxi.yJLJjrCmSa1FEsKuYKM9TJpJgp10MZ+L6aokP470YROhj igP4ebKeVcvblEsu570FsUK1gVJ8rIMNFmTr4KaVPbUXG7F2rMHyZRnkiiLf KGFN.XT6VkEIPkSuquojdu8c5WSCEmZb4WP0oXp1Q.5u+342vuNPvDHXsbCJ cS1EXBdifokNvr36rc4edafqSKfaM6UDIoKiUA9v6ucTOO8X1lRYtPyxnIRw HRnjjJt7GprDO681SBCaRcJYax4bWRuDCRC4ZkXv.kX3HIwFectpSSybzIb3 J1JvT.WgnrraWejJONT82+e00V+tNuB99VEBMKdWKJKDf0nnhHbpFaKtUlWC hiSbh7BuJIr5NTQY9SrfWJyorkOQipyEufqNdway5pQ2SxKC6rW7wGVgOdZK tl+Rv3gOugB.oXuULIe4O4SSicqg4uxe7k+h+DmDJaQZyNR4nhCITNRVTLFd 8fp9One71CTg2.GGcIt5uz9+UYtVTPCam5BZH+hxcj8ZvmsjWoFqMvYn7A.B pk5xUaw9WNxjRb6BgL9QUba1IYVpga+XzR25pA5osxWimYxGJuMur+OSRBSe 139s4HzPJOXQIvBVpCfbFecnO564SFibWq6sRCMuZCshOEaWkK5yHHwC3r9d 7vAoUUUCvyuZgzfOA03Sf1Kxf6H58+MUIM9ds7B5f3tfMU.LwL1LSHI9cd9D En3E4QDnlePG4P303ctH+gKyc3hSygJMBe+8JOhPxlJIxKXPRj8jIQKGf7.l ToAbyHMd92TfiGb.hyxoSb.CwX2uG4YXeI4XR3gTV7mEzRt9.AsqScvMt9Rd 2VZB5U67xR9gmqZpV7GObYHvBb5NlFhNL+5ILQxi6.jmoSZbVdSIN12XGVvg XiClNJP3P7O.ltHLD2Ay9AHmoiUFLHM5oTGB3LHAZ5jGwduWsHa3DKQ8alEb qIQVSn.MHCMavDJQChazeJUiFhurIjJBLjjcfSnRD3VKXH.3cUfj4ye1sggK KmcKXN6Fvb4seoqa9Bac9w7+E6fDP4A -----------end_max5_patcher-----------
and there is the jit.gl.hap chain that moves in opengl too.