vlc源码分析（三）调用live555接收RTP数据

最新推荐文章于 2024-05-21 20:05:39 发布

爱自在

最新推荐文章于 2024-05-21 20:05:39 发布

阅读量622

点赞数

分类专栏： vlc

原文链接：https://www.cnblogs.com/jiayayao/p/6819722.html

版权

vlc 专栏收录该内容

15 篇文章 1 订阅

订阅专栏

原文地址：https://www.cnblogs.com/jiayayao/p/6819722.html

首先了解RTSP/RTP/RTCP相关概念，尤其是了解RTP协议：RTP与RTCP协议介绍（转载）。

　　vlc使用模块加载机制调用live555，调用live555的文件是live555.cpp。

一、几个重要的类　　

　　以下向左箭头（“<-”）为继承关系。

1. RTPInterface

　　RTPInterface是RTPSource的成员变量，其成员函数handleRead会读取网络数据存入BufferedPacket内，该类最终会调到UDP的发送接收函数。

Boolean RTPInterface::handleRead(unsigned char* buffer, unsigned bufferMaxSize,
                 unsigned& bytesRead, struct sockaddr_in& fromAddress, Boolean& packetReadWasIncomplete)

2. BufferedPacket

　　BufferedPacket：用于存储媒体的RTP数据包

　　BufferedPacket<-H264BufferedPacket:用于存储H264媒体RTP数据包

　　该类有一个重要函数fillInData，是由RTPInterface读取数据存入包中。

Boolean BufferedPacket::fillInData(RTPInterface& rtpInterface, Boolean& packetReadWasIncomplete)；

　　相对于BufferedPacket，有对应的工厂类：

　　BufferedPacketFactory:工厂模式生成BufferedPacket包
　　BufferedPacketFactory<-H264BufferedPacketFactory：专门生产H264BufferedPacket的工厂

　　在SessionsSetup的时候（也是模块加载的时候），会根据Source类型，选定生产BufferedPacket的工厂类型，即如果Source是H264格式的话，就会new H264BufferedPacketFactory，之后在接收数据的时候就会生产H264BufferedPacket用于存储H264媒体数据。

　　ReorderingPacketBuffer：MultiFramedRTPSource的成员变量，用于管理多个BufferedPacket。

3. Source相关类　　

　　Source相关类的继承关系：Medium<-MediaSource<-FramedSource<-RTPSource<-MultiFramedRTPSource<-H264VideoRTPSource。
　　在SessionsSetup的时候，会根据数据源的类型，选定Source的类型，即如果数据源是H264格式的话，就会调用

static H264VideoRTPSource* createNew(UsageEnvironment& env, Groupsock* RTPgs,
　　unsigned char rtpPayloadFormat,
　　unsigned rtpTimestampFrequency = 90000);

二、播放流程的建立

　　播放流程的建立可以参考vlc源码分析之播放流程。

三、接收RTP数据

　　vlc在播放IPC时，会开启一个线程接收网络数据，该线程接收网络数据后会调用Demux()进行分离（因为可能是音频，也可能是视频）。Demux()首先将必要的接口，如StreamRead、StreamClose注册下去，然后就进入事件循环：

p_sys->scheduler->doEventLoop( &p_sys->event_data );

　　如果有网络数据到来了，Demux()会做两件事，第一件事是分析RTP包，放入ReorderingPacketBuffer管理的BufferedPacket中，堆栈如下图所示：

　　第二件事是读取的BufferedPacket，进行一系列拆包操作后，将数据放入数据fifo中，堆栈如下图所示：

　　doEventLoop会进入死循环，直到p_sys->event_data的值被中断或者超时改变，从而退出循环。当有网络数据到来的时候，doEventLoop会执行SingleStep->...->doGetNextFrame1()，在doGetNextFrame1()函数中读取RTP数据。这个过程的代码及注释如下：

复制代码

