(转)live555学习笔记9－h264 RTP传输详解(1)

2024-03-18 11:19:28

九 h264 RTP传输详解(1)

前几章对Server端的介绍中有个比较重要的问题没有仔细探究：如何打开文件并获得其SDP信息。我们就从这里入手吧。

当RTSPServer收到对某个媒体的DESCRIBE请求时，它会找到对应的ServerMediaSession,调用ServerMediaSession::generateSDPDescription()。generateSDPDescription()中会遍历调用ServerMediaSession中所有的调用ServerMediaSubsession，通过subsession->sdpLines()取得每个Subsession的sdp，合并成一个完整的SDP返回之。
我们几乎可以断定，文件的打开和分析应该是在每个Subsession的sdpLines()函数中完成的，看看这个函数：

  1. char const* OnDemandServerMediaSubsession::sdpLines()
  2. {
  3. if (fSDPLines == NULL) {
  4. // We need to construct a set of SDP lines that describe this
  5. // subsession (as a unicast stream).  To do so, we first create
  6. // dummy (unused) source and "RTPSink" objects,
  7. // whose parameters we use for the SDP lines:
  8. unsigned estBitrate;
  9. FramedSource* inputSource = createNewStreamSource(0, estBitrate);
  10. if (inputSource == NULL)
  11. return NULL; // file not found
  12. struct in_addr dummyAddr;
  13. dummyAddr.s_addr = 0;
  14. Groupsock dummyGroupsock(envir(), dummyAddr, 0, 0);
  15. unsigned char rtpPayloadType = 96 + trackNumber() - 1; // if dynamic
  16. RTPSink* dummyRTPSink = createNewRTPSink(&dummyGroupsock,
  17. rtpPayloadType, inputSource);
  18. setSDPLinesFromRTPSink(dummyRTPSink, inputSource, estBitrate);
  19. Medium::close(dummyRTPSink);
  20. closeStreamSource(inputSource);
  21. }
  22. return fSDPLines;
  23. }

其所为如是：Subsession中直接保存了对应媒体文件的SDP，但是在第一次获取时fSDPLines为NULL，所以需先获取fSDPLines。其做法比较费事，竟然是建了临时的Source和RTPSink，把它们连接成一个StreamToken，Playing一段时间之后才取得了fSDPLines。createNewStreamSource()和createNewRTPSink()都是虚函数，所以此处创建的source和sink都是继承类指定的，我们分析的是H264，也就是H264VideoFileServerMediaSubsession所指定的，来看一下这两个函数：

  1. FramedSource* H264VideoFileServerMediaSubsession::createNewStreamSource(
  2. unsigned /*clientSessionId*/,
  3. unsigned& estBitrate)
  4. {
  5. estBitrate = 500; // kbps, estimate
  6. // Create the video source:
  7. ByteStreamFileSource* fileSource = ByteStreamFileSource::createNew(envir(),
  8. fFileName);
  9. if (fileSource == NULL)
  10. return NULL;
  11. fFileSize = fileSource->fileSize();
  12. // Create a framer for the Video Elementary Stream:
  13. return H264VideoStreamFramer::createNew(envir(), fileSource);
  14. }
  15. RTPSink* H264VideoFileServerMediaSubsession::createNewRTPSink(
  16. Groupsock* rtpGroupsock,
  17. unsigned char rtpPayloadTypeIfDynamic,
  18. FramedSource* /*inputSource*/)
  19. {
  20. return H264VideoRTPSink::createNew(envir(), rtpGroupsock,
  21. rtpPayloadTypeIfDynamic);
  22. }

可以看到，分别创建了H264VideoStreamFramer和H264VideoRTPSink。可以肯定H264VideoStreamFramer也是一个Source，但它内部又利用了另一个source--ByteStreamFileSource。后面会分析为什么要这样做，这里先不要管它。还没有看到真正打开文件的代码，继续探索：

  1. void OnDemandServerMediaSubsession::setSDPLinesFromRTPSink(
  2. RTPSink* rtpSink,
  3. FramedSource* inputSource,
  4. unsigned estBitrate)
  5. {
  6. if (rtpSink == NULL)
  7. return;
  8. char const* mediaType = rtpSink->sdpMediaType();
  9. unsigned char rtpPayloadType = rtpSink->rtpPayloadType();
  10. struct in_addr serverAddrForSDP;
  11. serverAddrForSDP.s_addr = fServerAddressForSDP;
  12. char* const ipAddressStr = strDup(our_inet_ntoa(serverAddrForSDP));
  13. char* rtpmapLine = rtpSink->rtpmapLine();
  14. char const* rangeLine = rangeSDPLine();
  15. char const* auxSDPLine = getAuxSDPLine(rtpSink, inputSource);
  16. if (auxSDPLine == NULL)
  17. auxSDPLine = "";
  18. char const* const sdpFmt = "m=%s %u RTP/AVP %d\r\n"
  19. "c=IN IP4 %s\r\n"
  20. "b=AS:%u\r\n"
  21. "%s"
  22. "%s"
  23. "%s"
  24. "a=control:%s\r\n";
  25. unsigned sdpFmtSize = strlen(sdpFmt) + strlen(mediaType) + 5 /* max short len */
  26. + 3 /* max char len */
  27. + strlen(ipAddressStr) + 20 /* max int len */
  28. + strlen(rtpmapLine) + strlen(rangeLine) + strlen(auxSDPLine)
  29. + strlen(trackId());
  30. char* sdpLines = new char[sdpFmtSize];
  31. sprintf(sdpLines, sdpFmt, mediaType, // m= <media>
  32. fPortNumForSDP, // m= <port>
  33. rtpPayloadType, // m= <fmt list>
  34. ipAddressStr, // c= address
  35. estBitrate, // b=AS:<bandwidth>
  36. rtpmapLine, // a=rtpmap:... (if present)
  37. rangeLine, // a=range:... (if present)
  38. auxSDPLine, // optional extra SDP line
  39. trackId()); // a=control:<track-id>
  40. delete[] (char*) rangeLine;
  41. delete[] rtpmapLine;
  42. delete[] ipAddressStr;
  43. fSDPLines = strDup(sdpLines);
  44. delete[] sdpLines;
  45. }

