Scalable, Ultra Low Latency and Adaptive WebRTC Streaming
antmedia.io
antmedia.io
In the community edition there are MP4 Recording, IP Camera Support, HLS Support, WebRTC Ingestion, web panel, etc.
In enterprise features, it's totally different than the Red5. There is no single line of source code of Red5 in the enterprise features of the project. Everything is implemented from scratch.
[1] https://www.wowza.com/blog/ietf-incorporates-low-latency-hls... [2] https://www.wowza.com/blog/apple-low-latency-hls
- https://github.com/video-dev/hlsjs-rfcs/blob/lhls-spec/propo...
When searching for a tool to use to record the videos, I was very happy to find this open source server, so I wouldn't be locked to some service provider. The documentation is quite good and I didn't have difficulty integrating it to our project, despite the fact that I'm mostly a front-end and NodeJS developer.
Now that the project is live, we are having a few problems with some users. The videos that our users record are stored and watched later by specialists, we don't watch them live. But after the user start and stop recording, sometimes the .mp4 video file is not found on the server. But it is very nice that Ant Media has a admin page with CPU and memory usage, and it also reports when there's been a server crash.
It asks my email address and the support service receives the log files and reply at most a few days later. We're in contact right now, I'm sending them all the information I can to help resolve this issue. Of course we tested the integration ourselves, with 5 concurrent users recording, but not a single one of our tests has failed the way our users are reporting.
Edit: the topic of my bachelor's thesis included low latency live streaming, so I hope I have at least some knowledge :)
Getting buffers down to 500ms is already pretty insane assuming reliability doesn't suffer. 250ms is well within the envelope of a single drop on a 3G network killing playback
The way you drop latency is by reducing or eliminating buffers, that's pretty much it.
There's a trade-off with h264 and hevc/265, as with most video codecs - the larger the buffer you have, the more delta frames you can have between key frames.
This means lower bandwidth and better compression.
So it's a constant struggle between compression and latency.
The lowest latency that webrtc can get is about 4ms one way, 8ms round trip, at least based on the project I started to do realtime steaming with https://github.com/3DStreamingToolkit/3DStreamingToolkit
We proved you could do round trip times in the real world from cloud to customer in under 25ms.
But it comes with a lot of tradeoffs and cost and complexity to make it work.
Google Stadia fundamentally uses webrtc under the covers, although they use QUIC instead of TCP/ICE.
If you ripped out all of the congestion management from the video engine in webrtc, you'd reduce another several ms roundtrip at the cost of basically no network resilience.