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

[B. Bogart]

Etienne,

Are these dropped frames your seeing a result of rotating the object via
numberbox/PD GUI or from another machine running over -nogui? 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.
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?

Disappointed B.

:(

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
>
>
-------------- 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/20050609/2d2d7557/attachment.pgp>