Analysis of--RTSP protocol for UAV remote video transmission based on Easydarwin

Affirm that this article references the article of http://blog.csdn.net/haolipengzhanshen/article/details/50802081, here to mark thanks!

This article mainly analyzes Easydarwin's rtsp content from several aspects
RTSP Protocol Overview
Wireshark capture case Analysis of a complete RTSP interactive process
Easydarwin initialization of RTSP in project code
Easydarwin process for RTSP requests in project code

If you are only want to realize the transmission of video stream, there is not much demand for the forwarding server, it is recommended that as long as the research Easydarwin client can, the client involves decoding playback displayed on the ground station. The use of Easydarwin is described in detail in the official Easydarwin.

The first part: RTSP protocol

I. Overview of the RTSP protocol

RTSP (Real-timestream Protocol) is a text-based application layer protocol, and the RTSP protocol is similar to HTTP protocol in syntax and some message parameters. The HTTP protocol is quite familiar to everyone.

RTSP is used to establish the transmission of the control media stream, which plays the role of "Network remote control" for multimedia services. Although it is sometimes possible to interleave the RTSP control information with the media data stream, the general condition of RTSP itself is not used to transmit media stream data. The transmission of media data can be done through protocols such as RTP/RTCP.

A basic RTSP operation process is:
First, the client connects to the streaming server and sends an RTSP description command (DESCRIBE).
The streaming server uses an SDP description to make feedback, including information such as the number of streams, the type of media, and so on.
The client then parses the SDP description and sends an RTSP Setup command (SETUP) for each stream in the session, and the RTSP Setup command tells the server that the client is using the port to receive the media data.
After the streaming media connection is established, the client sends a play command (play) and the server begins to transmit the media Stream (RTP packet) to the client on UDP.
The client can also send commands to the server to control fast forward, rewind, and pause during playback. Finally, the client can send a terminate command (Teradown) to end the streaming session

Ii. Important methods of RTSP
C->s indicates that data is sent from the client to the server, and S->c indicates that data is being sent from the server to the client. Through the above methods to complete the interaction between the client and the server instruction, constitute the basic framework of the RTSP protocol.

We use Wireshark to analyze the RTSP command flow familiar with the instruction flow for our understanding of Easydarwin is very important to help.

To analyze the following RTSP package:

Figure 1.1 client pushes a stream to the server

Figure 1.2 player obtains video stream from server

The RTSP protocol basic flow, we open Easydarwin project run, streaming media server.

2.c->s:describe request//requires the media initialization description information provided by S 2.s->c:describe Response//s Response Media initialization description information, The main reason is that the SDP client sends describe to the server to obtain the media description information specified by the URI, typically the SDP information. The client specifies the type of media information that the client can accept through the accept header. The RTSP://192.168.1.100:8003/ST0.SDP rtsp/1.0\r\n after the OPTIONS field is the URI resource on the requested server. CONTENT-TYPE:APPLICATION/SDP//Indicates response to SDP information content-length:1383//The following is a specific SDP information media description is commonly used in our analysis. 

v=<version> o=<username> <session id> <version> <network type> <address type> < address> s=<session name> i=<session description> u=<uri> e=<email address> p=<phone number> c=<network type> <address type> <connection address> b=<modifier>:< bandwidth-value> t=<start time> <stop time> r=<repeat interval> <active duration> <list of Offsets from start-time> z=<adjustment time> <offset> <adjustment time> <offset> .... k=< method> k=<method>:<encryption key> a=<attribute> a=<attribute>:<value> m=< media> <port> <transport> <fmt list> v = (protocol version) O = (owner/creator and session identifier) s = (session name) i = * (Session information) U = * (UR I description) E = * (Email address) p = * (phone number) c = * (connection information) b = * (bandwidth information) z = * (time zone adjustment) k = * (encryption key) A = * (0 or more session property rows) Time Description: T = (will Time) r = * (0 or more repetitions) media Description: M = (media name and transport address) i = * (media title) C = * (evenAccess information-if included in the session layer then the field is optional) b = * (bandwidth information) k = * (encryption key) A = * (0 or more media property rows) 

3.c->s:setup Request//sets the properties of the session, as well as the transfer mode, reminding S to establish a session 3.s->c:setup response//s establish a session, return session identifiers, and session-related information used to determine the transfer mechanism to establish an RTSP session. The client can issue a setup request to change the transmission parameters for the media stream being played, and the server may agree to change these parameters. If you disagree, it must respond to the error "455 Method not Valid in the"

4.c->s:play request//C Requests Playback 4.s->c:play response//s Back the information method that should be requested tells the server to start sending data through the mechanism specified in Setup. The client is not able to issue a play request until a successful answer to the setup request has been received. The play request navigates the normal play time to the beginning of the specified range, and transmits the data stream until the end of the playback range. The play request may be piped (pipelined), which is placed in the queue (queued), and the server must put the play request into the queue for orderly execution. That is, the latter play request needs to wait for the previous play request to complete before it can be executed.

6.c->s:teardown request//C Requests shutdown session 6.s->c:teardown Response//s should request a complete RTSP protocol request process that's it.

The above process is only a standard, friendly RTSP process, but the actual requirements do not necessarily follow this process.

The third and fourth steps are required! As a first step, if the server client is well-appointed and what methods are available, the option request may not. The second step, if we have other ways to get the media initialization description information (such as HTTP requests, etc.), then we do not need to pass the describe request in RTSP to complete.

For more information, see: http://www.amovauto.com/?p=481 Itsuki Community

QQ Group: 526221258

Analysis of--RTSP protocol for UAV remote video transmission based on Easydarwin