[mv4]

You comment mentions two types of latency:

1. network latency, in milliseconds, that affects stream quality and stability

2. the delay (lag) between real-time capture and what the end user is seeing; this one is usually measured in seconds. A stream needs to be ingested, transcoded, sent from distribution servers to edge servers in each target region - with each step adding to the delay.

Minimizing the lag is very hard, because stripping all buffers (to reduce the delay) makes the stream very sensitive to network conditions (which reduces quality). With most commercial CDN providers you will get 5..10 seconds. It can be reduced to 2..3 sec if you know what you're doing.

edit: in case anyone is interested - in the second scenario, where we achieved 2..3 sec broadcast lag vs real-time, stream source (ingestion) was in the US, and the viewers were in mainland China. Network latency was over 600 msec. Wasn't easy!

[isostatic]

60 seconds in the case of iplayer for the fa cup. 1m20 in the case of BBC News channel right now. HLS tends to be packetised in something like 15 second chunks at the end of the process.

I know why there's a delay, I'm just amazed that people aren't concerned about it. The BBC used to offer multicast sources of live TV, which is a far more sensible solution, far more bandwidth efficient and allows end-to-end transmission in the satellite (or even less) range.

Wowza did a talk at demuxed last year about how to do "3 second latency end to end at scale", which I found amusing given that TV people have been doing sub millisecond latency at scale for nearly 100 years, so at least some people in the industry recognize the problem (which is mainly for sports events)

[vdnkh]

Hey, I was also at Demuxed last year! I help maintain Hls.js; it should have some form of LHLS support by soon(tm). There's no standard yet so actual adoption will be tough (current implementations use non-standard EXT-X tags to signal LHLS). But pretty much everyone does the same thing: early signaling of segments, chunked transfers, and on the client side, progressive demuxing. HTTP-based solutions typically achieve the aforementioned 3 seconds, but anyone talking about LHLS now (Akamai and Wowza) have their own protocols; it remains to be seen what the rest of us will get.

Twitch has recently implemented LHLS (looks like a "periscope-style" implementation) and I was seeing 1.2s glass-to-glass.

[shittyadmin]

I hate that I try to stream a game for my friends and they don't see what I did til 10-15s later. I'm trying to have discussions with them in real time on our voice chat server and any input they give me is inherently dated. Mumble gives extremely low latency, so achieving this kind of thing over the internet isn't exactly impossible, the bandwidth requirements of video would probably make it a bit more iffy, but should still be doable with some random issues.

Maybe I just need to get away from the public streaming services which use HLS, switch to UDP streams and sub-1s buffer sizes.

[Deathmax]

Twitch has introduced low latency mode for a while now, and I've seen sub-2s latencies.

https://help.twitch.tv/customer/en/portal/articles/2935005-l...

[mv4]

As for what TV people have been doing - YES.

No matter what anybody says, the Internet just isn't well suited for massive live streaming events. That's what television is for!

[mv4]

Honestly, I think people are concerned, but everyone's experience to date with big streaming events has been that something invariably goes wrong - people can't connect, login issues, event won't start, buffering, etc (e.g. the McGregor Mayweather PPV). If you can get a high-quality stream at all, perhaps the time shift is secondary!

[isostatic]

I only usually deal with the distribution side as an end user, and personally I tend to watch about 2 live events a year (I'd watch new years, but that's clearly pointless, so that leaves eurovision and maybe an election program), so I don't have much experience with that side.

It does amuse me when we were looking at latency for a program from a ropey bit of connectivity which we were using ARQ on. We were discussing whether we could push the latency up from 2 seconds to 6 seconds (it kept dropping out for 2 or 3 seconds at a time), as it's sport. Then we realised there was a good 30-40 seconds downstream before it even left to the CDN!

I still don't understand half of what Streampunk [1] are trying to do with their nmos grain workflows, but they are talking about sub-frame HTTP units

  This is not an approach that supports line-synced timing and may not be appropriate for live sports action that requires extremely low latency. 
  However, for many current SDI workflows that can tolerate a small delay, this approach is sufficient.

With UHD you're talking 20MBytes for a single frame, or each "grain" (a subdivision of a frame) being in the order of a millisecond/megabyte.

I think I prefer this approach to the SMPTE 2110 approach to be honest, especially with the timing windows that 2110 requires (it doesn't lead well to a COTS virtualised environment when your packets have to be emitted at a specific microsecond)

But I digress, this is all very off topic

[0] https://github.com/Streampunk/arachnid [1] https://www.streampunk.media/

[mv4]

I am amazed that video delivery is not a solved problem still.