3

I'm looking for some suggestions on how to use the tag to stream a live-video stream with relatively low latency (~2s). I've seen some other questions similar to this posted such as this and this but neither really adequately answered my question. The first one is working under the assumption that the content consumers will not be on site. The second also seems to make that assumption.

I'm looking for technologies, libraries or any suggestions really to achieve this. I've experimented with nginx-RTMP to receive streams from video devices and then using HLS to send it to the browser. The lowest latency I've been able to achieve with this however was ~4s. I haven't gotten around to working with DASH and I found this paper that describes using it for low-latency in a similar setup to mine but I wanted some opinions before I got started in trying that.

I understand that solutions such as gstreamer do exist and I've gotten latency of around 200ms measured using GPAC tools but having users download things is not really an option I can pursue (the site of the LAN setup won't have internet, cellular or otherwise, at all).

edit 1:

I'm not working at massive scale at all. At most there will be 200 users all of which will connect to the LAN via wifi. The reason I need low latency is that the goal of the project is to provide users better views of the event they are at. The actual viewpoints are pretty bad.

Community
  • 1
  • 1
Curtis Bezault
  • 53
  • 1
  • 7
  • the only thing that even comes close is webrtc. Otherwise you need to use a app, and not a browser – szatmary Mar 07 '17 at 04:17
  • At an event... are the users on WiFi by chance, or wired? – Brad Mar 08 '17 at 03:48
  • Wifi, but I think I have that part figured out. I'm going to have ~10 small servers each connected to 4 mesh aps which will all be wired to a central server that will be handling the encoding of the video being sent to it and will send out the final feed to all the smaller servers, I'm using a bunch of ubiquiti aps which apparently can do this kind of stuff plus limiting their broadcast strength to encourage user devices to migrate to the better ap. Or I might have no clue. Either way this is more of a personal project than something that HAS to be done the absolute best way. – Curtis Bezault Mar 08 '17 at 04:13
  • That's not to say I don't appreciate suggestions on how to do this best within a reasonable budget. How would you, for example, do this with 20-40 people? – Curtis Bezault Mar 08 '17 at 04:22
  • @CurtisBezault The Ubiquity gear is solid. Ruckus also makes similar equipment. I'd avoid the mesh networking aspect and wire all the APs to a central switch, and use an AP controller. Since you control the physical network, UDP multicast is the way to go, but this is not possible with WebRTC in the browser. (Streams are encrypted, and I'm not sure you can get the same key on all clients.) Take a look at Janus for the WebRTC server. – Brad Mar 08 '17 at 04:52
  • I have been considering Janus as an option but it still creates a connection per webrtc client exactly because of the encryption. I did find this [paper](http://dl.acm.org/citation.cfm?id=2749223) which implied that Janus was pretty good. If I went the UDP multicast route what would I use on the client side? I looked into the websockets suggestion and it seems workable but I don't have a lot of experience in this space. Could you also suggest an AP controller? Do I need a physical device or could I just use Ubiquiti's controller running on one of the servers. – Curtis Bezault Mar 08 '17 at 15:25
  • Okay so there really is no way of receiving a udp multicast in a browser without some kind of additional plugin which I can't really do. – Curtis Bezault Mar 08 '17 at 23:36
  • Ubiquiti's controller is fine. And, no, unfortunately there's no UDP multicast support in-browser. Depending on the event and what you're trying to do, it might be easier/cheaper to get some projector screens. :-) – Brad Mar 09 '17 at 22:21
  • Yeah this is in addition to some projectors which I'm going to use rtp to stream to directly. The in-browser aspect is a pet project of mine. – Curtis Bezault Mar 10 '17 at 17:11

1 Answers1

4

You won't achieve low latency with any of the segmented distribution methods (HLS, DASH, or similar). The very nature of these protocols is that the data is chunked into relatively large pieces. 4 seconds with HLS is amazingly low, and with chunks that small you have quite a bit of overhead... a waste of bandwidth and not really HLS and DASH are good for.

The first one is working under the assumption that the content consumers will not be on site.

My answer there (https://stackoverflow.com/a/37475943/362536) doesn't assume that the consumers will not be on your site... that's not the case at all. What I'm suggesting there is that you take advantage of YouTube and embed their viewer when low latency isn't needed, saving you mountains of money.

If all of your viewers require low latency video to make this work, you're going to have to get crafty on the server side. If you told us what sort of scale you were working with, perhaps we could suggest something more specific. Since you didn't, let's focus on the possibilities client-side.

WebRTC is one of the best options. Everything in the whole WebRTC stack is built with low latency in mind. With WebRTC, you can get those sub-second latencies in normal operation. Note that aren't a lot of good choices for streaming servers that support WebRTC today.

You can also use Media Source Extensions and Web Sockets. This gives you quite a bit of control and allows very fast streaming of data to the clients, at a slightly higher cost of latency. It's much easier to do this than it is to implement your own server-side WebRTC that supports media streams.

I strongly recommend reading over my answer on that other question again as well. There are a lot of considerations here... make very sure that this low latency is actually worth the reduction in quality and the financial costs involved. This is rarely the case, expecially for 10s of thousands of users or more.

Community
  • 1
  • 1
Brad
  • 159,648
  • 54
  • 349
  • 530
  • Hi Brad, thanks for taking the time to answer. I did re-read your answer and it's more clear to me that you were talking about a more agnostic setup than I originally understood. The scale that the question was talking about is probably what made me immediately think of the users not being on the LAN. I updated my question with some of the details you pointed out. Also I would like all my users to have low-latency, if possible. – Curtis Bezault Mar 08 '17 at 03:46
  • @CurtisBezault I have exactly the same requirement. WebRTC is not acceptable as we need to rewind and go back to real time when needed. 4 seconds is the minimum what I have with standard DASH player and nginx rtmp plugin with 2 seconds fragments. I saw that paper about low latency DASH and thinking to modify player javascript code to load fragments earlier and don't refresh mpd all the time. If a fragment is requested before it is available I will wait on the server side and return when it is. I'm still new to DASH and don't know if that will work. Any comments? – Olga Khylkouskaya Mar 11 '17 at 00:15
  • 1
    @OlgaKhylkouskaya There's no reason you can't use a different technology for the rewind/on-demand portion of your application. If you want a unified system though, web sockets and media source extensions are your best bet. – Brad Mar 11 '17 at 02:10
  • Thank you @Brad I can use different technology for rewind(that's actually Plan B:)) What do you mean by web sockets + media source extensions? WebRTC like? Can you give more details about the source to use(RTP, any Gateway...) We have to use h264 codec though. – Olga Khylkouskaya Mar 12 '17 at 03:14
  • @OlgaKhylkouskaya web sockets + media source extensions can actually give you lower latency than Flash. Live example with IP camera streaming h.264 video to Unreal Media Server: open HTML5 player and Flash player on their demo webpage, compare the latency: http://umediaserver.net/umediaserver/demos.html – user1390208 Apr 04 '17 at 15:50