Hacker News Reader

Comment by zbobet2012 | Hacker News Reader

zbobet2012

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.

View on HN

@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?

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.

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).

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?

Reply on news.ycombinator.com