Forum Replies Created
-
Posts
-
Hi
The Syphon pd extension currently only outputs the content of the gem window, so I don’t think you could do that – unless it’s possible to have two gem windows? – I’m not a pd user. I can get two (identical) syphonserver objects running, but with the same content.
Sorry ’bout that – I’ve put up a new version – this one really should work
http://kriss.cx/tom/elsewhere/Syphon%20QC%20garbage-collection-friendly.zip
Ummmmm… weird. Can you restart your machine and remove all the third-party plugins you have installed, then add them back one by one, starting QC each time to see if you still have the issue – just to be sure it is the fault of Syphon.
Sounds like a problem with your code. If you can share a reduction which reproduces the issue we can take a look at that.
Impossible to know without knowing what myTexName refers to and what you have done and are doing with it.
We do support GL_TEXTURE_2D for serving. The underlying IOSurface only supports GL_TEXTURE_RECTANGLE. Is it a problem to you?
Welcome to the world of GPU-driver induced kernel panics… They shouldn’t happen, but they are easily triggered by abusing the GL.
Creating a reduction is my usual strategy when faced with kernel panics – often it’s the quickest way to identify the bad code, even though it can be a pain. Also, if you haven’t already, run your app in OpenGL Profiler, breaking on errors, and see if it throws any GL errors prior to causing the KP.
Syphon takes care of synchronisation (well, the underlying IOSurface does). As long as you retain a SyponImage in the client app, the surface remains valid even if the server is no longer using it.
Can you recreate the problem using only Simple Server and Simple Client? If not, can you provide an Xcode project for a minimal client app which does recreate the problem?
Also what hardware and OS version are you on?
There’s no support for 10.6, sorry. It’s quicker and easier work to target more modern system versions.
You could have a go at swapping the 2.12 ESDK into Blair Neal’s Canon2Syphon, which does support 10.6 – though I think his still causes a brief interruption to the stream every 20 minutes for some camera models.
Just to note that the OpenFrameworks movie code was recently rewritten to use 64-bit APIs and is not mature – but it’s widely used so it should shape up fast.
The 3.0 player currently lacks many of the features of the 2.0 player. It is built on the newer AVFoundation rather than QuickTime, so performance for those codecs it does support is generally improved.
Yea maybe Resolume has a weirdness – I noticed I had to toggle the Syphon checkbox in Resolume’s preferences off then on again to get Simple Server to show up. You could ask about it on the Resolume forums if it’s a problem.
Resolume 4 has native Syphon support, no need to use the QC plugin with it.
I can’t remember how VDJ is set up as far as getting individual channels – I’d ask them for support/try their forums.
For now, here’s a version of the plugin with a fix for the problem. We’ll try to get a new release out soon.
http://kriss.cx/tom/elsewhere/Syphon%20QC%20garbage-collection-friendly.zip
Are you planning to distribute the finished app? If so, you’ll have to include and load a version of the plugin and be able to handle conflicts with any installed version users may already have – which is a whole other kettle of fish…
Also I’d generally avoid using DXV outside of apps which support its accelerated decode (ie Resolume and the few licensed 3rd party products) – it has no advantages without their acceleration.
The current “release” v002 Movie Player 2 has terrible performance. Neither of us have the time to fix it right now.
A Syphon-serving movie app is a sound idea. The v002 Movie Player 2 spawns another process and uses the same mechanism as Syphon (IOSurface) to send the video to QC. Apple’s QC player does that too.
If you are able to use codecs supported by AVFoundation – H.264, ProRes and Photo-JPEG I think are the current list – then that is by far the simplest route to take, and very fast.
The maximum frame dimensions Syphon supports is dependent on the GPU. If you’re careful about how you feed your frames to Syphon it needn’t add any further performance hit.
If you let us know if you can work with AVFoundation or not we can probably give you pointers to the most efficient route to send frames through Syphon (if you need them).
This looks like a problem with our support for garbage collection in the framework.
If you can hook things up in Xcode with the Syphon patch removed from your QC composition, then switch it in when you run your app, it should work. If that’s a pain then we can look at providing you with a fixed framework version. Sorry ’bout that…
I haven’t tested this, but you could try doing “Get Info” on Airbeam in the Finder, and checking “Open in Low Resolution” – that might force it to use the correct dimensions.
I’d suggest you both pursue this with Airbeam – Syphon is just passing on the frame Airbeam gives it, without making any modifications.
You’ve asked this question before, and got an answer
http://v002.info/forums/topic/syphon-recorder/page/3/#post-4665
