LIVE555 Source Code Analysis

live555 Source code Download (VC6 project): http://download.csdn.net/detail/leixiaohua1020/6374387

The source code for the Livemedia Project (http://www.live555.com/) consists of four basic libraries, a variety of test codes, and media Server. The four basic libraries are: Usageenvironment&taskscheduler, Groupsock, Livemedia and Basicusageenvironment. The Usageenvironment and TaskScheduler classes are used for event scheduling, which implements the setting of the handle of an asynchronous read event and the output of the error message. In addition, there is a Hashtable class that defines a generic hash table, which is used by the other code. These are abstract classes that implement your own subclasses based on these classes in your application. The Groupsock class is an encapsulation of network interfaces for sending and receiving packets. As the name itself, Groupsock is mainly for multicast data transmission, it also supports unicast data transmission and receiving. There are a series of classes in the Livemedia library, and the base classes are medium, which target different streaming media types and encodings.

Various test codes are in the Testprogram directory, such as OPENRTSP, which helps to understand the Livemedia application.
Media server is a purely RTSP server. Support for media files in multiple formats:

* TS stream file with extension TS.

* PS streaming file, extension mpg.

* MPEG-4 video Basic stream file with extension m4e.

* MP3 file, extension mp3.

* wav file (PCM), extension wav.

* AMR audio file, extension. Amr.

* AAC file, ADTS format, extension AAC.

developing applications with live555

Livemedia-based programs need to define classes to handle event scheduling, data read and write, and error handling by inheriting Usageenvironment abstract classes and TaskScheduler abstract classes. There is a basic implementation of these classes in the source code of the live project, which is the "basicusageenvironment" library. Basicusageenvironment is mainly for simple console applications, using Select to achieve event acquisition and processing. This library uses UNIX or Windows console as input and output, in the application prototype or debugging purposes, you can use this library users can develop traditional running and console applications. By using the subclasses of the custom "Usageenvironment" and "TaskScheduler" abstract classes, these applications can run in a specific environment and do not require much modification. It should be noted that under the graphical Environment (GUI Toolkit), subclasses of abstract class TaskScheduler should be integrated with their own event processing framework when implementing Doeventloop (). Basic Concepts

First, familiarize yourself with the concepts of source,sink and filter in the Livemedia library. Sink is the object of consuming data, such as storing the received data to a file, this file is a Sink. Source is the object that produces data, such as reading data through RTP. The data flow passes through multiple ' source ' and ' sink ' s, and here's an example:

' Source1 ', ' source2 ' (a filter), ' Source3 ' (a filter), ' sink '

Source that receives data from other source is also called "Filters". The Module is a sink or a filter. The end point of the data receive is the sink class, and Mediasink is the base class for all sink classes. The Sink class implements the processing of data by implementing a pure virtual function continueplaying (), typically continueplaying calls Fsource->getnextframe to set the data buffer for source. A callback function that handles data, such as Fsource, is a class member of the Mediasink type framedsource*.
The control flow of the basic control flow based Livemedia application is as follows:
The application is event-driven and uses a loop of the following way

while (1) {
finds the task that needs to be completed by finding a list of read network handles and a delay queue
}

For each sink, before entering this loop, the application usually calls the following method to start the build task that needs to be done: somesinkobject->startplaying (). At any time, a module needs to fetch data by invoking the Framedsource::getnextframe () method of the module that is just before it. This is achieved through the pure virtual function Framedsource::d ogetnextframe (), each of the source module has a corresponding implementation.
Each ' source ' module's implementation of "Dogetnextframe ()" works by arranging for a ' after getting ' function to be Calle D (from a event handler) when new data becomes available for the caller.
Note the flow of data from ' sources ' to ' sinks ' happens within each application, and doesn ' t necessarily correspond t o the sending or receiving of the network packets. For example, a-server application (such as "Testmp3streamer") that sends RTP packets would do-using one or more "Rtpsink "Modules. These "Rtpsink" modules receive data from the other, "*source" modules (e.g., to read data from a file), and, as a side effect , transmit RTP packets.

live555 code Interpretation: The process of setting up RTSP connection

The Rtspserver class is used to build an RTSP server, which also defines a rtspclientsession class within it to handle individual client sessions.
First create the RTSP server (the implementation class is Dynamicrtspserver), in the creation process, first establish the socket (oursocket) on TCP port 554 to listen, and then the connection handler function handle (rtspserver:: Incomingconnectionhandler) and the socket handle to the Task Scheduler (TaskScheduler).
The Task Scheduler puts the socket handle in the socket handle set (Freadset) used in the next select call, and associates the socket handle with the Incomingconnectionhandler handle. Next, the main program begins to enter the Task Scheduler's main loop (Doeventloop), calling the system function select Block in the main loop, waiting for the network connection.
When the RTSP client input (RTSP://192.168.1.109/1.MPG) is connected to the server, select returns the corresponding Scoket and, depending on the previously saved correspondence, can find the corresponding handler handle. Here is the Incomingconnectionhandler mentioned earlier. The rtspclientsession is created in Incomingconnectionhandler and the session of this client begins to be processed.

live555 Code Interpretation of the second: DESCRIBE request message processing process

After the RTSP server receives the client's describe request, it finds the corresponding streaming media resource according to the request URL (rtsp://192.168.1.109/1.mpg) and returns the response message. The Servermediasession class in live555 is used to process the description of the session, which contains multiple (audio or video) sub-session descriptions (servermediasubsession).
In the previous section we talked about the RTSP server receiving a connection request from the client, establishing the Rtspclientsession class, and processing a separate client session. The newly created socket handle (Clientsocket) and the RTSP request handler function handle are rtspclientsession during the setup process Rtspclientsession::incomingrequesthandler To the Task Scheduler, which is a one-to-one association between the Task Scheduler. When the client makes an RTSP request, the Select call in the server's main loop returns, and the corresponding Incomingrequesthandler is found based on the socket handle to begin the message processing. Parse the message first and enter the Handlecmd_describe function if the request is found to be DESCRIBE. Depending on the suffix of the client request URL (for example, 1.mpg), the member function dynamicrtspserver::lookupservermediasession is called to find the corresponding vector information servermediasession. If Servermediasession does not exist, but a local 1.mpg file exists, a new servermediasession is created. During the creation of the servermediasession process,
Based on the file suffix. mpg, create the media mpeg-1or2 (Mpeg1or2fileserverdemux). A sub-session is then created by Mpeg1or2fileserverdemux to describe the mpeg1or2demuxedservermediasubsession. Finally, the SDP information in the assembly response message is completed by Servermediasession (the SDP assembly process is described below), and the response message is then sent to the client to complete a message interaction.

SDP Message Assembly process

Servermediasession is responsible for generating the session public description information, and the sub-session description is generated by mpeg1or2demuxedservermediasubsession. Mpeg1or2demuxedservermediasubsession generates session description information in its parent class member function Ondemandservermediasubsession::sdplines (). Inside the Sdplines () implementation, create a fictitious (dummy) Framedsource (the implementation class is Mpeg1or2audiostreamframer and Mpeg1or2videostreamframer) and Rtpsink (the concrete implementation class is Mpeg1or2audiortpsink and Mpeg1or2videortpsink), and the Last call to Setsdplinesfromrtpsink (...) The member function generates a child session description.

The above related classes and inheritance relationships:

Medium <-servermediasession

Medium <-servermediasubsession <-ondemandservermediasubsession <-mpeg1or2demuxedservermediasubsession

Medium <-MediaSource <-framedsouse <-framedfilesource <-Bytestreamfilesource

Medium <-MediaSource <-framedsouse <-mpeg1or2demuxedelementarystream

Medium <-Mpeg1or2fileserverdemux

Medium <-Mpeg1or2demux

Medium <-MediaSource <-framedsouse <-mpeg1or2demuxedelementarystream

Medium <-MediaSource <-framedsouse <-framedfilter <-mpegvideostreamframer <- Mpeg1or2videostreamframer

Medium <-mediasink <-rtpsink <-multiframedrtpsink <-videortpsink <-mpeg1or2videortpsink

live555 code Interpretation of the third: Setup and Play request message processing process
The Rtspclientsession class has been mentioned earlier to handle individual client sessions. Its class member function Handlecmd_setup () processes the client's SETUP request. Call Parsetransportheader () for the transport header resolution of the setup request, and invoke the Getstreamparameters () of the sub-session (which specifically implements the class Ondemandservermediasubsession) The function gets the stream media send transmission parameters. These parameters are assembled into a response message and returned to the client.

To get the process of sending transport parameters:

Call the Createnewstreamsource (...) of the child session (Implementation class Mpeg1or2demuxedservermediasubsession) to create the Mpeg1or2videostreamframer, Select Send transport parameters and invoke the Createnewrtpsink (...) of the child session Create a Mpeg1or2videortpsink. This information is also stored in the Streamstate class object, which is used to record the state of the stream.
The client sends two setup requests for the creation of an RTP receive for audio and video.

The PLAY request message processing process:

The

Rtspclientsession class member function Handlecmd_play () handles the client's playback request. Call the Startstream () of the child session first, call Mediasink::startplaying (...) internally, and then multiframedrtpsink::continueplaying (), Then call Multiframedrtpsink::buildandsendpacket (...). Buildandsendpacke Internal first set the RTP header, the inner
part calls Multiframedrtpsink::p ackframe () fills the encoded frame data.
Packframe Internal through Framedsource::getnextframe (), then Mpegvideostreamframer::d ogetnextframe (), Then go through Mpegvideostreamframer::continuereadprocessing (), framedsource::aftergetting (...), Multiframedrtpsink:: Aftergettingframe (...), multiframedrtpsink::aftergettingframe1 (...)   A series of tedious calls, and finally to Multiframedrtpsink:: Sendpacketifnecessary (), the RTP packet is actually sent here. Then the next packet is calculated to send the time, the Multiframedrtpsink::sendnext (...) The function handle is passed to the Task Scheduler as a deferred event dispatch. In the main loop, when Multiframedrtpsink::sendnext () is dispatched, it starts calling Multiframedrtpsink::buildandsendpacket (...). Start a new send data process so that the client can receive a steady stream of RTP packets from the server.
Interval calculation method to send RTP packets:

Update the time at which the next packet should is sent, based on the duration of the frame then we just packed into it.

Some of the classes involved are:

MPEGVIDEOSTREAMFRAMER:A filter, breaks up a MPEG video elementary stream into headers

and frames

MPEG1OR2VIDEOSTREAMFRAMER:A filter, breaks up an MPEG 1 or 2 video elementary Stream

into frames For:video_sequence_header, Gop_header, Picture_header

Mpeg1or2demuxedelementarystream:a MPEG 1 or 2 elementary Stream, demultiplexed from

A program Stream

Mpeg1or2demux:demultiplexer for a MPEG 1 or 2 program Stream

Bytestreamfilesource:a file source is A plain byte stream (rather than frames)

Mpegprogramstreamparser:class for parsing MPEG program stream

Streamparser:abstract class for parsing a byte stream

Streamstate:a class that represents the state of a ongoing stream

About RTSP (ZT)
Real Time streaming Protocol or RTSP (live Streaming protocol) is an application layer protocol that is proposed by real network and Netscape to effectively transmit streaming media data over an IP network. RTSP provides a scalable framework that enables the delivery of real-time data, such as audio and video files, that can be controlled and delivered on demand. The source data can include the feedback of the field data and the stored files. RTSP Streaming media provides control such as pause, fast forward, and it does not transmit data itself, and RTSP acts as a remote control for streaming media servers. The transfer data can be passed through the TCP,UDP protocol of the Transport layer, and RTSP also provides some effective methods based on the RTP transmission mechanism.

RTSP message Format:

There are two main types of RTSP messages, one is the request message, one is the response message (response), and the format of the two messages is different.

Request message:
Method URI RTSP version cr LF
Message head CR LF CR LF
Message body CR LF
The method includes all the commands in the option response, and the URI is the address of the subject, for example: rtsp://192.168.20.136.
The RTSP version is generally rtsp/1.0. The CR LF at the back of each line represents a carriage return and requires a corresponding parsing at the receiving end, and the last message header needs to have two CR LF

Response message:
RTSP Version Status code interpretation CR LF
Message head CR LF CR LF
Message body CR LF
In which the RTSP version is generally rtsp/1.0, the status code is a numeric value, 200 indicates success, and the explanation is the text interpretation corresponding to the status code.

The simple RTSP interaction process:
C represents the RTSP client, S represents the RTSP server

1.c->s:option request//Ask S What methods are available
1.s->c:option Response//s response information includes all available methods provided
2.c->s:describe Request//Required Media Initialization description information provided by S
2.s->c:describe Response//s Response Media Initialization description information, mainly SDP
3.c->s:setup request// Set the session's properties, as well as the transfer mode, to remind S to establish
session 3.s->c:setup response//s to set up sessions, return session identifiers, and session-related information
4.c->s:play request//c Request Playback
4.s->c:play Response//s Back the information that should be requested
S->c: Send streaming media data
5.c->s:teardown request//C requests to close session
5. S->c:teardown response//s back should request

The above process is a standard, friendly RTSP process, but the actual requirements do not necessarily come in step. The 3rd and 4 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. The fifth step, according to the system requirements of the design to determine whether the need.

Common methods in RTSP:

1.OPTION

The goal is to get the available methods provided by the server:
OPTIONS rtsp://192.168.20.136:5000/xxx666 rtsp/1.0
Cseq:1//Each message is marked with an ordinal, the first packet is usually an option request message
USER-AGENT:VLC Media Player (LIVE555 streaming media v2005.11.10)
The server's response information includes some of the methods provided, such as:
rtsp/1.0 OK
Server:userver 0.9.7_rc1
Cseq:1//CSEQ value of each response message corresponds to the cseq of the request message
Public:options, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, Scale,get_parameter//server available methods

2.DESCRIBE

C initiates a describe request to s, in order to obtain the session description information (SDP):
DESCRIBE rtsp://192.168.20.136:5000/xxx666 rtsp/1.0
Cseq:2
Token
Accept:application/sdp
USER-AGENT:VLC Media Player (LIVE555 streaming media v2005.11.10)
The server responds to some descriptive information (SDP) for this session:
rtsp/1.0 OK
Server:userver 0.9.7_rc1
Cseq:2
x-prev-url:rtsp://192.168.20.136:5000
x-next-url:rtsp://192.168.20.136:5000
X-accept-retransmit:our-retransmit
X-accept-dynamic-rate:1
Cache-control:must-revalidate
Last-modified:fri, 2006 12:34:38 GMT
Date:fri, 2006 12:34:38 GMT
Expires:fri, 2006 12:34:38 GMT
content-base:rtsp://192.168.20.136:5000/xxx666/
content-length:344
Content-type:application/sdp
V=0//The following are SDP information
O=onewaveuserverng 1451516402 1025358037 in IP4 192.168.20.136
s=/xxx666
u=http:///
e=admin@
C=in IP4 0.0.0.0
T=0 0
a=isma-compliance:1,1.0,1
a=range:npt=0-
M=video 0 RTP/AVP//m represents the media description, the following is the media description of the video channel in the session
a=rtpmap:96 mp4v-es/90000
a=fmtp:96
profile-level-id=245;config=000001b0f5000001b509000001000000012000c888b0e0e0fa62d
089028307
A=control:trackid=0//trackid=0 indicates that the video stream is using channel 0

3.SETUP

The client reminds the server to establish a session and determines the transfer mode:
SETUP rtsp://192.168.20.136:5000/xxx666/trackid=0 rtsp/1.0
Cseq:3
Transport:rtp/avp/tcp;unicast;interleaved=0-1
USER-AGENT:VLC Media Player (LIVE555 streaming media v2005.11.10)
The URI is provided with Trackid=0, which indicates that the channel is set. The Transport parameter sets the transport mode, the package structure. Next packet header second byte position is interleaved, its value is each channel is different, trackid=0 interleaved value has two 0 or 1,0 represents the RTP packet, 1 means the RTCP package, the receiving end according to interleaved The value to distinguish what kind of packet.
Server Response Information:
rtsp/1.0 OK
Server:userver 0.9.7_rc1
Cseq:3
session:6310936469860791894//The session identifier of the server response
Cache-control:no-cache
transport:rtp/avp/tcp;unicast;interleaved=0-1;ssrc=6b8b4567

4.PLAY

The client sends a play request:
PLAY rtsp://192.168.20.136:5000/xxx666 rtsp/1.0
Cseq:4
session:6310936469860791894
range:npt=0.000-//Set the range of playback time
USER-AGENT:VLC Media Player (LIVE555 streaming media v2005.11.10)
Server Response Information:
rtsp/1.0 OK
Server:userver 0.9.7_rc1
Cseq:4
session:6310936469860791894
range:npt=0.000000-
rtp-info:url=trackid=0;seq=17040;rtptime=1467265309
Seq and rtptime are all information in the RTP package.

5.TEARDOWN

The client initiates a shutdown request:
TEARDOWN rtsp://192.168.20.136:5000/xxx666 rtsp/1.0
Cseq:5
session:6310936469860791894
USER-AGENT:VLC Media Player (LIVE555 streaming media v2005.11.10)
Server response:
rtsp/1.0 OK
Server:userver 0.9.7_rc1
Cseq:5
session:6310936469860791894
Connection:close
The above methods are the most common in the interactive process, and there are some important methods such as get/set_parameter,pause,redirect and so on.

Appendix

format of the SDP

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) 

Reference article: rfc2326 (RTSP); rfc2327 (SDP)
RTSP on-Demand Message Flow instance

(Clients: VLC, RTSP server: LIVE555 Media server) 1) C (client)-M (Media server)

