I have been asked to work on a project that requires live low-latency (under 1s best, up to 2s ok) video to be transmitted publicly to anywhere from 10-100 viewers. The current target is to embed the video in a web page that visitors can browse to and simply click "play" to start viewing the live stream. I've done this in the past with Wowza and JW Player. This was at least 4 years ago and we were able to get 1-2s quite reliably but it was mostly PCs. What I'm concerned about is that I'm reading that this is only reliable on devices/browsers that still support flash. Ideally we would need to keep all devices below 1-2s latency.
What I'm not sure about is if this can be done reliably for an HTML embedded player where the browser no longer supports flash. Is it reasonable to expect to get PCs, Macs, iPhone, iPads, Android Phones & Tablets, Windows Phones & Tablets all getting low-latency video through their web browsers?
If not, are apps like VLC able to provide this for mobile devices? If we have to tell viewers that the live stream is only fast on certain devices via web browser and that they should load up a link in VLC (etc.) for best performance on mobile devices that may be an acceptable option.
RTMP is going to provide the lowest latency when streaming on a web page. It would be extremely difficult currently to get latency of 2 seconds using HLS (to target mobile devices). This is largely due to how HTTP streaming protocols work. We have heard of customers getting latency down to 10 or less seconds but certainly not down to 1-2 seconds.
This article has some tips. As an example, you could try setting the keyframe on the source to 1 second set the cupertinoChunkDurationTarget to 1 second (1000 milliseconds). Note though that the HLS protocol requires 3 chunks before it starts streaming so it will always be somewhat behind the encoder output.