Introduction of Streaming Terminology- What is UDP, TCP, Unicast, Multicast, RTP, RTSP, RTMP and more
Apr 06 2016
UDP stands for user datagram protocol and is an unreliable connectionless transmission protocol. The term connectionless means that the sender is not aware of the receiver(s): it is sending out data without knowing if the intended recipient is there as there is no handshake before sending data.
UDP is like sending out a letter in the post with a standard stamp; you won't get a confirmation that's its arrived you just hope it does.
TCP stands for transmission control protocol and is a reliable connection-based transmission protocol. As TCP is connection-based the sender is fully aware of the state of the intended recipients. A handshake must take place and a connection formed between sender and receiver before any data is sent.
TCP is like sending a letter using a recorded postal service, you get an acknowledgement that the letter has arrived and if it does not you can send it again.
Unicast is a one-to one connection between the client and the server (In most cases the server is the video encoder). Unicast uses IP delivery methods such as Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). The client has a direct relationship to the server. Each unicast client that connects to the server takes up additional bandwidth. For example, if you have 10 clients all playing 100-kilobits per second (Kbps) streams, those clients as a group are taking up 1,000 Kbps. If you have only one client playing the 100 Kbps stream, only 100 Kbps is being used.
Multicast is a true broadcast. There is no direct relationship between the clients and server. This is similar to tuning into a station on a radio. Each client that listens to the multicast adds no additional overhead on the server. In fact, the server sends out only one stream. The same load is experienced on the server whether only one client or 1,000 clients are listening.
It's the job of the network switch or router to receive this single stream from the encoder and send it out to all the clients.
Please Note: Multicast on the Internet is generally not practical because only small sections of the Internet are multicast-enabled.
Even on a local network you need to be careful with multicast as routers and switches that are not capable of handling multicast correctly will treat it as a BROADCAST message. What this means is that if your encoder is connected to an un-configured Ethernet switch and sends out a multicast message it will broadcast this message out on all ports and flood the entire network with your stream. If the network is dedicated to that stream this is no big problem however it the network is used for other things it will cause performance issues.
The solution to this problem is to use switches that are IGMP compatible, these switches will forward multicast traffic only on ports connected to devices that are subscribed to that multicast group. In other words the switch will only forward the stream out on ports that are connected to devices that are trying to tune in to your multicast stream.
Broadcast is a type of communication where data is sent from one computer once and a copy of that data will be forwarded to all the devices. In Broadcast, there is only one sender and the data is sent only once. But the Broadcast data is delivered to all connected devices.
Switches by design will forward the broadcast traffic and routers by design will drop the broadcast traffic. In other words, Routers will not allow a broadcast from one LAN to cross the Router and reach another Network Segment. The primary function of a Router is to divide a big Broadcast domain to multiple smaller broadcast domains.
Packet loss occurs when one or more packets of data travelling across a computer network fails to reach its destination. Typically packet loss on an Ethernet network is non existant, packet loss on WiFi is moderate if signal strength is good and packet loss over the internet is heavily dependent on the carrier's paths but can be heavy with poor internet connections.
A buffer or cache is the amount of video that is stored in memory before playback begins. A large buffer results in more delay but gives more stability when jitter and packet loss are present.
Jitter is the variation in the time between packets arriving, caused by network congestion, timing drift, or route changes. Jitter is a very important factor when streaming as if the delay over network path is constantly changing it could cause a packet to arrive late, the decoder must have a buffer big enough to continue playback while waiting for delayed packets.
The most commonly used streaming protocols, how they work and where they work best.
RTP and RTSP are two completely different protocols that are commonly used together, although RTP can be used on its own RTSP cannot be used without RTP, this means if you see the term RTSP it always means RTP/RTSP.
RTP stands for real-time transport protocol and is used to carry the actual media stream, in most cases H264 or MPEG4 video is inside the RTP wrapper. RTSP is short for real-time streaming protocol and is used to establish and control the media stream.
What does this mean in practice?
RTP on its own is a push protocol. This means that if a encoder wants to send video to a decoder using RTP, the encoder would need to know the decoder's IP address and would push the video to the listening decoder.
RTP/RTSP is a pull protocol, this means the decoder connects to the encoder using the RTSP protocol the encoder then sends video to the decoder using the RTP protocol. Multiple decoders can connect to one RTSP server (this is called multi-unicast). RTSP also supports multicast.
Is it TCP or UDP based?
Actually it can be either. Usually RTSP works over TCP and the actual RTP video stream is sent over UDP; the video and audio are sent over a pair of UDP ports. This is fine for streaming over a LAN but can be troublesome if used over the internet as it requires multiple ports. Also as video and audio are sent separately we rely on the timestamps in the RTP headers for synchronization.
So when using RTSP over the internet we can interleave the RTP video and audio streams over the same TCP connection used for RTSP. Everything works over port 554 TCP.
What's it suitable for?
RTSP is great for streaming to multiple devices on a local network where jitter and packet loss are minimal. RTSP works with almost all decoders and software players.
MPEG-TS is probably the most commonly used streaming protocol in the broadcast industry, compatible with most set top boxes and decoders. MPEG-TS is commonly called a MPEG 2 Transport Stream even though the video inside the wrapper is actually H264 / MPEG 4 Part 10. MPEG TS is a usually a push protocol that takes audio and video over one stream.
Is it TCP or UDP based?
Typically it is UDP based meaning if there is packet loss glitches will be seen in the stream as the lost data is not re-sent however high end encoders utilize a technology called FEC (Forward Error Correction) to combat this. FEC allows the decoder to make educated guesses as to what data was lost and fill the gaps back in.
Some equipment also supports MPEG-TS over TCP although this is not such a commonly used standard, Teradek equipment for example supports MPEG-TS over TCP.
This is flash streaming and mainly used to get video into a CDN for distribution to large audiences online.
What's it suitable for?
RTMP is reliable over the internet. Its low latency and low overhead have made it the standard for streaming into all major CDNs (YouTube Live, UStream, Wowza e.t.c). It can also be used for point to point connections with some encoders and decoders (Such as the Datavideo NVS and NVD series).
Is it TCP or UDP based?
It's TCP-based.
HTTP Live Streaming (HLS)
This stands for HTTP Live Streaming, this protocol is used to stream video IOS devices running the Safari web browser. Expect to see many seconds of delay as HLS downloads video in large chunks and the player always downloads one full chunk before starting playback.
What's it suitable for?
HLS is usually used to stream to IOS devices when delay is not critical but stability is. HLS is now also becoming the standard protocol that most CDNs use to deliver video behind the scenes, however this is beyond the scope of this document.
Is it TCP or UDP based?
It uses HTTP which is a TCP based protocol.
This protocol was specifically designed by Zixi to provide reliable delivery over extremely poor networks where packet loss and jitter are high (transatlantic for example). Zixi uses some very clever error correction to maintain a stable image even with huge packet loss.
What's it suitable for?
Low latency streaming over extremely poor internet connections where MPEG-TS and RTMP fail to deliver.
Is it TCP or UDP-based?
It is UDP-based but features forward error correction so achieves reliability similar to that of TCP-based protocols.
