Hacker News Reader

Comment by jordanbaucke | Hacker News Reader

I'm interested in learning what the average "delay" for live-streaming would be? At a high-level RTMP > (Segmenter: EvoStream) HLS > Cassandra < NginX-LUA < HTTP Request (seems to flow model outlined here (From the 2014 World Cup): https://www.nginx.com/blog/globo-coms-live-video-platform-fi...)

I'd assume it's minimum > 20 seconds depending on setup and teardown time for first "chunk" in a sequence to reach cache and be transferred to a user?

View on HN

TL;DR: The delay is normally a segment length. Somewhere between 2-16s depending on there configs.

Because the system is realtime (live) it _must_ not fall behind live. These systems therefore are always only a single segment behind live. (A segment is an independently decodable chunk of video, usually between 2 and 16s).

Source: I designed the backends, including segmenting, for NBC.

@zbobet2012 makes sense, certainly, you can shrink the chunk-size down to 2 seconds, I wonder if it's not practical to do though wouldn't the practicality of setting up a setup > teardown of a new HTTP connection, fetching the next chunk, etc. cause inconsistency in completing this procedure by the time a 2 second chunk has played out.

I believe people have used WebSockets to push these segments? Since once you have established one TCP socket connection you don't have to setup a new "session" for each discrete segment?

HTTP keepalives prevent the excessive connection requests. The main issue with HLS distribution is TCP sucks over high latency links, so you have to have edges near your users.

Gotcha! I've also heard of people using WebRTC to reduce latency by setting up a direct-to-user link between the ingest server and the end-user? Any idea how this helps?

Beam (recently acquired by Microsoft) does very similar to this. Rather than wait for the whole X second segment to be built and distributed, they apparently stream MPEG atoms through websockets which are them reassembled in JS and presented via media source extensions. At this point you may as well have re-invented RTMP, minus the Flash dependency :).

Yep^^

In addition there is a major encoding downside to this. If your encoder can grab a whole 2-10s chunk of video it can produce a better quality stream. This is actually _super_ important for producing good video quality (especially on things like sports streams).

We (Comcast/NBC) run 2s segments for our video streaming service which is... substantially larger than this. High latency mobile networks on clients which don't do keep alive can be _somewhat_ problematic. The best fix for that is just to have a very fast/close CDN edge node.

In my experience live streaming events in Canada, the delay is approx 60s behind cable TV. In your estimate, is the Internet broadcaster here using extremely large segments, or is something else at play?

Personal anecdote as brazilian that watched a lot through streaming (both web and app), sometimes comparing with live digital (uhf) open TV and friends updating results through WhatsApp (as each kick result at female football shootout).

The delay would vary between 20 seconds and 60 seconds between streaming and uhf TV (just as an observation, cable TV also has a delay of about 4, 5 seconds comparing to open tv)

Reply on news.ycombinator.com