【视频开发】RTSP SERVER（基于live555）详细设计

具体做法：在live555文件夹下新建文件夹liveLib用于存放其它文件生成的.a. 此文件夹用于生成live555.a最终库。（将所有.a先打散成.o，再合成一个live555.a）.每个文件夹下在生成.a时都拷贝一份.a到liveLib中。最后将生成的live555.a拷贝到master\LIB\ARM\SN6108中。可执行程序链接时在此文件夹下可找到live555.a。

2.功能添加

Live555源码的功能要用到我司具体项目中还需做一定的修改，不是拿来就能用的。

原本对于开源项目，尤其是c++项目，最好不要改动原有的类，所以修改应该是继承父类，在子类中修改。这样有利于代码的升级，和维护。但是由于考虑到c++的继承的层数以及虚函数的运行时绑定对性能的影响，以及编译出文件的大小，所以本修改中只对一部分类作了继承，另一些直接在原有类中添加新方法。

2.1 数据的输入

数据从ringbuffer到server模块的传输，使用了通知机制，即当ringbuf有数据时，数据发出通道，告知某一通道有数据可用，则server在需要的时候会来这个通道来取数据。

数据输入框图

通知机制主要由以下函数实现。

void signalNewFrameData(int mediaType, int chanel,int trans_mode,int buf_len)

signalNewFrameData为一个全局函数，可被外部线程调用（注意，整个live555是一个单线程程序）。signalnewFrameData会调用virtual void triggerEvent(EventTriggerId eventTriggerId, void*clientData = NULL), 这个函数共两个参数，一个是触发的事件id,另一个是此id对应的事件处理函数所在的类实例指针，这里具体是各个输入的videoSource和audioSource类实例指针。

数据的写入ringbuffer由以下函数实现:

在write_unicast_data_live里(只用于单播)，每当一个数据到来后，先判断是音频还是视频，然后再装入各自对应的ringbuffer，接着调用 signalnewFrameData通知相应的server. 通知时刻落在server刚好需要数据的时刻区间间的概率较小，大部分情况是(经实验证明了的)：server正在处理其它数据; 或已经取完数据，正在等下次取数据时刻的到来(此时可能正停留在Eventloop 里的sigleStep的select中)。所以通知后都会把事件记入一个bitmask类型的变量fTriggersAwaitingHandling(最多可累计挂入32个待处理事件)中, 然后在select结束后，再处理每个TriggerNum所对应的事件（调用Source中的deliverFrame将数据向后传送）。处理完一个事件，则将fTriggersAwaitingHandling中对应的bitmask位清0,singleStep每一次循环中TriggerEvent只处理一个事件(如有未处理完事件，等下一循环再处理)。

2.2实时视频（H264）的输入和输出

Live555提供的示例里面有直接读文件的类和使用方法，但没有实时输入的类及其实现。

Live555中数据流基本路线是：

SourceàFilter1àFilter2…àSink

Filter可能有多个，也可能一个也没有。对于h264，filter有两个，对于音频g711.a，实现中则没有Filter.

本设计具体实现视频实时输入方法如下：

1.视频输入

在live555中，输入为Source类，输出为 Sink类。中间处理环节类称为Filter.

SNDeviceSource类继承于FramedSource,用于实时输入h264视频。该类的实现参考了DeviceSource。

在SNDeviceSource::deliverFrame()中实现数据的输入。Memmove 将数据拷贝到fTo.(最后优化后已经改为传指针了，没有了内存拷贝).

2 .Filter

对于H264视频Source不是直接到Sink, 而是经过如下：

SNDeviceSourceàH264VideoStreamDiscreteFrameràH264FUAFragmenteràH264VideoRTPSink

中间两个类称为Filter,是对视频数据的进一步处理。

H264VideoStreamDiscreteFramer继承于H264VideoStreamFramer, H264VideoStreamFramer主要是提取sps, pps。H264VideoStreamDiscreteFramer 主要是用于输入离散的NAL单元，H264FUAFragmenter主要是对H264nal进行分片打包，根据rfc3984中FU-A规则进行分片打包。

3 .视频输出

H264VideoRTPSink为原有类, 实现了h264 rtp包的输出.

