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.
On Windows, DirectShow is typically much, much faster than Quicktime (which Apple abandoned a while back). DirectShow takes advantage of multiple cores/CPUs while Quicktime does not.
You can play a lot of Quicktime files using DS provided you have the right codec installed. I recommend the ffdshow package which covers all of the MPEGs, JPEGs and so on.
http://ffdshow-tryout.sourceforge.net/
On Wed, Mar 17, 2010 at 7:27 PM, Matteo Sisti Sette < matteosistisette@gmail.com> wrote:
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.
-- Matteo Sisti Sette matteosistisette@gmail.com http://www.matteosistisette.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
chris clepper escribió:
On Windows, DirectShow is typically much, much faster than Quicktime (which Apple abandoned a while back). DirectShow takes advantage of multiple cores/CPUs while Quicktime does not.
Oh that's funny because I'm observing a tremendously worse performance with DirectShow. So is it because of the codec? Don't QuickTime and DirectShow use the same codecs? In this case the file is DV-PAL...
chris clepper escribió:
On Windows, DirectShow is typically much, much faster than Quicktime (which Apple abandoned a while back). DirectShow takes advantage of multiple cores/CPUs while Quicktime does not.
You can play a lot of Quicktime files using DS provided you have the right codec installed. I recommend the ffdshow package which covers all of the MPEGs, JPEGs and so on.
Hi, I've just installed it and configured it to use ilbavcodec (the only available choice except "disabled") for DV video files (which is the kind of files I'm using).
I've tested again and nothing has changed: performance is awfully slow, compared to that of a 2006 version of GEM (namely gem-CVS20060412-NT-i686-bin):
** Current version (with DS):
- Every [open file.mov( message to a [pix_movie] starts eating up 30% of
an intel core duo 2.5GHz CPU (two [pix_movie] open -> about 60% cpu; three [pix_movie] -> have to open task manager and kill Pd) and it keeps consuming that much cpu even if you don't play it _and_ even after disconnecting it from the gemhead
- playing back more than one file at a time is impossible (very slow and
some frames show up black)
** 2006 version (with QT):
- can play up to 6 files at the same time, actually rendering some
portion of them to some portion of the screen (all at full size, using pix_crop)
- can "open" as much as 16 files (i guess many more) at the same time
without any significant increase in cpu consumption; obviously they do eat up some cpu at the very moment you send them the open message, but only for few seconds.
- with so many files open (and up to 4 playing at the same time) I can
at any time stop a file (disconnect the gemhead programmatically with a spigot) and start playing back another one at an arbitrary frame and I almost never get a noticeable delay; i.e. even disk access is as efficient and fast as you can conceive it to be. That's where the 16-open-file limitation comes up. And then I can open 16 more files on the same [pix_film]s ("closing" the previously opened ones) and everything goes well, so over time I open _literally_ hundreds of files, no more than 16 at a time.
I can't believe that DirectShow itself is that bad, or that much worse than an old and unupdated QuickTime. There must be something wrong with [pix_film]...
...Or with my configuration? What could it be? (affecting only DS and not QT)??
Can anybody with a Windows machine confirm this issue?
By the way, I see a "Gem Man: QT init OK" message in the console with gem 0.92.1, so I guess there still _is_ some kind of support of QuickTime. Is there a way I can tell [pix_video] to use QuickTime rather than DirectShow (until I figure out what's wrong with DS)???
I used to do that by an [open file.mov 1( message, but on the current version it does not work (and is not even mentioned in the help file, though I don't know if it was in the older version).....
Or is the QT support meant for other things, and has it been eliminated in [pix_film]??
chris clepper escribió:
On Windows, DirectShow is typically much, much faster than Quicktime (which Apple abandoned a while back). DirectShow takes advantage of multiple cores/CPUs while Quicktime does not.
You can play a lot of Quicktime files using DS provided you have the right codec installed. I recommend the ffdshow package which covers all of the MPEGs, JPEGs and so on.
http://ffdshow-tryout.sourceforge.net/
On Wed, Mar 17, 2010 at 7:27 PM, Matteo Sisti Sette <matteosistisette@gmail.com mailto:matteosistisette@gmail.com> wrote:
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. -- Matteo Sisti Sette matteosistisette@gmail.com <mailto:matteosistisette@gmail.com> http://www.matteosistisette.com _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2010-03-18 19:18, Matteo Sisti Sette wrote:
By the way, I see a "Gem Man: QT init OK" message in the console with gem 0.92.1, so I guess there still _is_ some kind of support of QuickTime. Is there a way I can tell [pix_video] to use QuickTime rather than DirectShow (until I figure out what's wrong with DS)???
I used to do that by an [open file.mov 1( message, but on the current version it does not work (and is not even mentioned in the help file, though I don't know if it was in the older version).....
Or is the QT support meant for other things, and has it been eliminated in [pix_film]??
you can see which decoding backends are used when you create the first [pix_film]. it should say something like: pix_film:: DirectShow support pix_film:: QuickTime support
and yes, the [open bla.avi 1( should still work (what it does is: first try to open the file with the "1"st codec, and if that fails try all codecs starting from 0) eventually i want to get rid of numbers, as this is not very portable (and replace it by a symbolic id, like "QuickTime")
fgamsdr IOhannes
IOhannes m zmoelnig escribió:
and yes, the [open bla.avi 1( should still work (what it does is: first try to open the file with the "1"st codec, and if that fails try all codecs starting from 0)
Oh great! I tried it with increasing numbers and indeed it does use QuickTime with [open bla.avi 2(
For some reason the older version gets QuickTime at position 1 while this version has it at position 2.
Now, just out of curiosity, it has a strange behaviour:
- if I use "0" or "1" it says:
"Trying DirectShow" and succeeds loading it with DirectShow (I say it because it is certainly not QT [see next] and because I guess if it failed it would say "trying <something else>" before succeeding)
So I may think that 0 is DirectShow, or maybe 1
- if I use "2" it does not say "try <anything>" and immediately succeeds
loading it and it is quick time (I can tell it because the file has the inglorious "high quality" flag unset and I see it at 1/4 resolution, and it only QuickTime uses that flag to my knowledge)
Why doesn't it say "Trying QuickTime"? Because it only says "trying" when the given one fails and it has to fall back? But then why does it say "trying Directshow" when I use 0? Because 0 isn't DirectShow nor is 1? But then, how is it that it falls back to DirectShow and not QuickTime?
eventually i want to get rid of numbers, as this is not very portable (and replace it by a symbolic id, like "QuickTime")
That would be great
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.
-
chris clepper -
IOhannes m zmoelnig -
Matteo Sisti Sette