Multipeer connectivity low latency video stream?

Hey devs!

I recently started a project, a macOS app, which is like a Remote Desktop app but only on local network.

For this I wanted to use the MultipeerConnectivity framework, and it's my first time using it. So I have already done the device discovery side that is working well as it is the easier part. Now I just need someone who knows how it works and who has time to explain me (as I couldn't find any documentation about this) how does work the OutputStream And InputStream in MC and if its a good choice for my needs. It has to be low latency and high resolution... I also have seen other frameworks such as WebRTC that I could combine with a local WebSocket Server, but as I'm new to live video streaming and that I don't know anyone that is experimented with this I wanted to ask there for your advices.

Thank you in advance, TR-MZ (just an unknown Indie dev).

Accepted Reply

My general advice is that you not use Multipeer Connectivity for new code. See TN3151 Choosing the right networking API for more on that. For a screen sharing app, where there’s a clearly defined client and server, you’re much better off using Network framework.

In terms of how you actually transport the data, there’s definitely a latency versus complexity trade-off to be made here. Networking has fundamental limitations — limited packet size, packet loss, and out-of-order delivery — and you have to decide whether you want to deal with those limitations yourself or let the system deal with them.

If you use a TCP stream then life is simple — data you pour in one end flows out the other — but you can run into latency issues. Specifically, it suffers from the head-of-line blocking problem.

To get around you can switch to UDP, but that exposes you to all of the above-mentioned limitations.

There is a third way here, namely QUIC, but that has its own complexities.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

  • Hey Eskimo ! Thank you for this quick answer. I will check everything you sent me Tommorow. Just a question, you told me about Quic , is this the best choice if I want something very smooth ? I prefer going for something more complexe and better for the user than something easier for me even if it has to take some time to understand. Also you said that UDP exposes me to the above limitations, are you talking about the package size,…?and thank you again for taking your time to help me :)

Add a Comment

Replies

My general advice is that you not use Multipeer Connectivity for new code. See TN3151 Choosing the right networking API for more on that. For a screen sharing app, where there’s a clearly defined client and server, you’re much better off using Network framework.

In terms of how you actually transport the data, there’s definitely a latency versus complexity trade-off to be made here. Networking has fundamental limitations — limited packet size, packet loss, and out-of-order delivery — and you have to decide whether you want to deal with those limitations yourself or let the system deal with them.

If you use a TCP stream then life is simple — data you pour in one end flows out the other — but you can run into latency issues. Specifically, it suffers from the head-of-line blocking problem.

To get around you can switch to UDP, but that exposes you to all of the above-mentioned limitations.

There is a third way here, namely QUIC, but that has its own complexities.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

  • Hey Eskimo ! Thank you for this quick answer. I will check everything you sent me Tommorow. Just a question, you told me about Quic , is this the best choice if I want something very smooth ? I prefer going for something more complexe and better for the user than something easier for me even if it has to take some time to understand. Also you said that UDP exposes me to the above limitations, are you talking about the package size,…?and thank you again for taking your time to help me :)

Add a Comment