视频的打包和发送操作都在H264VideoRTPSink的父类multiFramedRTPSink中.其打包发送的流程如下：

sendNextàbuildandSendPacketàpackFrameàgetnextFrameà…àafterGettingFrameàsendPacketIfnessaryàscheduleDelayedTask àsendNextà。。。

buildandSendPacket会将rtp包头打好（timestamps and sequence num先预留，等取到帧数据后再填充）。

packFrame即将帧数据往rtp包头后面挂。所以其任务就是要取得帧数据，所以调用getnextFrame来从上一游来获取帧数据。对于h264来说，它的上一级由2.12可看出是H264FUAFragmenter, 这个类会将帧数据分好片(<1448字节), 交给multiFramedRTP Sink。好，获取到帧数据后，就是afterGettingFrame了，这里面主要做一些检查工作（检查数据是否正确，buffer是否溢出等各种检查）和补充工作（填充前面所说的timestamps和rtp sequence number）。之后便是sendPakcetIfnessary, 这里面会使用tcp或udp将数据发送出去。发送完后，需将下一次任务准备一下，即调用scheduleDelayedTask将sendNext放入延迟队列中，等待其在singleStep中被调用，再开始下一次发包过程。

提示下，tiemstamps和sequence num是在doSpecialFrameHandling中做的，这是个虚函数，其具体实现在H264VideoRTPSink中实现。

上面说到: H264FUAFragmenter, 这个类会将帧数据分好片(<1448字节), 交给multiFramedRTP Sink。但是它的数据是从哪来的。其所套路一样，它也是通过getNextFrame从它的上游获H264VideoStreamDiscreteFramer取的，而H264VideoStreamDiscreteFramer又是通过getNextFrame从它的上游SNDeviceSource来获取。形式有些多余，效率上会打折，但有很明显的组件思想，这种设计，典型 c++思想，有利于扩展，像堆积木一样，可堆出更多的功能。当然对于我们只使用其中h264和音频功能来说，这样设计框架有些多余。

2.3实时音频（G711.a）的输入和输出

1、输入

SNAudioDeviceSource继承于DeviceSource.用于音频输入。类似于视频输入，也是能过DeliverFrame（）将数据向后传输的。

2、输出

SNG711RTPSink继承于SimpleRTPSink，用于音频rtp包的输出。

simpleRTPSink只用于简单的发包处理，不进行分片，聚合等操作，而我司g711.a音频包大小为320bytes,符合简单打包的条件。

音频流程中没有Filter，直接是：

SNAudioDeviceSourceàSimpleRTPSinkàMultiFramedRTPSink

和视频一样的取数据发送方法，只是环节更少，G711.a音频不需要分片，以及PPS,SPS等提取。MultiFramedRTPSink中的getNextFrame直接从SNAudioDeviceSource中取得帧数据。

2.4 H264视频离散nal单元输入的实现

Live555的H264数据的输入有两种方式，一种所谓ByteStream,读文件时采用的主是这种方式，每次读入的不是整数个帧，这些数据还要被解析成独立的帧数据才能进一步操作，这种方法使用的filter是H264VideoStreamFramer,它利用H264VideoStreamParser :: parse()从读入的数据中解析出一个个nal单元。另一种是所谓DiscreteFramer，即输入是一帧帧离散的 nal单元，这就省去了再解析的环节。

对于本公司的数据格式来说，是介于这两种之间。因为对于p帧本司是一个个离散的nal单元，但对于I帧来说，则是四个nal单元（pps,sps,sei,I）拼起来作为一个整体进行输入的。这种不“纯粹性”导致只能把每个输入都当成byteStream，显然对于p帧来说，多余了。

所以，设计将I帧解析成单独的NAL单元后再进行输入，这样所有的输入都是离散的NAL单元，即可以使用DiscreteFramer方式进行输入了。

设计SNGetNextNalU函数用来实现对I 帧数据的解析。如果不是视频I帧，则直接通过deliverframe将数据向后传，如果是I帧，则要先从中解析出单独的NAL单元，再通过deliverFrame向后传。

2.5单播的实现

Live555具有单播和多播功能，将单播具体应用到我司环境中，如下：

