The 30 seconds is not because twitch sucks. They do encoding/decoding/sampling

And honestly, if you were streaming a 1080p video over p2p, I see no physical way that it would be below a 30s delay if there was 1k+ people watching it.

You are limited by peers outbound bandwidth and for most in the US that is going to be sub 5MB/s. With that in mind, you can really only have a maximum of 5 or less streams per user. That means to get to the 1000th viewer, its going to be a daisy chain of 50+ users in front of you before you get the data.

P2P does not and can not work for distributed video until home connections catch up. (Unless you are OK with insane delays)

If each peer can retransmit to 5 other users, then a simple tree-structured fanout gets you to more than 1000 users with only 5 hops of delay.

Obviously in practice you wouldn't get a perfectly balanced tree, but I don't see where your "50+ users" is coming from.

So, lets assume every viewer can broadcast to three others, so the first one reaches 3 that reaches 9 etc. You'd be "behind" 7 others for "up to" 2187 viewers. This is assuming no "super hubs" in between. Or am I missing something? Even if every peer on average is only able to reach two "new" peers, that's still just 10 hops for 1024 users...?

Can you explain why delay matters? AFAIK TV usually has over 1 minute of delay for live events.

TV has usually about 5-6s delay for live events, add a second or two for HD content. 1 minute delay might be in case of legal issues (where broadcasters are bound by law to add a delay) or some very convoluted video signal distribution.

Delay matters most in case of live betting and live score. There is whole industry around this, I am sure you've heard about bwin.com or bet365.com.

Delay matters when a twitch.tv streamer is interacting with their viewers through the stream chat.

Delay matters when multiple people are trying to watch the same stream "together", but end up seeing wildly different points of time in that stream.

Streaming should be free, as should the protocol it's developed on top of, so anybody can use it, and trust it.

Revenue streams come from supporting the back-end telcos (billing, active traffic mgmt & shaping), and content generators (disney/pixar etc), and a couple of other things I'm not ready to talk about just yet ;-).

Well, if you had a website that cataloged and displayed the streams, much like Twitch.tv, then people can still find streams and subscribe to them in much the same way they do over at Twitch, while the site gets a cut.

Additionally, broadcasters can still do Paypal donation links, like they do over at Twitch.

Advertisements playing before videos, I'm not sure how it could be done, but it probably could be an overlay before the stream starts, or just a HTML5 video that loads first and must finish before the P2P stream begins.

cool, thanks. just curious what your thoughts were along monetization.

In this case, this is like asking how you would monetize TCP. This specification is a transport protocol and could apply to multiple use cases, not including video.

i was responding to the parent's assertion about monetizing, just curious what he/she was thinking along those lines. it was a genuine question.