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

[B. Bogart]

Hi Etienne,

I'm trying your patch on my g4 now.

The square does rotate smoothly, unless I move the PD windows around.

loading an image DOES stall rendering, I thought you meant that the
image having been loaded already slows down rendering, which this patch
does not show.

So reading a big file from disk in pix_image does slow things. I did a
test using pix_film in place of pix_image on OSX and that still stalls.
Gem only stalls while loading, not once the texture IS loaded (on my
setup). I wish I had my new linux machine to test...


So I guess you are proposing that the part that opens files be threaded
so that loading the file off disk does not stall rendering?

This is impossible for your project because there is not enough RAM to
hold all the textures needed?

I have a patch that loads about 20 JPG's at 512x512 plus 8 TIFs at 500KB
each, on OSX with only 512MB of Ram and this works fine... all using
pix_multiimage.

I've attached a change to your patch that uses the gemchain render
signal as the rotation clock, rather than the metro, Does this also
rotate choppily?

B.

Etienne Desautels wrote:
>
> 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
>>>
>>>
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: etpatch.pd
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20050610/9d0353da/attachment.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20050610/9d0353da/attachment.pgp>