Most of what we use is HTTP (which is on TCP). It downloads the video in chunks (maybe 5-10 seconds? not sure) over TCP, and the client-side (javascript) player tries to keep a couple of chunks ahead of where the user is. If the player can't download fast enough to keep ahead of the user, it switches to a lower resolution (smaller) chunk on the next request.
Using HTTP, each chunk has a different url (usually thru query parameters), so the chunks can be cached. I can host the videos in a central location and then have a local caching proxy that will serve the video (chunks) it has seen recently without using internet bandwidth, for example. Or do the same in the cloud to scale internet video load.
UDP is seemingly more appropriate for live / multicast videos.
Edit: I don't specifically know what strategy Twitch is using. But I could see a use case for HTTP (TCP) live streaming. It is much easier to support with existing tools and through browsers. With UDP you would need to develop your own protocol on top of it (and maybe client) if one of the existing ones (mostly for teleconf?) did not quite fit your use case.
Edit2: Currently you cannot make UDP connections through the browser, period. So using UDP, the user would have to download and install a custom app to watch streams. Twitch probably didn't want to require that of users. The closest available browser-based capability is WebRTC, but it is not widely supported as yet.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Most of what we use is HTTP (which is on TCP). It downloads the video in chunks (maybe 5-10 seconds? not sure) over TCP, and the client-side (javascript) player tries to keep a couple of chunks ahead of where the user is. If the player can't download fast enough to keep ahead of the user, it switches to a lower resolution (smaller) chunk on the next request.
Using HTTP, each chunk has a different url (usually thru query parameters), so the chunks can be cached. I can host the videos in a central location and then have a local caching proxy that will serve the video (chunks) it has seen recently without using internet bandwidth, for example. Or do the same in the cloud to scale internet video load.
UDP is seemingly more appropriate for live / multicast videos.
This SO question on the same topic has a pretty good accepted answer.
Edit: I don't specifically know what strategy Twitch is using. But I could see a use case for HTTP (TCP) live streaming. It is much easier to support with existing tools and through browsers. With UDP you would need to develop your own protocol on top of it (and maybe client) if one of the existing ones (mostly for teleconf?) did not quite fit your use case.
Edit2: Currently you cannot make UDP connections through the browser, period. So using UDP, the user would have to download and install a custom app to watch streams. Twitch probably didn't want to require that of users. The closest available browser-based capability is WebRTC, but it is not widely supported as yet.