OPTIONS rtsp://192.168.1.109/1.mpg rtsp/1.0
cseq:1
user-agent:vlc Media Player (LIVE555 streaming media v2007.02.20)
1) M-C
rtsp/1.0-OK
cseq:1
date:wed, Feb 07:13:24 GMT
public:options, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

2) C-M

DESCRIBE rtsp://192.168.1.109/1.mpg rtsp/1.0
cseq:2
ACCEPT:APPLICATION/SDP
USER-AGENT:VLC Media Player (LIVE555 streaming Media v2007.02.20)

2) M-C

rtsp/1.0
cseq:2
date:wed, Feb 07:13:25 GMT
content-base:rtsp://192.168.1.109/1.mpg/
CONTENT-TYPE:APPLICATION/SDP
content-length:447
v=0
o =-2284269756 1 in IP4 192.168.1.109
s=mpeg-1 or 2 program Stream, streamed by the LIVE555 media Server
i=1.mpg
t=0 0
a=tool:live555 streaming media v2008. 02.08
a=type:broadcast
a=control:*
a=range:npt=0-66.181
a=x-qt-text-nam:mpeg-1 or program Stream, streamed by the LIVE555 Media Server
a=x-qt-text-inf:1.mpg
m=video 0 RTP/AVP c=in IP4 0.0.0.0
  a=control:track1
