Hi
I can no longer get pix_share to work the way I had originally written the object.
First, the csize selection does not work. On OSX it is fixed to 2 and neither 4, r, R, or RGBA changes it.
Second, after the shm buffer is set there is no way to change the size. I get endless amounts of this:
pix_share_*: 2048x768x2: 3145728 pix_share_*: someone was faster: only got 1572864 bytes instead of 3145728 pix_share_*: shm:: id(131072) segsz(1572884) cpid (23205) mem(0x101F6000)
Someone was faster? WTF? I get that even after deleting the pix_share_write object and recreating it. Creating the object should set up whatever I tell it to set up.
Finally, after setting up one shm buffer at an address I can no longer create one at any other address. I get this message:
pix_share_*: 2048x768x2: 3145728 error: pix_share_*: couldn't get shm_id: error 12
Again, I'm telling pix_share_write to create a shm buffer at a certain address and of a certain size. Why would it refuse to do this?
The code I checked in did not do this. I cannot figure out what the intended function of some of the code is and do not know how to make changes other than reverting back to what I know works and continuing from that point.
Thanks cgc
chris clepper wrote:
Hi
I can no longer get pix_share to work the way I had originally written the object.
i admit i changed it to not crash anymore on my machines :-)
First, the csize selection does not work. On OSX it is fixed to 2 and neither 4, r, R, or RGBA changes it.
this is very weird. the only reason i can imagine for this is that imageStruct.setCsizeByFormat(GL_RGBA) returns something very wrong (like enforcing it to be ycbcr and ignoring the argument)...but i doubt it
Second, after the shm buffer is set there is no way to change the size. I get endless amounts of this:
pix_share_*: 2048x768x2: 3145728 pix_share_*: someone was faster: only got 1572864 bytes instead of 3145728 pix_share_*: shm:: id(131072) segsz(1572884) cpid (23205) mem(0x101F6000)
you mean, you get this error message each render-cycle? or do you repeatedly trigger a "set" message to [pix_share_write]?
Someone was faster? WTF? I get that even after deleting the pix_share_write object and recreating it. Creating the object should set up whatever I tell it to set up.
the difference (iirc) between your original version and the current one is, that both [pix_share_read] and [pix_share_write] set up the shared memory segment, whichever is faster (read: created earlier) so "someone was faster" means, that another object (e.g. [pix_share_read]) has already set up an shm-segment with the same id. if the shm-segment is already there, then none of the objects try to resize it but instead use what is already there.
in order to free the shm-segment you will have to destroy ALL references to it (read: all [pix_share_read] and [pix_share_write] objects referencing the same segment)
Finally, after setting up one shm buffer at an address I can no longer create one at any other address. I get this message:
pix_share_*: 2048x768x2: 3145728 error: pix_share_*: couldn't get shm_id: error 12
Again, I'm telling pix_share_write to create a shm buffer at a certain address and of a certain size. Why would it refuse to do this?
i'll have a look at that (i cannot remember having that problem)
what comes to my mind is that the symbolic/numeric id exposed given is evaluated incorrectly. could you please give the exact arguments of the [pix_share*] objects you try to create?
The code I checked in did not do this. I cannot figure out what the intended function of some of the code is and do not know how to make changes other than reverting back to what I know works and continuing from that point.
it would be great if we could make the current version running on your system instead of reverting it to a version that is known to crash on other systems. (in the end i hope it will work on all systems)
mfg.adsr. IOhannes
IOhannes m zmoelnig wrote:
in order to free the shm-segment you will have to destroy ALL references to it (read: all [pix_share_read] and [pix_share_write] objects referencing the same segment)
and quitting pd might _not_ free the shm-segments, since the destructors of the objects are not called. (which is a pd bug).
you either have to "properly" close the pd-patch or free the shm-segments with an external application (on linux (and afaik some bsd's) this is "ipcrm", probably on osX too)
mfg.asdr. IOhannes
On 6/8/06, IOhannes m zmoelnig zmoelnig@iem.at wrote:
First, the csize selection does not work. On OSX it is fixed to 2 and neither 4, r, R, or RGBA changes it.
this is very weird. the only reason i can imagine for this is that imageStruct.setCsizeByFormat (GL_RGBA) returns something very wrong (like enforcing it to be ycbcr and ignoring the argument)...but i doubt it
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.
Second, after the shm buffer is set there is no way to change the size. I get endless amounts of this:
pix_share_*: 2048x768x2: 3145728 pix_share_*: someone was faster: only got 1572864 bytes instead of
3145728
pix_share_*: shm:: id(131072) segsz(1572884) cpid (23205)
mem(0x101F6000)
you mean, you get this error message each render-cycle? or do you repeatedly trigger a "set" message to [pix_share_write]?
Someone was faster? WTF? I get that even after deleting the pix_share_write object and recreating it. Creating the object should set up whatever I tell it to set up.
the difference (iirc) between your original version and the current one is, that both [pix_share_read] and [pix_share_write] set up the shared memory segment, whichever is faster (read: created earlier) so "someone was faster" means, that another object (e.g. [pix_share_read]) has already set up an shm-segment with the same id. if the shm-segment is already there, then none of the objects try to resize it but instead use what is already there.
in order to free the shm-segment you will have to destroy ALL references to it (read: all [pix_share_read] and [pix_share_write] objects referencing the same segment)
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.
The alternative idea to put checks in place to keep from crashing/etc should probably be even more complete. Rather than locking the shm per ID, pix_share_write should allow for resizing and the pix_share_read objects would have to be alerted to this change. In my initial testing (on OSX only) changing the size of the shm region for a single ID worked. If this is not the case on Linux then some other solution will have to be figured out.
Finally, after setting up one shm buffer at an address I can no longer create one at any other address. I get this message:
pix_share_*: 2048x768x2: 3145728 error: pix_share_*: couldn't get shm_id: error 12
Again, I'm telling pix_share_write to create a shm buffer at a certain address and of a certain size. Why would it refuse to do this?
i'll have a look at that (i cannot remember having that problem)
what comes to my mind is that the symbolic/numeric id exposed given is evaluated incorrectly. could you please give the exact arguments of the [pix_share*] objects you try to create?
This has to do with running out of shm memory. I was recreating the object with a new ID and values and it refused to go beyond a certain size. This leads me to think that created regions are not being freed since the 4MB allowance on OSX is used up by the first 1024x768 object.
The code I checked in did not do this. I cannot figure out what the intended function of some of the code is and do not know how to make changes other than reverting back to what I know works and continuing from that point.
it would be great if we could make the current version running on your system instead of reverting it to a version that is known to crash on other systems. (in the end i hope it will work on all systems)
I agree. I originally wrote the object from some code Chris Klippel used on Linux back in the old days of jMax video and it worked fine on OSX back then too. I could have made a mistake or the Linux spec could have changed since though.
I made some hacks since I need the code to work right then, so now it's time for real fixes. The first thing to figure out is how we want the object to behave in end use. Do we allow for any settings or do we confine the objects even further than they are now?
cgc
chris clepper wrote:
On 6/8/06, *IOhannes m zmoelnig* <zmoelnig@iem.at mailto:zmoelnig@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)
in order to free the shm-segment you will have to destroy ALL references to it (read: all [pix_share_read] and [pix_share_write] objects referencing the same segment)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 :-)
The alternative idea to put checks in place to keep from crashing/etc should probably be even more complete. Rather than locking the shm per ID, pix_share_write should allow for resizing and the pix_share_read objects would have to be alerted to this change. In my initial testing (on OSX only) changing the size of the shm region for a single ID worked. If this is not the case on Linux then some other solution will have to be figured out.
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)
I agree. I originally wrote the object from some code Chris Klippel used on Linux back in the old days of jMax video and it worked fine on OSX back then too. I could have made a mistake or the Linux spec could have changed since though.
i don't think so. most likely it just crashed because i didn't know how to use the objects.
I made some hacks since I need the code to work right then, so now it's time for real fixes. The first thing to figure out is how we want the object to behave in end use. Do we allow for any settings or do we confine the objects even further than they are now?
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.
mfg.asd.r IOhannes
On 6/8/06, IOhannes m zmoelnig zmoelnig@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
chris clepper wrote:
On 6/8/06, *IOhannes m zmoelnig* <zmoelnig@iem.at mailto:zmoelnig@iem.at> wrote:
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.
well yes: the object IS very useful (for advanced uses)
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.
actually it is almost like this.
Would this be a viable system?
- only one pix_share_write per ID (probably has to be like this anyway)
hmm, i don't see a real reason for this constraint (though again: i don't know where you would really want to use such feature)
- 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
actually this is how it works now: you define the default max size as argument(s) and any image that fits within this size can be sent via the shm buffer.
however, there is no "default" maxsize right now. probably SHMMAX would be a good starting point?
- an image over max size would throw a message with a hint to manually
set the max
if we can resize the shm buffer while objects are still referring to it, this would be very cool.
- some sort of flag or counter to determine when images are sent by
_write so _read doesn't copy out bad data
ah yes, the sync problem: i am not sure how to handle this efficiently (this is: not via netsend/netreceive) can the shm-segment be locked?
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.
well, as long as it is shmmax<10MB i don't think that wastefullness is a big issue. (and if you are concerned you could always set a lower size explicitely via arguments)
by "total shm" you mean "the sum of all shm segments"? this would be bad!
Is this crazy talk?
makes a lot of sense.
Like a Jack/Rewire method of passing video between apps?
i think this has been discussed at piksel 2 years ago.
shm is obviously the fastest, but you get huge penalties when using different apps that want the data aligned differently.
mfga.sdr IOhannes
chris clepper wrote:
On 6/8/06, *IOhannes m zmoelnig* <zmoelnig@iem.at mailto:zmoelnig@iem.at> wrote:
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.
done
mfg.ads.r IOhannes
On Jun 8, 2006, at 2:48 PM, IOhannes m zmoelnig wrote:
chris clepper wrote:
On 6/8/06, *IOhannes m zmoelnig* <zmoelnig@iem.at mailto:zmoelnig@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)
...either way, I think that one problem with setCSizeByFormat() is that it tries to also set type & format (ie. on macppc we want "GL_BGRA" instead of "GL_RGBA", yet we want to be lazy and not add an #ifdef to all instances of "setCSizeByFormat(GL_RGBA) in GEM...guess this means we need a little rewrite for macintel, too), but only returns "csize"...
weird, jamie
ps: finally getting thru some deadlines n'stuff, so I'll be a bit more active soon ;-)
On 6/8/06, james tittle tigital@mac.com wrote:
...either way, I think that one problem with setCSizeByFormat() is that it tries to also set type & format (ie. on macppc we want "GL_BGRA" instead of "GL_RGBA", yet we want to be lazy and not add an #ifdef to all instances of "setCSizeByFormat(GL_RGBA) in GEM...guess this means we need a little rewrite for macintel, too), but only returns "csize"...
I just changed the GL_UNSIGNED_*_REV to non _REV and it seems to work ok. I do have one strange patch where pix_movie is all messed up, but other patches with pix_movie work fine.
The #ifdef is probably the most straightforward method for this - although I am not sure what the best on to use for PPC or x86 is. I've been using __VEC__ which is wrong, but I know it works as long as the PPC build process sets the -faltivec flag. Apple says not to use __i386__ and __LITTLE_ENDIAN__ only if you must. I suspect they say that to use there own detection and btye swapping functions, but who knows.
cgc
On Jun 8, 2006, at 4:50 PM, chris clepper wrote:
I just changed the GL_UNSIGNED_*_REV to non _REV and it seems to work ok. I do have one strange patch where pix_movie is all messed up, but other patches with pix_movie work fine.
...I didn't realize what you meant when you said "all messed up": if the colors are weird, it's probably a good indication that channels are outta order...I was thinking you meant "messed up" in a deeper sense ;-)
The #ifdef is probably the most straightforward method for this - although I am not sure what the best on to use for PPC or x86 is. I've been using __VEC__ which is wrong, but I know it works as long as the PPC build process sets the -faltivec flag. Apple says not to use __i386__ and __LITTLE_ENDIAN__ only if you must. I suspect they say that to use there own detection and btye swapping functions, but who knows.
...yeh, of course they have they're own (I think they call them "flippers"?)...I don't see any reason for us to use them, especially since we support ppc and intel cross-platform...so, I think it'd be fine to use:
#if defined(__APPLE__) && defined(__LITTLE_ENDIAN__) or #if defined(__APPLE__) && defined(__BIG_ENDIAN__)
jamie
james tittle wrote:
On Jun 8, 2006, at 2:48 PM, IOhannes m zmoelnig wrote:
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)
...either way, I think that one problem with setCSizeByFormat() is that it tries to also set type & format (ie. on macppc we want "GL_BGRA" instead of "GL_RGBA", yet we want to be lazy and not add an #ifdef to all instances of "setCSizeByFormat(GL_RGBA) in GEM...guess this means we need a little rewrite for macintel, too), but only returns "csize"...
actually i quite like the way it is done right now: require an rgba format and get what the system thinks is the best match for rgba. however, it might be better if we would use our own defines like: GEM_RGBA (which is GL_RGBA or GL_ARGB or whatever)
i also like that setCSizeByFormat() sets the csize and the format (after all, that is the idea of the function). the return value (csize) is just for convenience: if you need to know the format and the csize, they should be queried explicitely via imageStruct.csize and imageStruct.format
mfg.asdr IOhannes
On Jun 9, 2006, at 5:20 AM, IOhannes m zmoelnig wrote:
i also like that setCSizeByFormat() sets the csize and the format (after all, that is the idea of the function). the return value (csize) is just for convenience: if you need to know the format and the csize, they should be queried explicitely via imageStruct.csize and imageStruct.format
...yeh, after looking at it again, I understand what it's doing: I'd just glanced at it yesterday and was thrown off by the return value! Thanks for doing the cleanup of it, btw...I guess we can look to chris to start pepper-ing the code with the mac intel/ppc #ifdef's...
jamie
It looks like a conflict and merge got my copy of GemPixUtil.cpp pretty screwed. Also, CVS claimed that both IOhannes and I added the same pix_share_* files so I've been manually copying the files when updating. I'm doing a fresh checkout of everything to fix these things. Maybe XCode will get some CVSroot files it likes as well.
cgc
PS -humboldtblvd.com is offline for a bit, so my gmail address is the only to reach me at.
On 6/9/06, james tittle tigital@mac.com wrote:
On Jun 9, 2006, at 5:20 AM, IOhannes m zmoelnig wrote:
i also like that setCSizeByFormat() sets the csize and the format (after all, that is the idea of the function). the return value (csize) is just for convenience: if you need to know the format and the csize, they should be queried explicitely via imageStruct.csize and imageStruct.format
...yeh, after looking at it again, I understand what it's doing: I'd just glanced at it yesterday and was thrown off by the return value! Thanks for doing the cleanup of it, btw...I guess we can look to chris to start pepper-ing the code with the mac intel/ppc #ifdef's...
jamie
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On 6/7/06, chris clepper cgclepper@gmail.com wrote:
Finally, after setting up one shm buffer at an address I can no longer create one at any other address. I get this message:
pix_share_*: 2048x768x2: 3145728 error: pix_share_*: couldn't get shm_id: error 12
pix_share_write might not be releasing the shm object correctly or at all. I could only get one set up for a ~2.5MB buffer without rebooting to free up more. OSX might have changed the shmmax defaults to 4MB total in a recent update as well. I put it to 8MB and can now use a 1024x768x4 buffer after a fresh reboot although changing it to one double that size using the set message fails.
cgc
chris clepper wrote:
On 6/7/06, *chris clepper* <cgclepper@gmail.com mailto:cgclepper@gmail.com> wrote:
Finally, after setting up one shm buffer at an address I can no longer create one at any other address. I get this message: pix_share_*: 2048x768x2: 3145728 error: pix_share_*: couldn't get shm_id: error 12pix_share_write might not be releasing the shm object correctly or at all.
you are right. in the process of detecting how big an already segment is attached a memory segment and did not properly release it anymore.
i have checked in a fix for this.
actually it is just an "shmdt(h);" below the "m_size=h->size;" below the "somebody was faster" warning.
I could only get one set up for a ~2.5MB buffer without rebooting to free up more. OSX might have changed the shmmax defaults to 4MB total in a recent update as well. I put it to 8MB and can now use a 1024x768x4 buffer after a fresh reboot although changing it to one double that size using the set message fails.
note that you can only resize the buffer to something larger if nothing refers to this segment any more.
mfg.asdr. IOhannes
IOhannes m zmoelnig wrote:
you are right. in the process of detecting how big an already segment is attached a memory segment and did not properly release it anymore.
whatever that means...
corrected version: in the process of detecting how big an already existing segment is, the process attaches itself to this segment but fails to detach itself afterwards.
mfg.asd.r IOhannes
On 6/8/06, IOhannes m zmoelnig zmoelnig@iem.at wrote:
chris clepper wrote:
On 6/7/06, *chris clepper* <cgclepper@gmail.com mailto:cgclepper@gmail.com> wrote:
Finally, after setting up one shm buffer at an address I can nolonger
create one at any other address. I get this message: pix_share_*: 2048x768x2: 3145728 error: pix_share_*: couldn't get shm_id: error 12pix_share_write might not be releasing the shm object correctly or at all.
you are right. in the process of detecting how big an already segment is attached a memory segment and did not properly release it anymore.
i have checked in a fix for this.
actually it is just an "shmdt(h);" below the "m_size=h->size;" below the "somebody was faster" warning.
Thanks. I'll give it a test in a bit.
I could only get one set up for a ~2.5MB buffer without rebooting
to free up more. OSX might have changed the shmmax defaults to 4MB total in a recent update as well. I put it to 8MB and can now use a 1024x768x4 buffer after a fresh reboot although changing it to one double that size using the set message fails.
note that you can only resize the buffer to something larger if nothing refers to this segment any more.
Ok, I might have missed that in my testing by keeping a pix_share_read open in another instance of Pd or I could have not removed the object properly (sometimes I just crtl-c or kill Pd).
Would it be possible to have message that said something like 'Cannot resize buffer because it is in use by another pix_share_ object'?
cgc
Hi,
I am trying to get my DV camera to work with pix_video under linux. I have to use Ubuntu. I have tried different fixes I have seen on this list like commenting out code in pix_videoNEW and the like. I have also different versions of gem and created my nodes in /dev. The console says: pix_videoNEW starting transfer. It seems I am getting close to my goal only this is the error i now get afterwards:
pix_texture:not using client storage
Could anyone shed some light on this for me?
Thanks in advance.
Sylvain
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Studio Zodiak wrote:
Hi,
I am trying to get my DV camera to work with pix_video under linux. I have to use Ubuntu. I have tried different fixes I have seen on this list like commenting out code in pix_videoNEW and the like. I have also different versions of gem and created my nodes in /dev. The console says: pix_videoNEW starting transfer. It seems I am getting close to my goal only this is the error i now get afterwards:
pix_texture:not using client storage
this is just a warning and not an error (and not related to dv-capturing at all, just with texturing) do you compile the current CVS? (if so, why did you define DEBUG_ME in pix_texture.cpp? - else you shouldn't see this message)
what else do you get? no image? (does a [pix_info] connected to the [pix_video] output any sensible dimensions?) blue/green image?
mfg.adsr IOhannes
Hi, I have been away, but i really wish to resolve this issue.
I get this: /dev/ieee1394/dv/host0/NTSC/in: No such file or directory
Even if /dev/ieee1394/dv/host0/NTSC/in exists and has permissions.
I did this:
mkdir -p /dev/ieee1394/dv/host0/PAL/in chmod 666 /dev/ieee1394/dv/host0/PAL/in test -e /dev/ieee1394/dv/host0/PAL/in || mknod -m 666 /dev/ieee1394/dv/host0/PAL/in c 171 0 mkdir -p /dev/ieee1394/dv/host0/NTSC/in chmod 666 /dev/ieee1394/dv/host0/NTSC/in test -e /dev/ieee1394/dv/host0/NTSC/in || mknod -m 666 /dev/ieee1394/dv/host0/NTSC/in c 171 0
and
lsmod |grep 1394
gives:
dv1394 21356 0 raw1394 31596 0 ohci1394 37524 1 dv1394 ieee1394 306520 4 sbp2,dv1394,raw1394,ohci1394
I still get no image with a white strip.
the pd console says: DV4L :closed pix_videoNEW:starting transfer
thanks
Sylvain
----- Original Message ---- From: IOhannes m zmoelnig zmoelnig@iem.at To: Studio Zodiak studiozodiak@yahoo.ca Cc: gem-dev gem-dev@iem.at Sent: Thursday, June 8, 2006 11:12:09 AM Subject: Re: [GEM-dev] pix-video again
Studio Zodiak wrote:
Hi,
I am trying to get my DV camera to work with pix_video under linux. I have to use Ubuntu. I have tried different fixes I have seen on this list like commenting out code in pix_videoNEW and the like. I have also different versions of gem and created my nodes in /dev. The console says: pix_videoNEW starting transfer. It seems I am getting close to my goal only this is the error i now get afterwards:
pix_texture:not using client storage
this is just a warning and not an error (and not related to dv-capturing at all, just with texturing) do you compile the current CVS? (if so, why did you define DEBUG_ME in pix_texture.cpp? - else you shouldn't see this message)
what else do you get? no image? (does a [pix_info] connected to the [pix_video] output any sensible dimensions?) blue/green image?
mfg.adsr IOhannes
On Mon, 19 Jun 2006, Studio Zodiak wrote:
I get this: /dev/ieee1394/dv/host0/NTSC/in: No such file or directory Even if /dev/ieee1394/dv/host0/NTSC/in exists and has permissions. I did this: mkdir -p /dev/ieee1394/dv/host0/PAL/in chmod 666 /dev/ieee1394/dv/host0/PAL/in test -e /dev/ieee1394/dv/host0/PAL/in || mknod -m 666 /dev/ieee1394/dv/host0/PAL/in c 171 0 mkdir -p /dev/ieee1394/dv/host0/NTSC/in chmod 666 /dev/ieee1394/dv/host0/NTSC/in test -e /dev/ieee1394/dv/host0/NTSC/in || mknod -m 666 /dev/ieee1394/dv/host0/NTSC/in c 171 0
Both "in" should be character-devices, but it seems like you have created them as directories. remove "/in" from the mkdir and chmod commands.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hi Sylvain,
You know that, if you had a RCA video capture card, it would be a bit easier to capture a video stream from your miniDV camera. The winTV works very well for me. (though I never tried it on other OS...)
Cheers,
aalex
On 6/19/06, Mathieu Bouchard matju@artengine.ca wrote:
On Mon, 19 Jun 2006, Studio Zodiak wrote:
I get this: /dev/ieee1394/dv/host0/NTSC/in: No such file or directory Even if /dev/ieee1394/dv/host0/NTSC/in exists and has permissions. I did this: mkdir -p /dev/ieee1394/dv/host0/PAL/in chmod 666 /dev/ieee1394/dv/host0/PAL/in test -e /dev/ieee1394/dv/host0/PAL/in || mknod -m 666
/dev/ieee1394/dv/host0/PAL/in c 171 0
mkdir -p /dev/ieee1394/dv/host0/NTSC/in chmod 666 /dev/ieee1394/dv/host0/NTSC/in test -e /dev/ieee1394/dv/host0/NTSC/in || mknod -m 666
/dev/ieee1394/dv/host0/NTSC/in c 171 0
Both "in" should be character-devices, but it seems like you have created them as directories. remove "/in" from the mkdir and chmod commands.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On Thu, 8 Jun 2006, Studio Zodiak wrote:
I am trying to get my DV camera to work with pix_video under linux. I have to use Ubuntu. I have tried different fixes I have seen on this list like commenting out code in pix_videoNEW and the like.
I tried to port [pix_video] to GridFlow [#in dv1394], but found out that I had to change a bunch of #defines that now have an extra "IOC_" in the name, and then it froze my computer twice in a row. I could try to fix the code, at the cost of rebooting every 10 minutes, but I'd rather not use a driver so brittle. Then I learned that this driver is not maintained anymore and that a user-space equivalent exists, based on libraw1394.
Next time that I try working on DV support for GF I'll try going through libraw1394, and if it works, then we could sit together to retranslate it into GEM, if using [#export_pix] is not sufficient.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-I did not compile out of CVS nor did I change anything in pix_texture. (DEBUG_ME)
I am using version .90
I remember getting the pix_texture:not using client storage comment before without doing so.
All I get is a white strip (rectangle 4 3)
pix_info does not seem to be doing much.
Thank you
Sylvain
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Studio Zodiak wrote:
-I did not compile out of CVS nor did I change anything in pix_texture. (DEBUG_ME)
I am using version .90
all right then.
I remember getting the pix_texture:not using client storage comment before without doing so.
All I get is a white strip (rectangle 4 3)
pix_info does not seem to be doing much.
you have to attach a numberbox to the 2nd, 3rd and 4th outlet (expand the object with dummy args like [pix_info .....] to see the outlets)
anyhow, it seems like there is no image. you do have read permissions to the firewire devices and other apps work?
mfg.asdr. IOhannes
*/Thank you
/*Sylvain*/ /*
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-
Alexandre Quessy -
chris clepper -
chris clepper -
IOhannes m zmoelnig -
james tittle -
Mathieu Bouchard -
Studio Zodiak