It sounds a bit complex, all this network protocol stuff! Well, sorry, it can be intimidating. But I promise this will not be too painful if you read slowly. Actually you may find this interesting.
The best I can do is to try to make the concepts simple. Let's start with an assumption that you already know how VBrick does multicasting. For a review of multicasting, see White Papers.
MPEG-1 and MPEG-2 both combine audio and video into a series of 1's and 0's. Exactly how those 1's and 0's are created is defined by the MPEG standards. So, when we say "MPEG-2 Transport Stream", we can look at a document and agree on what we mean. MPEG-1 and MPEG-2 are self sufficient, but they do little to specify exactly how they might be transmitted over IP.
MPEG-4 is also self-sufficient, but rather than defining unique "MPEG" ways of sending video, it specifies sending the video using existing standards. Among those standards are IP, RTP and RTSP, but I'm getting ahead of myself. We must start with simple concepts.
It seems everyone's heard of "TCP/IP". You probably know that "IP" stands for "Internet Protocol". The "TCP" stands for "Transmission Control Protocol". Here is the deal: to ensure a packet arrives without errors, the sender of a packet keeps an extra copy and waits for the receiver to say "I got it okay". If the sender hears this from the receiver, the sender can discard that extra copy. If the receiver says "I didn't get it" or says nothing at all after awhile, the sender resends it. As you can see, this makes for reliable delivery but takes time. It also adds a great deal of overhead because there is a dialog between the sender and receiver. Practically all email, web pages, and other Internet traffic is sent using TCP/IP.
TCP is a key reason why your web traffic or email "slows down" but does not "break". When there is too much traffic, your packets may be discarded or lost somewhere...but not to worry! Without you even knowing it, your packets are being resent until they finally get through (and you thought you just had a "good" connection).
Analogy: TCP is like a telephone call. If you didn't hear what the other person said, you say "What?"
UDP stands for "User Datagram Protocol". It is sometimes called "send and pray" because there is no dialog between the sender and receiver. If the receiver does not get a packet, the sender will never know. "When the heck would I want that!" you may ask. Well, UDP is very efficient when there is little chance of errors (like in your LAN), or when TCP would provide "too late" delivery.
All VBrick video is sent via UDP. Hey, we are sending live video, right? If I send you video frame #1, #2, #3 .... #1000 and you display the video frames in real time as you receive them, and you didn't get frame #500, what would you do with new frame #500 if I resent it to you? Display it after frame #1000? That wouldn't look too good, would it?
Video is normally send via UDP. But there is trouble with UDP now-adays. Many corporate firewalls block all UDP packets, making it impossible for streaming video to reach desktops. This is done to prevent hackers from getting access to the network, and is also sometimes done to prevent excessive use of bandwidth. More on this later.
Analogy: UDP is like a public address system. If you didn't hear what was announced, you can't hear it again.
RTP stands for Real-time Transport Protocol. It is normally sent via UDP. It does not ensure "real time" but is a protocol that enhances the control and synchronization of real time stuff (like streaming video). Here is where it gets interesting: with MPEG-1 and MPEG-2, RTP is unnecessary because MPEG itself provides synchronization (see White Paper). Like so many standards, there are several ways to implement it. For example, you can split apart the MPEG-1 stream and send audio on one IP address and video on another, or you can send both audio & video on the same address. RTP provides timestamps that will provide audio/video sync. VBrick has long supported RTP in the VB3000 for interoperability with other vendors.
In the case of MPEG-4, the only meaningful way to send audio/video is via RTP (there is nothing like a "MPEG-1 System Stream" nor a "MPEG-2 Transport Stream"). In other words, for MPEG-4, a/v sync is provided via RTP.
Analogy: RTP is like an orchestra leader, keeping all the musicians in sync.
RTSP stands for Real Time Streaming Protocol. RTSP is control protocol, not to be confused with IP, TCP, or UDP. However, RTP and RTSP are linked. You could find RTP without RTSP, but you would not find RTSP without RTP.
A good way to position RTSP in your mind is to think of it the same way you think of "http" and "ftp". You know, if you want to see a web page, you will enter "http://something". If you want to view a video in a player, you will enter "rtsp://something". This is only true for unicast streams, where each viewer receives their own stream from the server (i.e. from the VBrick). RTSP is not used for multicast.
Analogy: RTSP is like a "touch tone" telephone vs. the old rotary dial telephone. It is merely a method of signaling.
The Hyper Text Transfer Protocol is often confused with the Hyper Text Markup Language. Its description is beyond the scope of this page, and on the surface seems out of place here. However, because virtually all firewalls allow the default http port (port 80) to pass, streaming video can be sent via http "tunneling". There is a severe penalty, since http is sent via TCP which increases the overhead by some 30% and magnifies the delay.
Unicasting is simply sending packets from one source to one destination. For example, from one web server to one (or each) person viewing a page on a web browser. What may be new to you is the idea that one VBrick can send video via unicast to many viewers. More on this in a moment. Data (or video) can be sent via UDP or TCP, with RTP and RTSP, and can be sent via Unicast. So, Unicast is a method, not a protocol.
Analogy: Mailing a letter (although we assume IP is faster!)
Multicasting is sending data from a sender to multiple receivers where each receiver signals that they want to receive the data. This is different from Unicasting, and different from broadcasting (where everyone gets the data whether they want it or not). Notice that you normally have a one-way connection, thereby ruling out TCP. Yes, that's right, Multicast is done via UDP. There are methods in use where a receiver can signal a sender that it has received a bad packet using a different 'reverse channel'. This is called "reliable multicast" and has little value for live video transmission.
Analogy: Distributing brochures with a sign that says "Take One". Only those who want it take it.
The Session Description Protocol, for our purposes, is a file that describes a MPEG-4 stream. SDP files are uniquely created for each stream, whether the stream is multicast or unicast. SDP files are put on servers to allow them to identify a stream and replicate it to viewers. Wow, really new concept! But not to worry, VBrick makes it largely invisible. But you should know the standard exists and we support the relevant sections.
Here we go. You can send MPEG-4 video by wrapping the video steam in a RTP packet, wrapping the audio stream in another RTP packet, then wrapping each RTP packet in a UDP packet, then controlling the stream using RTSP. You can encapsulate the RTP in http if necessary (via an external server).
You can send MPEG-1 System and MPEG-2 Transport streams via raw UDP (this is what we normally do in LANs). You can send MPEG-1 System Streams and MPEG-2 transport streams via RTP over UDP (we do this for stored video on demand).
The best I can do is to try to make the concepts simple. Let's start with an assumption that you already know how VBrick does multicasting. For a review of multicasting, see White Papers.
MPEG-1 and MPEG-2 both combine audio and video into a series of 1's and 0's. Exactly how those 1's and 0's are created is defined by the MPEG standards. So, when we say "MPEG-2 Transport Stream", we can look at a document and agree on what we mean. MPEG-1 and MPEG-2 are self sufficient, but they do little to specify exactly how they might be transmitted over IP.
MPEG-4 is also self-sufficient, but rather than defining unique "MPEG" ways of sending video, it specifies sending the video using existing standards. Among those standards are IP, RTP and RTSP, but I'm getting ahead of myself. We must start with simple concepts.
Networking Concepts
TCP
It seems everyone's heard of "TCP/IP". You probably know that "IP" stands for "Internet Protocol". The "TCP" stands for "Transmission Control Protocol". Here is the deal: to ensure a packet arrives without errors, the sender of a packet keeps an extra copy and waits for the receiver to say "I got it okay". If the sender hears this from the receiver, the sender can discard that extra copy. If the receiver says "I didn't get it" or says nothing at all after awhile, the sender resends it. As you can see, this makes for reliable delivery but takes time. It also adds a great deal of overhead because there is a dialog between the sender and receiver. Practically all email, web pages, and other Internet traffic is sent using TCP/IP.
TCP is a key reason why your web traffic or email "slows down" but does not "break". When there is too much traffic, your packets may be discarded or lost somewhere...but not to worry! Without you even knowing it, your packets are being resent until they finally get through (and you thought you just had a "good" connection).
Analogy: TCP is like a telephone call. If you didn't hear what the other person said, you say "What?"
UDP
UDP stands for "User Datagram Protocol". It is sometimes called "send and pray" because there is no dialog between the sender and receiver. If the receiver does not get a packet, the sender will never know. "When the heck would I want that!" you may ask. Well, UDP is very efficient when there is little chance of errors (like in your LAN), or when TCP would provide "too late" delivery.
All VBrick video is sent via UDP. Hey, we are sending live video, right? If I send you video frame #1, #2, #3 .... #1000 and you display the video frames in real time as you receive them, and you didn't get frame #500, what would you do with new frame #500 if I resent it to you? Display it after frame #1000? That wouldn't look too good, would it?
Video is normally send via UDP. But there is trouble with UDP now-adays. Many corporate firewalls block all UDP packets, making it impossible for streaming video to reach desktops. This is done to prevent hackers from getting access to the network, and is also sometimes done to prevent excessive use of bandwidth. More on this later.
Analogy: UDP is like a public address system. If you didn't hear what was announced, you can't hear it again.
RTP
RTP stands for Real-time Transport Protocol. It is normally sent via UDP. It does not ensure "real time" but is a protocol that enhances the control and synchronization of real time stuff (like streaming video). Here is where it gets interesting: with MPEG-1 and MPEG-2, RTP is unnecessary because MPEG itself provides synchronization (see White Paper). Like so many standards, there are several ways to implement it. For example, you can split apart the MPEG-1 stream and send audio on one IP address and video on another, or you can send both audio & video on the same address. RTP provides timestamps that will provide audio/video sync. VBrick has long supported RTP in the VB3000 for interoperability with other vendors.
In the case of MPEG-4, the only meaningful way to send audio/video is via RTP (there is nothing like a "MPEG-1 System Stream" nor a "MPEG-2 Transport Stream"). In other words, for MPEG-4, a/v sync is provided via RTP.
Analogy: RTP is like an orchestra leader, keeping all the musicians in sync.
RTSP
RTSP stands for Real Time Streaming Protocol. RTSP is control protocol, not to be confused with IP, TCP, or UDP. However, RTP and RTSP are linked. You could find RTP without RTSP, but you would not find RTSP without RTP.
A good way to position RTSP in your mind is to think of it the same way you think of "http" and "ftp". You know, if you want to see a web page, you will enter "http://something". If you want to view a video in a player, you will enter "rtsp://something". This is only true for unicast streams, where each viewer receives their own stream from the server (i.e. from the VBrick). RTSP is not used for multicast.
Analogy: RTSP is like a "touch tone" telephone vs. the old rotary dial telephone. It is merely a method of signaling.
HTTP
The Hyper Text Transfer Protocol is often confused with the Hyper Text Markup Language. Its description is beyond the scope of this page, and on the surface seems out of place here. However, because virtually all firewalls allow the default http port (port 80) to pass, streaming video can be sent via http "tunneling". There is a severe penalty, since http is sent via TCP which increases the overhead by some 30% and magnifies the delay.
Unicast
Unicasting is simply sending packets from one source to one destination. For example, from one web server to one (or each) person viewing a page on a web browser. What may be new to you is the idea that one VBrick can send video via unicast to many viewers. More on this in a moment. Data (or video) can be sent via UDP or TCP, with RTP and RTSP, and can be sent via Unicast. So, Unicast is a method, not a protocol.
Analogy: Mailing a letter (although we assume IP is faster!)
Multicast
Multicasting is sending data from a sender to multiple receivers where each receiver signals that they want to receive the data. This is different from Unicasting, and different from broadcasting (where everyone gets the data whether they want it or not). Notice that you normally have a one-way connection, thereby ruling out TCP. Yes, that's right, Multicast is done via UDP. There are methods in use where a receiver can signal a sender that it has received a bad packet using a different 'reverse channel'. This is called "reliable multicast" and has little value for live video transmission.
Analogy: Distributing brochures with a sign that says "Take One". Only those who want it take it.
SDP
The Session Description Protocol, for our purposes, is a file that describes a MPEG-4 stream. SDP files are uniquely created for each stream, whether the stream is multicast or unicast. SDP files are put on servers to allow them to identify a stream and replicate it to viewers. Wow, really new concept! But not to worry, VBrick makes it largely invisible. But you should know the standard exists and we support the relevant sections.
Putting It All Together
Here we go. You can send MPEG-4 video by wrapping the video steam in a RTP packet, wrapping the audio stream in another RTP packet, then wrapping each RTP packet in a UDP packet, then controlling the stream using RTSP. You can encapsulate the RTP in http if necessary (via an external server).
You can send MPEG-1 System and MPEG-2 Transport streams via raw UDP (this is what we normally do in LANs). You can send MPEG-1 System Streams and MPEG-2 transport streams via RTP over UDP (we do this for stored video on demand).
Đăng nhận xét