4 ms·

No but bittorrent scales as the number of user increases. P2P may be explored again.

fidotron 3y ago
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.
- BiteCode_dev 3y ago
  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)
  - fidotron 3y ago
    2 minutes latency is a non starter, especially for broadcasts with some level of viewer interaction.
    - littlestymaar 3y ago
      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)
- littlestymaar 3y ago
  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). [1] https://www.lumen.com/help/en-us/cdn/mesh-knowledge-base/faq.html https://www.lumen.com/help/en-us/cdn/mesh-knowledge-base/faq...
  - fidotron 3y ago
    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.
    - littlestymaar 3y ago
      > 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.
      - 3y ago

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.

BiteCode_dev 3y ago
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)
- fidotron 3y ago
  2 minutes latency is a non starter, especially for broadcasts with some level of viewer interaction.
  - littlestymaar 3y ago
    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)
littlestymaar 3y ago
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). [1] https://www.lumen.com/help/en-us/cdn/mesh-knowledge-base/faq.html https://www.lumen.com/help/en-us/cdn/mesh-knowledge-base/faq...
- fidotron 3y ago
  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.
  - littlestymaar 3y ago
    > 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.
    - 3y ago