|
|
GPU-rendering for H.264 not supported? I am working on a composition to play various videos on a big screen via a triplehead2go. I thought, since QC is somehow a good friend of QT, they would solve all the problems for me. But: no. Big performance problems. I compared the performance of QC3 and QC4 to that of QTX and found out, that obviously QC is not using the GPU to render the H.246 videos. My Hardware is a new mb pro with a 9600m gt. I checked the performance with atMonitor while playing a Video 640x480, 6s, motion-jpg, Fullscreen on external Display and the same Video quicktime-compressed to h.264
So what I get from the results is a) that playing the motion-jpg-version with QC3 is more or less the same in performance as playing it with QT. But b) playing the h.264-version with QC is making even less use uf the GPU and not at all holding up with the performance of QT. QC4 is even worse in all points of view. So whats up here? Is my system fucked up? Is my OS rubbish? Or is QC just not meant to play videos???? I appreciate every idea that helps me with my trouble! Thanks, H*ns
|
this is normal. despite your assumption that QT and QC were friends, you're mistaken, and QT is hostile to every environment it's used in (it's unable to work in 64bit mode without cheating, it's unable to deal with threading without severe handholding, it's crippled in QTKit, etc.)
you can help performance a bit in QC by setting the movie players to "asynchronous" mode, but then you lose timing control.
The reason it sucks is because QC tells the QT patch to seek to a specific time every frame, and seeking in QT is expensive. There are other expenses, but that's one of the more noteworthy ones (async works around that).
cool!!!!
that helps a lot. not only do i now know, what "asynchronous mode" is really meaning, but it decreases the cpu-load significantly! (to stay with my measurements: sync:60% -> async:20%)
but still i see more cpu- and less gpu-load with qc than with qt. +/-5%
for now i love to live with the loss of timing control since everything i need at the moment is to pause, reset and play.
but still: why is qc4 performing worse than qc3??
thanks, h*ns
qc4 performs worse than qc3 because they "optimized" qc4 (in normal situations, optimizing code makes it faster, but I think someone forgot to actually measure the results -- qc4's demonstrably slower in numerous ordinary cases, and not demonstrably faster in any non-trivial cases that I've found) -- a lot of these "optimizations" make qc4 do a lot more unnecessary work than qc3 did.
This, of course, sucks a lot :(
My, how that resoundingly echoed with me at my desktop. Many the time recently when those sort of questions, anxieties and emotions were raised by my working in Snow Leopard.
One can't even QuickLook at a composition icon without that composition's internals provoking the dreaded flourescent bulb sepia flicker.
Once I've gone through the somewhat exhausting test trail on one item, I'm going to be doing a re install of SL on top of Leo, so I can enable QT7 in SL as my recent clean SL reinstall missed that and QT7 doesn't seem to have half the codec facilities that QT , for all its faults, had.
Thanks for the head's up on this cwright. Helped to clarify one whole lot of stuff I'd been wondering about in regards of Snow Leopard.
Thank goodness for Leopard, partitioning and dual boot systems :-) .