- This topic has 28 replies, 9 voices, and was last updated 7 years, 5 months ago by
.
-
Posts
-
Looking over the changes now and just so I understand all changes made here some statements for correction if needed:
a) I don’t need a framebuffer to be able to draw at all (which I thought) having a context is enough to create and modify a texture in OpenGL.
b) I don’t need to update the context as I am not technically changing anything that needs to be updated (e.g. painting meshes etc.) but only set this one texture buffer.
c) I don’t need to make the context current as I am the only one managing it..? This is the thing I was wondering most about.. Its clear that for one capture session I’ll get served from one thread but couldn’t it be that another capture device arrives on another thread? Is having a reference to the context and being sure you are the only one using it enough to be able to use it? Is makeCurrentContext just for “thread locking” the context?
d) The use of GLMacro is just more efficient when not using all the apple-related GL stuff I suppose? The “switching GL context” is caused due to the class I used being apple-specific GL use?Again thanks very much for the help, its much appreciated, this is what I love OSS for 😉
a) correct – you were creating an extra FBO for drawing offscreen from the main context when you can just draw in the context you create – but in fact you never do any drawing at all (apart from what happens inside Syphon)
b) -update doesn’t do what you think it does, see the documentation. You could do a glFlush() but actually Syphon flushes to push updates to clients.
c&d) CGLMacro.h handles directing commands to the correct context instead of using the more expensive makeCurrentContext, etc (see documentation). As you have one context per device you do need to make sure each device directs its commands to the correct context, but CGLMacro.h takes care of that (by using the value of the specially named cgl_ctx ivar to identify the context).Alright, thanks for clearing that up 🙂
Edit: Made the changes and also uploaded new binaries for all binary leecherz 😉@normen Your Syphon Camera App is useful, thanks for sharing it! I’d love to see it improved with some camera controls. In any case, I think it will allow me to easily accomplish some video input from webcams, cool!
Normen – you are a legend.
My previous Capture->Quatrz->Syphon solution stopped working as of 10.8. Using your app (forced in 32bit mode) I’ve got 720p50 coming in perfectly via a BM Ultrastudio 3D and then getting in to MadMapper. Will do some more exhaustive testing over the weekend to see how stable it is.
Alas it seems that some point in the last few months Syphon Camera has stopped work. Capture cards detect but don’t pass through to syphon.
Is it definite that it no longer works ? Trying to get a Messoa IP camera working via SyphonNetCamera into Jitter.
Should I give up ?
I’m trying to get SyphonNetCamera working with Spydroid, an OSS Android IP Camera app. When I put the Spydroid URL into SyphonNetCamera, it connects and the stream begins, but SyphonNetCamera does not publish the frames to Syphon. SyphonNetCamera does work for me with other IP Cameras.
Here’s a video showing SyphonNetCamera connecting to Spydroid, failing to publish frames, and then successfully publishing frames from another IP Camera source. Spydroid IP camera SyphonNetCamera problem.
To confirm that the problem is not Spyrdoid-specific, here is proof of Spydroid successfully streaming into VLC using the same URL:
I have a similar problem with Bakercp’s IPCAM2SYPHON. I wonder if it has to do with the formatting of the Spydroid URL (http://18.189.9.13:8080/spydroid.sdp?h264=640-30) or the encoding of its frames (available in h264 or h263), the choice of port, or some other issue.
Thanks for your help!
- You must be logged in to reply to this topic.