Apple’s Low Latency HLS differs from the community-developed solution
I've been recently tasked to find a live video solution for an industrial device.  In my case, I want to display video from a camera to a local LCD and simultaneously allow it to be live streamed over the web.  By web, I mean that the most likely location of the client is on the same LAN, but this is not guaranteed.  I figured this has to be a completely solved problem by now.<p>Anyway, so I've tried many of the recent protocols.  I was really hoping that HLS would work, because it's so simple.  For example, I can use the gstreamer "hlssink" to generate the files, and basically deliver video with a one-line shell script and any webserver.  But the 7 second best case latency is unacceptable.  I really want 1 second or better.<p>I looked at MPEG-DASH: it seems equivalent to HLS.  Why would I use it when all of the MPEG-DASH examples fall back on HLS?<p>I looked at WebRTC, but I'm too nervous the build a product around the few sample client/server code bases I can find on github.  They are not fully baked, and then I'm really depending on a non-standard solution.<p>I looked a Flash: but of course it's not desirable to use it these days.<p>So the solution that works for me happens to be the oldest: Motion JPEG, where I have to give up on using a good video compression (MPEG).  I get below 1 second latency, and no coding (use ffmpeg + ffserver).  Luckily Internet Explorer is dead enough that I don't have to worry about its non-support of it.  It works everywhere else, including Microsoft-Edge.  MJPEG is not great in that the latency can be higher if the client can't keep up.  I think WebRTC is likely better here.<p>Conclusion: here we are in 2019 and the best low latency video delivery protocol is from the mid-90s.  It's nuts.    I'm open to suggestions in case I've missed anything.