// 做了两件事，一件是分析RTP包，放入ReorderingPacketBuffer管理的BufferedPacket中；
// 另一件是读取的BufferedPacket，进行一系列拆包操作后，将数据放入数据fifo中
void MultiFramedRTPSource::networkReadHandler1() {
  BufferedPacket* bPacket = fPacketReadInProgress;
  if (bPacket == NULL) {
    // Normal case: Get a free BufferedPacket descriptor to hold the new network packet:
    bPacket = fReorderingBuffer->getFreePacket(this);
  }

  // Read the network packet, and perform sanity checks on the RTP header:
  Boolean readSuccess = False;
  // do-while(0)结构，出现错误直接break
  do {
    Boolean packetReadWasIncomplete = fPacketReadInProgress != NULL;
    if (!bPacket->fillInData(fRTPInterface, packetReadWasIncomplete)) break;
    if (packetReadWasIncomplete) {
      // We need additional read(s) before we can process the incoming packet:
      fPacketReadInProgress = bPacket;
      return;
    } else {
      fPacketReadInProgress = NULL;
    }
#ifdef TEST_LOSS
    setPacketReorderingThresholdTime(0);
       // don't wait for 'lost' packets to arrive out-of-order later
    if ((our_random()%10) == 0) break; // simulate 10% packet loss
#endif

    // Check for the 12-byte RTP header:
    if (bPacket->dataSize() < 12) break;
    // 读取RTP头，向前移4个字节
    unsigned rtpHdr = ntohl(*(u_int32_t*)(bPacket->data())); ADVANCE(4);
    // 读取RTP头中的标记位
    Boolean rtpMarkerBit = (rtpHdr&0x00800000) != 0;
    // 读取时间戳，向前移4个字节
    unsigned rtpTimestamp = ntohl(*(u_int32_t*)(bPacket->data()));ADVANCE(4);
    // 读取SSRC，向前移4个字节
    unsigned rtpSSRC = ntohl(*(u_int32_t*)(bPacket->data())); ADVANCE(4);

    // Check the RTP version number (it should be 2):
    // 检查RTP头版本，不是2的话，break
    if ((rtpHdr&0xC0000000) != 0x80000000) break;

    // Skip over any CSRC identifiers in the header:
    // 跳过CSRC计数字节
    unsigned cc = (rtpHdr>>24)&0xF;
    if (bPacket->dataSize() < cc) break;
    ADVANCE(cc*4);

    // Check for (& ignore) any RTP header extension
    // 如果扩展头标志被置位
    if (rtpHdr&0x10000000) {
      if (bPacket->dataSize() < 4) break;
      // 获取扩展头
      unsigned extHdr = ntohl(*(u_int32_t*)(bPacket->data())); ADVANCE(4);
      // 获取扩展字节数
      unsigned remExtSize = 4*(extHdr&0xFFFF);
      if (bPacket->dataSize() < remExtSize) break;
      // 直接跳过扩展字节？？？
      ADVANCE(remExtSize);
    }

    // Discard any padding bytes:
    // 如果填充标志被置位，直接丢弃不处理
    if (rtpHdr&0x20000000) {
      if (bPacket->dataSize() == 0) break;
      unsigned numPaddingBytes
    = (unsigned)(bPacket->data())[bPacket->dataSize()-1];
      if (bPacket->dataSize() < numPaddingBytes) break;
      bPacket->removePadding(numPaddingBytes);
    }
    // Check the Payload Type.
    // 检查载荷类型，如果源数据H264类型，则其值为96
    // 如果与我们生成的source类型不同，则break
    if ((unsigned char)((rtpHdr&0x007F0000)>>16)
    != rtpPayloadFormat()) {
      break;
    }

    // The rest of the packet is the usable data.  Record and save it:
    if (rtpSSRC != fLastReceivedSSRC) {
      // The SSRC of incoming packets has changed.  Unfortunately we don't yet handle streams that contain multiple SSRCs,
      // but we can handle a single-SSRC stream where the SSRC changes occasionally:
      fLastReceivedSSRC = rtpSSRC;
      fReorderingBuffer->resetHaveSeenFirstPacket();
    }
    // RTP包序号，随RTP数据包而自增，由接收者用来探测包损失
    unsigned short rtpSeqNo = (unsigned short)(rtpHdr&0xFFFF);
    Boolean usableInJitterCalculation
      = packetIsUsableInJitterCalculation((bPacket->data()),
                          bPacket->dataSize());
    struct timeval presentationTime; // computed by:
    Boolean hasBeenSyncedUsingRTCP; // computed by:
    // 根据数据包的一些信息，进行一些计算和记录
    receptionStatsDB()
      .noteIncomingPacket(rtpSSRC, rtpSeqNo, rtpTimestamp,
              timestampFrequency(),
              usableInJitterCalculation, presentationTime,
              hasBeenSyncedUsingRTCP, bPacket->dataSize());

    // Fill in the rest of the packet descriptor, and store it:
    struct timeval timeNow;
    gettimeofday(&timeNow, NULL);
    // 将计算所得的一些参数再赋值到包中
    bPacket->assignMiscParams(rtpSeqNo, rtpTimestamp, presentationTime,
                  hasBeenSyncedUsingRTCP, rtpMarkerBit,
                  timeNow);
    // 经过以上判断和检查，没有发现问题，则由管理类fReorderingBuffer存储包
    if (!fReorderingBuffer->storePacket(bPacket)) break;

    readSuccess = True;// 读取成功
  } while (0);
  if (!readSuccess) fReorderingBuffer->freePacket(bPacket);// 如果读取不成功，则释放内存

  // 将读取到的数据包送至数据fifo中，等待解码线程解码
  doGetNextFrame1();
  // If we didn't get proper data this time, we'll get another chance
}

