4 ms·

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 < HTT

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-fifa-world-cup-14-part-ii-microservices/ 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?

zbobet2012 10y ago
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.
- jordanbaucke 10y ago
  @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?
  - r1ch 10y ago
    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.
    - jordanbaucke 10y ago
      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?
      - r1ch 10y ago
        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 :).
        zbobet2012 10y ago
        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).
  - zbobet2012 10y ago
    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.
- kobayashi 10y ago
  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?
soneca 10y ago
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)

zbobet2012 10y ago

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.

jordanbaucke 10y ago
@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?
- r1ch 10y ago
  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.
  - jordanbaucke 10y ago
    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?
    - r1ch 10y ago
      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 :).
      - zbobet2012 10y ago
        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).
- zbobet2012 10y ago
  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.
kobayashi 10y ago
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?

soneca 10y ago

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)