Dual output for 3D stereo projection?

[relaxpi4]

Ok, thanks for the info!
For me, a few restart (your player or Pi?) is acceptable

[dividuum]

For me, a few restart (your player or Pi?) is acceptable

Just the software. Which, to be honest, makes all this more confusing

[relaxpi4]

yes, indeed

[relaxpi4]

And what about lower resolution, like 2560x720?
Mis-sync is also 8ms max?
And how can you measure the delay?

thanks!

[dividuum]

And what about lower resolution, like 2560x720?
Mis-sync is also 8ms max?

Didn't try that.

And how can you measure the delay?

I wrote debug output indicating the state of each screen including a sequentially incremented frame number, whether it's drmModePageFlip'ed already and when the callback confirming a flip arrived. Essentially each frame when through 3 states: next (ready and waiting to be flipped), flipping (waiting for vsync confirmation) and current (it's now on the screen). The debug output printed that to the console IIRC 1000 times per second and you could see a pattern where the frame becoming current on one screen happened at roughly half way between a complete cycle on the other screen. As 60Hz is 16.6ms/frame, the offset was around 8ms.

[6by9]

No, splitting stereoscopic via the two hdmi outputs is not a use case that is currently supported. Splitting a single decoded image between screens is possible, but synchronisation between the two outputs is the main issue.

It may be possible to slew the clock for one output, but I don't know enough detail of the clock hierarchy to say. Likewise you may be able to add a few dummy lines into one frame, but I don't know if the pixel valve is happy with those values being changed dynamically.

[relaxpi4]

Ok, understand, thank you for writing.
Anyway if the mis-sync is max 8ms, and that can be lower with a few restart of the player, and that delay will stay constant for a longer period of time (say 1-2 hours), that will be usable for my need.

[dividuum]

[...] and that delay will stay constant for a longer period of time (say 1-2 hours)

I did not do any long term tests to see if there's any drift.

[relaxpi4]

yeah, if you have a chance to do it (no hurry) i will considering buying your app

[dividuum]

yeah, if you have a chance to do it (no hurry) i will considering buying your app

No need to make this a prerequisite or wait: If you want to test the software and see if the syncing works for your use case, you can use the "private" version for free. It's feature-identical to the paid version, except you can not use if for any public or commercial use cases.

[relaxpi4]

cool, thanks

[relaxpi4]

Does your player support 50Hz on both output?
Mind you share also your "debug output" tool, so i can help you testing it on my sytstem, with different videos, etc?
Pi4 2GB version is enough, right?
That's what i ordered, so support the dev. team

[relaxpi4]

Hi

so what would be the LUA file exactly, if i have my 3840x1080 HEVC video?

I like to test.
Thank you!

[relaxpi4]

somebody? dividuum?

[dividuum]

somebody? dividuum?

Sorry, I seem to have missed the topic notifications. The debug view isn't included in the default build of info-beamer and even then its output is quite confusing and not very actionable. As long as there's no proper way to force synchronization, I fear the randomness is all that's possible at the moment.

[relaxpi4]

For backup 3D player thats fine

[relaxpi4]

No news since then, right?
In my experiences drift will change even while playing a videofile
So only usable for very slow 3D scenes (no action, sport, running animal, etc)