live5 数据发送及封装

1. live 555 数据发送流程

每一行类及重要函数

SPServer::RTSPClientSession::handleCmd_PLAY ->subsession->startStream
OnDemandServerMediaSubsession::startStream->->streamState->startPlaying
StreamState::startPlaying->fRTPSink->startPlaying
MediaSink::startPlaying->continuePlaying()
H264or5VideoRTPSink::continuePlaying()
MultiFramedRTPSink::continuePlaying()->buildAndSendPacket->RTP封装h264数据
MultiFramedRTPSink::buildAndSendPacket->packFrame()
MultiFramedRTPSink::packFrame()->fSource->getNextFrame
FramedSource::getNextFrame ->doGetNextFrame()
H264or5Fragmenter::doGetNextFrame()->fInputSource->getNextFrame
FramedSource::getNextFrame ->doGetNextFrame()
ByteStreamFileSource::doGetNextFrame()->doReadFromFile()
ByteStreamFileSource::doReadFromFile()-> fFrameSize = read(fileno(fFid), fTo, fMaxSize)->FramedSource::afterGetting(this)
H264or5Fragmenter::afterGettingFrame->afterGettingFrame1->doGetNextFrame（分支)->FramedSource::afterGetting(this);
MultiFramedRTPSink::afterGettingFrame->afterGettingFrame1->sendPacketIfNecessary();
MultiFramedRTPSink::sendPacketIfNecessary()->fRTPInterface.sendPacket->nextTask() = envir().taskScheduler().scheduleDelayedTask(uSecondsToGo, (TaskFunc*)sendNext, this);
MultiFramedRTPSink::sendNext->buildAndSendPacket RTP数据封装

附一张网上流程图

2.  buildAndSendPacket  rtp封装数据

RTP packet的结构如下：

RTP Header：RTP 包的头部
contributing sources：个数为0-n个，所以可以为空。具体定义参考rfc3550
RTP payload：即RTP要传输的数据
RTP Header
这是RTP流的头部，在网上搜索RTP格式，就会搜到很多文章介绍这个头部的定义。我们这里参考rfc3550的定义，在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             |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

每行是32 bits，由此可以直观看到每个表示部分所占的位数。简单介绍一下：

V(version)：2 bits，RTP的版本，这里统一为2

P(padding)：1 bit，如果置1，在packet的末尾被填充，填充有时是方便一些针对固定长度的算法的封装

X(extension)：1 bit，如果置1，在RTP Header会跟着一个header extension

CC(CSRC count): 4 bits，表示头部后contributing sources的个数

M(marker): 1 bit，具体这位的定义会在一个profile里

PT(playload type): 7 bits，表示所传输的多媒体的类型，对应的编号在另一份文档rfc3551中有列出(http://tools.ietf.org/html/rfc3551)

sequence number: 16 bits，每个RTP packet的sequence number会自动加一，以便接收端检测丢包情况

timestamp: 32 bits，时间戳

SSRC: 32 bits，同步源的id，没两个同步源的id不能相同

CSRC: 上文说到，个数由CC指定，范围是0-15

live 会在数据封装12字节的头