and we have been actively pushing the boundaries of streaming for a couple of years now. As far as we know, we are the only ones who have benchmarked most of the existing solutions out there, and published some results. With Phenix RTS, we are the only ones with a PaaS based on webrtc and solely design for the streaming use case. Our infrastructure is based on the Medooze media server, but single server, or naive clustering of webrtc servers do not work for streaming at scale.
Kurento does seems to behave much worse under load than the others. The project also seems to be less active than one would like:
That study above was done in the Video conferencing use case (many to many). We also did the benchmarking for the streaming use case, and we seem to get the same results you did with wowza. Specifically, you can see on the slide #32 of our presentation at the Live streaming West 2018 conference that when wowza server gets saturated, instead of adapting like it should (slide #31), it is just dropping connections.
https://www.slideshare.net/alexpiwi5/streaming-media-west-webrtc-the-future-of-low-latency-streaming
If you want a state of the art of webrtc in streaming, you have the more recent presentation at Live Media East:
in short:
= services =
- you have traditional video conferencing services that can be used for streaming even though they will be suboptimal for that especially in terms of scalability. For limited number of viewer, and if you re not on premises, it can be a choice: tokbox,
agora.io, twillio, ....
- you have specialised streaming services, with dedicated design, and features (server-side ad-insertion, DRM, RTMP ingest, HLS egress, ...): phenix RTS and
millicast.com- you have non-webrtc based low latency services (based on websocket mainly): nano cosmos.
= Servers =
- you have traditional VoIP servers that support webrtc: kamailio, opens, free switch, asterisk, ....
- you have "webrtc native" video conferencing servers (as opposed to flash): jitsi, Janus, [Kurento], [licode], Mediasoup, OpenWebrtcToolbox (intel), ...
- you have hybrid media server toolbox: medooze
- you have traditional flash servers that supports webrtc: wowza, red5, and ant5.
Note that for the traditional flash servers, red5 is using a modified version of jitsi, and ant5 is using a modified version of red5. They also do clustering and not smart routing / streaming, so their capacity to scale is somehow limited. (That touches on harald comment on hierarchical topology of media servers.). Janus and its RTP-forwarding feature works better out of the box.
for delays between 0 and 1 second, prefer a webrtc solution; 1 to 3 seconds, websocket or wowza's webrtc (as per their marketing material), more than 3 seconds, you might want to use flash or HLS/MPEG-DASH if possible with a CMAF container.
for an on-premises, a few thousands viewers, small resolution, on a single location, almost everything will work. red5 and ant5 servers have an on-premises free version, an on-premises paid version, and a hosted version as well. If you're OK with Java, they are usually the starting point for streaming to small audience.
While the media servers will be adequate, beware of the delivery network, as harald mentioned. Test on site with someone wireshark-proficient :-)
hope this helps.