Syphon is a Mac OS X technology to allow applications to share video and still images with one another in realtime, instantly.
License: Other
Syphon is an open source Mac OS X technology that allows applications to share video and still images with one another in realtime.
See http://syphon.github.io for more information.
This project hosts the Syphon.framework for developers who want to integrate Syphon in their own software. If you are looking for the Syphon plugins for Quartz Composer, Max/Jitter, FFGL, etc, the project for the Syphon Implementations currently at http://github.com/Syphon
This crash is from the current commit (10/19/20). Basically SyphonOpenGLServer::dealloc releases _renderer, then calls super, which calls destroyResources, which tries to call destroySizedResources on the newly deallocated _renderer.
Not sure the best way to fix it. Maybe just add
_renderer = nil; in dealloc?
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x5cbe00ffd398)
frame #0: 0x00007fff6d37ae5d libobjc.A.dylib`objc_msgSend + 29
frame #1: 0x000000010c9a2478 Syphon`-[SyphonOpenGLServer destroyResources](self=0x000060000236c070, _cmd=<unavailable>) at SyphonOpenGLServer.m:301:5 [opt]
frame #2: 0x000000010c9a1fa4 Syphon`-[SyphonOpenGLServer stop](self=0x000060000236c070, _cmd=<unavailable>) at SyphonOpenGLServer.m:169:2 [opt]
frame #3: 0x000000010c9a9594 Syphon`-[SyphonServerBase dealloc](self=0x000060000236c070, _cmd=<unavailable>) at SyphonServerBase.m:125:5 [opt]
* frame #4: 0x000000010c9a1f73 Syphon`-[SyphonOpenGLServer dealloc](self=0x000060000236c070, _cmd=<unavailable>) at SyphonOpenGLServer.m:155:2 [opt]
I just updated to macOS 10.12.4 and noticed that Syphon Recorder is not working anymore. I can launch it but cannot select an input (buttons are greyed out). Is this a common issue?
Hi, may be I am trying to do something this tool is not designed to do. Can the syphon client connect to a remote server using IP and port, or does it only work on local port? I see the server displays its IP and the port it is using, but I cannot find a way to enter the sever address using the syphon client. I am using the TCPsyphonserver/client apps.
When I attempt to download from http://syphon.v002.info/, I get this 404 error;
- That’s an error.
The requested URL /files/Syphon%20SDK%20Public%20Beta%202.zip was not found on this server. That’s all we know.
SyphonServerDirectory currently uses the dictionary describing the server as the object when it emits NSNotifications. It should use itself, and set the dictionary as the userInfo, to allow filtering of notifications by object. Or at least think about this.
https://code.google.com/p/syphon-framework/issues/detail?id=23
FBO blit in (and out?)
See #13 (comment)
I believe Syphon apps as currently designed require the kIOSurfaceIsGlobal flag set on the IOSurface published by the server, in order to be shared by clients via a globally shared IOSurfaceID.
However, this feature is deprecated since macOS 10.11, and when it is removed, I believe Syphon apps will break.
warning: 'kIOSurfaceIsGlobal' is deprecated: first deprecated in macOS 10.11 [-Wdeprecated-declarations]
I suppose a globally accessible buffer with screen contents is considered a security hole, and nowadays the specific IOSurface should be shared explicitly between client/server through some IPC mechanism, as suggested in this forum post:
You should use IOSurfaceCreateXPCObject() or IOSurfaceCreateMachPort() and then transfer the resulting object or port to the other process(es) through the appropriate IPC mechanism. Those other processes can use IOSurfaceLookupFromXPCObject() or IOSurfaceLookupFromMachPort() to get a reference to the IOSurface from the object or port.
https://forums.developer.apple.com/thread/18958
Is my read on this correct? Syphon will need such an IPC channel added to the design for sending IOSurfaces, and all Syphon apps (clients + servers) will need their Syphon.framework updated to a version which knows about the IPC method to publish/discover Syphon servers.
See discussion in #20.
SyphonServer name changes are propagated to SyphonServerDirectory by notifications, and directly to any attached SyphonClients by messaging.
If a host is keeping a SyphonClient alive based on name, then it can end up deleting the client (based on the client's updated version of the name) and then immediately recreating it (based on the directory's not-yet-updated version of the name). The new client is stuck with the old name (because it is created after the server-to-client messaging).
We should probably only use a single form of IPC for updating names, and do it atomically so SyphonClients and SyphonServerDirectory vend the same name, however this still leaves the time between querying SyphonServerDirectory and instantiating the SyphonClient open for a SyphonClient to end up stuck with an old name, so whatever fix we choose, newly created SyphonClients should be provided with the current name - either from the server, or if SyphonServerDirectory becomes a single name authority, by querying that.
Out of the box checkout produces the following error
clang: error: garbage collection is no longer supported
Issue to track progress of subclassing branch
Hi,
Is it true, that, if when using Syphon Server to push frames, FPS will be capped to 60 (display Hz)? Has to do with some intrinsic properties how it binds to OS @ low level?
I have never had need to run Syphon enabled apps before above 60fps.
I am using oF stable branch (0.9.8 tag), current master branch of ofxSyphon, OS X 10.11.6 (15G31) w/ AMD FirePro D700, NSAppSleepDisabled for bunde identifier. However not asking in oF addon repo as first wanted to understand is it SyphonFramework behaviour, that the addon only extends.
If no and there is no capping, I will ask @astellato about the oF & ofxSyphon.
Thanks!
My test has
ofSetFrameRate(120);
ofSetVerticalSync(false);and
syphonServerTex.publishTexture(&someFbo.getTexture());Whenever I comment out the tex publishing (that one line above, not delinking Syphon), app reports 120fps as expected.
When tex publishing line is present it caps to 60fps.
Stupid bug, but @dlublin and I are working on a new Syphon enabled app, and on a View Controller View Did Load on a fresh OS X app with Storyboards, we could not get a SyphonServerDirectory to return any available servers.
Moving our Syphon Server Directory to app controller, Application Did Finish Launching makes it work, sans any other code changes
Speculation, but either an NSRunloop issue or some sort with NSDistributedNotifications aren't available / received in a timely fashion until App Did Finish Launching is fully completed.
Not so much a bug perhaps but a note of nuance.
Computers amirite?
Is there a syphon implementation that can extract alpha and fill from a html source website? Has something similar been done before? Would something like this be possible?
Has anybody embedded Syphon Client into GPUImage framework?
Any pointers would be appreciated.
Hi there,
since now we are know OpenGL going to be deprecated sooner or later, I'm wondering how you see the future of Syphon? Can all this be done using Metal?
Thanks!
From Google Code:
May be made moot if we become sandboxable - see #10.
Reported by bangnoise, Nov 3, 2010
Currently SyphonClient invokes any new-frame handler on the main thread. This means that drawing may happen on the main thread, and that new-frame handlers can never be invoked in parallel for different clients.
This is because currently SyphonCFMessageReceiver installs its CFRunLoopSource on the main thread.
We could use SyphonDispatch to invoke new-frame handlers on their own threads. Currently SyphonDispatch does no exception handling. We should probably address that if we start using it to call user code.
Additionally we could consider installing SyphonCFMessageReceiver's CFRunLoopSource on a dedicated thread.
Apr 16, 2011 bangnoise
(No comment was entered for this change.)
Labels: -Priority-Medium -Milestone-Release1.0 Priority-High Milestone-PublicBeta2
Jun 1, 2011 bangnoise
Fixed in r33
Status: Fixed
Jun 13, 2011 bangnoise
Either there's a subtle bug in SyphonMessaging somewhere or a bug in CFMessagePortSetDispatchQueue() (under 10.6.7 but not the next major revision) causing SyphonMessageReceivers to never receive messages sent to them in some circumstances. This needs some more investigation to pinpoint the source of the bug (in the OS or Syphon), and if in the OS avoid using CFMessagePortSetDispatchQueue().
Status: Accepted
Jun 13, 2011 bangnoise
I've undone the change in public-beta-2 so its behaviour is as public beta 1 (messages are received on the main thread).
Labels: -Milestone-PublicBeta2 Milestone-PublicBeta3
Jun 13, 2011 [email protected]
So 10.6.8 behavior in CFMessagePortSetDispatchQueue() works as expected and the non main thread messaging works fine? Or do you mean 10.7 ?
Jun 17, 2011 bangnoise
I don't mean 10.6.8. Shh! ;)
Feb 4, 2012 bangnoise
r60 reverts r33 pending a real fix for this
Feb 4, 2012 [email protected]
Is this something we could change between 10.7 and 10.6.8, doing a runtime check? 10.7 seems to work with the above (now reverted fix), but 10.6.8 does not - it eventually looses handle on messaging. Perhaps 10.6.8 clients can have the main thread behavior, but 10.7 clients can use our own private queue? I'm sure you want a cleaner fix, but this might be a way to settle it and move on, for now?
Feb 4, 2012 bangnoise
I think original issue (moving messaging off main thread) is important enough that solution should work for all supported OS versions.
If an app with a server is hidden or its windows obscured, Mavericks will sometimes nap it, causing the server to cease to update.
I propose to add a feature to have each SyphonServer suspend App Nap for its lifetime. An new option will be created to pass when creating a server to opt out of this feature if wanted.
Comments welcome.
If SYPHON_CORE_SHARE is TRUE then the call "_shareContext = CGLRetainContext(context);" in initWithServerDescription:context:options:newFrameHandler is not balanced by a CGLReleaseContext call, introducing a potential context leak.
Here's the code from SyphonServer.m
#ifdef SYPHON_CORE_SHARE
_shareContext = CGLRetainContext(context);
if (SyphonOpenGLContextIsLegacy(context))
{
_context = CGLRetainContext(context);
}
else
{
_context = SyphonOpenGLCreateSharedContext(context);
}
#else
_context = CGLRetainContext(context);
#endif
balanced by this in the stop method
if (_context)
{
CGLReleaseContext(_context);
_context = NULL;
}
I fixed this in my version as follows
if (_shareContext)
{
CGLReleaseContext(_shareContext);
_shareContext = NULL;
}
if (_context)
{
CGLReleaseContext(_context);
_context = NULL;
}
Hey there! We've been getting occasional reports of a crash-on-quit, where our main thread is waiting on Syphon's finalizer() function when a background thread crashes (usually a CVDisplayLink thread crashing deep in shader compilation code).
Here's an extract from a report that seems pretty representative of the majority of these cases:
OS Version: Mac OS X 10.13.4 (17E199)
Crashed Thread: 29 CVDisplayLink
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00007fa1b8985400
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Bus error: 10
Termination Reason: Namespace SIGNAL, Code 0xa
Terminating Process: exc handler [0]
VM Regions Near 0x7fa1b8985400:
MALLOC_SMALL 00007fa1b8970000-00007fa1b8976000 [ 24K] rw-/rwx SM=PRV
--> MALLOC_SMALL 00007fa1b8976000-00007fa1b8999000 [ 140K] rw-/rwx SM=COW
MALLOC_SMALL 00007fa1b8999000-00007fa1b89aa000 [ 68K] rw-/rwx SM=ZER
Thread 0:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff54d6b25e semaphore_timedwait_trap + 10
1 libdispatch.dylib 0x00007fff54bfa99f _dispatch_sema4_timedwait + 72
2 libdispatch.dylib 0x00007fff54bf299e _dispatch_semaphore_wait_slow + 58
3 info.v002.Syphon 0x0000000105a1b174 finalizer + 147
4 dyld 0x000000010b89cdfd ImageLoaderMachO::doTermination(ImageLoader::LinkContext const&) + 259
5 dyld 0x000000010b888613 dyld::runAllStaticTerminators(void*) + 64
6 libsystem_c.dylib 0x00007fff54cd0eed __cxa_finalize_ranges + 351
7 libsystem_c.dylib 0x00007fff54cd11fe exit + 55
8 com.apple.AppKit 0x00007fff2a08af2a -[NSApplication terminate:] + 1930
9 com.apple.AppKit 0x00007fff2a641a43 -[NSApplication(NSResponder) sendAction:to:from:] + 312
10 com.apple.AppKit 0x00007fff2a0d6213 -[NSMenuItem _corePerformAction] + 323
11 com.apple.AppKit 0x00007fff2a0d5f9b -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 114
12 com.apple.AppKit 0x00007fff2a0d4dff -[NSMenu performKeyEquivalent:] + 363
13 com.apple.AppKit 0x00007fff2a6406a9 routeKeyEquivalent + 884
14 com.apple.AppKit 0x00007fff2a63dce0 -[NSApplication(NSEvent) sendEvent:] + 1096
15 com.apple.AppKit 0x00007fff29e9e8b5 -[NSApplication run] + 812
16 com.figure53.QLab.4 0x0000000104f4fe19 -[QLab run] + 71
17 com.apple.AppKit 0x00007fff29e6da72 NSApplicationMain + 804
18 libdyld.dylib 0x00007fff54c24015 start + 1
...
Thread 29 Crashed:: CVDisplayLink
0 ??? 0x00007fa1b8985400 0 + 140332563452928
1 ATIRadeonX4000SCLib.dylib 0x00007fff25a50f8d boost::detail::sp_if_not_array<InputShaderControl>::type boost::make_shared<InputShaderControl, CompilerBase*&, _SC_SRCSHADER const*&>(CompilerBase*&&&, _SC_SRCSHADER const*&&&) + 77
2 ATIRadeonX4000SCLib.dylib 0x00007fff25a50d30 ShaderControl::ShaderControl(CompilerBase*, _SC_SRCSHADER const*&, _SC_HWSHADER*&) + 192
3 ATIRadeonX4000SCLib.dylib 0x00007fff25a5e23a SCCompileShader + 74
4 com.apple.AMDRadeonX4000GLDriver 0x0000000108ee908c glrATI_SI_SCCompileVertexShader + 982
5 com.apple.AMDRadeonX4000GLDriver 0x0000000108f3410b glrAMD_Hwl_CompileVertexShader + 247
6 com.apple.AMDRadeonX4000GLDriver 0x0000000108ed7225 glrUpdateCtxSysVertexProgram + 1118
7 com.apple.AMDRadeonX4000GLDriver 0x0000000108eee177 gpusLoadCurrentPipelinePrograms + 4219
8 com.apple.AMDRadeonX4000GLDriver 0x0000000108ed5092 gldUpdateDispatch + 1989
9 GLEngine 0x00007fff36ede9e0 gleDoDrawDispatchCore + 601
10 GLEngine 0x00007fff36ea37ee glDrawRangeElements_IMM_Exec + 288
11 com.apple.QuartzCore 0x00007fff37c75f25 CA::OGL::GLContext::draw_elements(CA::OGL::PrimitiveMode, unsigned int, unsigned short const*, CA::OGL::Vertex const*, unsigned int, unsigned int, CA::OGL::ClipPlane const*) + 215
12 com.apple.QuartzCore 0x00007fff37c75e45 CA::OGL::Context::array_flush() + 93
13 com.apple.QuartzCore 0x00007fff37c850bf CA::OGL::Context::ClippedArray::next_rect(CA::Bounds&) + 295
14 com.apple.QuartzCore 0x00007fff37db258f CA::OGL::emit_one_part_rect(CA::OGL::Context&, CA::OGL::RectState const&, float const*, float const*, unsigned int) + 940
15 com.apple.QuartzCore 0x00007fff37c83dc4 CA::OGL::fill_rect(CA::OGL::Context&, CA::OGL::RectState const&) + 176
16 com.apple.QuartzCore 0x00007fff37db328d CA::OGL::fill_round_rect(CA::OGL::Context&, CA::OGL::RectState const&, double, unsigned int, bool) + 175
17 com.apple.QuartzCore 0x00007fff37cfb3f0 CA::OGL::render_solid_background(CA::OGL::Renderer&, CA::OGL::Layer const*, CA::OGL::BaseColor, CA::Render::Pattern*) + 1735
18 com.apple.QuartzCore 0x00007fff37c83775 CA::OGL::render_background(CA::OGL::Renderer&, CA::OGL::Layer const*) + 373
19 com.apple.QuartzCore 0x00007fff37c829d2 CA::OGL::render_contents_background(CA::OGL::Renderer&, CA::OGL::Layer const*) + 535
20 com.apple.QuartzCore 0x00007fff37c82399 CA::OGL::LayerNode::apply(float, CA::OGL::Surface**, float*) + 59
21 com.apple.QuartzCore 0x00007fff37c8079a CA::OGL::ImagingNode::render(CA::OGL::ImagingNode::RenderClosure*, unsigned int) + 456
22 com.apple.QuartzCore 0x00007fff37c89296 CA::OGL::ImagingNode::retain_surface(float&, unsigned int) + 150
23 com.apple.QuartzCore 0x00007fff37c891b5 CA::OGL::LayerNode::retain_surface(float&, unsigned int) + 113
24 com.apple.QuartzCore 0x00007fff37c80660 CA::OGL::ImagingNode::render(CA::OGL::ImagingNode::RenderClosure*, unsigned int) + 142
25 com.apple.QuartzCore 0x00007fff37c804f3 CA::OGL::render_layers(CA::OGL::Renderer&, CA::OGL::Layer*) + 299
26 com.apple.QuartzCore 0x00007fff37c8243c CA::OGL::LayerNode::apply(float, CA::OGL::Surface**, float*) + 222
27 com.apple.QuartzCore 0x00007fff37c8079a CA::OGL::ImagingNode::render(CA::OGL::ImagingNode::RenderClosure*, unsigned int) + 456
28 com.apple.QuartzCore 0x00007fff37c804f3 CA::OGL::render_layers(CA::OGL::Renderer&, CA::OGL::Layer*) + 299
29 com.apple.QuartzCore 0x00007fff37c8243c CA::OGL::LayerNode::apply(float, CA::OGL::Surface**, float*) + 222
30 com.apple.QuartzCore 0x00007fff37c8079a CA::OGL::ImagingNode::render(CA::OGL::ImagingNode::RenderClosure*, unsigned int) + 456
31 com.apple.QuartzCore 0x00007fff37c804f3 CA::OGL::render_layers(CA::OGL::Renderer&, CA::OGL::Layer*) + 299
32 com.apple.QuartzCore 0x00007fff37c8243c CA::OGL::LayerNode::apply(float, CA::OGL::Surface**, float*) + 222
33 com.apple.QuartzCore 0x00007fff37c8079a CA::OGL::ImagingNode::render(CA::OGL::ImagingNode::RenderClosure*, unsigned int) + 456
34 com.apple.QuartzCore 0x00007fff37c804f3 CA::OGL::render_layers(CA::OGL::Renderer&, CA::OGL::Layer*) + 299
35 com.apple.QuartzCore 0x00007fff37c8243c CA::OGL::LayerNode::apply(float, CA::OGL::Surface**, float*) + 222
36 com.apple.QuartzCore 0x00007fff37c8079a CA::OGL::ImagingNode::render(CA::OGL::ImagingNode::RenderClosure*, unsigned int) + 456
37 com.apple.QuartzCore 0x00007fff37c804f3 CA::OGL::render_layers(CA::OGL::Renderer&, CA::OGL::Layer*) + 299
38 com.apple.QuartzCore 0x00007fff37c7bbaa CA::OGL::render_root_layers(CA::OGL::Renderer&, x_link_struct const*, CA::OGL::Gstate const&) + 487
39 com.apple.QuartzCore 0x00007fff37c7173a CA::OGL::Renderer::render(CA::Render::Update const*) + 1012
40 com.apple.QuartzCore 0x00007fff37c71311 CA::OGL::render(CA::OGL::Renderer&, CA::Render::Update*) + 396
41 com.apple.QuartzCore 0x00007fff37c60b09 view_draw(_CAView*, double, CVTimeStamp const*, bool) + 3093
42 com.apple.QuartzCore 0x00007fff37c5fec3 view_display_link(double, CVTimeStamp const*, void*) + 153
43 com.apple.QuartzCore 0x00007fff37c5fd1b link_callback + 255
44 com.apple.CoreVideo 0x00007fff2e4d95cf CVDisplayLink::performIO(CVTimeStamp*) + 233
45 com.apple.CoreVideo 0x00007fff2e4d8a14 CVDisplayLink::runIOThread() + 612
46 libsystem_pthread.dylib 0x00007fff54f3c661 _pthread_body + 340
47 libsystem_pthread.dylib 0x00007fff54f3c50d _pthread_start + 377
48 libsystem_pthread.dylib 0x00007fff54f3bbf9 thread_start + 13
Binary Images:
0x104f29000 - 0x10547cfcf +com.figure53.QLab.4 (4.2.3 - 4203) <C0916F24-A452-3F09-AF5C-EA9522243AFD> /Applications/QLab.app/Contents/MacOS/QLab
0x105a13000 - 0x105a25fff +info.v002.Syphon (3 - 3) <1034CFCA-CAB7-3823-A23F-AD77736BEEB5> /Applications/QLab.app/Contents/Frameworks/Syphon.framework/Versions/A/Syphon
Many of the crashes are in CA::OGL code like that one; some are in CoreImage code, still while attempting shader compilation. A handful are not on CVDisplayLink threads at all, but rather on threads with names like Dispatch queue: TFSVolumeInfo::GetSyncGCDQueue: vRefNum = -100(boot).
Do you have any insight as to what might be happening here? It's a crash on quit, and not a terribly common one, but I'd feel better if I at least understood what was going on, and whether it's something we can prevent on our end. As it is, I don't know how to reproduce it. It's a rare race, although at least one customer has hit it multiple times on a single computer.
Currently, our reliance on NSDistributedNotifications for Server Announce, Server Retirement, SurfaceID exposure, etc, limits Mac App Store capability due to the fact that NSUserInfo dictionaries cannot be populated to Applications running in a sandboxed environment.
This limits Syphon Framework to only be included in non Mac App Store binaries. That is sad.
Some may be absent - docs need to emphasise that.
Hi
have you had a chance to peek in the "App Extensions" feature of the forthcoming OSX 10.10?
As it seems it is all we'll get from Apple about interprocess communication and Apple Store compatibility. I wonder if it could partially help to replace the NSDistributedNotifications mechanism, even if I suspect that some of the constraint of the framework aren't suitable for Syphon (i.e. an interaction by the user is required through a system UI).
This is related to: #10
I'm using GLFW on Mavericks with an OpenGL core 4.1 context with forward compatibility turned on.
After my first call to bindToDrawFrameOfSize:, glGetError() returns GL_INVALID_OPERATION. Subsequent calls produce no error.
Everything still works as expected, however, and I can see my published frames in the Simple Client.
My guess is that something in setupIOSurfaceForSize: is causing problems, perhaps glPushAttrib, which is deprecated.
I would prefer to use publishFrameTexture:, but it doesn't work at all, I suspect because it makes much more extensive use of deprecated functions. Is there a branch lurking out there that fixes this, or a suggested workaround?
Some issues can be resolved and closed. The aim is to have either fixed and closed or opened GitHub issues for all Google Code issues by Beta 3.
Sometimes the SyphonClientBase class calls the frameHandler, but the boolean "hasNewFrame" indicates there is no new frame to draw (This behaviour is logged in our client demo app) which is inconsistant
This is likely because we rely on a glFlush (the sync point for the IOSurface) after unbindAndPublish. This does mean the remote client can have the new-frame handler invoked prior to the IOSurface update being synced. In practice, it is likely (but not certain) that sync will have happened before the client actually uses the surface.
Adding this certainty would require performing the flush ourselves in unbindAndPublish - after unbinding and before publishing.
SyphonServer -> SyphonGLServer (or SyphonOpenGLServer?), etc
Original names kept as aliases, or possibly as subclasses so we can mark them deprecated to encourage users to move to the new names.
Information could be shared between applications thru the stablished Syphon connection.
Using a NSDictionary would leave the server and client open to share anything.
As an example, render time, document name, color correction, name of a complementary Syphon texture.
Unless anyone objects I'm going to update the deployment target to 10.8.
This will require a couple of minor code changes for deprecated calls.
SyphonClient is not Key-Value-Observable for the isValid property.
SyphonClient is not Key-Value-Observable for the hasNewFrame property. This will likely not change. If you need to observe this, use a new-frame handler instead.
(from google code)
Generally applications use a combination of app and server name (if present) when maintaining clients through server lifetimes or reinstating Syphon state from saved files.
One situation in which this is inadequate is when server state is stored in a file opened by different applications, as the app name will change, making client restoration impossible based on the app/server name combination.
Having a persistent unique identifier for servers would
This was previously discussed and largely rejected in #23 in the context of SyphonClient persistence.
Hi, I've downloaded the the client and server examples and linked my project with Syphon.framework included in the client, and then opened the example server, and tried listing the available servers with:
NSArray *available = [[SyphonServerDirectory sharedDirectory] servers]
as suggested by the documentation, available.count is returning 0, and when closing and reopening the server many times, the SyphonServer*Notifications are never triggered. I'm linking with Foundation.framework too, and the example client and server are communicating between them well. I'm using OS X 10.12.
Maybe I'm need to link to another framework? or maybe I need to initialize something else?
Not for naught, Syphon uses an IOSurfaceRef internally and it would be great if I could provide it directly instead of converting it to a texture first.
Hello Guys,
ran into a GPU restarting problem which only occurs on 10.10 with Intel HD GPUs. Really hard to reproduce, and I am not sure this is related to Syphon and not a driver problem.
In a nutshell, I have a window with an NSOpenGLContext, and while resizing the window sometimes the GPU restarts in the background, sometimes crash on the publishFrameTexture... method. I have locks around the GL calls, so I believe this is not related to that, and surprisingly the issue stops when I don't send frames via Syphon.
I have a relatively minimal example project as well as a little screen record about the problem - maybe I just make something stupid there?
Syphon Recorder (13) using framework head is crashing on a hackintosh (forum post). Hopefully we can at least avoid the crash, even if not get it working...
Process: Syphon Recorder [704]
Path: /Applications/Syphon Recorder.app/Contents/MacOS/Syphon Recorder
Identifier: info.v002.syphon.Syphon-Recorder
Version: 13 (13)
Code Type: X86 (Native)
Parent Process: launchd [172]
Responsible: Syphon Recorder [704]
User ID: 501
Date/Time: 2014-09-26 10:09:05.838 +0200
OS Version: Mac OS X 10.9.4 (13E28)
Report Version: 11
Anonymous UUID: 64AB6CC7-FFFE-705C-77BB-D2281A3A634D
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000038
VM Regions Near 0x38:
--> __PAGEZERO 0000000000000000-0000000000001000 [ 4K] ---/--- SM=NUL /Applications/Syphon Recorder.app/Contents/MacOS/Syphon Recorder
__TEXT 0000000000001000-0000000000024000 [ 140K] r-x/rwx SM=COW /Applications/Syphon Recorder.app/Contents/MacOS/Syphon Recorder
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.apple.Foundation 0x92d3af8f probeGC + 221
1 com.apple.Foundation 0x92d4186a -[NSConcreteMapTable removeObjectForKey:] + 57
2 com.apple.Foundation 0x92d9d2bc NSMapRemove + 71
3 info.v002.Syphon 0x000368be -[SyphonClientConnectionManager newFrameForContext:] + 50
4 info.v002.Syphon 0x00035589 -[SyphonClient newFrameImageForContext:] + 81
5 info.v002.syphon.Syphon-Recorder 0x0000682a 0x1000 + 22570
SyphonClient sometimes returns YES for isValid when it could return NO.
From google code
I am getting the following glitch in a syphon client from a syphon server embedded into GPUImage application, which seems to be due incorrect texture indexing in the syphon server.
In the GPUImage host I am using GL_TRIANGLE_STRIP to render the textures, and that works fine.
From Google code:
Reported by bangnoise, Nov 18, 2010
Currently a SyphonClient is created with credentials for one instance of a SyphonServer. When the server dies, the client is no longer useful. If an identical server is subsequently created, it is up to the host app to observe this and create a new SyphonClient
Perhaps:
comments?
Nov 18, 2010 [email protected]
4. Seems redundant to me. Would not matching the Application name and Server name be equivalent to having a new "SyphonServerOptionIdentifier", no?
I say, if anything, 1, 2, and 3. This seems like something SyphonNameBoundClient can have, if gets rolled into the framework proper?
Nov 19, 2010 bangnoise
1, 2, and 3 suggest we roll it into SyphonClient. The only change to the API would be the additional NSString const SyphonClientOptionStayAlive to be passed in the options dict for SyphonClient.
Because this behaviour is what I imagine 99% of people want, I think it makes sense to make it the default, rather than having it in an extra class (something like SyphonNameBoundClient).
From google code:
Currently all textures passed are GL_UNSIGNED_INT_8_8_8_8_REV GL_BGRA. We could support other types and formats.
Perhaps
Internally, the backing chosen will be the "highest" values for format and type requested by any clients, but never a higher value than that set by the server. Consequently in a situation with multiple clients the backing may change during the lifetime of the clients (but only for the better quality-wise). If none of the optional attributes are present, behaviour will be exactly as now.
my current thinking is that clients should transmit their capabilities to servers when they join, and servers should scale down their backing if a client can't deal with what it has selected. Cases where that scaling down would happen should be rare as any sanely-created contexts are going to match capabilities on the same machine
When a SyphonClient exists and a server is resized or removed, any existing cached SyphonImage will be deleted from the main thread, which may conflict with the host app's GL thread management (Unity 4.2 is a casualty of this). We currently incorrectly rely on CGLLockContext().
To track the lifetime of contexts we may need to tie a SyphonClient to a particular CGLContext by taking a context as an argument at init and deleting any cached resources when that client is deleted.
Work on this is currently in the mt-issue branch.
If a client receives calls to -newFrameImageForContext: for a series of different contexts, textures for the previous contexts remain in existence until the client is released. This affects Unity and potentially any app which rebuilds contexts to reflect renderer changes.
A no-API-changing way to fix this would be to only retain internally the SyphonImage for the last context passed to newFrameImageForContext (and delete images in earlier contexts when the context changes).
If we were to change the API for SyphonClient we could tie clients to a single context by taking a context at init and exposing a readwrite context property, dropping -newFrameImageForContext: and adding -newFrameImage.
If a server is alive but not publishing frames and a client connects to it, the client will remain black until the server starts publishing again.
The client should receive the last published frame upon connection.
Since eafbc08
SyphonClient's -stop causes -invalidateFrame to be called resulting in SpinLock contention.
We could do with getting doxygen to output a custom sidebar (rather than its current verbose top-bar, even after we've trimmed it as much as humanly possible).
Packaging a DocSet, and making it available via a feed URL would be neat, too. There's a bug in Doxygen's current DocSet generation making them suboptimal, but still useful. See https://bugzilla.gnome.org/show_bug.cgi?id=619040
From google code:
Right now we provide the option of "private" Syphon servers, but one can still programatically access their surfaces by guessing surface IDs. Surfaces could be private and servers could transmit the mach port right rather than the surface ID. This would require using mach messaging directly.
We need to properly build individual -D arguments from GCC_PREPROCESSOR_DEFINITIONS, the current version no longer works
Hey I saw you moved the project on GitHub, welcome! :)
Now it would be easier to integrate Syphon in CocoaPods to make it easier to add it in a new project. Do you know it? I myself wished a Syphon pod to exist.
If you wish I can write a specification for the project.
Ciao
a.
Some compiler settings will cause warning or errors when there's no newline at the end of a file. Currently Syphon.h doesn't have a newline at EOF. Ignoring this is a bad idea, so I suggest adding this super simple fix.
/Users/theuser/Projects/capturetheweb/build/vendor/syphon/src/syphon-build/build/Debug/Syphon.framework/Headers/Syphon.h:184:4: error:
no newline at end of file [-Werror,-Wnewline-eof]
*/
^
1 error generated.
My compiler settings that produce an error since Syphon.h doesn't have a newline at EOF.
Thanks for this great project!
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.