Hi,
So does anybody use [pix_film] on Windows with DirectShow (as opposed to QuickTime) and get decent performance?
Whenever I send an [open ( message to a pix_film, it starts eating up a lot of CPU and it never stops afterwards, even if I send it [auto 0( and/or disconnect the gemhead from it. More than a couple of [pix_film] lead to an unusable patch.
I have tried with a couple more codecs (besides DV-PAL: namely "animation" and h264) with DirectShow and the same happens, so it is not something specific to DV-PAL.
If I use QuickTime (thanks to the list for hints to force gem to use Quicktime) everything goes smooth. Isn't it strange? Chris wrote:
On Windows, DirectShow is typically much, much faster than Quicktime (which Apple abandoned a while back).
I also tried ffdshow-tryout codecs as Chris suggested but nothing changed.
thanks m.
Matteo Sisti Sette escribió:
Hi,
With the latest release of Gem pix_film eats about ten or twenty time more CPU than a precompiled binary compiled in August 2006 that I downloaded time ago. And it eats so much cpu after opening a file no matter whether it is playing it or not (I mean even after disconnecting the gemhead from it). That didn't happen in the 2006 version
So I've realised that with the 2006 version of gem, it uses QUICKTIME, while when I use the latest version it uses DIRECTSHOW.
Digging into the patch (which I wrote a couple of years ago for the 2006 version) I notice I opened files with a message like this: [open myfile.mov 1(
That "1" is undocumented in the current help patches, but iirc I used it in order to force [pix_film] to use quicktime rather than directshow.
Was that feature removed? If so, is there another way to force gem to use quicktime rather directshow? I'd like to test with quicktime to figure out whether this absurdly huge cpu consumption is due to the use of DirectShow as opposed to Quicktime, or if it is just a bug introduced in some recent version of Gem.
thanks m.