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.

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).

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.

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!

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.

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.

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 soon 😉

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..

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.

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 system 🙂

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 mistakes 😉

I’ve committed some basic changes to SyphonCamera – the same sort of thing could probably happen in SyphonNetCamera. Nothing major.

You could consider letting the cameras choose the pixel format if you don’t mind having to handle a variety of pixel formats and potentially non-CVPixelBuffer-based output – it would save the buffer conversion and for cameras which output Y’CbCr frames would half the data-throughput to the GPU as well – if you fancy that much work 🙂

Cool, thanks, thats exactly the kind of looking over the code I was hoping for 🙂 I’ll do that to the NetCam application as well when I got time. I know from jMonkeyEngine3 that going down the “support all image formats” road can get hairy quick so I don’t think I’ll do that for now 😉