Hi List!
setup: Windows XP-SP 3 / latests Gem / PD Release. (June 12/09)
My patch opens a motion jpeg coded avi-file with "pix_movie" and plays it back by "manually" switching the frames with a counter. Although no autoplay message is sent to pix_movie the movie starts to play immediatedly after opening the file instead of instantly showing the first frame. I tested on 4 different WinXP PCs and found out that the movie did not automatically play on 2 of them and 2 other showed the problem.
There seems to be a correlation with Quicktime. At first pix_movie worked only on one pc. i had to install quicktime on the second computer and then it worked fine. unfortunately the installation of quicktime did not help on the second and third computer.
any ideas? does pix_movie depend on the graphics-card?
all the best, Hannes
Hannes Breitschädel wrote:
Hi List!
setup: Windows XP-SP 3 / latests Gem / PD Release. (June 12/09)
just to make sure, your "latest" is the same as mine: Pd-vanilla 0.42.5 Gem 0.92CVS20090528
if not, please specify full version numbers.
My patch opens a motion jpeg coded avi-file with "pix_movie" and plays it back by "manually" switching the frames with a counter. Although no autoplay message is sent to pix_movie the movie starts to play immediatedly after opening the file instead of instantly showing the first frame. I tested on 4 different WinXP PCs and found out that the movie did not automatically play on 2 of them and 2 other showed the problem.
There seems to be a correlation with Quicktime. At first pix_movie worked only on one pc. i had to install quicktime on the second computer and then it worked fine. unfortunately the installation of quicktime did not help on the second and third computer.
any ideas?
[pix_movie] uses QuickTime and/or DirectShow (and/or vfw) to decode videos on w32. if it can find QuickTime at runtime, it will prioritize this over DirectShow. if a movie cannot be opened by QuickTime, then it will fall back to DirectShow. while we are trying our best to make the decoding work the same with all backends, sometimes there are inconsitencies (bugs!).
so, it seems like in your case using QuickTime made the problem go away (so the QuickTime backend behaves as it should; while the DirectShow backend probably does not. are you using the same video-files on all machines or are they differing (e.g. Gem finds that it cannot use QuickTime and falls back to DirectShow)
you find a bit of information when you carefully look at the output inthe Pd-console. (things like "QuickTime: initialized"; or the number of "..." lines when opening a file)
does pix_movie depend on the graphics-card?
well, it depends on openGL as it directly uses textures to display the frames. there souldn't be a difference in the functionality of [pix_movie] regardless which gfx-card you use (and the only thing that _might_ happen is problems with texturing; nothing that is related to atuo-playing)
gfasdrm IOhannes
Hi Johannes!
Thanks a lot for the quick answer!
1. I did not use the latest version of gem and pd. sorry. i had pd 0.42.4 and the current official gem release. since the update it works fine on all computers.
here is the gem printout:
GEM: Graphics Environment for Multimedia GEM: ver: 0.92.CVS GEM: compiled: May 28 2009 ... GEM: using SSE2 optimization Gem Man: QT init OK
pix_film:: directshow support pix_film:: quicktime support [pix_movie]: opening T:/Daten/Hannes/VideoPlayer/./patches/../data/rem- leaving.avi with format 1908 Trying DirectShow [pix_movie]: loaded file: T:/Daten/Hannes/VideoPlayer/./patches/../ data/rem-leaving.avi with 4250 frames (640x480) at -1.000000 fps GEM: GLEW version 1.5.1 GEM: Start rendering GL: invalid enumerant
obviously pix_movie uses dirct show. my avi format ist motion jpeg. i use the same avi files on all 4 computers. i found out that motion jpeg is the only format that i am able to playback with pix_movie. but i omit that i gave up trying after the 5th or so codec.
do i need to worry about: "GL: invalid enumerant"
so, again, thanks! i have a question regarding recommended codecs, i will put this in a new thread.
all the best from overcast vienna, hannes
Am 15.06.2009 um 11:16 schrieb IOhannes m zmoelnig:
Hannes Breitschädel wrote:
Hi List! setup: Windows XP-SP 3 / latests Gem / PD Release. (June 12/09)
just to make sure, your "latest" is the same as mine: Pd-vanilla 0.42.5 Gem 0.92CVS20090528
if not, please specify full version numbers.
My patch opens a motion jpeg coded avi-file with "pix_movie" and plays it back by "manually" switching the frames with a counter. Although no autoplay message is sent to pix_movie the movie starts to play immediatedly after opening the file instead of instantly showing the first frame. I tested on 4 different WinXP PCs and found out that the movie did not automatically play on 2 of them and 2 other showed the problem. There seems to be a correlation with Quicktime. At first pix_movie worked only on one pc. i had to install quicktime on the second computer and then it worked fine. unfortunately the installation of quicktime did not help on the second and third computer. any ideas?
[pix_movie] uses QuickTime and/or DirectShow (and/or vfw) to decode videos on w32. if it can find QuickTime at runtime, it will prioritize this over DirectShow. if a movie cannot be opened by QuickTime, then it will fall back to DirectShow. while we are trying our best to make the decoding work the same with all backends, sometimes there are inconsitencies (bugs!).
so, it seems like in your case using QuickTime made the problem go away (so the QuickTime backend behaves as it should; while the DirectShow backend probably does not. are you using the same video- files on all machines or are they differing (e.g. Gem finds that it cannot use QuickTime and falls back to DirectShow)
you find a bit of information when you carefully look at the output inthe Pd-console. (things like "QuickTime: initialized"; or the number of "..." lines when opening a file)
does pix_movie depend on the graphics-card?
well, it depends on openGL as it directly uses textures to display the frames. there souldn't be a difference in the functionality of [pix_movie] regardless which gfx-card you use (and the only thing that _might_ happen is problems with texturing; nothing that is related to atuo-playing)
gfasdrm IOhannes
---------------------------------------------------- Hannes Breitschädel tel. +43 699 - 19 20 62 05 ----------------------------------------------------
-
Hannes Breitschädel -
IOhannes m zmoelnig