leo {depart} wrote:

hello!

i've just tried gem-bin0.888pre on winxp (with pd 0.36-0). unfortunately i have problems with pix_film and my movie files now (worked fine with gem0.87+cvs) whenever i try to load one of my movies (avi, indeo4/5.1, 512x512px) my pd crashes. when i turn rendering off, before i load the movie file, i get a a decent "pix_filmNEW: loaded... " message. if i turn rendering on then, it crashes.

• the homer.avi works fine !!, so i guess it could be a codec issue (

has the indeo support been cut? )

• further it won't accept my relative paths ("unable to find...") that i

used so far in my patches...

looks like you are using an older pre-release of gem. try the one that can be found at http://gem.iem.at/download/gem-bin-0.888pre1.zip

this should fix the relative-paths issue. about codecs: of course, the decoding is not done in Gem itself but by libraries provided by the system. this does mean, that there is no way to "drop support" for a specific codec (this is wrong too: of course a check could be done whether a file is encoded with a special codec and refuse to decode; but this would be plain malignity)

the issue seems to be more about using quicktime4windows. i haven't been able to get it really stable when decoding AVI-files (MOVs work fine however) in prior versions (i guess like the one you are using) quicktime4win has been tried prior to the "normal" (microsoft) avi-decoding. this lead to crashes when trying to load "another" movie (say: you loaded a quicktime and *then* wanted to load an avi --> crash) at least on my machine. i have changed the library order, so that microsoft's avi-loader will give a first try (and fail on quicktimes), and then quicktime will have a look. however, loading MPEGs crashes fine with me.

mfg.a.sdr IOhannes

i've just tried gem-bin0.888pre on winxp (with pd 0.36-0). unfortunately whenever i try to load one of my movies (avi, indeo4/5.1, 512x512px) my pd crashes. when i turn rendering off, before i load the movie file, i get a a decent "pix_filmNEW: loaded... " message. if i turn rendering on then, it crashes.

• the homer.avi works fine !!, so i guess it could be a codec issue ( has

the indeo support been cut? )

hi, i have not used GEM much, but recently a friend asked for a recent windows binary as the one on the site was missing or old, so out of curiosity i built it v/ vs7.1 on windows 2003

my basic observations are that GEM is using a hobbled together collection of some old aVi reading library, and an equally crusty quicktime for windows SDK, in attempt to provide readability of a variety of formats. for the sake of brevity i disabled quicktime while compiling, and found that while the homer avi loaded, only one out of about a dozen other random video clips i tried would load, a few others would load and then gem would freeze before displaying anything, etc..

unfortunately C/c++ doesnt like me as much as python/perl/et al, but depending on your level of interest & skill you might want just wipe out the old avi & quicktime reading code entirely and start with a simple DirectShow-file input module. by doing so you would support every codec that is installed at a system level, and adding new codecs would just be a matter of installing them in windows and relaunching GEM. to learn how this is done, the source to VirtualDub & MediaPlayerClassic ( http://sf.net/projects/guliverkli )might be a good starting point, the author of the latter has also made several 'splitters' that let you load quicktime & realvideo in any directshow aware player. if you need universal directshow file loading in a pd like app today, try vvvv, it already has this.. but i think adding it to GEM wouldnt be too difficult if you knew what you were doing, and would likely solve the video loading issues...until microsoft decided to change the API at least..

..