[PD] GEM error on latest pd extended with Ubuntu Gutsy

[altern]

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