
Ultra Low Latency WebRTC Streaming – Open-Source Media Server - selim17
https://antmedia.io/
======
kwindla
This looks to be nicely architected. Looking forward to digging in.

In answer to the questions about TURN, this approach won't be lower latency
than TURN but will scale better. TURN servers are just (nearly) passive
relays, so the sending client needs to set up as many outbound streams as
there are receiving clients in the session.

The advantage to the TURN approach is that you can do end-to-end encryption.

The server this post is about "forwards" streams. It's in a class of
infrastructure traditionally called a "Selective Forwarding Unit." So the
sending client can send one stream, and the SFU copies the stream and sends it
to the receiving clients. The server needs more CPU and outgoing bandwidth as
the receiver count grows, but the sending client doesn't need much of either.

Once you have streams piping through a server, you can do lots of other
things, of course. This server can transcode to several formats, including HLS
and RTMP, and can copy streams internally across a cluster to scale more than
a single machine can.

Media servers are really fun to work on: lots of small(-ish) hard problems
that touch low-level network protocols, memory and cpu optimization,
architecture (because eventually you want a clean plugins interface, etc.).

If you're interested in this stuff, check out Mediasoup, an open source WebRTC
SFU with a very nice design in which all the low-level stuff is c++ and all
the high-level interfaces are exposed as nodejs objects.[0]

[0]-[https://mediasoup.org/](https://mediasoup.org/)

~~~
tpetry
The sad part about selective forwarding units (SFU) is you loose end-to-end-
encryption. So you only have encryption between you and the sfu and sfu to
your participant. For hosted solutions this means a server could record all
your conferences.

Therefore i am waiting for the PERC standard. It will allow to send the
audio/video to server only once and the server will retransmit to all peers -
everything still end-to-end encrpted.

~~~
pjc50
How does the key distribution work for that?

------
kodablah
What makes this approach lower latency than, say, a centralized TURN server in
one of those clouds?

~~~
adreamingsoul
From my understanding, the current challenge with ultra-low-latency is scale.
Will it scale to 100, 1000, 100,000, concurrent users?

At the moment, everyone in the industry is working to figure out how to
provide a viewer experience that is similar, or better than the current
expectations of live streaming.

Live streaming is hard. Ultra-low-latency is just as hard.

However, I'm still not sure why we need ultra-low-latency. Will it improve the
live experience? Maybe. Aside from live-action sports or significant events,
do we as content consumers really need ultra-low-latency?

~~~
pedrocr
How low is ultra-low-latency that it's relevant for sports? Does anyone really
care if their broadcast is 30 seconds delayed from live?

I subscribe to both Formula 1 and MotoGP online streaming services and
couldn't care less if the broadcasts were even multiple minutes delayed. They
may very well be already and I wouldn't know. As far as I can tell they both
just use standard CDNs delivering DASH or similar (basically just short video
files played in sequence).

That seems more than enough for sports. Multiple minutes may result in getting
real time information from elsewhere (e.g., Twitter, local radio) but anywhere
from 10 to 30 seconds seems fine.

~~~
oaththrowaway
I work for a video streaming company (primarily sports). There is a huge
problem with latency in sports.

We call it the "Twitter effect". Essentially people either see things on
social media or app notifications before it happens. Kinda ruins it for some
people.

We are working on sub-30 second latency in 4K w/ server side ad insertion, but
it's hard work. Especially with encoding with DRM baked in.

~~~
pedrocr
Thanks! Do you know what the equivalent latency number is for cable TV? The
Twitter effect only applies for the difference between the two numbers.

~~~
cstejerean
Broadcast TV latency is usually in the 4-10 second range, with typical latency
being around 6s. Not sure how it breaks down between cable vs satellite vs
over-the-air.

------
rkagerer
500ms is low latency? What's usual?

~~~
BeefySwain
The best Vimeo/Livestream can do is about 30 seconds from the time the frame
hits their server, as a reference.

------
gugagore
There's also possible latency savings from having the video encoder be aware
of network conditions on a per-frame basis:
[http://ex.camera](http://ex.camera) but I don't think it's found its way to
the "mainstream".

~~~
hexane360
There's also this which tried to do something similar:
[https://snr.stanford.edu/salsify/](https://snr.stanford.edu/salsify/)

Edit: It's the same author

------
mgamache
I've used Wowza (video streaming server) for years and this is a direct
competitor. The pricing is a little higher for Wowza, but Wowza is a mature
product with tons of options for web streaming. The weakness of Wowza has been
its support for WebRTC. I am using it, but it's not easy to stream from
RTSP/RTMP to WebRTC. It also doesn't scale out for WebRTC

------
selim17
Test AMS Live Demo in
[https://antmedia.io/livedemo/](https://antmedia.io/livedemo/) AMS Github
Pages: [https://github.com/ant-media/Ant-Media-Server](https://github.com/ant-
media/Ant-Media-Server) Thanks.

------
dboreham
And here I was blissfully unaware that I'm experiencing reality 30 seconds
delayed. Had no idea, other than obviously there's some # frames delay needed
to do motion compression, and some transit latency.

------
rv11
It will help apps which require interaction from users, like google stadia's
game streaming. for other use cases, I think one does not care even if the
feed is delayed by few seconds.

~~~
IshKebab
Another interesting use case someone mentioned here before is the world cup -
you don't want a penalty shoot-out ruined by your neighbours cheering a few
seconds before you see the goal.

A few seconds would also such for live streaming where the streamer interacts
in chat.

------
MuffinFlavored
How does one-to-many streaming work? If 256 clients connect to one streamer,
how does the streamer not need to send his/her stream 256 times?

~~~
pault
That's what the server is for.

------
fabioyy
The problem is that webrtc is a very intensive CPU ( each connection have its
own encription ). How many users can this solution handle per server?

~~~
ec109685
How is encryption expense different from normal https streaming from a cdn?

~~~
fabioyy
packet size of webrtc(rtp) is VERY VERY VERY small, and since they are UDP,
each individual packet must be encrypted. ( i can't just encode a big chunk of
data and send to the network like tls ).

in fact, for scaling a solution that uses "near realtime broadcast", you
probably don't want encryption at all. ( afaik you can't disable webrtc
encryption. )

in my tests i can get 3x more performance just using rtmp/rtsp. ( ~8000 video
streaming connections on a aws c5.xlarge at 800kbit/s ).

------
DiseasedBadger
I've heard enough of this anti-anonymity, anti-privacy protocol.