需继承OnDemandServerMediaSubsession类，重写与自己特定source相关的OnDemandServerMediaSubsession子类。本设计中

class SNG711OnDemandServerMediaSubsession:public OnDemandServerMediaSubsession

classSNH264OnDemandServerMediaSubsession:public OnDemandServerMediaSubsession

其中G711*类用于输入音频子会话，H264对应视频子会话。

其中最主要的是需重写createNewStreamSource 和createNewRTPSink这两个虚函数，使*subsession将source和sink关联起来。Soure类和Sink类的实例化就是在这两个函数调用时创建的。

SNH264OnDemandServerMediaSubsession可参考H264VideoFileOnDemandServer MediaSubsession来实现。

SNG711OnDemandServerMediaSubsession有些特别。参考实现文件是WAVAudioFile ServerMediaSubsession.其中音频的位宽（8或16）和编码方式（a law或u law）都会影响到具体实现方法。所以这些参数一定要提前确定好。Ps:之前由于参数认识错误，导致改了很久还是错的。

2.6多路连接的实现

从单路到多路的实现，主要是将一个输入流输出流改为多个。

多路输入输出图

在SNonDemandRTSPServer（相当于本线程的main函数）中，用数组来实现多个ServerMediaSessin，再向每个servermdiaSesson添加各自的subsession （视频：SNH264OnDemandServerMediaSubsession,音频：SNG711OnDemandServerMediaSub session)，每个subsession 会管理属于自己的source和sink。

另外，还有一个需注意的是输入的事件通知也要改成多个通道的通知。

多路连接的示意图如下：

多路输入事件的触发有两种方式：

方法1:

使用多个triggerEventId来代表每一路的音/视频输入，本设计使用了这种方法。

但这种法有局限性。即通道数的限制。Live555使用一个32位的bitMask来代表每一个EventTriggerId, 也就是说最多可使用32 tirggerId, 本设计为8通道，每路音视频各需一个triggerId,所以共要8*2=16个id. 如果通道数超过16路，按这种方法则有问题。当然也可以将bitMask改成64位的，应该可以解决此问题。

方法2:官方推荐

只用一个eventTriggerId,所有通道数据到达事件用各个voidSNDeviceSource::deliverFrame0(void* clientData)的clientData来区分。

这种该去方法在应用中出现问题：数据输入缓慢。初步分析是因为使用了虚函数，而像数据输入这种很频繁的操作，如果每次都要通过查虚函数表来确定具体运行哪个函数的话，就会耗费不少时间，导致输入缓慢，ringbuffer总是满。当然也可能是我方法不对头，后续开发者应该可能会想到其它更好的实现方法。

多路连接类关系示意图

通道数由宏CHANNEL_NUM_LIVE来设置。

2.7最大连接数的限制

本设计为8通道rtspserver，为避免server上连接上超过八路的客户端，对平均每路性能造成影响，需对最大连接数做限制。

先要知道一个server拥有的client在代码中对应的是RTSPClientSession类。每一连接对应一个rtspClientSession实例。而这个实例由RTSPServer::createNewClientSession函数产生。所以应当限制作其产生的实例个数不超过8个。

设计：在rtspServer类中添加私有成员变量fNumConnectedClients。在每次调用RTSPServer::createNewClientSession后fNumConnectedClients值做相应的增加。当计数达到8时，在createNewClientSession中直接反回，而不产生rtspClientSession实例。

最大连接数可通过SN_CLIENT_LIMIT来设置。

2.8服务端主动断开连接的实现

Server端断开某一通道连接的正常过程一般是：

Client请求断开（teardown）àServer响应请求，关闭相应资源à断开连接

半闭资源时，最重要的是关闭顺序要对，而且要关闭完全，否则会造成崩溃或内存泄露。如果要找到每一个资源的关闭地方，自己再写一个函数内，按正确的时间和顺序去关闭难度较大，容易出错。

一个简单的办法是，只能能从服务器端触发client的tearDown请求，则剩下的关闭流程会自动走完,这样做也较安全,本设计用的就是此法。服务器里的rtcp “BYE” packet可以实现此功能。流程是：

Server发送rtcp”BYE”àClient（teardown）àServer关闭相应资源à断开连接

void DSND_DisConnect(intchn)实现了这个功能。

2.9 sdp信息的添加修改

Sdp为session descript的缩写，会话描述息。是流媒体在会话开始时交互信息的一种方式。一般流媒体使用的都是sdp格式来描述。

Live555的sdp信息由char* ServerMediaSession::generateSDPDescription()生成。此函数先生成session级别的sdp信息，如“v=…,o=…,s=…”，然后再补充subsession级别的sdp信息，如“a=fmtp:。。。，a=rtpmap:。。。”.subsession级别的sdp信息填充是在各个rtpSink中实现的。如H264的char* H264VideoRTPSink::rtpmapLine(),和char const*H264VideoRTPSink::auxSDPLine().

需注意的是subSession级别SDP信息，一般是由rtp/avptype来确定的。

当0=<type<96时，一个号码确定唯一的编码及rtpmap参数，也就是说这种情况下，参数是死的，只能按国际标准来，自己不能随便改（当然你非要改成自己想像的那种形式或参数，也可以，只是别人识别不了你时，就麻烦了）。

当type>=96时，属于动态范围，号码和参数内容允许不同的公司有不同的参数。H264一般取这个范围的起始数字96,当然你要改为97也没人拦你。

对于我们的音频编码类型G711.a即pcma类型，其type在rtp/avp 里规定为8.所以它的采样率，编码率，你不能随便改。

如果非要添加音频sdp非标准化信息到sdp中（命令如山倒，做吧，不管合不合理），可在voidOnDemandServerMediaSubsession::setSDPLinesFromRTPSink中先进行音频/视频的判断，当判断出音频时，填充auxSDPLine字符串，内容便是你想要添加的sdp内容。

关于在OnDemandServerMediaSubsession中进行音视频的判断方法，可通过在Source中设计一个虚函数实现，在运行时，再根据绑定的实例判断出是音频Source 还是视频Source,。本设计中使用sourceType()来实现。

RTP/AVP types可参考下面网址：

http://en.wikipedia.org/wiki/RTP_audio_video_profile#RTP.2FAVP_audio_and_video_payload_types

2.10重定向的实现

为了减轻服务器的压力，有时需将数据重定向到其它服务器，如IPC。

重定向功能是rtsp 协议里的内容，但在live555里并没有实现，所以只能自己实现。

实现函数void getOneRedirectUrl(char*dst,const int chid,const int streamType)来对某一通道的请求进行URL重定向，即在RTSP 信令走到DISCRIBE命令时，服务器返回一个重定向后的url, 并结束此次会话。客户端只需连接到新的url即可。

voidRTSPServer::RTSPClientSession::handleRequestBytes(int newBytesRead) 中当收到DESCRIBE请求时，先返回一个错误码

RTSP/1.0 305 UseProxy
再调用getOneRedirectUrl来获取一个指定的url, 在发送了返回码之后，再发送此url.

客户端需在此后发送TEARDWON来结束此次会话。

3. 代码裁剪

1、媒体转发功能下的裁剪：

裁剪后为150多个文件。

Live555代码原有360个以上的文件，里面有各种我们用不到的媒体类型的流媒体实现，如aac,mpeg1,mepg2,mp3,mkv等，我们只需要其中的H264 和有关简单音频的实现方法。所以需对源码进行裁剪。

首先删除明显用不到的媒体类型文件。

liveMedia文件夹：

删除以下列字母开头的文件：AAC, AC3, ADT, AMR, DV，GSM, H261, H263, JPEG, Matroska, MP3 ,MPEG1or2, MPEG2,MPEG4ES,QuickTime, Sip, T140text, vob, Vorbis, VP8, WAV, 以及各种文件各中带有*file*的文件（因为我们这是实时流媒体，用不着file）。

然后在Boolean MediaSubsession::createSourceObjects(intuseSpecialRTPoffset) 中做如下修改：这个函数中包含了各种媒体类型，我们将除H264和pcma类外的代码内容都删除，否则会编译不过。

Source文件夹（testProgs改名）：

保留：SNOnDemandRTSPServer用于server，playCommon，testRTSPClient(这两个用于client), 和Makefile。除此外，其它全部删除。

其它文件夹下不作修改。

再修改Makefile。Makefile中将对应已经删除的媒体对应的语句删除，同时将每个makfile中的文件依赖删除。如：

Media.$(CPP): include/Media.hh

include/Media.hh: include/liveMedia_version.hh删除掉也不影响。

2、仅保留重定向功能的裁剪

相对于具有媒体转发功能下的裁剪进一步做了以下裁剪：

删除所有媒体相关的文件。

liveMedia文件夹：删除以下文件

MPEGVideoStreamFramer.$(OBJ)MPEG4VideoStreamFramer.$(OBJ) MPEG4VideoStreamDiscreteFramer.$(OBJ)H264VideoStreamFramer.$(OBJ) H264VideoStreamDiscreteFramer.$(OBJ)MPEGVideoStreamParser.$(OBJ)

H264VideoRTPSink.$(OBJ)

FramedFilter.$(OBJ) BasicUDPSource.$(OBJ) $(MPEG_SOURCE_OBJS) SNDeviceSource.$(OBJ)SNAudioDeviceSource.$(OBJ)

BasicUDPSink.$(OBJ) $(H264_SINK_OBJS) SimpleRTPSink.$(OBJ) SNG711RTPSink.$(OBJ)

MultiFramedRTPSink.$(OBJ) VideoRTPSink.$(OBJ)

OnDemandServerMediaSubsession.$(OBJ)SNH264OnDemandServerMediaSubsession.$(OBJ)SNG711OnDemandServerMediaSubsession.$(OBJ)

BitVector.$(OBJ) StreamParser.$(OBJ)

其它文件夹保持不变。

4. 效率优化

刚添加完功能时, 一路跑起来的cpu利用率为5~6%

优化完之后的CPU利用率，一路为4%左右。8路D1全开时为：

//最终性能 8路全开udp

PIDUSER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

1175root 20 0 65712 23m 3112 R 29.0 34.5 285:13.05 dvrapp_SN6108

//最终性能 8路全开tcp

PIDUSER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

1175root 20 0 65612 23m 3112 R 31.0 34.4 289:03.86 dvrapp_SN6108

主要做了以下两点的优化:

4.1Ring buffer双队列的修改

先了解下背景：

基于live555的数据输入模型是”拉”模式，即server需要发送什么数据时，server再去索取，对于server（假定他是一个人），他关注的是sendPacket,sendnextPacket, sendnextnext Packet…., 其它所有的过程如取数据，打RTP包等都是sendPacket的辅助过程。所以数据的应该是以输出为主导而不是输入。

对于Ringbuf而言，当server是输入（对于server而言，ringbuf是server外的模块）主导模式时，我Rinbuf可以来一个帧，我要求你server发一个帧。

当server是输出主导时，我不管你ringbuf有没有来帧，当我server需发送数据时，再向你rinbuf要，你ringbuf给我塞，我只会暂时记下，但并不取数据，一直等到需要时再取。

我们的rinbuffer 是单队列模式，即音频视频混合在一个队列中。

个人分析（可能不对，后来者可做参考），当单队列rinbuffer与live555配合时，存在这种情况:当server需要视频数据时，去队列里取时，而队列尾部恰好是个音频数据，这会导致此番数据取不到，而取数据之前，此rtp包的包头已经打好，就只等帧数据到来后就可发送。但因没有取到，等吧。。。等到延迟队列触发了下一次sendNextPacket后，RTP包头会重新打，因为这次要发的是另外一帧数据，所以上次只打了包头而没有发送的数据便被覆盖了，没有发。。丢包。。。费时。.反之亦然。

改：改成音视频分开的双队列，保证每次去取时，都进入各自的媒体队列，只有队列里有数据，就一定会取到，而不会出现要音频确碰见视频帧，要视频确碰到音频的情况。

先说一下改动后的结果：本来是冲着减小cpu占用率去的，但没什么效果。然而性能上有一个改观就是：基本上不会发生队列满的情况。队列不满，在发送前便不会丢包（试验结果:八路全开，udp, 跑了两天，没有出现过一次ringbuf满的情况）。

单队列改双队列的基本队列的存取逻辑还和单队列一样，只是来一个数据时，先判音视频，再分别送入各自的队列。双队列rinbuffer如下图所示:

主要的逻辑不同处在于，队列满时，该怎么判断，怎么处理。因为有2个队列，便有以下4种情况：

a .Video full, audio not full

b. video full, audio full

c. video not full, audio full

d. video not full, audio not full

首先确立video主导地位，即videofull时,情况a,b ，清空所有队列，不管audio 是否full.

情况d为正常情况。

情况c , audio不做清空，video不做清空。为添加新结点，Audio队列需删除最后（最old）一个结点，再添加新结点。

情况以c发生的概率较小，因为音频很小，很快就发送完毕业，而大概率的事件应该是视频满，因为视频节点数据大，发送比较费时。（然而这2种满的情况都还没有碰到过）.

4.2内存拷贝的去除及socket writev 的实现

为了减小cpu利用率，内存拷贝，首当其冲被想到要被去掉。

Live555中至少有一次内存拷贝，对于H264来说有两次，对于g711.a来说有一次。

一次内存都不要则要用socketwirtev函数来将分散的各个内存块发送出去。

首先定义3个结构体：

typedef struct _ptr{

unsigned char* nalBufStart;

unsigned char* qBufDataPtr;

int theLastNalu;//1(is the last).or 0(notthe last) , becase SN capasulate 4 nal in one Frame called I framed, free mustafter all 4 nal have passed

}BufPtr;

typedef struct _VecPtr{

unsigned char* firstPtr;

unsigned char* secndPtr;

unsigned char* qBufDataPtr;

int firstSize;//will be 2 or 0

int secndSize;

int theLastNaluOrFrame;

int theLastPacketOfOneFrame;

}VecPtr;

typedef struct{

unsigned char* bufStart;

unsigned curOffset;

unsigned TotSize;

unsigned type;

}BufferType;

BufPtr用于从Source：：DeliverFrame中进行指针的赋值.

VecPtr fFrameData定义在multFramedRTPSink中，用于存放wirtev所需的参数指针。

BufferType用于h264视频分片打包时的数据指针存储。

1、视频流程的修改

H264视频传输经过的类如下：

SNDeviceSourceàH264videoDiscreteFrameràH264FUAFragmentàH264VideoRTPSinkà MuitiFramedRTPSink

要把数据流经路线上的所有类中有关数据的操作都操作掉，利用传指针。

BufferTypefNalu;

BufPtr fBufptr;

以上两个变量定义在H264FuaFragment中，fBufptr从前方 Source中获取数据指针（指向ringbuffer中的数据）。fNalu用于记录nal单元在分片打包时，各分片的指针状态。

各个类中的修改如下：

SNDeviceSource：：

修改deliverFrame, 去除内存拷贝，给传入的指针赋值，此时的fTo即传入的结构体指针fBufptr。

H264videoDiscreteFramer：：

修改afterGettingFrame1,需将sps, pps 拷贝下来，以备后用，这个类中的指针也要做相应的修改。

H264FUAFragment：：

1.afterGettingFrame1对fNalu进行赋值。

2.修改doGetnextFrame, 将各个分片内存拷贝取消。并将指针传向后面流程（multframedRTPSink）

3.重写构造函数，对FinputBufSize做修改，改成2bytes, 只用来存放分片头和分片指示单元。关于这个可参考rfc3984 fua 分片打包规则。

MultiFramedRTPSink：：

1,afterGettingFrame1中对fVecBuf[3~5]进行填充。fVecbuf[3]指向RTP包头，fVecbuf[4]指向分片头或分片对+分片指示单元，fVecbuf[5]指向除分片和指示单元外的帧数据部分。

fVecbuf[0~2], 用来存入TCP方式发送时的三块头字节。

关于wirtev这里说一下，fVecbuf[i]可能NULL,这时，writev会动跳过，接着发fVecbuf[i+1], 因此设6块vecbuf, 并不意味着6块内存一定要都有数据。

2.void MultiFramedRTPSink::sendPacketIfNecessary()：

修改fRTPInterface.sendPacket。

RTPInterface：：

1.重载BooleanRTPInterface::sendPacket(struct iovec *vecBuf,int vecCnt,unsigned packetSize)

2. 添加函数Boolean sendRTPOverTCP2(structiovec *vecBuf, int vecCnt,unsigned packetSize, int socketNum, unsigned charstreamChannelId)

此时实现了视频的TCP 方式下的writev操作。

经测试，性能未见明显提升，悲剧。。。

2、音频流程的修改

音频相对较简单。其数据流程如下：

SNAudioDeviceSourceà SNG711RTPSinkàMuitiFramedRTPSink

SNAudioDeviceSource:

修改deliverFrame, 对传入VecPtr（fTo）赋值。

MuitiFramedRTPSink：

afterGettingFrame1中对fVecBuf[3~5]进行填充。

3、 UDP的sendto与tcp witev混合实现。

因为udp 使用writev时，会先进行connect，而《unix网络编程》中关于udp 使用connect方法指出，它只能与一个对端进行数据报的交互，所以当UDP使用了WIRTEV后，对于某一个特定的通道，它只能有一个客户端，当有多个客户端去连接此通道时，只有最后一个连接能成功，前面的即使刚开始成功，也会被后连接的客户端给挤掉。

权衡考虑，决定tcp 用writev, udp仍用sendto.

其实这个有个简单的方法就是将writev参数里的各个vecBuf[i] 里的数据再拷贝到一整块内存中，然后再sendto发送。本设计即用这种方法实现。也就是说，UDP最终还是用了一次内存拷贝。

在UDP改动中，需做以下修改：

1.添加 BooleanwriteSocket2(UsageEnvironment& env,

int socket, struct in_addr address, Portport,

u_int8_t ttlArg,

struct iovec *vecBuf, int vecCnt,unsignedbufferSize)

2.重载Boolean OutputSocket::write

3.重载Boolean Groupsock::output

4、 FREE_BUF的调用

当指针指向的数据使用完之后应调用FREE_BUF来减小数据节点的引用计数。

两个判断是否该FREE_BUF：

a.是否是最后一个RTP包发掉了（一个视频帧节点可分多个RTP包来发送）。用FrameData.theLastPacketOfOneFrame==1判断。

b.是否是最后节点的最后一部分。对于视频P帧和音频帧，一帧永远是节点的最后一部分，因为节点只有这一个帧。而对于我司H264视频来说，key frame节点里面包含了sps,pps,sei,I 4个NAL单元，所以对于这个节点，一帧发完了仍然不能free这个节点，而要到这4个帧都发完了才能free此节点。用fFrameData.theLastNaluOrFrame== 1判断。

5.部分函数说明：

void write_unicast_data_live(int chid, unsigned char *data, int datalen, unsignedchar *header, int StreamIdx)

功能：

将数据写入ringbuffer. 只用于单播放.

参数：

Chid:数据来源通道

Data:QBUFFER_DATA类型的数据指针

Datalen:数据的长度

Header:ringbuffer结点头，用来保存该节点的某些信息，如：video or audio,I or p frame

StreamIdx:没有用到

返回值：无

void signalNewFrameData(int mediaType, int chanel, inttrans_mode,int buf_len)

功能:

通知某一通道数据可用。

参数：

mediaType：媒体类型，VIDEO_LIVE 或 AUDIO_LIVE

chanel: 通道号 1~8

trans_mode: 单播或多播。UNICAT_LIVE或MULTICAST_LIVE

buf_len: 当前ringbuf的长度，这个参数用处不大。

返回值：无

SNDeviceSource::SNGetNextNalU(unsigned&lenNal,unsigned char &type)

功能:

查找出一个NALu, 从我司的I frame中。需配合IFrameStatus结构体使用。

参数：

lenNal: 用来保存找到的NAL单元的长度,包括startcode

type: 查找到的NALU的类型

返回值:

0 已经找到下一个startCode 00000001

1 没有找到下一个startCode（这是这一块中的最后一个nal单元）

-1 错误，解析对象不正确，非我司I帧.

void DSND_DisConnect(int chn)

功能:

断开某一通道(1~max)的连接.包播放已经建立在此通道上的所有连接（一个通道连接了八路客户端也是有可能的）。

参数:

Chn,通道号，url中指定的那个通道号

