January 18, 2017 at 9:12 am #3325
Do you know if there’s a way to know when a sender has a new frame ready. For instance if the sender is playing a movies at 25 FPS, I don’t want my engine to make 60 FPS. I’d like to synchronize my engine on the sender. Is it an option in SPOUT ?
It’s possible with Syphon…
Thanks!January 18, 2017 at 12:33 pm #3326
Some colleagues and I looked into this a little while back.
Spout senders and receivers simply see a DirectX texture all the time which might or might not be different. Syphon does not depend on DirectX texture sharing and works in a different way.
Basically a new frame will be ready from a sender as soon as it can render it, and that is when some other instance has finished with accessing it. Access of a receiver is within one frame time (16.7msec) and the sender can update the shared texture straight away after that.
So the sender will easily keep pace at 16msec per frame. The receiver does not need to access at this rate, but it is difficult to know when a “new frame is ready”.
The question is when the sender renders the next frame and updates the texture. The problem is knowing when that happens and there is no way to know when a particular command of the OpenGL command queue has finished. That is if you don’t flush the command queue and then risk a stall and subsequent problems.
What has been on my mind is a function like “FrameReady” that a sender calls and an equivalent and “IsFrameReady” for the receiver. This might involve additional messaging by some means and how to do it without disrupting the current process is uncertain. It is only an idea at this stage.January 18, 2017 at 3:29 pm #3327
What has been on my mind is a function like “FrameReady” that a sender calls and an equivalent and “IsFrameReady” for the receiver
Yes that’s what is missing. With Syphon on OSX, you can attach a callback when the sender finished a frame. That’s handy to avoid flooding the GPU with useless work… I think about people using many applications on the same machine, if each app does OpenGL processing at 60FPS, switching context, swapping etc. while it just displays an image, that’s a shame :-/January 19, 2017 at 12:53 am #3328
Tests so far have shown that Vertical sync prevents the sender or receiver from writing to or reading from the same frame during the same cycle. A signal independent from the monitor refresh rate would be useful in your project for video at a lower rate than the monitor refresh rate. That’s why I am thinking of that option.
But at 60fps cycle, the question is when the sender has finished the frame. A frame-ready signal would indeed signal ready to read and the sender would have completed the texture write function, but the texture might not have been refreshed yet as explained above.
Frame numbering tests, by embedding a number directly in the image data, have shown that generally the sender and receiver access the texture within the same vertical sync cycle. You would expect that because the write/read is less than 0.5msec. But every now and then the receiver misses a frame and more frequently (but not always), the receiver is getting the frame on the next sync cycle. But always the frame number is the same as the sender is producing. I am reluctant to put a frame-ready signal on top of this without knowing what is going on.
Anyway there is more coming soon with Spout 2.006 which will hopefully provide a compatibility mode for graphics that do not support the OpenGL/DirectX interop without disturbing the fundamental DirectX texture sharing. Then I can re-visit the sync issues.September 18, 2018 at 9:40 am #4011situsjudionlineParticipant
its goodSeptember 16, 2019 at 12:39 pm #4384
Any news on this point ?
People are complaining with Unity => spout => MadMapper fluidity. I can also reproduce the issue with Resolume generator => SpoutReceiver on another screen (even if both screens have same frequency and connected to the same GPU)
Maybe the sync is better with D3D => D3D app.
I get good results with an OpenGL app of us => spout => MadMapper (OpenGL).
A synchronization mechanism would really push spout quality. Would getting a callback in the receiver when the sender unlocked the texture be an option ?September 17, 2019 at 12:41 am #4385
Have a look at the GitHub beta branch for Spout 2.007. The entire SDK can replace the 2.006 files with only minor changes if any. You will need to use the 2.007 utilities. All instructions are in the readme.
Synchronization is still controlled by mutex lock as well as the OpenGL/DirectX interop locking function. But on top of that, frame counting is used to determine whether the sender has produced a new frame and the frame data is only updated if the frame is new. In place of a callback, there is a function IsFrameNew() that the application can used to avoid time consuming processing if necessary.
Because the OpenGL/Interop lock operates at the driver level there is no control over it, so you might find that driver settings can affect the result. In particular “Threaded Optimization” can cause hesitation or stutter, so turn it off.September 17, 2019 at 7:36 am #4386
That’s a great news. I plan testing in the coming weeks and will let you know. Thanks !September 17, 2019 at 7:59 am #4387
OK I will be keen to hear how you get on. The important thing to know, in order to be confident of release, is whether the application works without problems with existing applications. It should do, even if Frame Count is enabled. Before release, there could be some changes for the latest 2.007 methods but existing code will not be affected.September 17, 2019 at 11:26 am #4389
Is there a planned release date ? (so I schedule dev & testing)September 18, 2019 at 12:43 am #4390
The beta branch was created to give people an opportunity for early testing and report any problems. At this stage I am thinking of some changes to class files as indicated above. All the various plugins and libraries need to be updated as well as the documentation. I am sorry that I can’t give a firm time frame for this.
- You must be logged in to reply to this topic.