May 19, 2012 at 6:45 pm #6027
I am working on getting all my video sources to syphon (big fat thanks to the syphon developers for this great library!) As Syphon seamlessly works between 64bit and 32bit apps its a good way to get pictures from cameras with 32bit drivers into 64bit software (e.g. ARC-based applications). I made two applications that might be interesting for more people and I’ll release them as soon as I have tested them enough and removed the last usability quirks.
One is a 64/32bit app that uses QTKit to get camera streams and push them into syphon, if you run it in 32bit mode you can access all 32bit camera devices. The other is a 64bit app that can put stream of any (MJPEG compatible) IP Camera into syphon. For the latter I used libjpeg-turbo to get the best possible decoding performance. Additionally for the IP Cameras, the data stream and the decoding is suspended when there is no syphon client. This way one can switch cameras and get the best possible performance (with my cameras in wireless mode I can only have two streaming at once while keeping the framerate above 25fps).
Everything is done via backbuffers and there is as few data copying involved as possible. The performance of the camera input application is as good as when I use apples ways directly to record from the camera.
A picture says more than a thousand words
I’ll check back here with some download link after a bit of testing.
Update: GoogleCode repository with complete source and binary downloads available here: http://code.google.com/p/syphon-camera/
NormenMay 19, 2012 at 7:30 pm #6028
Normen, this is great work! Do you intend to open source these? If so, we are happy to host in the main repositories. I have some additional code to get native driver input from Black Magic Devices (which is *seriously* faster than native QTKit and Quicktime Library 32 bit calls).
Either way, and whatever you wish, the Net camera inputs are huge.
Thank you for helping the community.May 19, 2012 at 7:43 pm #6029
Sure I could OSS them, would also alleviate the problem of hosting them for me. They are really not much code, was more the research for me. I guess some additional eyes and ideas can improve them still, they were not really intended to become OSS, eherm . Blackmagic driver support would be nice indeed Should I contact you directly somehow when I got “per-cam-hotness” working? Everything else seems to work fine so far, some threading could be more elegant but its safe so this would probably be the last thing I’d do for myself.
NormenMay 20, 2012 at 9:44 am #6032
cool yea this is good – looking forward to seeing something to try out. if you could share code either with us or on github or whatever that would be awesome, but even if you want to keep it closed-source… good work!May 20, 2012 at 2:33 pm #6042
cool! Some time ago I wrote a tool to pipe IIDC cameras to Syphon server using libiidc1394. Feel free to use the source code if you think it could be useful.
May 20, 2012 at 3:41 pm #6049
- This reply was modified 1 year, 6 months ago by Andrea Cremaschi.
Nice, thanks or the feedback I guess I finished work on the IP-Cam plugin so I uploaded it to google docs for now: https://docs.google.com/open?id=0B84M35anjNjANEtUQWxHemJjMmM
It contains the binary and sources for possibly adding them to the projects repo. Maybe the “on demand” enabling of cameras could be made optional still to have faster switching for some applications (its pretty fast with my ip cameras though)..
I also uploaded the QTKit thingy, just didn’t have a chance to improve the “hot camera” handling yet. Its working globally and you should set it before you enable any camera. Maybe I’ll improve this still so if you want to you could wait with adding this. https://docs.google.com/open?id=0B84M35anjNjAbnB1NkZpOG9md2s
I marked some parts of the code as “TODO”, maybe someone can have a look at these parts as with some stuff I am not 100% sure if its supposed to work like this.
Thanks again to everybody!
NormenMay 20, 2012 at 3:47 pm #6050
Normen, do you have a google code account? If so, I can add you as a committer to the Syphon-Implementations project, and we can host it there (if you want to)May 20, 2012 at 3:50 pm #6051
Sure, maybe you wanna take a look at the code first though? Theres one thing where I don’t exactly know why its working (painting the texture)… but it does work My googlemail is normen667 and I have the full googlemail.com (not gmail.com) ending.May 20, 2012 at 6:47 pm #6057
Hey cool – I’ve downloaded the code but not taken a look yet. Maybe this could live as a separate project somewhere – either on google code or github – our syphon-implemenations repository is in danger of becoming unmanageably sprawling. Do you use either of those? If you wanted to put it up I’m sure one or both of us will get around to providing annoying code suggestions soonMay 20, 2012 at 6:55 pm #6058
Yeah, I could set up another gc repo for this but personally I enjoyed being able to download so much example code for syphon from one place.. The actual code I implemented for this now is pretty slick and might help others who just want to push some kind of image into the gpu/syphon (even without a gl context in the first place). I just need some hints if I should re-apply some gl states or if its not necessary or if it could be done even simpler. Oh and ofc I found one bug in the netcam thing, forgot to replace a call to a wrong thread where I even explicitly comment about it in another place I just wouldn’t want to be responsible for any complaints to you about bad syphon example code..May 20, 2012 at 8:01 pm #6061
Hey Normen, one idea Tom and I were discussing, was the possibility of setting up a “Syphon IO” application, where we could provide a plugin interface for things like QTKit Capture, and for IP Cameras (and additionally, native Deck Link, etc capture, screen capture, etc).
I think this could either be great, or a pain in the ass. Thoughts? Is that something you would be open to having your code included in, as a plugin? Let us know.May 21, 2012 at 3:11 am #6067
Hm sounds a bit problematic to me actually.. Like for example the threading part etc.? Making the system adapt to multiple ways of doing it (lock the context, create new contexts etc.) sounds like it might bloat the system pretty quick to me.. But maybe thats because I think of plugins basically in a “single-threaded” callback way similar to VST’s / AudioUnits..?
Syphon itself already feels pretty plugin-ish to me given its cross-application abilities and the ability to pipe it around as you wish. What I would have liked when I started doing this would have been a base class to reuse like [syphonTool startServerAndGlContext]; [syphonTool publishImageData:nsData];. Still maybe I am just oblivious of better and simpler ways to implement such a plugin systemMay 21, 2012 at 3:42 am #6068
yea I’m not convinced of vade’s plugin idea either
We’d link to your project from the syphon-implementations one and generally do our best to make sure it got wide coverage. The main problem with adding endlessly to syphon-implementations is that most people only want one of the implementations but have to sync the whole repository to get the top level shared parts – and some of the projects are fairly large.
As I’m quite a fan of SCM I’d rather add any changes to your code once it’s up on google code or github or wherever – I find it’s safest to be able to track my mistakesMay 21, 2012 at 4:09 am #6069
haha, fair enough I’ll check in the code in a GC repo at some point and pingback here.May 21, 2012 at 9:20 am #6071
You must be logged in to reply to this topic.