State of WebRTC outside of major browsers
I've been trying to set up a reliable lightweight solution for high quality, low-latency webcam (v4l2) streaming from Linux server to browsers, allowing for small (1-5) number of concurrent viewers.
The obvious choice here is WebRTC, which when used through browser APIs, works wonderfully. It has low latency and automatic quality adjustment depending on network performance.
I also checked out RTSP and RTMP, which are not supported without browser plugins. Next candidates were DASH and HLS, but while they provide high quality, they also have high latency.
For a while I used MPEG1 streaming through Websockets (using jsmpeg library), which worked and had low latency, but the video quality was bad.
Back to WebRTC - It seems like reliable, lightweight and maintained projects are really hard to find. So far I've found a few WebRTC media servers, but they're overkill for my use case:
- Janus
- MediaSoup
- Kurento (unmaintained)
I also tried implementing this functionality using low level Gstreamer elements in Python using PyGObject, but that's proving to be rather complicated with a ton of extremely low level implementation details.
If anyone has tried doing something similar, I'd really like to hear what (if any) problems you had and if you found any sane solutions. Next thing on my list is using headless Chromium in combination with Puppeteer, but I'd really prefer more lightweight solutions.
Have you looked at aiortc?
I'll take a look tomorrow, thanks.
I don't have any good advice for you on the WebRTC side, but I was wondering what the latency requirements are that took DASH/HLS off the table? Those I can perhaps point you in a helpful direction on, depending exactly what you need to do.
Ideally, sub 500ms + network latency. But up to around 1s is still acceptable.
I haven't done any optimization, but my initial research showed that while DASH/HLS can be optimized down to ~5s of latency, it's still far too much to feel like things are happening in real time.
You might just get away with it, actually. Up until recently the DASH/HLS limit was segment length, which would give a delay of a few segments at maybe 2 seconds each - in the vicinity of 5s minimum, as you say.
There's now somewhat wider support for CMAF, and specifically its low latency mode that allows you to subdivide the segments into ~500ms pieces and use HTTP chunked encoding to send them more quickly.
Back on your original question, I did also stumble across this (in a 'state of low latency' article) while I was looking for a good CMAF overview to share - never used it, but looks like it might be helpful if you do go down the WebRTC route: https://github.com/priologic/easyrtc/blob/master/docs/easyrtc_server_install.md