UDP, TCP, RTP, RTSP, Unicast, Multicast...

UDP, TCP, RTP, RTSP, Unicast, Multicast...

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, 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).

An Innovative Tool for Measuring Video Streaming QoE

An Innovative Tool for Measuring Video Streaming QoE

I AM...................

I am what lies between the beigining and the end and further beyond.

I am a feeling that comes, touches you and slowly slips away, i am and I am not.

I am in you and still I will never be.

A careless feeling, dat haunts and humms somewhere at the back of your mind and is not and will never be and yet you will remember me......

AAJ DIL BEZUBAAN HO JAISE

AAJ DIL BEZUBAAN HO JAISE

ANKAHEE DASTAAN HO JAISE



DOOR TAK GOONJ HAI SANNATE KI

BEEYABAAn MEIn AZAAN HO JAISE



DHALTE SOORAJ KO DEKH LAGTA HAI

JAL RAHA AASMAAN HO JAISE



ZINDGI CHAL RAHI HAI RUKRUK KE

UMAR BHAR KI THAKAAN JO JAISE



DIL MERA HAI SHAITAN BACHE SA

ZIDDI BACHA NAADAAN HO JAISE



PAAS HO PHIR BHI LAGTA HAI AISA

PHAASLE DARMYAAn HO JAISE



AISA LAGTA HAI AAJ TAERE BIN

SOONA SAARA ZAHAAn HO JAISE



HAI YE AALAM BHARI BAHAARO ME

SAARI BAGIYA VEERAN HO JAISE



USNE HI SAB SITAM NAHEEn DHAYE

MAULA BHI MEHARBAAN HO JAISE



BHOOL JANA WOH KEH GAYA MUJHKO

KAAM KOI AASAAN HO JAISE -- Gurcharan D Narang

Packet and frame difference

A packet is the PDU - protocol delivery unit at layer 3 (network layer) of the networking OSI model. You may have heard them referred to as ip packets. This is the organization of your data at layer 3

A frame is the PDU of layer 2 (data link) of the OSI model.
At layer 2, packets get encapsulated into frames so that they can be transferred over different media to the end destination. Still the same data...it could be split up differently due to varying window size, but there are a few different details added into the frame header.


a packet is a formatted block of data carried by a packet mode computer network. Computer communications links that do not support packets, such as traditional point-to-point telecommunications links, simply transmit data as a series of bytes, characters, or bits alone. When data is formatted into packets, the bitrate of the communication medium can better be shared among users than if the network would have been circuit switched. By using packet switched networking it is also harder to guarantee a lowest possible bitrate.

In computer networking, a frame is a data packet of fixed or variable length which has been encoded by a data link layer communications protocol for digital transmission over a node-to-node link. Each frame consists of a header frame synchronization and perhaps bit synchronization, payload (useful information, or a packet at higher protocol layer) and trailer. Examples are Ethernet frames and Point-to-point protocol (PPP) frames.


A packet is a group of bits of data. A frame is a place to put a packet.
You can't store a frame -- it is mainly of interest to low level network
hardware. A frame is typically an interval of time. Sometimes, it is the
equivalent region along the length of a wire.

If you look at a very early use of the term "frame" this is clear. In the
RS-232 asynchronous serial line protocol, a packet (though not called
that) is typically 8 bits that represent a byte of data being sent from
one node to another. But on the wire, you have to add a start bit in
front and a stop bit in back. Adding those bits is called "framing." You
will never see the 10 bit sequence stored anywhere - the bits are added on
the fly by hardware. The start and stop bits are not part of any packet.
The time between when the receiver sees the start bit and when the
receiver sees to stop bit, not the 10 bits, is a frame.

In T1, a frame is defined by points in time alone -- no extra bits
involved at all. It's not uncommon on T1 voice lines for the packets to
end up distributed incorrectly among the frames (instead of one packet to
each frame), thus causing individual voice circuits to get messed up.

Overview of MPEG-4 encoding format

Overview of MPEG-4 encoding format:
• MPEG-4 is a standard used to compress audio and visual data. The MPEG-4 standard is generally used for streaming media and CD distribution, video conversation, and broadcast television. MPEG-4 incorporates many features of MPEG-1, MPEG-2 and other related standards.
• MPEG-4 is still a developing standard and is divided into several parts. The standard includes the concept of “profiles” and “levels,” allowing a specific set of capabilities to be defined in a manner appropriate for a subset of applications.
• MPEG-4 is able to crunch massive video files into pieces small enough to send over mobile networks. While these blurry pictures are unlikely to persuade millions of people to upgrade immediately their mobile phones but holds enough promise for future.
• Perhaps more important are the interactive features that MPEG-4 offers. The video functions almost like a Web page, but allowing people to interact with the picture on the screen or to manipulate individual elements in real time.
• MPEG-4 also allows other types of content to be bundled into a file, such as video or images. These files require special software to play.
• MPEG-4 would allow the interactivity of the video which may open potential to do far more than just point and click at links on the screen. Individual elements of the video like a character, a ball in a sporting event, a rocket ship in a science-fiction epic can exist in a separate layer from the rest of the video. This could allow viewers to interact with these elements somehow, even changing the direction of the story.
Overview of H.264 Coding Format:
• Also known as MPEG-4 Part 10 or AVC (for Advanced Video Coding).
• Poised to become the next standard for format of convergence in the digital video industry regardless of the video playback platform . Big Internet players like Google/YouTube, Adobe, and Apple iTunes are all backing this cross-platform format.
• H.264 standard is jointly maintained with MPEG so that they have identical technical content.
• The intention behind H.264/AVC project was to provide good video quality at substantially lower bit rates than previous standards. An additional goal was to provide enough flexibility to allow the standard to be applied to a wide variety of applications on a wide variety of networks and systems.
• H.264/AVC/MPEG-4 Part 10 contains Multi-picture inter-picture prediction including the features like using previously-encoded pictures as references in a more flexible way than in past standards, allowing up to 32 reference pictures to be used sometimes.
• H.264 provides quarter-pixel precision for motion compensation enables very precise description of the displacements of moving areas. For chroma the resolution is typically halved both vertically and horizontally, therefore the motion compensation of chroma uses one-eighth chroma pixel grid units.
• H.264 provides six-tap filtering for derivation of half-pel luma sample predictions, to lessen the aliasing and eventually provide sharper images.
• H.264 provides flexible interlaced-scan video coding features, includes Macro block-adaptive frame-field (MBAFF) coding, using a macroblock pair structure for pictures coded as frames, allowing 16×16 macroblocks in field mode compared with 16×8 half-macroblocks in MPEG-2. An enhanced lossless macroblock representation mode allowing perfect representation of specific regions while ordinarily using substantially fewer bits than the PCM mode. Picture-adaptive frame-field coding, allowing a freely-selected mixture of pictures coded as MBAFF frames with pictures coded as individual single fields (half frames) of interlaced video.
• H.264 is more attractive for video network delivery and for delivery of HD, high definition video.
• H.264 or AVC is an open format with published specification and is available for anyone to implement.

Mark Twain...

Work like you don’t need the money.
Love like you’ve never been hurt.
Sing like no-one’s listening.
Dance like no-one’s watching.
Live like there’s no tomorrow.

--mark twain

Really inspiring..

trying my best to follow his magnificent lines :D :D