hi
IOhannes m zmoelnig(e)k dio:
altern wrote:
hi
the video does not seem corrupted i can open it with VLC, no problem. I tried to find the reason for the error and I found that I can use the first frame but as soon as I go the the second or further it doesnt display it.
is lqtplay able to playback this movie? aviplay?
yes it plays ok with lqtplay.
which decoding libraries is Gem linked against? (you can see this when you create the first [pix_film] object. it should say something like: pix_film:: quicktime support pix_film:: libmpeg3 support pix_film:: libaviplay support pix_film:: FFMPEG support)
pix_film:: quicktime support pix_film:: libmpeg3 support pix_film:: libaviplay support pix_film:: libmpeg support
btw. i am using pix_movie instead of pix_film to play the video, i am not sure about the difference between both at the moment. I am going to check the docs now...
which decoding library is used for the movie? you should be able to find this out by looking on the pd-console when the video is opened (depending on the version and verbosity of Gem)
e.g. i get something like: [pix_filmNEW]: opening /Net/iem/Benutzer/zmoelnig/src/cvs/pd-gem/Gem/examples/data/homer.avi with format 1908 [pix_filmNEW]: ... [pix_filmNEW]: ... [pix_filmNEW]: loaded file: /Net/iem/Benutzer/zmoelnig/src/cvs/pd-gem/Gem/examples/data/homer.avi with 85 frames (160x120) at 25.000000 fps
which means that the famous homer.avi has been loaded by the 3rd option (libaviplay), after the 1st two options failed (indicated by "...")
I get
[pix_movieNEW]: opening /home/r2d2/ixi/pd/ehu/ehu/../train.mov with format 1908 [pix_movieNEW]: ... [pix_movieNEW]: ... [pix_movieNEW]: loaded file: /home/r2d2/ixi/pd/ehu/ehu/../train.mov with 108 frames (240x180) at 12.019231 fps
then it opens with libaviplay i guess ...
btw 2 . the quality of the video has dropped since i upgraded to Gutsy. The webcam image was already bad before, but now with Gutsy the compression "boxes" are far bigger. The image is far more poor now. I guess it has to do with the libraries that do the uncompressing.
btw. passing mode 0 to pix_texture crashed PD. I was trying this to
now that is bad. did you send the "mode 0" message before you started rendering or after you got several "gl invalid enumerant" errors?
it is connected to a loadbang so it should be before starting rendering.
critical area. Bad because I dont have the time before the installation opening.
sorry to hear that.
we found another computer that runs the patches fine, it is actually newer and faster so it was good in the end :)
thanks
enrike