4 ms·

You'd get into latency and consistency issues. It seems a poor choice if your main design constraint is real-time or near real-time interactive content delivery

by Bayart 3y ago

You'd get into latency and consistency issues. It seems a poor choice if your main design constraint is real-time or near real-time interactive content delivery.

littlestymaar 3y ago
Consistency is a non issue (it's simply doesn't exist), latency could be if your constraint is to be very low latency (less than 5 seconds) but Twitch used to have low-latency opt-in until 2019 and had something like 15s latency at that time while already being an enormous success so I'm not certain how important the factor is, especially for the bigger streams where interactivity is lower than in the smaller ones. Maybe Twitch's management effectively prefers 3s of latency at 20x the bandwidth cost of 7 seconds of latency, but I have to admit that it would surprise me.
- chongli 3y ago
  Maybe Twitch's management effectively prefers 3s of latency at 20x the bandwidth cost of 7 seconds of latency, but I have to admit that it would surprise me. Twitch is an interactive medium, not merely a video stream delivery platform. Streamers chat with their viewers and play games with them. They run merchandise giveaways based on guessing games. Low latency is critical for these applications. If a stream viewer sees a ton of people guessing random words or numbers in chat before they even see the streamer mention what everyone’s guessing at, they’re going to have a bad experience, leading to disengagement. Twitch goes out of their way to lower the latency. They even offer options in the client to switch to a lower latency mode, at the expense of stability.
  - littlestymaar 3y ago
    I was a bit confused when reading your comment at first because I was a big Twitch user at a time when they had around 10-15s latency for everyone without feeling that this latency was a problem. But then I eventually understood that you're talking about latency between viewers and then indeed it would be a very frustrating experience. Fortunately it's not what I'm talking about: I'm talking about having some latency (or rather “buffer size”) for all users, with synchronized playback between viewers. And again we're not talking about a prohibitive buffer size but rather a 5-15s buffer size, which is pretty common for live streaming services.
    - chongli 3y ago
      How does that work? Let’s say a stream is running with a 5s latency with the streamer and a bunch of viewers, all located in the US on fast connections. Now someone from rural Australia connects to the stream on a slow connection. Do you pause the stream for everyone in order to build a buffer for that new user and allow them to catch up and synchronize? What does the latency look like after that? 15-20s for everyone? That sounds like a terrible experience! When users find out what’s going on they’re going to demand the ability to block these slow/distant users from the stream so that everyone else doesn’t have their performance degraded. It also doesn’t solve all of the interactivity issues. If a streamer is directly chatting with their viewers, a 15s latency is huge! It effectively makes normal back-and-forth conversations impossible and therefore leads to disengagement. Why is this such a problem? Look at the relationship between engagement and monetization. Highly engaged viewers give way more money to streamers than do passive viewers. Highly engaged viewers are simply way more valuable as an audience, so their experience is given top priority. This is why best-effort low latency without synchronization makes sense. Lowest-common-denominator synchronized video sounds much more difficult to achieve if these “power viewers” are your priority audience.
      - littlestymaar 3y ago
        > How does that work? Let’s say a stream is running with a 5s latency with the streamer and a bunch of viewers, all located in the US on fast connections. Now someone from rural Australia connects to the stream on a slow connection. It works exactly as for non-p2p streaming, as the playback synchronization is independent from the p2p part and entirely managed by the video player through its buffer management system. Basically you get the “latest block” from the stream's manifest (that always comes from the CDN) and then the player is playing a few blocks behind and keeping its buffer full. > What does the latency look like after that? 15-20s for everyone? Yes, but that's already the case for most live streaming website you can find unless they specifically aim for low-latency (which comes with a QoS drawback since smaller buffer means buffering is more likely for the end user if the connection isn't flawless, so going to low-latency is a trade-off) and it was the case on Twitch itself before 2019. > It also doesn’t solve all of the interactivity issues. If a streamer is directly chatting with their viewers, a 15s latency is huge! It effectively makes normal back-and-forth conversations impossible and therefore leads to disengagement. It's less convenient, but at the same time Twitch has worked like that for almost a decade so it's not a complete showstopper. And again, 15s isn't the minimum you can reach, it's going below 5s that's not necessarily feasible (also, when I left my former employer, 5s was the limit but people were working on that so maybe they managed to reach 3s as they were trying to). > Highly engaged viewers are simply way more valuable as an audience, so their experience is given top priority. This is why best-effort low latency without synchronization makes sense. Maybe, but how many times more valuable? Has the per user value increase by a factor 20 since 2019? If no, maybe having reduced the bandwidth cost would have made more sense that trying to improve engagement.

by Bayart 3y ago

You'd get into latency and consistency issues. It seems a poor choice if your main design constraint is real-time or near real-time interactive content delivery.

littlestymaar 3y ago

Consistency is a non issue (it's simply doesn't exist), latency could be if your constraint is to be very low latency (less than 5 seconds) but Twitch used to have low-latency opt-in until 2019 and had something like 15s latency at that time while already being an enormous success so I'm not certain how important the factor is, especially for the bigger streams where interactivity is lower than in the smaller ones. Maybe Twitch's management effectively prefers 3s of latency at 20x the bandwidth cost of 7 seconds of latency, but I have to admit that it would surprise me.

chongli 3y ago
Maybe Twitch's management effectively prefers 3s of latency at 20x the bandwidth cost of 7 seconds of latency, but I have to admit that it would surprise me. Twitch is an interactive medium, not merely a video stream delivery platform. Streamers chat with their viewers and play games with them. They run merchandise giveaways based on guessing games. Low latency is critical for these applications. If a stream viewer sees a ton of people guessing random words or numbers in chat before they even see the streamer mention what everyone’s guessing at, they’re going to have a bad experience, leading to disengagement. Twitch goes out of their way to lower the latency. They even offer options in the client to switch to a lower latency mode, at the expense of stability.
- littlestymaar 3y ago
  I was a bit confused when reading your comment at first because I was a big Twitch user at a time when they had around 10-15s latency for everyone without feeling that this latency was a problem. But then I eventually understood that you're talking about latency between viewers and then indeed it would be a very frustrating experience. Fortunately it's not what I'm talking about: I'm talking about having some latency (or rather “buffer size”) for all users, with synchronized playback between viewers. And again we're not talking about a prohibitive buffer size but rather a 5-15s buffer size, which is pretty common for live streaming services.
  - chongli 3y ago
    How does that work? Let’s say a stream is running with a 5s latency with the streamer and a bunch of viewers, all located in the US on fast connections. Now someone from rural Australia connects to the stream on a slow connection. Do you pause the stream for everyone in order to build a buffer for that new user and allow them to catch up and synchronize? What does the latency look like after that? 15-20s for everyone? That sounds like a terrible experience! When users find out what’s going on they’re going to demand the ability to block these slow/distant users from the stream so that everyone else doesn’t have their performance degraded. It also doesn’t solve all of the interactivity issues. If a streamer is directly chatting with their viewers, a 15s latency is huge! It effectively makes normal back-and-forth conversations impossible and therefore leads to disengagement. Why is this such a problem? Look at the relationship between engagement and monetization. Highly engaged viewers give way more money to streamers than do passive viewers. Highly engaged viewers are simply way more valuable as an audience, so their experience is given top priority. This is why best-effort low latency without synchronization makes sense. Lowest-common-denominator synchronized video sounds much more difficult to achieve if these “power viewers” are your priority audience.
    - littlestymaar 3y ago
      > How does that work? Let’s say a stream is running with a 5s latency with the streamer and a bunch of viewers, all located in the US on fast connections. Now someone from rural Australia connects to the stream on a slow connection. It works exactly as for non-p2p streaming, as the playback synchronization is independent from the p2p part and entirely managed by the video player through its buffer management system. Basically you get the “latest block” from the stream's manifest (that always comes from the CDN) and then the player is playing a few blocks behind and keeping its buffer full. > What does the latency look like after that? 15-20s for everyone? Yes, but that's already the case for most live streaming website you can find unless they specifically aim for low-latency (which comes with a QoS drawback since smaller buffer means buffering is more likely for the end user if the connection isn't flawless, so going to low-latency is a trade-off) and it was the case on Twitch itself before 2019. > It also doesn’t solve all of the interactivity issues. If a streamer is directly chatting with their viewers, a 15s latency is huge! It effectively makes normal back-and-forth conversations impossible and therefore leads to disengagement. It's less convenient, but at the same time Twitch has worked like that for almost a decade so it's not a complete showstopper. And again, 15s isn't the minimum you can reach, it's going below 5s that's not necessarily feasible (also, when I left my former employer, 5s was the limit but people were working on that so maybe they managed to reach 3s as they were trying to). > Highly engaged viewers are simply way more valuable as an audience, so their experience is given top priority. This is why best-effort low latency without synchronization makes sense. Maybe, but how many times more valuable? Has the per user value increase by a factor 20 since 2019? If no, maybe having reduced the bandwidth cost would have made more sense that trying to improve engagement.