The fact that Twitch has allowed simultaneous streaming on other platforms suggests that the platform is no longer able to offer famous streamers the financial incentives they are seeking.
All this means Twitch isn’t able to capture most of the revenue for the streaming business. I don’t know what they can do to fix it. Perhaps this new non-exclusivity deal is a way of shedding some of the deadweight. If viewers of large streams spread out to other platforms then maybe a lot of the non-revenue-producing ones will move off Twitch. Smaller streams that are more subscription-based may be less likely to do so.
It's the best use-case for webRTC-based delivery though. They could be saving ~90-95%[1] of their bandwidth cost on these use-cases, I find it very intriguing that they haven't adopted it after all that time.
[1] actual production number when I was working on that topic.
You can't be suggesting that the source streamer sends out millions of webRTC streams from their house, can you?
P2P may be explored again.
- don't do full P2P, keep twitch as a central server, and delegate only part of the load to P2P to those with good connection, with progressive roll in as buffering grows
- get a 2 minutes padding between the live and actual video streaming, so that you have a decent buffer and margin of maneuver to switch back to twitch server
- create an OBS clone that does streaming and video client with less ads as you said, but that act as an optimized node that works even when you don't what a video (the more you accumulate up time, the less you see adds, you get points, etc)
(Edit: I love how I get downvoted when saying that although I literally built a p2p streaming software and I'm citing actual configuration requirements we had in production back then)
[1] https://www.lumen.com/help/en-us/cdn/mesh-knowledge-base/faq...
From your description elsewhere was it using the WebRTC data channels to deliver DASH/HLS style segments or actually using the MediaStream stuff?
I think the magic info we're missing here is what the Twitch viewers are watching on, and my hunch is it's a lot of mobile for which the P2P idea will not work (and/or provoke angry messages from mobile operators). In the case of smart TV then I can see the P2P idea saving a lot of money, but I don't believe there is even an official Twitch app for Samsung TVs so they don't seem to think that is where their audience is.
Generally 10-20s depending on the size of the video segments. For streams we controlled entirely, we could even go as low as 5s (at the expense of short video segments).
> From your description elsewhere was it using the WebRTC data channels to deliver DASH/HLS style segments or actually using the MediaStream stuff?
The former, but we'd split the segments in much smaller chunks for delivery purpose.
> I think the magic info we're missing here is what the Twitch viewers are watching on, and my hunch is it's a lot of mobile for which the P2P idea will not work (and/or provoke angry messages from mobile operators).
Yeah mobile is more complex than desktop because you must not incur spendings on the viewer side and because battery use is paramount. But you can still get good result by setting the mobile users as leaf node (receiver-only).
> In the case of smart TV then I can see the P2P idea saving a lot of money
Yeah, smart-TV and set top boxes were a very important segment for us. But as you said it's probably not Twitch's market.
You are totally right to call out battery life. I have worked in mobile a long time (including webrtc) and find people persistently underestimate how irrelevant sounding changes, such as vp8 vs h264, can suddenly make things intolerable for a lot of users.
Anyway I'm very frustrated that after 8 years the concept has not been adopted by the industry despite the very positive results we had.
Our main challenge back then was more related to the business model of a third party technology provider because each customer required integration with their entire video pipeline, but the fact that big players still haven't rolled their own p2p distribution tech after all that time is something I really don't understand.
It's not about just switching protocol nor it is about the source steamer (who should never be exposed, for DDoS/doxing reasons). But instead of delivering the video from the CDN to all users directly, you build a p2p network of viewers and have non-leaf viewers rebroadcast the video segments they've received (either directly from the CDN or from another peer).
It's obviously not as trivial as the description above implies, but it's not very hard either and for live streaming with lots of users it works very well. (I used to work on such a system and deployed it in production for streams with up to 300k concurrent viewers)
If you use HLS to deliver video to viewers, you can cache segments in a CDN. Your CDN. Someone else's CDN. You'll add some latency, but your bill will be lower.
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.
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.
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.
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.
Those blocks still need to be sent to the new user's entry point to the CDN. I doubt you're going to save any money by sending every single video stream to every single node in the CDN. You're going to send the video only to nodes that have connected viewers of that particular stream. Then you have the issue of pausing everyone else’s feed until the new user catches up.
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.
I think Twitch has moved on from that. Users' expectations have gone way up. They want more interaction with streamers, not less. They aren't going to tolerate a backslide to higher latencies if the only purpose is to save Twitch money. Competition from other platforms, especially YouTube, is fierce.
High latency (>5s) leads to this shallow form of engagement where viewers send one-way comments to the streamer and then wait (and hope) they hear back. Low latency promotes live conversations. This is especially critical on small streams where the number of people in the chat doesn't overwhelm the streamer. And as I said before, smaller streams are less likely to have streamers who lean into heavy third-party monetization strategies. These streamers often develop closer relationships with their viewers and have a higher percentage of subscribed viewers.
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.
I think they are trying to reduce bandwidth costs, but not uniformly across users. My theory is that they are trying to discourage casual viewers who don't subscribe. Getting rid of these "freeloader users" would naturally cause per-user value to go up!
What? The meat of the cost isn't when sending videos segments to the CDN, it's what the CDN charges you for sending those segments thousands of time.
> Then you have the issue of pausing everyone else’s feed until the new user catches up.
No, if the p2p system isn't working well, it falls back to the CDN transparently for the users. And again it's not something theoretical, we ran this in production for up to several hundred thousands viewers, and it was working great.
> I think Twitch has moved on from that. Users' expectations have gone way up. They want more interaction with streamers, not less. They aren't going to tolerate a backslide to higher latencies if the only purpose is to save Twitch money.
Maybe, people getting used to comfort and never wanting to go back is a real phenomenon. But Twitch had many years between when I worked in the field and 2019 to deploy such a system without degrading the experience and to me it's pretty disappointing that they didn't.
The latency between streamer and viewer on Twitch (in low-latency mode, which is the default) is normally less than 5 seconds and often between 1 and 2 seconds. The player actually slightly speeds up the video if it exceeds 5 seconds.
This is essential for interactivity, because the streamer can ask a question and get a response without constant awkward pauses.
Maybe it improves things but we're back to my previous comment:
> 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.
I don't think they are. Given the same size total audience it's much cheaper for Twitch to distribute one stream around the world a million times than it is to distribute thousands of streams around the world a few times each. Transcoding only has to happen once, each segment only has to be distributed to each area of the world once, etc. This gets more nuanced when you include things like chat, which gets harder as you scale up, but I highly doubt that cost is significant compared to the video feed.
Those large streamers may be monetizing their viewers through other means, but as long as they're not actively pulling them away from Twitch those viewers are still either watching ads or subscribing. And based on anecdotes shared by some of those big streamers Twitch ads have gotten more and more profitable.
No, they are, according to internal leaks. Basically, after around some thousand viewers, the cost of a stream grows faster than the income it generates. Though, not sure if it's still valid after their increase of ads in the last year.
> Given the same size total audience it's much cheaper for Twitch to distribute one stream around the world a million times than it is to distribute thousands of streams around the world a few times each.
Same size of what? Viewers? Resolution?
> Transcoding only has to happen once, each segment only has to be distributed to each area of the world once
This has two flaws. Each stream is available in multiple resolutions, and the bigger a stream, the higher the chance someone will pick a different resolution than origin. Similar, most stream are kinda local, but with bigger streams, chance raises that it goes into some different corner of the world. So your argument is only valid under the assumption that the baseload of each stream would be exactly same in every detail.
But you also miss the important detail, that traffic costs, and there is only so much you can do to reduce it. But somehow you think that between 1k viewers, 10k viewers and 100k viewers there is no relevant cost-difference?
> And based on anecdotes shared by some of those big streamers Twitch ads have gotten more and more profitable.
Yes, but that's a very recent development.