Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Best latency configuration with high quality #374

Open
zbynekdrlik opened this issue Feb 26, 2024 · 3 comments
Open

Best latency configuration with high quality #374

zbynekdrlik opened this issue Feb 26, 2024 · 3 comments

Comments

@zbynekdrlik
Copy link

Hi, I am looking for best configuration for lowest possible latency in this scenario:

  1. Powerful windows pc with spout out from resolume TO other powerful windows pc (possible hdmi/sdi out). In this configuration we are able to provide optical 10gbit connection.
  2. powerful windows pc with spout out form resolume TO raspberry pi or other suggested mini pc

We like to replace sdi connection from source windows pc to led wall processor and have similar latency.
We have done some tests today and be able to get 3 frames latency in first scenario.
Is there possibility for lower latency?
Could this latency be also on some rpi?
Which compression should be used when we like to have 2.5gbit lines with lowest latency?

@zbynekdrlik
Copy link
Author

Hi, reaction from dev team please :)

@alatteri
Copy link

I would think a non-temporal comrpession algorithm would provide the lowest latency. Maybe try JPEG, Cineform, Prores.

@MartinPulec
Copy link
Collaborator

We have some here some latency measurements but unfortunately the numbers are quite dated. Basically, OpenGL with without sync-on-vblank provided best latency (but the vsync may be required). It is is possible, that Vulkan now would perform better now.

Moreover, there is a fixed 1 frame latency added at the receiver. If your network doesn't reorder packets, you can try to lower it even to zero.

Generally, I think that 2 frames may be feasible. It depends how you measure it - in the above-mentioned measurements, the capture card added also 1 frame delay.

For the RPi - hard to tell, we didn't measure. But as Alan proposed, it is worth trying JPEG to fit the link speed, ideally GPUJPEG on the sender. I have doubts if RPi would be powerful enough for Cineform or ProRes decode.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants