live555 基本框架

最新推荐文章于 2023-06-02 14:17:43 发布

yuzhoudiwang

最新推荐文章于 2023-06-02 14:17:43 发布

阅读量1.9k

点赞数

分类专栏： live555

live555 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

从程序的结构来看，live项目包括了四个基本库、程序入口类（在mediaServer中）和一些测试代码（在testProgs中）。四个基本库是UsageEnvironment，BasicUsageEnvironment、groupsock和liveMedia。

UsageEnvironment包括抽象类UsageEnvironment和抽象类TaskScheduler，这两个类用于事件调度，其中包括实现了对事件的异步读取、对事件句柄的设置及对错误信息的输出等；UsageEnvironment代表了整个系统运行的环境，它提供了错误记录和错误报告的功能，无论哪一个类要输出错误，就需要保存UsageEnvironment的指针．而TaskScheduler则提供了任务调度功能．整个程序的运行发动机就是它，它调度任务，执行任务（任务就是一个函数）．TaskScheduler由于在全局中只有一个，所以保存在了UsageEnvironment中．而所有的类又都保存了UsageEnvironment的指针，所以谁想把自己的任务加入调度中，那是很容易的．在此还看到一个结论：整个live555（服务端）只有一个线程．

class UsageEnvironment {
public:
  void reclaim();

  // task scheduler:
  TaskScheduler& taskScheduler() const {return fScheduler;}

  // result message handling:
  typedef char const* MsgString;
  virtual MsgString getResultMsg() const = 0;

  virtual void setResultMsg(MsgString msg) = 0;
  virtual void setResultMsg(MsgString msg1, MsgString msg2) = 0;
  virtual void setResultMsg(MsgString msg1, MsgString msg2, MsgString msg3) = 0;
  virtual void setResultErrMsg(MsgString msg, int err = 0) = 0;
	// like setResultMsg(), except that an 'errno' message is appended.  (If "err == 0", the "getErrno()" code is used instead.)

  virtual void appendToResultMsg(MsgString msg) = 0;

  virtual void reportBackgroundError() = 0;
	// used to report a (previously set) error message within
	// a background event

  virtual void internalError(); // used to 'handle' a 'should not occur'-type error condition within the library.

  // 'errno'
  virtual int getErrno() const = 0;

  // 'console' output:
  virtual UsageEnvironment& operator<<(char const* str) = 0;
  virtual UsageEnvironment& operator<<(int i) = 0;
  virtual UsageEnvironment& operator<<(unsigned u) = 0;
  virtual UsageEnvironment& operator<<(double d) = 0;
  virtual UsageEnvironment& operator<<(void* p) = 0;

  // a pointer to additional, optional, client-specific state
  void* liveMediaPriv;
  void* groupsockPriv;

protected:
  UsageEnvironment(TaskScheduler& scheduler); // abstract base class
  virtual ~UsageEnvironment(); // we are deleted only by reclaim()

private:
  TaskScheduler& fScheduler;
』

该库中还有一个HashTable，这是一个通用的HashTable，在整个项目中都可以使用它，当然该HashTable也是一个抽象类。

BasicUsageEnvironment中的类主要是对UsageEnvironment中对应类的实现。

groupsock，顾名思义，用于数据包的接收和发送，其同时支持多播和单播。groupsock库中包括了GroupEId、Groupsock、GroupsockHelper、NetAddress、NetInterface等类，其中Groupsock类有两个构造函数，一个是“for a source-independent multicast group”，另一个是“for a source-specific multicast group”；而GroupsockHelper类主要用于读写Socket。Groupsock的构造函数有一个参数是struct in_addr const& groupAddr，在构造函数中首先会调用父类构造函数创建socket对象，然后判断这个地址，若是多播地址，则加入多播组。Groupsock的两个成员变量destRecord* fDests和DirectedNetInterfaceSet fMembers都表示目的地址集和，但我始终看不出DirectedNetInterfaceSet fMembers有什么用，且DirectedNetInterfaceSet是一个没有被继承的虚类，看起来fMembers没有什么用。仅fDesk也够用了，在addDestination()和removeDestination()函数中就是操作fDesk，添加或删除目的地址。

Groupsock::changeDestinationParameters()函数

//改变目的地址的参数
//newDestAddr是新的目的地址
//newDestPort是新的目的端口
//newDestTTL是新的TTL
void Groupsock::changeDestinationParameters(
		struct in_addr const& newDestAddr,
		Port newDestPort,
		int newDestTTL)
{
	if (fDests == NULL)
		return;

	//获取第一个目的地址（此处不是很明白：fDest是一个单向链表，每次添加一个目的地址，
	//都会把它插入到最前目，难道这个函数仅改变最后一个添加的目的地址？）
	struct in_addr destAddr = fDests->fGroupEId.groupAddress();
	if (newDestAddr.s_addr != 0) {
		if (newDestAddr.s_addr != destAddr.s_addr
				&& IsMulticastAddress(newDestAddr.s_addr))
		{
			//如果目的地址是一个多播地址，则离开老的多播组，加入新的多播组。
			socketLeaveGroup(env(), socketNum(), destAddr.s_addr);
			socketJoinGroup(env(), socketNum(), newDestAddr.s_addr);
		}
		destAddr.s_addr = newDestAddr.s_addr;
	}

	portNumBits destPortNum = fDests->fGroupEId.portNum();
	if (newDestPort.num() != 0) {
		if (newDestPort.num() != destPortNum &&
				IsMulticastAddress(destAddr.s_addr))
		{
			//如果端口也不一样，则先更改本身socket的端口
			//（其实是关掉原先的socket的，再以新端口打开一个socket）。
			changePort(newDestPort);
			//然后把新的socket加入到新的多播组。
			// And rejoin the multicast group:
			socketJoinGroup(env(), socketNum(), destAddr.s_addr);
		}
		destPortNum = newDestPort.num();
		fDests->fPort = newDestPort;
	}

	u_int8_t destTTL = ttl();
	if (newDestTTL != ~0)
		destTTL = (u_int8_t) newDestTTL;

	//目标地址的所有信息都在fGroupEId中，所以改变成员fGroupEId。
	fDests->fGroupEId = GroupEId(destAddr, destPortNum, destTTL);
	
	//(看起来这个函数好像只用于改变多播时的地址参数，
	//以上分析是否合理，肯请高人指点)
}

liveMedia是很重要的一个库，其不仅包含了实现RTSP Server的类，还包含了针对不同流媒体类型（如TS流、PS流等）编码的类。在该库中，基类是Medium，层次关系非常清晰。在该库中，有几个很重要的类，如RTSPServer、ServerMediaSession、RTPSink、RTPInterface、FramedSource等。

在http://www.live555.com上的相关文档中提到穿透防火墙的问题，方法是开启一个HTTP的tunnel，然后我们可以在liveMedia库中找到一个RTSPOverHTTPServer的类，该类解决了这样的问题。

mediaServer下的live555MediaServer提供了main函数，DynamicRTSPServer继承了RTSPServer并重写了虚函数lookupServerMediaSession。

鉴于UsageEnvironment库、BasicUsageEnvironment库和groupsock库中的类较少，就暂且不作分析了。这里主要针对liveMedia库中的主要类结构进行分析。通过查看类关系图，可以从整体把握，但是苦于类太多，用类关系图看起来也不方便，于是就自己重新整理了一下，下面是 liveMedia库的主要类结构。（注：其他单类及结构体等不在此列出）

l Medium

n RTSPServer

n RTSPOverHTTPServer

n MediaSession

n ServerMediaSession

n ServerMediaSubsession

u OnDemandServerMediaSubsession

l FileServerMediaSubsession

n ADTSAudioFileServerMediaSubsession

n AMRAudioFileServerMediaSubsession

n H263plusVideoFileServerMediaSubsession

n MP3AudioFileServerMediaSubsession

n MPEG1or2VideoFileServerMediaSubsession

n MPEG2TransportFileServerMediaSubsession

n MPEG4VideoFileServerMediaSubsession

n WAVAudioFileServerMediaSubsession

l MPEG1or2DemuxedServerMediaSubsession

u PassiveServerMediaSubsession

n MediaSource

u FramedSource

l FramedFileSource

n ByteStreamFileSource

n ADTSAudioFileSource

n MP3FileSource

u MP3HTTPSource

l BasicUDPSource

l RTPSource

n MultiFramedRTPSource

u RawQCELPRTPSource

u AC3AudioRTPSource

u MPEG4GenericRTPSource

u RawAMRRTPSource

u H261VideoRTPSource

u H263plusVideoRTPSource

u H264VideoRTPSource

u JPEGVideoRTPSource

u MP3ADURTPSource

u MPEG1or2AudioRTPSource

u MPEG1or2VideoRTPSource

u MPEG4ESVideoRTPSource

u MPEG4GenericRTPSource

u MPEG4LATMAudioRTPSource

u DVVideoRTPSource

u QuickTimeGenericRTPSource

u SimpleRTPSource

l AMRAudioSource

n AMRDeinterleaver

n AMRAudioFileSource

l ByteStreamMultiFileSource

l DeviceSource

l JPEGVideoSource

l MPEG1or2DemuxedElementaryStream

l MPEG2TransportStreamMultiplexor

n MPEG2TransportStreamFromESSource

n MPEG2TransportStreamFromPESSource

l AudioInputDevice

n WAVAudioFileSource

l FramedFilter

n H264FUAFragmenter

n QCELPDeinterleaver

n AC3AudioStreamFramer

n ADUFromMP3Source

n uLawFromPCMAudioSource

n H264VideoStreamFramer

n MP3FromADUSource

u MP3Transcoder

n PCMFromuLawAudioSource

n MPEG2IFrameIndexFromTransportStream

n NetworkFromHostOrder16

n HostFromNetworkOrder16

n MP3ADUinterleaverBase

u MP3ADUinterleaver

u MP3ADUdeinterleaver

n MPEG2TransportStreamFramer

n EndianSwap16

n H263plusVideoStreamFramer

n MPEGVideoStreamFramer

u MPEG1or2VideoStreamFramer

l MPEG1or2VideoStreamDiscreteFramer

u MPEG4VideoStreamFramer

l MPEG4VideoStreamDiscreteFramer

n MPEG1or2AudioStreamFramer

n DVVideoStreamFramer

n MP3ADUTranscoder

n MPEG2TransportStreamTrickModeFilter

n MediaSink

u DummySink

u BasicUDPSink

u RTPSink

l MultiFramedRTPSink

n MPEG4GenericRTPSink

n VideoRTPSink

u H264VideoRTPSink

u MPEG1or2VideoRTPSink

u H263plusVideoRTPSink

u JPEGVideoRTPSink

u DVVideoRTPSink

u MPEG4ESVideoRTPSink

n AudioRTPSink

u AC3AudioRTPSink

u MPEG4LATMAudioRTPSink

u GSMAudioRTPSink

u MPEG1or2AudioRTPSink

u AMRAudioRTPSink

u MP3ADURTPSink

n SimpleRTPSink

u HTTPSink

l MPEG1or2VideoHTTPSink

u FileSink

l AMRAudioFileSink

l H264VideoFileSink

n RTCPInstance

n RTSPClient

n SIPClient

n DarwinInjector

n QuickTimeFileSink

n MPEG1or2Demux

n MPEG2TransportStreamIndexFile

n MPEG1or2FileServerDemux

n AVIFileSink

l BufferedPacketFactory

n QCELPBufferedPacketFactory

n AMRBufferedPacketFactory

n MPEG4GenericBufferedPacketFactory

n ADUBufferedPacketFactory

n QTGenericBufferedPacketFactory

n LATMBufferedPacketFactory

n H264BufferedPacketFactory

n JPEGBufferedPacketFactory

l BufferedPacket

n QCELPBufferedPacket

n AMRBufferedPacket

n MPEG4GenericBufferedPacket

n ADUBufferedPacket

n QTGenericBufferedPacket

n LATMBufferedPacket

n H264BufferedPacket

n JPEGBufferedPacket

l StreamParser

n AC3AudioStreamParser

n MPEGVideoStreamParser

u MPEG1or2VideoStreamParser

u MPEG4VideoStreamParser

n MPEG1or2AudioStreamParser

n H263plusVideoStreamParser

n MPEGProgramStreamParser

从上面这个主要的类结构可以看出，liveMedia库中的基类为Medium，其下又有几个非常重要的部分，一个是×××Subsession，除Medium父类外，所有的×××Subsession类都继承于ServerMediaSubsession；一个是×××Source，MediaSource的frameSource下主要包含FramedFileSource、RTPSource、FramedFilter等几个主要的部分；一个是MediaSink，以继承于RTPSink的类居多。

class H264VideoFileServerMediaSubsession: public FileServerMediaSubsession {
public:
  static H264VideoFileServerMediaSubsession*
  createNew(UsageEnvironment& env, char const* fileName, Boolean reuseFirstSource);

  // Used to implement "getAuxSDPLine()":
  void checkForAuxSDPLine1();
  void afterPlayingDummy1();

protected:
  H264VideoFileServerMediaSubsession(UsageEnvironment& env,
				      char const* fileName, Boolean reuseFirstSource);
      // called only by createNew();
  virtual ~H264VideoFileServerMediaSubsession();

  void setDoneFlag() { fDoneFlag = ~0; }

protected: // redefined virtual functions
  virtual char const* getAuxSDPLine(RTPSink* rtpSink,
				    FramedSource* inputSource);
  virtual FramedSource* createNewStreamSource(unsigned clientSessionId,
					      unsigned& estBitrate);
  virtual RTPSink* createNewRTPSink(Groupsock* rtpGroupsock,
                                    unsigned char rtpPayloadTypeIfDynamic,
				    FramedSource* inputSource);

private:
  char* fAuxSDPLine;
  char fDoneFlag; // used when setting up "fAuxSDPLine"
  RTPSink* fDummyRTPSink; // ditto
};

#endif

此外，还包含了用于处理packet的BufferedPacketFactory和BufferedPacket及其相关子类，用于处理流分析的StreamParser及其子类。

基本上，整个liveMedia库的主要类结构就是这样。不过，类太多了，分析起来还是有较大的困难。于是乎，采取去掉枝叶保留主干的做法，将整个服务器精简成支持一种格式的服务器，如MP3流服务器。经过分离，一个基于MP3的测试服务器的主要类结构如下所示。（注：其他单类及结构体等不在此列出）

l Medium

n RTSPServer

n MediaSession

n ServerMediaSession

n ServerMediaSubsession

u OnDemandServerMediaSubsession

l FileServerMediaSubsession

n MP3AudioFileServerMediaSubsession

n MediaSource

u FramedSource

l FramedFileSource

n MP3FileSource

u MP3HTTPSource

l BasicUDPSource

l RTPSource

n MultiFramedRTPSource

u MP3ADURTPSource

u MPEG1or2AudioRTPSource

u SimpleRTPSource

l FramedFilter

n ADUFromMP3Source

n MP3FromADUSource

u MP3Transcoder

n MP3ADUinterleaverBase

u MP3ADUinterleaver

u MP3ADUdeinterleaver

n MP3ADUTranscoder

n MediaSink

u BasicUDPSink

u RTPSink

l MultiFramedRTPSink

n AudioRTPSink

u MPEG1or2AudioRTPSink

u MP3ADURTPSink

n RTCPInstance

l BufferedPacketFactory

n ADUBufferedPacketFactory

l BufferedPacket

n ADUBufferedPacket

根据上面这种相对简单的类结构，分析起来就方便多了。于是，开始进入具体的分析细节了，这是一个相对漫长的过程，再加上本人的C++水平有限，这又将是一个相对艰苦的过程，一切慢慢来吧……

末了，讲讲启动服务器的过程：

LIVE555是一个纯粹的RTSP服务器，其服务器主类为liveMedia库下的RTSPServer；mediaServer下的live555MediaServer为主程序的入口类，DynamicRTSPServer是RTSPServer的实现类。

从live555MediaServer类的入口函数main中可以非常清晰地分析出服务器的启动过程。

首先是createNew一个TaskSchedulers对象和一个UsageEnvironment对象，这是初始工作。

之后是一段访问控制的代码。然后开始进入创建RTSP服务器的代码段，服务器指定了一个默认端口554和一个可供替代的端口8554。

接下来，createNew一个DynamicRTSPServer，这里建立了Socket(ourSocket)在TCP的554端口（默认端口）进行监听，然后把连接处理函数句柄和socket句柄传给任务调度器(即taskScheduler)，既是RTSPServer类中的这句代码：env.taskScheduler().turnOnBackgroundReadHandling(fServerSocket, (TaskScheduler::BackgroundHandlerProc*)&incomingConnectionHandler,this)。紧接着就是对socket句柄和incomingConnectionHandler句柄的处理，主要是进行关联等。

最后，进入主循环（即env->taskScheduler().doEventLoop();），等待客户端连接。服务器启动完毕。

文章的最后，需要说明的是，在编译运行的过程中，我是使用VLC播放器来进行测试的，同时通过使用Ethereal的网络分析工具抓包分析其建立到传输的过程，虽然在live555源代码中关于RTSP建立及收发数据包的过程已经用代码写得非常清楚（这个好好分析一下源码就可以了），但我想，学习使用一下一些网络分析工具对自身也是颇为有益的。

yuzhoudiwang

关注

0
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
live555 基本框架

从程序的结构来看，live项目包括了四个基本库、程序入口类（在mediaServer中）和一些测试代码（在testProgs中）。四个基本库是UsageEnvironment，BasicUsageEnvironment、groupsock和liveMedia。UsageEnvironment包括抽象类UsageEnvironment和抽象类TaskScheduler，这两个类用于事件调度，其中
复制链接

扫一扫