[GEM-dev] pix_share broken several ways

[chris clepper]

On 6/8/06, IOhannes m zmoelnig <zmoelnig at iem.at> wrote:
>
>
> > I put a simple if statement in pix_share_write to replace the
> > imageStruct call and it works fine.  I think setCSizeByFormat() might
> > not be working on the Mac.  All those #ifdefs are hard to read!  I will
> > try to replace it with a single one for __APPLE__ and see if that helps.
>
>
> i agree that it might be better to just have one big #ifdef _APPLE__
> #endif instead of 4 of them
> would you change it or should i do it? (and honestly, i much prefer an
> #ifdef over an #ifndef for readability)


You can go ahead and do it if you have time now.  I may not get to it today.

> This is the tricky part of these objects to deal with.  You can either
> > allow the user to whatever they want when setting up shm or put in a
> > check to help keep them from doing something which might crash or become
> > unusable.  My original thinking was that anyone using these objects
> > would have to really know what they are doing to set them up properly
> > and to just let them do it.
>
> i see.
> since there were no help-patches, you were the only person who knew
> exactly what the objects were doing. when i first tried to use them they
> just plain crashed which i found a bit "unusable".
> so i was kind of a burnt child and tried to make it nice.
>
> that if pd is meant to be a real programming language then the user must
> be able to crash the computer :-)


I should have put up a test patch and some decent comments in the code.  I
needed to have the object to spread video capture and compression between
more than one instance of Pd to make it all 'multi-proccessor aware'.  I
forgot about the objects after that though.

I have the current one working for up to one 1024x768 RGB buffer.  I'm using
it to have pix_snap write to shm and another instance of Pd record the
results as a Quicktime movie.  I can get about 30fps doing this, so the
objects are pretty useful.

actually i never really tried to do change the size, but i am not sure
> how this would be done (i haven't found a way to resize an already
> existing shared memory segment as long as processes are attached to it)
>
> so we might have to notify all related objects that they should detach
> themselves (which i don't know how to do)
>
> remember that the given size is just the amount of memory reserved.
> you can send images of any size via this segment, as long as the data
> fits into the reserved memory.
> so i am not sure whether there is a realy need for resizing on the fly.
>
> one possibility that comes to my mind is, that we could use 2 portions
> of shared memory: one fixed-sized segment which just holds the key to
> the actual data segment (and probably all the meta-data such as
> dimensions,...)
>
> however, i am not sure whether this all would work with multiple
> [pix_share_write]s accessing the same memory (which i think is a nice
> feature, though i don't have an application at hand)


My thinking on the resizing is if the objects are 'smart' enough then you
could just put them into a render chain and any image that they get feeds
them.  I recall that Chris K and I got a little bit of this going for
vDSP/jMax, but that was a while ago.  I think our purpose was just one shm
region that set aside a large enough size for any video the user was likely
to throw at it. I believe the first N bytes were set aside for the x, y and
c size to let the receiver know how much of the region to copy out and the
dimensions to pass to the rest of the processes.

Would this be a viable system?

- only one pix_share_write per ID (probably has to be like this anyway)
- default max size is a reasonable size (1024x768, 1280x1024,???)
- arguments to the object can set the max size
- any image that comes in under the max size set the x,y,c and copy the
frame into the shm buffer
- an image over max size would throw a message with a hint to manually set
the max
- some sort of flag or counter to determine when images are sent by _write
so _read doesn't copy out bad data

This is kind of like sub texturing using 2D textures in a way.  It could
free end users from having to set anythign beyond the ID for common video
sizes (320x240, 640x480).  It is potentially wasteful if the default is a
lot bigger than the images used and it looks like OSX by default is limited
to 4MB of total shm, but manually setting the max would help avoid this.

Is this crazy talk?


> hmm. one of my ideas was to export the shared-memory thing into a
> different set of objects (not related to Gem!)
> then a pointer to this memory would be passed to the read/write objects.
> this way they would not need to know anything about shared memory and it
> would allow for the biggest flexibility.


Like a Jack/Rewire method of passing video between apps?


cgc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20060608/59c8ef2f/attachment.htm>