返回值:

无.

注意:

一个通道对应一个ServermediaSession实例。

一个连接对应一个RTSPClientSession实例。

一个session包含有2个subsession,一个音频，一个视频。在关闭时要都关闭掉。

int FramedSource::sourceType()父类

int SNDeviceSource::sourceType()视频子类

int SNAudioDeviceSource::sourceType()音频子类

功能：

返回此实例的种类。用于父子类，兄弟类之间的身份确认。

返回值：在SNDeviceSource中返回VIDEO_LIVE

在SNAudioDeviceSource中返回AUDIO_LIVE

在FramedSource中返回0

注意：运行时任何一个FramedSource类型的对象调用sourceType便可知道它是哪个实例。

void getOneRedirectUrl(char *dst,const int chid,const intstreamType)

功能：

获取一个重定向URL, 将dst指针指向新的url.

参数:

dst:目标URL指针

chid：通道号 1~8

streamType:MAINSTREAM 或SUBSTREAM

返回值：无

6. 部分实验结果

cpu and memory rate:

测试环境：SN6000 D1

以下为 top �p pid的显示结果

//两次内存拷贝省去, TCP writev

tcp writev 1channel connected

1167 root 20 0 65552 23m 3092 R 5.7 34.3 0:32.48 dvrapp_SN6108

tcp writev 4channel connected

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

1167 root 20 0 66944 24m 3096 R 22.3 36.3 4:49.36 dvrapp_SN6108

//两次内存拷贝省去, UDP writev(只支持单客户端连接)

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

1167 root 20 0 65272 22m 3128 R 4.3 33.9 1:22.50 dvrapp_SN6108

//udp sendto, 由iovec 数组再合成一个完整的内存区域供udp sendto使用

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

1167 root 20 0 64900 22m 3124 R 4.3 33.4 0:13.06dvrapp_SN6108

//媒体走通后, 信号量阻塞方式。

Tcp writev ,1channle connected

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

1193 root 20 0 65008 22m 3092 S 5.0 33.5 0:08.13dvrapp_SN6108

//改双队列后开1通道 UDP

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

1175 root 20 0 65900 23m 3120 R 4.3 34.8 0:03.82 dvrapp_SN6108

//改双队列后 8通道全开 UDP

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

1201 root 20 0 64576 22m 3144 R 29.7 32.9 0:48.49 dvrapp_SN6108

//改双队列后 8通道全开 TCP

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

1175 root 20 0 66252 23m 3120 R 32.3 35.3 0:53.46 dvrapp_SN6108

//改双队列后开1通道 TCP

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

1175 root 20 0 64084 21m 3120 R 4.0 32.2 1:14.59dvrapp_SN6108

//4路UDP,去掉SNservermediaSession SNh264videortpsink snrtspserversnrtspclientsession

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

1175 root 20 0 63464 21m 3092 R 13.7 31.3 0:30.24 dvrapp_SN6108

//最终性能 8路全开udp

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

1175 root 20 0 65712 23m 3112 R 29.0 34.5 285:13.05dvrapp_SN6108

// 最终性能 8路全开tcp

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

1175 root 20 0 65612 23m 3112 R 31.0 34.4 289:03.86 dvrapp_SN6108

posted @ 2017-08-01 12:32 ZhangPYi 阅读(1302) 评论(0) 编辑收藏举报

刷新页面返回顶部

青春的纪念

【视频开发】RTSP SERVER（基于live555）详细设计

1.代码移植

1.1代码获取

1.2文件初步裁剪

1.3修改Makefile

1.4将live555生成的静态库链接到我司的可执行程序中

2.功能添加

2.1 数据的输入

2.2实时视频（H264）的输入和输出

2.3实时音频（G711.a）的输入和输出

2.4 H264视频离散nal单元输入的实现

2.5单播的实现

2.6多路连接的实现

2.7最大连接数的限制

2.8服务端主动断开连接的实现

2.9 sdp信息的添加修改

2.10重定向的实现

3. 代码裁剪

4. 效率优化

4.1Ring buffer双队列的修改

4.2内存拷贝的去除及socket writev 的实现

5.部分函数说明：

6. 部分实验结果

公告