Write yourself rtpserver--about RTP protocol

Write yourself rtpserver--about RTP protocol

This article will walk you through a simple hand RTP transmission server, designed to understand the RTP streaming Media Transfer Protocol and some knowledge about multimedia codecs.

The necessary knowledge of the RTP protocol to implement a protocol, of course, you first need to read the document of the agreement.

The documentation for the RTP protocol is rfc1889, rfc1890, rfc3550. The rfc3550 is now the version number, the other two is the expiration version. This agreement can be found on the IETF's website: http://tools.ietf.org/html/rfc3550

The RTP PACKETRTP is based on the UDP protocol. Rtpserver will pass the UDP protocol, usually sending a RTP packet each time.

The client reads the data and then plays it by parsing the RTP packet.

The structure of the RTP packet is as follows:

1. The head of the RTP HEADER:RTP packet
   
2. Contributing sources: A number of 0-n. So can be empty. Detailed definition Reference rfc3550
3. RTP payload: That is, the data to be transferred by RTP
   

RTP Header

This is the head of the RTP stream, search the RTP format on the net, will search very many articles to introduce this head definition.

We are here to refer to the definition of rfc3550, in verse 5.1 (http://tools.ietf.org/html/rfc3550#section-5.1).

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| v=2| p|  X| CC |     m|       PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Contributing Source (CSRC) identifiers |
| ....                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Each line is a count of bits, which gives you a visual view of the number of bits that each representation part occupies.

To introduce:

V (Version): 2 BITS,RTP version number. Unified here is 2

P (padding): 1 bit, false set 1, filled at the end of packet, padding is sometimes convenient for some packages for fixed-length algorithms

X (extension): 1 bit, false set 1, the RTP header will follow a header extension

CC (CSRC count): 4 bits. Indicates the number of contributing sources after the head

M (marker): 1 bit, detailed this definition will be in a profile

PT (playload type): 7 bits, which represents the type of multimedia being transferred. The corresponding numbers are listed in a separate document rfc3551 (http://tools.ietf.org/html/rfc3551)

Sequence number:16 bits, each RTP packet's sequence number will be added to its own initiative. So that the receiving end detects the packet loss.

Timestamp:32 bits, timestamp

Ssrc:32 bits, the ID of the synchronization source, the ID of no two sync sources cannot be the same

CSRC: As mentioned above, the number is specified by CC with a range of 0-15

Some of the above concepts are some of the necessary knowledge to achieve rtpserver. The introduction is very brief, the specific definition or to refer to the original rfc3550.

Hands-on practice

Since we already know the structure of the RTP packet, is this the same structure as the RTP stream we used to use? How to verify it? Next. We'll step through the structure of the RTP stream.

We know that RTP is based on UDP, so let's start with a simple UDP receiver to see what information we can receive from Rtpserver.

To implement this receiving end. You need to have a certain network programming experience, as detailed to the operating system, programming environment, development language, etc. are not limited. For simplicity, I'm using Python to give you a small sample program.

Import socket# Build A socket to receive data from RTP server.# here we use SOCK_DGRAM, because RTP are on udp.sock = Socke T.socket (socket.af_inet, socket.        SOCK_DGRAM) sock.bind (("localhost", 6666)) for I in range (5): # We just get bytes to analyze the RTP Header.        BUF = Sock.recv (+) # Output the result in octal. For C in Buf:print "%x"% ord (c), Printsock.close ()

This is the acceptance procedure, very short, and with a simple gaze, which is not explained here.

The receiving end is ready. So where to find rtpserver to send the end? You can use some of the tools to build a streaming media server. I'm using the mighty VLC here. For VLC to build a streaming media server, please refer to my previous article based on mobile platform multimedia framework-using VLC to build a simple streaming media server. Here are a few places to look for configurations. One is to choose destination time to choose RTP and not to choose RTSP, and then address can fill in the local IP address or directly write Localhost,port number to fill the same with the receiver, here is 6666. The string after configuration should resemble the following:

: sout= #rtp {dst=localhost,port=6666,mux=ts}: no-sout-rtp-sap:no-sout-standard-sap:ttl=1

After the server configuration is complete. Start stream. When you open the receiving end, you will receive some data. The data I receive is at the beginning of:

8c CF 3c 74 47 0 44 10 A1
8c CF 4b 74 47 40 42 36 A1
A1 8c CF 7d (0) 1a
A1 8c CF BA (i) 1a
A1 8c CF (c) 0 1b
This is the hexadecimal representation.

We interpret it in the format of the header above:
The first byte 80 indicates:

V (version) =2

P (padding) =0

X (extension) =0

CC (CSRC count) =0

A second byte, A1, says:

M (marker) =1

PT (playload type) =33 (contrast rfc3551 can be found, 33 means mp2t AV. is exactly the type of format we use for VLC stream)

The back of the 2bytes sequence number we can intuitively see is in addition, 4bytes timestamp is also in constant increments.

Then the next 74 is SSRC ID, because CC is 0, so there is no CCRC. The next few are the data that RTP is going to transmit.

Summarize

To RTP familiarity with the protocol is the basis for achieving it. I'm just here to make a brief introduction. Specific knowledge is required. Reading official documents is an indispensable step.

By writing a small program to print out the RTP verbose data stream, you are unaware of the Rtpserver direct help. But the protocol itself allows you to become more familiar with the programming environment, and also facilitates debugging after the execution of the process. No matter what language you realize what the environment is, it is strongly recommended to write a small program.

Write yourself rtpserver--about RTP protocol