m=audio 0 RTP/AVP
c=in IP4 0.0.0.0
A=control:track2

3) C-M

SETUP rtsp://192.168.1.109/1.mpg/track1 rtsp/1.0
cseq:3
TRANSPORT:RTP/AVP; unicast;client_port= 1112-1113
USER-AGENT:VLC Media Player (LIVE555 streaming media v2007.02.20)

3) M-C

rtsp/1.0 OK
cseq:3
date:wed, Feb 07:13:25 GMT
Transport:
rtp/avp;unicast;destination= 192.168.1.222;source=192.168.1.109;client_port=1112-1113;server
_port=6970-6971
Session:3

4) C-M

SETUP rtsp://192.168.1.109/1.mpg/track2 rtsp/1.0
cseq:4
TRANSPORT:RTP/AVP; unicast;client_port=1114-1115
Session:3
USER-AGENT:VLC Media Player (LIVE555 streaming media v2007.02.20)

4) M-C

rtsp/1.0 OK
cseq:4
date:wed, Feb 07:13:25 GMT
Transport:
rtp/avp;unicast;destination= 192.168.1.222;source=192.168.1.109;client_port=1114-1115;server
_port=6972-6973
Session:3

5) C-M

PLAY rtsp://192.168.1.109/1.mpg/rtsp/1.0
cseq:5
session:3
range:npt=0.000-
USER-AGENT:VLC Media Player (LIVE555 streaming Media v2007.02.20)

5) M-C

rtsp/1.0 OK
cseq:5
range:npt=0.000-
session:3
rtp-info:
url=rtsp://192.168.1.109/1.mpg/ TRACK1;SEQ=9200;RTPTIME=214793785,URL=RTSP://192.168.1.109/1.
mpg/track2;seq=12770;rtptime=31721
(Start streaming media ...)