Short answer: Neither directly. Mostly HTTP (and thus TCP) due to the limitations of browsers etc, but some could use WebRTC and other technologies to improve performance now.
Longer answer:
First, video. Video works by sending a "key frame", following by a bunch of delta frames. If you know the basic parameters of the video (size, colour depth, etc) you can start playing at any key frame - but if you lose the key frame you have to wait until you get the next one.
TCP operates by creating a "virtual circuit", a continuous data stream containing a sequence of bytes, where each byte won't arrive until the previous ones have done so.
So if I send a sequence of 20 packets, and you miss the first one, the other 19 will be buffered at your end while your computer asks for the missing one.
Great for file transfer, less good for video - but on a lightly loaded network, you're unlikely to lose any packets at all these days, so the downside isn't too bad.
But the longer the stream of video, and the larger your latency (or smaller the bandwidth, or both), the more a lost packet will mess things up for you.
HTTP packetizes data anyway, though, so you can frame your video segments into HTTP responses, and then if one is lost or slow you can discard it if you're falling behind. Conveniently, web browsers speak HTTP, so it's highly interoperable too. There's a minor downside that the increased latency of HTTP means you need to get a few segments in the pipe before you can smoothly play through them all. Typically an application makes segments pretty big, and then allows the client-side to ask for fairly arbitrary segments - and the server-side can "fix" the client requests to the nearest key frame.
But if you really did want live streaming to mean "live" - that is, a low broadcast latency - then HTTP will introduce an unacceptable delay.
Examples might be teleconferencing, video calls, perhaps a very interactive TV show, etc.
For these, you want to use a protocol that will handle lost segments at a smaller, and lower, level.
RTP is built on UDP, and UDP is essentially a fire-and-forget packet - there's very little in the way of error handling in UDP. RTP does add some, and also adds ordering and timing information. Its companion protocol, RTCP, carries control information (like QoS data).
Routers can also spot key frames in RTP - RTP packets can have a Marker bit set which a router can then use to affect queue discards.
Finally, you can send the same RTP packets to everyone watching - in fact, you can use special routing tricks like multicast to save a lot of bandwidth if it's supported.
You can, of course, still lose packets with RTP - but the loss of a few delta packets really won't hurt you at all, and even losing a key frame will cause a minor jolt in the video instead of 30 seconds of "Buffering..."
As WebRTC becomes more popular - and if you're on Chrome or Firefox it's pretty stable already - I'd imagine we'll start to see some "broadcast" applications like Twitch start to experiment with it.
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.
Short answer: Neither directly. Mostly HTTP (and thus TCP) due to the limitations of browsers etc, but some could use WebRTC and other technologies to improve performance now.
Longer answer:
First, video. Video works by sending a "key frame", following by a bunch of delta frames. If you know the basic parameters of the video (size, colour depth, etc) you can start playing at any key frame - but if you lose the key frame you have to wait until you get the next one.
TCP operates by creating a "virtual circuit", a continuous data stream containing a sequence of bytes, where each byte won't arrive until the previous ones have done so.
So if I send a sequence of 20 packets, and you miss the first one, the other 19 will be buffered at your end while your computer asks for the missing one.
Great for file transfer, less good for video - but on a lightly loaded network, you're unlikely to lose any packets at all these days, so the downside isn't too bad.
But the longer the stream of video, and the larger your latency (or smaller the bandwidth, or both), the more a lost packet will mess things up for you.
HTTP packetizes data anyway, though, so you can frame your video segments into HTTP responses, and then if one is lost or slow you can discard it if you're falling behind. Conveniently, web browsers speak HTTP, so it's highly interoperable too. There's a minor downside that the increased latency of HTTP means you need to get a few segments in the pipe before you can smoothly play through them all. Typically an application makes segments pretty big, and then allows the client-side to ask for fairly arbitrary segments - and the server-side can "fix" the client requests to the nearest key frame.
But if you really did want live streaming to mean "live" - that is, a low broadcast latency - then HTTP will introduce an unacceptable delay.
Examples might be teleconferencing, video calls, perhaps a very interactive TV show, etc.
For these, you want to use a protocol that will handle lost segments at a smaller, and lower, level.
RTP is built on UDP, and UDP is essentially a fire-and-forget packet - there's very little in the way of error handling in UDP. RTP does add some, and also adds ordering and timing information. Its companion protocol, RTCP, carries control information (like QoS data).
Routers can also spot key frames in RTP - RTP packets can have a Marker bit set which a router can then use to affect queue discards.
Finally, you can send the same RTP packets to everyone watching - in fact, you can use special routing tricks like multicast to save a lot of bandwidth if it's supported.
You can, of course, still lose packets with RTP - but the loss of a few delta packets really won't hurt you at all, and even losing a key frame will cause a minor jolt in the video instead of 30 seconds of "Buffering..."
As WebRTC becomes more popular - and if you're on Chrome or Firefox it's pretty stable already - I'd imagine we'll start to see some "broadcast" applications like Twitch start to experiment with it.