此函数中取得Subsession的sdp并保存到fSDPLines。打开文件应在rtpSink->rtpmapLine()甚至是Source创建时已经做了。我们不防先把它放一放，而是先把SDP的获取过程搞个通透。所以把焦点集中到getAuxSDPLine()上。

  1. char const* OnDemandServerMediaSubsession::getAuxSDPLine(
  2. RTPSink* rtpSink,
  3. FramedSource* /*inputSource*/)
  4. {
  5. // Default implementation:
  6. return rtpSink == NULL ? NULL : rtpSink->auxSDPLine();
  7. }

很简单，调用了rtpSink->auxSDPLine()那么我们要看H264VideoRTPSink::auxSDPLine()：不用看了，很简单，取得source 中保存的PPS,SPS等形成a=fmpt行。但事实上并没有这么简单，H264VideoFileServerMediaSubsession重写了getAuxSDPLine()！如果不重写，则说明auxSDPLine已经在前面分析文件时获得了，那么既然重写，就说明前面没有获取到，只能在这个函数中重写。look　H264VideoFileServerMediaSubsession中这个函数:

  1. char const* H264VideoFileServerMediaSubsession::getAuxSDPLine(
  2. RTPSink* rtpSink,
  3. FramedSource* inputSource)
  4. {
  5. if (fAuxSDPLine != NULL)
  6. return fAuxSDPLine; // it's already been set up (for a previous client)
  7. if (fDummyRTPSink == NULL) { // we're not already setting it up for another, concurrent stream
  8. // Note: For H264 video files, the 'config' information ("profile-level-id" and "sprop-parameter-sets") isn't known
  9. // until we start reading the file.  This means that "rtpSink"s "auxSDPLine()" will be NULL initially,
  10. // and we need to start reading data from our file until this changes.
  11. fDummyRTPSink = rtpSink;
  12. // Start reading the file:
  13. fDummyRTPSink->startPlaying(*inputSource, afterPlayingDummy, this);
  14. // Check whether the sink's 'auxSDPLine()' is ready:
  15. checkForAuxSDPLine(this);
  16. }
  17. envir().taskScheduler().doEventLoop(&fDoneFlag);
  18. return fAuxSDPLine;
  19. }

注释里面解释得很清楚，H264不能在文件头中取得PPS/SPS，必须在播放一下后（当然，它是一个原始流文件，没有文件头）才行。也就是说不能从rtpSink中取得了。为了保证在函数退出前能取得AuxSDP，把大循环搬到这里来了。afterPlayingDummy()是在播放结束也就是取得aux sdp之后执行。在大循环之前的checkForAuxSDPLine()做了什么呢？

  1. void H264VideoFileServerMediaSubsession::checkForAuxSDPLine1()
  2. {
  3. char const* dasl;
  4. if (fAuxSDPLine != NULL) {
  5. // Signal the event loop that we're done:
  6. setDoneFlag();
  7. } else if (fDummyRTPSink != NULL
  8. && (dasl = fDummyRTPSink->auxSDPLine()) != NULL) {
  9. fAuxSDPLine = strDup(dasl);
  10. fDummyRTPSink = NULL;
  11. // Signal the event loop that we're done:
  12. setDoneFlag();
  13. } else {
  14. // try again after a brief delay:
  15. int uSecsToDelay = 100000; // 100 ms
  16. nextTask() = envir().taskScheduler().scheduleDelayedTask(uSecsToDelay,
  17. (TaskFunc*) checkForAuxSDPLine, this);
  18. }
  19. }

它检查是否已取得Aux sdp，如果取得了，设置结束标志，直接返回。如果没有，就检查是否sink中已取得了aux sdp，如果是，也设置结束标志，返回。如果还没有取得，则把这个检查函数做为delay task加入计划任务中。每100毫秒检查一次，每检查一次主要就是调用一次fDummyRTPSink->auxSDPLine()。大循环在检测到fDoneFlag改变时停止，此时已取得了aux sdp。但是如果直到文件结束也没有得到aux sdp，则afterPlayingDummy（）被执行，在其中停止掉这个大循环。然后在父Subsession类中关掉这些临时的source和sink。在直正播放时重新创建。

 
 
出自:http://blog.csdn.net/niu_gao/article/details/6931400
上一篇：【转】对H264进行RTP封包原理


下一篇：TCP/IP详解学习笔记(6)-UDP协议