It sounds a bit complex, all this n

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.



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

Kết quả (Việt) 1:

Nó âm thanh một chút phức tạp, tất cả các công cụ giao thức mạng này! Vâng, xin lỗi, nó có thể là đáng sợ. Nhưng tôi hứa điều này sẽ không được quá đau đớn nếu bạn đọc từ từ. Trên thực tế bạn có thể thấy điều này thú vị.Điều tốt nhất tôi có thể làm là cố gắng để làm cho các khái niệm đơn giản. Hãy bắt đầu với một giả định rằng bạn đã biết làm thế nào VBrick để multicasting. Bình luận của multicasting, xem giấy tờ trắng. MPEG-1 và MPEG-2 kết hợp âm thanh và video vào một loạt các 1 và 0 của. Chính xác làm thế nào những của 1 và 0 của được tạo được xác định bởi các tiêu chuẩn MPEG. Vì vậy, khi chúng ta nói "MPEG-2 Transport Stream", chúng tôi có thể nhìn vào một tài liệu và đồng ý về những gì chúng tôi có nghĩa là. MPEG-1 và MPEG-2 là tự đầy đủ, nhưng họ làm ít để xác định chính xác làm thế nào họ có thể được truyền qua IP. MPEG-4 cũng là tự cung tự cấp, nhưng thay vì xác định duy nhất "MPEG" cách gửi video, nó xác định việc gửi video bằng cách sử dụng tiêu chuẩn hiện có. Trong số những tiêu chuẩn IP, RTP và RTSP, nhưng tôi nhận được trước bản thân mình. Chúng ta phải bắt đầu với khái niệm đơn giản. Khái niệm mạngTCPIt 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?" UDPUDP 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. RTPRTP 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. RTSPRTSP 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