[GEM-dev] Re: [PD] GEM Linux and video codecs

Etienne Desautels titi at sat.qc.ca
Fri Jun 10 06:19:55 CEST 2005


Hey Ben,

> Are these dropped frames your seeing a result of rotating the object 
> via
> numberbox/PD GUI or from another machine running over -nogui?

No, either. Rotating from metro. (See the patch) I have the same 
problem on my 667 PowerBook and my Linux pentium 2.6GHz.

>  I ask
> because the PD gui is known to have issues and it is easily possible
> that it is the number box causing this problem and not Gem. Try sending
> a signal from python over a local socket to pd/Gem running in -nogui.

It will probably work. The problem is the internal timing of PD/metro. 
It's CPU time base, not real time base. And without threads.

> Does it do the same thing?
>
> I'll have to test things on my new linux machine when I get it, but I
> hope what your saying is not evident. I don't see this happening on 
> OSX.
> Do you have a test patch?

Here it is !

> Disappointed B.

Disappointed E. too.

#N canvas 513 371 819 325 10;
#X obj 187 150 gemhead;
#X msg 71 9 destroy;
#X obj 187 129 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0
1;
#X obj 485 157 gemhead;
#X obj 414 177 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
-1;
#X obj 485 264 pix_texture;
#X obj 485 287 rectangle 5.333 4;
#X msg 414 216 open \$1;
#X obj 414 195 openpanel;
#X obj 485 137 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0
1;
#X obj 485 240 pix_image;
#X msg 503 186 open /home/etienne/Desktop/froime400.jpg;
#X obj 187 198 rotateXYZ;
#X obj 289 62 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1
;
#X obj 340 62 nbx 5 14 -1e+37 1e+37 0 0 empty empty empty 0 -6 0 10
-262144 -1 -1 0 256;
#X obj 289 127 + 1;
#X obj 289 105 f 1;
#X obj 187 221 rectangle 2 2;
#X obj 327 106 nbx 5 14 -1e+37 1e+37 0 0 empty empty empty 0 -6 0 10
-262144 -1 -1 0 256;
#X msg 503 210 open /home/etienne/Desktop/thuangS.jpg;
#X msg 16 9 create;
#X msg 36 30 1;
#X msg 98 31 0;
#X msg 91 86 frame \$1;
#X obj 16 113 gemwin 30;
#X msg 91 60 30;
#X msg 125 60 60;
#X obj 289 82 metro 33;
#X obj 485 89 loadbang;
#X msg 485 113 0;
#X text 130 9 1 create the window;
#X text 233 29 2 start rotating the square watch it rotating not 
smoothly!
;
#X msg 254 151 0;
#X obj 289 151 select 361;
#X text 483 48 3 try to load some big textures (1024x1024) with the
chain turn on or off watch the square stall;
#X connect 0 0 12 0;
#X connect 1 0 24 0;
#X connect 2 0 0 0;
#X connect 3 0 10 0;
#X connect 4 0 8 0;
#X connect 5 0 6 0;
#X connect 7 0 10 0;
#X connect 8 0 7 0;
#X connect 9 0 3 0;
#X connect 10 0 5 0;
#X connect 11 0 10 0;
#X connect 12 0 17 0;
#X connect 13 0 27 0;
#X connect 14 0 27 1;
#X connect 15 0 33 0;
#X connect 16 0 15 0;
#X connect 18 0 15 1;
#X connect 19 0 10 0;
#X connect 20 0 24 0;
#X connect 21 0 24 0;
#X connect 22 0 24 0;
#X connect 23 0 24 0;
#X connect 25 0 23 0;
#X connect 26 0 23 0;
#X connect 27 0 16 0;
#X connect 28 0 29 0;
#X connect 29 0 9 0;
#X connect 32 0 16 0;
#X connect 33 0 32 0;
#X connect 33 1 16 1;
#X connect 33 1 12 3;

> :(
>
> Etienne Desautels wrote:
>>
>> Hello,
>>
>> On 05-06-05, at 17:14, Tim Blechmann wrote:
>>
>>> hi all ...
>>>
>>>>> Also, what I would really prefer is to had support in Gem for
>>>>> LibMPEG2.  Do you think it could be difficult to do ? Is it about
>>>>> creating a  filmMPEG2.cpp and filmMPEG2.h files with the good
>>>>> function calls to the  library and add the reference into the
>>>>> pix_filmNEW.cpp ?
>>>>
>>>>
>>>> correct.
>>>> if you like to add libMPEG2-support you are welcome!
>>>
>>> stupid question, but what about mplayer support instead of libMPEG2?
>>> mplayer is able to play back about every file format ...
>>>
>>> just thinking loud ... tim
>>
>>
>> I know, it would be wonderfull...
>>
>> But Mplayer is not a library. You can only use it as an application.
>> Mplayer itself use LibMPEG2 to play MPEG2 stream and use other 
>> libraries
>> for other formats and codecs (as FFMPEG, XVID, etc).
>>
>> Unfortunately, I will not add LibMPEG2 to GEM. In fact I'll not use
>> PD/GEM at all for the big project I'm working on. Maybe I'm crazy but
>> the problem is that PD is not multithreaded and work with CPU time and
>> not real time. So if you try in Gem to do something as simple as
>> rotating a square on the screen, it will not rotate regularly. It will
>> stall from time to time. And if you try to load a big texture
>> (1024x1024) the rotation of the square will stall even more badly. 
>> And I
>> don't think there's something I can do ? I tried to preload some big
>> textures with pix_buffer but when I display the image it's sucking a 
>> lot
>> of CPU. When I say a lot I mean a lot. The more your texture is big 
>> the
>> more CPU it's suck. It's very strange. I don't understand why? Anyway,
>> in the mid-term it's not an option for me to preload the images. So 
>> now
>> I'm doing the project in Python with pyOpenGL. This way I can schedule
>> redraw in real time, not cpu time, and open my textures in a thread.
>> This way everything play smoothly. But I have a lot more to code ! I
>> wish I could done it with PD/GEM but it's not possible.
>>
>> One last note:
>> for FFMEPG in Gem, I did try so many things but in the end it never
>> worked. I always have the -2 error meaning that there's an I/O 
>> problem?
>>
>> Anyway thanks for your good work to all the developers of PD and Gem !
>>
>> Etienne
>>
>>





More information about the GEM-dev mailing list