streaming-html5 | Testbed examples for Red5 Pro HTML SDK usage | Camera library

You won't achieve low latency with any of the segmented distribution methods (HLS, DASH, or similar). The very nature of these protocols is that the data is chunked into relatively large pieces. 4 seconds with HLS is amazingly low, and with chunks that small you have quite a bit of overhead... a waste of bandwidth and not really HLS and DASH are good for.

The first one is working under the assumption that the content consumers will not be on site.

My answer there (https://stackoverflow.com/a/37475943/362536) doesn't assume that the consumers will not be on your site... that's not the case at all. What I'm suggesting there is that you take advantage of YouTube and embed their viewer when low latency isn't needed, saving you mountains of money.

If all of your viewers require low latency video to make this work, you're going to have to get crafty on the server side. If you told us what sort of scale you were working with, perhaps we could suggest something more specific. Since you didn't, let's focus on the possibilities client-side.

WebRTC is one of the best options. Everything in the whole WebRTC stack is built with low latency in mind. With WebRTC, you can get those sub-second latencies in normal operation. Note that aren't a lot of good choices for streaming servers that support WebRTC today.

You can also use Media Source Extensions and Web Sockets. This gives you quite a bit of control and allows very fast streaming of data to the clients, at a slightly higher cost of latency. It's much easier to do this than it is to implement your own server-side WebRTC that supports media streams.

I strongly recommend reading over my answer on that other question again as well. There are a lot of considerations here... make very sure that this low latency is actually worth the reduction in quality and the financial costs involved. This is rarely the case, expecially for 10s of thousands of users or more.