复制代码

四、组装RTP包为音视频数据包

4.1 组帧要点

1. 默认一个音频包就是一个音频帧；

2. sps,pps会和I帧组成一个完整的帧；

3. 帧头：对于sps，默认为帧头。对于判断是slice开头的包，根据片中第一个宏块的地址（first_mb_in_slice，读取时注意是哥伦布编码的）判断当前片是否是视频帧的首片；注意，h264组帧协议RFC3984里，FU-header中的S和E标识的是片头和片尾，不是帧。

4. 帧尾：对于视频数据，如果marker为1，则该片对应的帧为帧尾。

5. 同一视频帧有相同的timestamp；

4.2 组帧实例

　以h264组帧帧为例，组帧协议是RFC3984。上层读取到一个个的RTP包之后，需要读取RTP包的payload组装成h264的视频帧。那么按照什么规则组装呢？这里有一个rfc3984协议，描述了RTP封装h264的方法。简单描述如下：

1. 单个NAL单元包：荷载中只包含一个NAL单元。NAL头类型域等于原始 NAL单元类型,即在范围1到23之间，此时的RTP包仅仅是将NALU的数据前加12个字节的RTP头，即RTP header(12 bytes)+NALU；

2. 聚合包：本类型用于聚合多个NAL单元到单个RTP荷载中。本包有四种版本,单时间聚合包类型A (STAP-A)，单时间聚合包类型B (STAP-B)，多时间聚合包类型(MTAP)16位位移(MTAP16), 多时间聚合包类型(MTAP)24位位移(MTAP24)。赋予STAP-A, STAP-B, MTAP16, MTAP24的NAL单元类型号分别是 24,25, 26, 27；

3. 分片单元：用于分片单个NAL单元到多个RTP包。现存两个版本FU-A，FU-B,用NAL单元类型 28，29标识；

NAL单元的一个分片由整数个连续NAL单元字节组成。每个NAL单元字节必须正好是该NAL单元一个分片的一部分。相同NAL单元的分片必须使用递增的RTP序号连续顺序发送(第一和最后分片之间没有其他的RTP包）。相似，NAL单元必须按照RTP顺序号的顺序装配。

格式如下：RTP header(12 bytes)+FU indicator(1 bytes)+FU header(1 bytes)+fu payload

FU indicator格式如下：

+---------------+

|0|1|2|3|4|5|6|7|

|F|NRI| Type |

+---------------+

F、NRI是原始NALU的前3位，Type指示的是FU的type

FU header格式如下：

+---------------+

|0|1|2|3|4|5|6|7|

|S|E|R| Type |

+---------------+

S: 1 bit 当设置成1,开始位指示分片NAL单元的开始。当跟随的FU荷载不是分片NAL单元荷载的开始，开始位设为0。

E: 1 bit 当设置成1, 结束位指示分片NAL单元的结束，即, 荷载的最后字节也是分片NAL单元的最后一个字节。当跟随的 FU荷载不是分片NAL单元的最后分片,结束位设置为0。

R: 1 bit 保留位必须设置为0，接收者必须忽略该位

Type指示的是NALU的type。

注意：原始的NAL头的前三位为FU indicator的前三位，原始的NAL头的后五位为FU header的后五位。解包时，取FU indicator的前三位和FU Header的后五位，即为NALU的首字节。

下图为笔者抓到的一个RTP包，前12个字节是RTP header。5c开始是RTP数据，5c是FU indicator，41是FU header，换算为二进制：

0 是F

10 是NRI

11100 是FU type，这里是28

0 是s

1 是E，说明是1帧的结束

0 保留，必须置0

00001 是NALU type，表示非IDR帧

将读取到的音视频数据包送至数据fifo中，之后就是等待解码线程从数据fifo中拿数据，解码和渲染了，具体可参考vlc源码分析之播放流程。

　　附：

　　配置好的Windows版vlc工程下载：https://github.com/jiayayao/vlc_2.1.0-vs_2010，下载后使用vs2010可以直接编译运行，调试学习非常方便。

爱自在

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
vlc源码分析（三）调用live555接收RTP数据

首先了解RTSP/RTP/RTCP相关概念，尤其是了解RTP协议：RTP与RTCP协议介绍（转载）。　　vlc使用模块加载机制调用live555，调用live555的文件是live555.cpp。一、几个重要的类　　　　以下向左箭头（“<-”）为继承关系。1.RTPInterface　　RTPInterface是RTPSource的成员变量，其成员函数handleRead会读取网络数据存入BufferedPacket内，该类最终会调到UDP的发送接收函数。Boolean R.
复制链接

扫一扫