Syphon frames received out of order

[timredfern]

Has anyone here used ofxSyphon successfully?

I'm trying to use syphon to make a recording of my performance software on a 2014 MBP with i7 & GT750M.

My software uses openFrameworks and ofxSyphon. The output is 1080p and I'm using the standard way of publishing the stream from the examples - ie mainOutputSyphonServer.publishScreen() on the main thread.

When I open syphon recorder, I can see the output, but the frames play out of sequence - movement jumps back and forth, I would estimate by at least a second - as if there's a buffer of 25 frames and they are being displayed in the wrong order.

Has anyone seen anything like this with ofxSyphon? Or has anyone used syphon successfully to record a 1080p stream?

[bangnoise]

Everyone here has used Syphon successfully...

To be clear, do you see the out-of-sequence frames in Syphon Recorder's preview window, or in the recorded movie?

It would be helpful if you could provide a minimal OF project to reproduce the issue.

[timredfern]

I see the out of sequence frames in both the preview window and recorded output.

Will make an example project.

[timredfern]

syphon_issue.zip

So in the course of making the minimal example I seem to have found the cause. I'm using 2 glfw windows with a shared context and exporting to syphon from the slave window. Doesn't seem to happen the other way round.

It makes a very strange glitch, somehow between the window output and syphon. I had thought that it was that frames were out of order but could it be a GL transformation glitch? Anyway I'll be trying to reproduce it in future work ;-)

[vade]

Im out of the loop with OF these days. Why aren't you drawing in draw, but in drawOutput?

[timredfern]

take a look in main.cpp, there are multiple glfw windows sharing a context

[vade]

I saw that, but why cant you use draw ?

[vade]

Oh, derp, I see. You just map the function pointer to the draw event. Derp. I dont really fuck with OF these days.

[vade]

I notice you aren't setting the projection matrix every draw loop, im rusty on my immediate mode GL but methinks that may be of import as well no?

[timredfern]

I don't think that's it, because the problem goes away when exporting to syphon from the "main" draw function rather than than the subsidiary one. Something about the shared GL context makes Syphon not send what's in the output window correctly.

[vade]

Is this because the order of flush vs clear commands means the surface being vended to syphon is invalidated and cleared before it’s displayed and you’re getting effectively fucked up video memory garbage?

Ie window 1 draw, send to syphon Window 2 draw content Window 1 clear Syphon draw (cleared frame) Window 1 draw, send to syphon Due to IPC timing fluctuations syphon draw correctly, Window 2 draw Window 1 clear

Honestly having worked with the OF core I wouldn’t be surprised. If a basic case of a single app window window single context works - I’d keep everything vanilla and manually control when flushed occur and do something like

Main screen draw, flush, don’t clear - vend to syphon, draw second screen, flush, then ensure you do all of it in same order again.

If you disable vsync and use simple timers to draw both windows independently you likely are seeing phasing between window drawing and flushing and surface invalidation. If you can control the draw cycle try to do it manually. Otherwise I don’t know. We need more info.

http://vade.info

On Mar 26, 2018, at 5:48 PM, Tim Redfern notifications@github.com wrote:

I don't think that's it, because the problem goes away when exporting to syphon from the "main" draw function rather than than the subsidiary one. Something about the shared GL context makes Syphon not send what's in the output window correctly.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[timredfern]

It's unimportant, I have a workaround - export from the "main" draw function.

Thanks for your help!