How to handle a slow consumer/client connected with live Streaming server

Question

I'm working on live streaming server using a custom codec (have to use that, no way around it). Multiple clients will connect with the server to get the live feed. In an ideal world, all clients will be connected via broadband connections and after encoding I can just forward all the encoded frames to each socket in round-robin manner. In real life though, I could have clients connected via high-latency connections as well as slow/mobile connections. This would result in few clients being able to ingest data rapidly whereas others will lag.

Clearly, techniques like round-robin won't work here. Another technique that would work is encoding for each connection, but that would consume excessive CPU on the server side - which isn't acceptable either. Finally, I was thinking of modified h264 i-frame technique. Basically, regardless of content, just add an I-frame every 1-2 seconds. That way a slow consumer will be able to sync up with the rest at every I-frame. Feedback? Are there any standard techniques/algorithms to handle such a scenario?

Answer 1

• You'll need at least 2 encodings a normal (high bandwidth) and a smaller (low bandwidth).
• Using .NET 4.5's await/async syntax with the socket.*Async methods would also bring out some extra performance rather than using round robin synchronous sockets, using IO completion ports and less blocking. (an SO example of this : https://stackoverflow.com/a/12631467/884862)
• Finally to figure out whether to serve your clients the high or low bandwidth version, without implementing adaptive bit-rate streaming.
• • Give the user a choice
• • Do a bandwidth test, send the client an echo request with 128KB of data and using the sent time and return time to figure out of the client is fast enough for high bandwidth version or not.