On 6/8/06, <b class="gmail_sendername">IOhannes m zmoelnig</b> <<a href="mailto:zmoelnig@iem.at" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">zmoelnig@iem.at</a>> wrote:<div><span class="gmail_quote">
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
> I put a simple if statement in pix_share_write to replace the
<br>
> imageStruct call and it works fine. I think setCSizeByFormat() might<br>> not be working on the Mac. All those #ifdefs are hard to read! I will<br>> try to replace it with a single one for __APPLE__ and see if that helps.
<br><br>i agree that it might be better to just have one big #ifdef _APPLE__<br>#endif instead of 4 of them<br>would you change it or should i do it? (and honestly, i much prefer an<br>#ifdef over an #ifndef for readability)
</blockquote><div><br>
You can go ahead and do it if you have time now. I may not get to it today.<br>
</div><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> This is the tricky part of these objects to deal with. You can either<br>> allow the user to whatever they want when setting up shm or put in a
<br>> check to help keep them from doing something which might crash or become<br>> unusable. My original thinking was that anyone using these objects<br>> would have to really know what they are doing to set them up properly
<br>> and to just let them do it.<br><br>i see.<br>since there were no help-patches, you were the only person who knew<br>exactly what the objects were doing. when i first tried to use them they<br>just plain crashed which i found a bit "unusable".
<br>so i was kind of a burnt child and tried to make it nice.<br><br>that if pd is meant to be a real programming language then the user must<br>be able to crash the computer :-)</blockquote><div><br>
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. <br>
<br>
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.<br>
</div><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">actually i never really tried to do change the size, but i am not sure<br>how this would be done (i haven't found a way to resize an already
<br>existing shared memory segment as long as processes are attached to it)<br><br>so we might have to notify all related objects that they should detach<br>themselves (which i don't know how to do)<br><br>remember that the given size is just the amount of memory reserved.
<br>you can send images of any size via this segment, as long as the data<br>fits into the reserved memory.<br>so i am not sure whether there is a realy need for resizing on the fly.<br><br>one possibility that comes to my mind is, that we could use 2 portions
<br>of shared memory: one fixed-sized segment which just holds the key to<br>the actual data segment (and probably all the meta-data such as<br>dimensions,...)<br><br>however, i am not sure whether this all would work with multiple
<br>[pix_share_write]s accessing the same memory (which i think is a nice<br>feature, though i don't have an application at hand)</blockquote><div><br>
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. <br>
</div><br>
Would this be a viable system?<br>
<br>
- only one pix_share_write per ID (probably has to be like this anyway)<br>
- default max size is a reasonable size (1024x768, 1280x1024,???)<br>
- arguments to the object can set the max size<br>
- any image that comes in under the max size set the x,y,c and copy the frame into the shm buffer<br>
- an image over max size would throw a message with a hint to manually set the max<br>
- some sort of flag or counter to determine when images are sent by _write so _read doesn't copy out bad data<br>
<br>
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.<br>
<br>
Is this crazy talk?<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>hmm. one of my ideas was to export the shared-memory thing into a<br>different set of objects (not related to Gem!)
<br>then a pointer to this memory would be passed to the read/write objects.<br>this way they would not need to know anything about shared memory and it<br>would allow for the biggest flexibility.</blockquote><div><br>
Like a Jack/Rewire method of passing video between apps?<br>
</div><br>
<br>
cgc</div>