Hi,
I use GEM under Windows XP, been using it for almost one year.
I used to use a version of GEM that I found somewhere among CVS snapshots or something, a precompiled binary compiled in 2006 for winNT, because it is the ONLY stable version that I found capable of handling DV-PAL-coded videos without crashing; and at that time (summer 2007), the most recent official release dated back to august 2004.
Recently a few months ago I think I remember a new official release was announced though I can't find it in the list archives. Now yesterday I had a look at http://gem.iem.at/ (isn't it the most official place to look at?), and download the binaries for windows at the top of the page. It says (on that page): "released 2007-07-04". However, the gem.dll file is dated august 2004, and I tried it and this is the output I can see on the PD window:
GEM: Graphics Environment for Multimedia GEM: ver: 0.90 GEM: compiled: Aug 3 2004
And I can assure I am using the version I just downloaded, namely gem-0.90.1-W32-i586-bin-doc.zip
So I'm really confused: it is said to have been released in july 2007 and yet it is still the old binary compiled in 2004???? Is there an error in the packaging? Am I downloading it from an obsolete page?
By the way, it crashes if I load a DV-PAL avi file in a pix_movie. (doen't crash with homer.avi). It does not crash when it loads though, it crashes when I turn on the [gemhead] chain containing the pix_movie with the file already loaded. (very same patch works perfectly with the old 2006 version, which indeed is newer).
Now I will try the 0.91 beta, however I am a bit confused about this supposed 0.90.1 which seems to be indeed 0.90........
Matteo Sisti Sette wrote:
Hi,
And I can assure I am using the version I just downloaded, namely gem-0.90.1-W32-i586-bin-doc.zip
So I'm really confused: it is said to have been released in july 2007 and yet it is still the old binary compiled in 2004????
the release date "2007-07" is obviously wrong, and the compile date "2004" is correct. the dates differ, because i migrated the webpages and did not care to open each and every binary to see on which date it _really_ was released.
Is there an error in the packaging? Am I downloading it from an obsolete page?
no, the latest release packages _are_ that old...
By the way, it crashes if I load a DV-PAL avi file in a pix_movie. (doen't crash with homer.avi). It does not crash when it loads though, it crashes when I turn on the [gemhead] chain containing the pix_movie with the file already loaded. (very same patch works perfectly with the old 2006 version, which indeed is newer).
could you post a bug-report at http://sf.net/projects/pd-gem preferrably with a patch (and data) that illustrates your problem? (probably it also crashes with a minimal DV-PAL file (e.g. only 10 frames). it would also be good to know which version of QuickTime and DirectX/DriectDraw you have installed (and all the rest of your specs)
Now I will try the 0.91 beta, however I am a bit confused about this supposed 0.90.1 which seems to be indeed 0.90........
0.90 has been released released around 2004-05 0.90.0 is the same as 0.90 0.90.1 is a bugfix release for w32 released after 0.90.0 0.91.0 (== 0.91) is the upcoming release
mfg.asdr IOhannes
no, the latest release packages _are_ that old...
Ok thanks a lot for clearing things out.
I guess the recent announce I remembered was about the beta release of 0.91 or something.
could you post a bug-report at http://sf.net/projects/pd-gem preferrably with a patch (and data) that illustrates your problem?
Ok I'll try to "clean" the patch and do that. However, current 0.91 does not crash (nor does the 2006 cvs snapshot i usually use) so will the bug report about 0.90 be of any use?
bye m.
Now the good news is that I was wrong when I said that it crashes with DV-PAL encoded videos.
They were not dv-pal (I thought they were), they were encoded with some weired MJpeg codec, and it seems I don't have a proper codec installed on my machine that QuickTime can use: if I open those files with QuickTime player, I see a blank white screen, though I do can open them with Windows Media Player and see them.
However, Gem certainly shouldn't crash, it should issue some understandable error message if it misses a codec to decode a file...
could you post a bug-report at http://sf.net/projects/pd-gem preferrably with a patch (and data) that illustrates your problem? (probably it also crashes with a minimal file (e.g. only 10 frames).
I'm afraid I can't. I may post the patch but not the data: it is a 1GB avi file, and currently I miss the software to trim a short piece of it; I did that video years ago on another computer and I don't know where the codec came from, so even if I edit the video I'll come up with one coded with another codec.
----- Original Message ----- From: "IOhannes m zmoelnig" zmoelnig@iem.at To: "Matteo Sisti Sette" matteosistisette@gmail.com Cc: pd-list@iem.at; gem-dev@iem.at Sent: Friday, May 02, 2008 10:07 AM Subject: Re: [GEM-dev] what happens with GEM versions?
Matteo Sisti Sette wrote:
Hi,
And I can assure I am using the version I just downloaded, namely gem-0.90.1-W32-i586-bin-doc.zip
So I'm really confused: it is said to have been released in july 2007 and yet it is still the old binary compiled in 2004????
the release date "2007-07" is obviously wrong, and the compile date "2004" is correct. the dates differ, because i migrated the webpages and did not care to open each and every binary to see on which date it _really_ was released.
Is there an error in the packaging? Am I downloading it from an obsolete page?
no, the latest release packages _are_ that old...
By the way, it crashes if I load a DV-PAL avi file in a pix_movie. (doen't crash with homer.avi). It does not crash when it loads though, it crashes when I turn on the [gemhead] chain containing the pix_movie with the file already loaded. (very same patch works perfectly with the old 2006 version, which indeed is newer).
could you post a bug-report at http://sf.net/projects/pd-gem preferrably with a patch (and data) that illustrates your problem? (probably it also crashes with a minimal DV-PAL file (e.g. only 10 frames). it would also be good to know which version of QuickTime and DirectX/DriectDraw you have installed (and all the rest of your specs)
Now I will try the 0.91 beta, however I am a bit confused about this supposed 0.90.1 which seems to be indeed 0.90........
0.90 has been released released around 2004-05 0.90.0 is the same as 0.90 0.90.1 is a bugfix release for w32 released after 0.90.0 0.91.0 (== 0.91) is the upcoming release
mfg.asdr IOhannes
Quoting Matteo Sisti Sette matteosistisette@gmail.com:
However, Gem certainly shouldn't crash, it should issue some understandable error message if it misses a codec to decode a file...
that's the idea :-)
I'm afraid I can't. I may post the patch but not the data: it is a 1GB avi file, and currently I miss the software to trim a short piece of it; I did
too bad. does it work with the directshow backend of [pix_film]? (just don't enforce the use of QuickTime for decoding...)
fgmadsr IOhannes
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
too bad. does it work with the directshow backend of [pix_film]? (just don't enforce the use of QuickTime for decoding...)
Yes it does. So I guess that: - I do have a codec to read those files through DirectX - I don't have a codec to read those files through QuickTime (does this make sense? Or I just have a codec that for some reason is compatible with DirectX but not with QuickTime) - Gem crashes (instead of issuing an error) if can't decode the video.
Note that Quick Time Player doesn't crash when I open those files, just displays a blank white non-video (it doesn't give any error message which is not a corret behaviour either)
Note that Gem does load the file and display information (size and duration) but crashes when I create the gemwin.
Windows says these files are "PVMJPEG". QuickTime says they are "Motion JPEG Open DML 720 by 240"
Hi again,
You can test this with Homer.avi and with the attached patch.
I'm testing it on Windows XP with PD Vanilla 0.41-2 and gem snapshot of 22 april 2008. I have DirectX 9.0c and QuickTime 7.4.5 installed.
This is not a difference among gem versions: this is a difference of behaviour of pix_film on the same (almost current) version of gem depending on whether you use quicktime or directx to handle videos.
The patch is a slightly modified version of the help patch for pix_film. There's a radio button to choose whether to load the file with quicktime or directx. And there's a toggle to turn the gemhead on/off.
Here's how to test it.
1) Turn on the gemhead toggle 2) Choose "directx" on the radio button 3) Bang the openpanel and load homer.avi 4) Create the gemwin. Note that you're actually seeing the last frame, which is quite questionable. 5) With the gemhead turned on, move the frame number forth and back and leave it at 0. You're now seing the first frame. That's OK 6) Turn off the gemhead toggle 7) Move the frame number up to frame 77 or so (do not exceed the length of the file) 8) Now turn on the gemhead toggle. You're still seing frame 0. Not good. 9) With the gemhead turned on, move the frame number back and forth again to frame 77. You're now seing frame 77. That's ok 10) Turn off the gemhead toggle. 11) Move the frame number to 0. 12) Turn on the gemhead. You're still seing frame 77. Not good.
Conclusion: when pix_film receives a frame number while its chain's gemhead is off, it won't change the frame number, and when you turn the chain on, it will be still displaying the old frame untill it receives a frame number again.
In my opinion this is the WRONG behaviour; however this may even possibly be questionable.
Now close PD, reopen it and the patch, and repeat the whole experiment, but choose "quicktime" at point (2).
You will observe the following differences: - at point (4) you'll be seing the first frame, which is more reasonable - at point (8) you'll be seing frame 77. Kinda what I would expect - at point (12) you'll be seing frame 0. Kinda what I would expect
conclusion: when pix_film receive a frame number, it accepts and remembers it even if the gemchain is off. When the chain will be turned on, it will display the frame corresponding to the last number he has received.
You may question which one is the correct behaviour (quicktime behaviour in my opinion) but what's certainly too bad is that it behaves differently depending on whether you're using DirectX or QuickTime.
All this obliges me to patch things in a COMPLETELY DIFFERENT way depending on the platform I use; I used to use quicktime. If I now switch to DirectX I'll have to change all my patches.
Can anyone confirm the same results on other platforms? (err... does DirectX exist at all on other platform than windows?)