Spitballing here . . . The unreliability of such a network for live video would make routing quite a challenge. Assuming that could be solved Twitch could offset this by reducing the number of ads shown to people acting as redistribution nodes.
There are a things you can try to see if this solves the problem:
- 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)
Good news is that you don't need that much, something like 4 video segments is more than enough.
(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)
It's not “assuming that could be solved” it has existed for years. Lumen (formerly CenturyLink) has had a commercial offering[1] of the tech for years (since they acquired my former employer actually).
What kind of latency did that approach manage to achieve?
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.
> What kind of latency did that approach manage to achieve?
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.
Interesting stuff, thanks for such a response - I was not sure if you would be ok sharing details like that, but those numbers are a lot better than I would have estimated.
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.
You're welcome. Don't worry it's not confidential stuff, it was basically our marketing pitch back then. (I've already given much more technical details in meetup talks with the founders in the room)
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.
P2P may be explored again.