Sharing Video Streams Between Applications (Spout & Syphon)

Theatre Technology

Syphon and Spout are tools that allow us to easily share video between applications on the same computer.

In last week's article we covered a video over ip protocol called NDI. This week we are going to stay in the video realm and look into both Syphon and Spout and by the end of this video you will know what they are, why they were created, how they work under the hood, and how you can use them in your next project.

What Problem Syphon and Spout Solve


To get a better understanding on why Syphon and Spout exist in the first place let's take a look at a real world problem that we need to solve. Say we have a computer that is running QLab and we want to send the video output from QLab into Touchdesinger for some additional post processing and mapping. Of course we could always grab ourselves two computers one with QLab and one with Touchdesinger then use an HDMI out on the QLab side then plug in a capture card on the Touchdesigner side.

Qlab to Touch



While this technically would work it leaves us with two main problems. The first problem is that we need two computers each of which running its corresponding software. The second issue is that there is a lot of computational overhead and latency. If we were to follow the data stream we would see that we needed to convert the video to an HDMI signal, send it over a cable then on the receiving end load it back into the GPU.

Each of these steps eats up our cpu and delays the video stream more and more. To solve this problem Syphon and Spout were created. First and foremost while these two SDK’s have different names they essentially perform the same task. Syphon is for the Mac operating system whereas Spout is for the windows operating system.

How Syphon and Spout Work


How Syphon Works



They work on a principle called texture sharing. Say we have a very simple image of a happy face. In the GPU’s memory this image will be mapped to individual memory locations. Whenever we want to show this happy face on the screen we simply need to read the data from memory and write it to the screen. 

Since all applications share the same GPU memory pool we can theoretically make some low level API calls to create a shared texture that can be accessed from different applications. While this would work it would require every software to play nicely with one another and would be dependent on the underlying graphics layer.

Now comes Syphon and Spout. These two SDK’s make it effortless to add this functionality, and it handles all the complex GPU stuff behind the scenes. If you watched my last video on NDI this workflow will be very familiar to you. 

How to Use Syphon and Spout


On the source side of the video stream which will be the application creating the video content we will need to create a shared texture. For Syphon this is called a “Server” and for spout it is called a “Sender”. Once we do this our video stream will be in a shared texture. Now on another app we can read from that shared texture by using a receiver. And with that we have successfully shared video between two applications.

Spout



One of the greatest benefits of using Syphon and Spout is that there is nearly zero lag at all. And this has to do with how we are using a shared texture in the GPU memory rather than using the CPU to transfer the data from one processor to another.

Limitations of Syphon and Spout


There are a couple of limitations that we need to keep in mind however. The largest limitation is that we can only share video between applications on the same computer. If we wanted to share video across computers we would have to reach for a solution such as NDI. Another limitation is that the software you are using has to support either Syphon or Spout and while the adoption of both has been very successful you may run into instances where an application does not support it.

touch.png 126 KB


I personally use both Syphon and Spout in my day to day projects and have found that they are a valuable tool to have. It allows the system designer to not be confined to a single piece of software and instead use whatever works best for the project.