live555学习（十） --RTP的打包与发送

最新推荐文章于 2024-05-29 00:05:11 发布
最新推荐文章于 2024-05-29 00:05:11 发布
阅读量1.9k 收藏 4
点赞数
分类专栏： 视频开发
这里主要分析一下，live555中关于RTP打包发送的部分。在处理完PLAY命令之后，就开始发送RTP数据包了(其实在发送PLAY命令的response包之前，就会发送一个RTP包，这里传输就已经开始了)
        RTP包的发送是从MediaSink::startPlaying函数调用开始的，应是sink跟source要数据，所以从sink上调用startplaying。
  1. Boolean MediaSink::startPlaying(MediaSource& source,   afterPlayingFunc* afterFunc, void* afterClientData)  
  2. {  
  3.     //参数afterFunc是在播放结束时才被调用。  
  4.     // Make sure we're not already being played:  
  5.     if (fSource != NULL) {  
  6.         envir().setResultMsg("This sink is already being played");  
  7.         return False;  
  8.     }  
  9.   
  10.   
  11.     // Make sure our source is compatible:  
  12.     if (!sourceIsCompatibleWithUs(source)) {  
  13.         envir().setResultMsg(  
  14.                 "MediaSink::startPlaying(): source is not compatible!");  
  15.         return False;  
  16.     }  
  17.     //记下一些要使用的对象   
  18.     fSource = (FramedSource*) &source;  
  19.   
  20.   
  21.     fAfterFunc = afterFunc;  
  22.     fAfterClientData = afterClientData;  
  23.     return continuePlaying();  
  24. }  

        这个函数只有最后一句最重要，即continuePlaying函数的调用。continuePlaying函数是定义在MediaSink类中的纯虚函数，需要到特定媒体的sink子类中实现，对于H264来讲是在H264VideoRTPSink中实现的。
       H264VideoRTPSink继承关系：H264VideoRTPSink->VideoRTPSink->MultiFramedRTPSink->RTPSink->MediaSink。

 
  1. Boolean H264VideoRTPSink::continuePlaying() {  
  2.   // First, check whether we have a 'fragmenter' class set up yet.  
  3.   // If not, create it now:   
  4.   if (fOurFragmenter == NULL) {  
  5.     //创建一个辅助类H264FUAFragmenter，用于H264的RTP打包     
  6.   
  7.     fOurFragmenter = new H264FUAFragmenter(envir(), fSource, OutPacketBuffer::maxSize,  
  8.                        ourMaxPacketSize() - 12/*RTP hdr size*/);  
  9.     fSource = fOurFragmenter;  
  10.   }  
  11.   
  12.   // Then call the parent class's implementation:  
  13.   return MultiFramedRTPSink::continuePlaying();  
  14. } 


        上面的代码中创建了一个辅助类H264FUAFragmenter，因为H264的RTP包，有些特殊需要进一步处理，可以参考RFC3986。接着调用MultiFramedRTPSink类的continuePlaying实现。
        MultiFramedRTPSink是与帧有关的类，其实它要求每次必须从source获得一个帧的数据，所以才叫这个name。可以看到continuePlaying()完全被buildAndSendPacket()代替。看一下buildAndSendPacket():

 
  1. Boolean MultiFramedRTPSink::continuePlaying() {  
  2.   // Send the first packet.   
  3.   // (This will also schedule any future sends.)  
  4.   buildAndSendPacket(True);  
  5.   return True;  
  6. }  

     这时调用buildAndSendPacket函数时，看名字就知道其中将完成打包并发送工作。传递了一个True参数，表示这是第一个packet。继续看buildAndSendPacket函数定义  

  1. void MultiFramedRTPSink::buildAndSendPacket(Boolean isFirstPacket) {  
  2.   fIsFirstPacket = isFirstPacket;  
  3.     // 此函数中主要是准备rtp包的头，为一些需要跟据实际数据改变的字段留出位置。
  4.     //设置RTP头,注意，接收端需要根据RTP包的序号fSeqNo来重新排序  
  5.     //   
  6.   // Set up the RTP header:   
  7.   unsigned rtpHdr = 0x80000000; // RTP version 2; marker ('M') bit not set (by default; it can be set later)  
  8.   rtpHdr |= (fRTPPayloadType<<16);  
  9.   rtpHdr |= fSeqNo; // sequence number  
  10.   fOutBuf->enqueueWord(rtpHdr);  //向包中加入一个字
  11.   
  12.   
  13.   //保留一个4 bytes空间，用于设置time stamp  
  14.   // Note where the RTP timestamp will go.  
  15.   // (We can't fill this in until we start packing payload frames.)  
  16.   fTimestampPosition = fOutBuf->curPacketSize();  
  17.   fOutBuf->skipBytes(4); // leave a hole for the timestamp   
  18.   
  19.   fOutBuf->enqueueWord(SSRC());     //跟RTCP相关   
  20.       
  21.     //在RTP头后面，添加一个payload-format-specific头，  
  22. // Allow for a special, payload-format-specific header following the  
  23.   // RTP header:   
  24.   fSpecialHeaderPosition = fOutBuf->curPacketSize();  
  25.     //   
  26.     //specialHeaderSize在MultiFramedRTPSink中的默认实现返回0，对于H264的实现不需要处理这个字段  
  27.     //   
  28.   fSpecialHeaderSize = specialHeaderSize();  
  29.   fOutBuf->skipBytes(fSpecialHeaderSize);   //预留空间  
  30.   
  31.   
  32.    //填充尽可能多的frames到packet中   
  33.   // Begin packing as many (complete) frames into the packet as we can:  
  34.   fTotalFrameSpecificHeaderSizes = 0;  
  35.   fNoFramesLeft = False;  
  36.   fNumFramesUsedSoFar = 0;   // 一个包中已打入的帧数。   
        //头准备好了，再打包帧数据   
  37.   packFrame();  
  38. }  

        buildAndSendPacket函数中，完成RTP头的准备工作。可以看到RTP头是非常简单的，RTP头中的序号非常重要，客户端需要据此进行RTP包的重排序操作。RTP包内容存放在一个OutPacketBuffer类型的fOutBuf成员变量中，OutPacketBuffer类的细节在文章的最后还会讨论。在RTP头中预留了一些空间没有进行实际的填充，这个工作将在doSpecialFrameHandling中进行，后面会有讨论。进一步的工作，在packFrame函数中进行,它将为RTP包填充数据。

 
  1. void MultiFramedRTPSink::packFrame()  
  2. {  
  3.     // First, see if we have an overflow frame that was too big for the last pkt  
  4.     if (fOutBuf->haveOverflowData()) {  
  5.         //如果有帧数据，则使用之。OverflowData是指上次打包时剩下的帧数据，因为一个包可能容纳不了一个帧。  
  6.         // Use this frame before reading a new one from the source  
  7.         unsigned frameSize = fOutBuf->overflowDataSize();  
  8.         struct timeval presentationTime = fOutBuf->overflowPresentationTime();  
  9.         unsigned durationInMicroseconds =fOutBuf->overflowDurationInMicroseconds();  
  10.         fOutBuf->useOverflowData();    
  11.   
  12.         afterGettingFrame1(frameSize, 0, presentationTime,durationInMicroseconds);  
  13.     } else {  
  14.         //一点帧数据都没有，跟source要吧。  
  15.         // Normal case: we need to read a new frame from the source  
  16.         if (fSource == NULL)  
  17.             return;    
  18.   
  19.         //更新缓冲中的一些位置   
  20.         fCurFrameSpecificHeaderPosition = fOutBuf->curPacketSize();  
  21.         fCurFrameSpecificHeaderSize = frameSpecificHeaderSize();  
  22.         fOutBuf->skipBytes(fCurFrameSpecificHeaderSize);  
  23.         fTotalFrameSpecificHeaderSizes += fCurFrameSpecificHeaderSize;  
  24.   
  25.         //从source获取下一帧   
  26.        fSource->getNextFrame(fOutBuf->curPtr(),//新数据存放开始的位置  
  27.                 fOutBuf->totalBytesAvailable(),//缓冲中空余的空间大小  
  28.                 afterGettingFrame,  //因为可能source中的读数据函数会被放在任务调度中，所以把获取帧后应调用的函数传给source  
  29.                 this,  
  30.                 ourHandleClosure, //这个是source结束时(比如文件读完了)要调用的函数。  
  31.                 this);  
  32.     }  
  33. } 

        packFrame函数需要处理两种情况：
       1).buffer中存在未发送的数据(overflow data)，这时可以将调用afterGettingFrame1函数进行后续处理工作。
       2).buffer不存在数据，这时需要调用source上的getNextFrame函数获取数据。getNextFrame调用时，参数中有两个回调用函数：afterGettingFrame函数将在获取到数据后调用，其中只是简单的调用了afterGettingFrame1函数而已，这是因为C++中是不充许类成员函数作为回调用函数的；ourHandleClosure函数将在数据已经处理完毕时调用，如文件结束。
     

        可以想像下面就是source从文件（或某个设备）中读取一帧数据，读完后返回给sink，当然不是从函数返回了，而是以调用afterGettingFrame这个回调函数的方式。所以下面看一下afterGettingFrame():

 
  1. void MultiFramedRTPSink::afterGettingFrame(void* clientData,  
  2.         unsigned numBytesRead, unsigned numTruncatedBytes,  
  3.         struct timeval presentationTime, unsigned durationInMicroseconds)  
  4. {  
  5.     MultiFramedRTPSink* sink = (MultiFramedRTPSink*) clientData;  
  6.     sink->afterGettingFrame1(numBytesRead, numTruncatedBytes, presentationTime,  
  7.             durationInMicroseconds);  
  8. }  

   
      可以看出，它只是过度为调用成员函数，所以afterGettingFrame1()才是重点：

 
  1. void MultiFramedRTPSink::afterGettingFrame1(  
  2.         unsigned frameSize,  
  3.         unsigned numTruncatedBytes,  
  4.         struct timeval presentationTime,  
  5.         unsigned durationInMicroseconds)  
  6. {  
  7.     if (fIsFirstPacket) {  
  8.         // Record the fact that we're starting to play now:   第一个packet，则记录下当前时间  
  9.         gettimeofday(&fNextSendTime, NULL);  
  10.     }  
  11.   
  12.   //这里的处理要注意了，当一个Frame大于OutPacketBuffer::maxSize(默认值为60000)时，则会丢弃剩下的部分，numTruncatedBytes即为超出部分的大小。   
  13.     //如果给予一帧的缓冲不够大，就会发生截断一帧数据的现象。但也只能提示一下用户  
  14.     if (numTruncatedBytes > 0) {    
  15.   
  16.         unsigned const bufferSize = fOutBuf->totalBytesAvailable();  
  17.         envir()  
  18.                 << "MultiFramedRTPSink::afterGettingFrame1(): The input frame data was too large for our buffer size ("  
  19.                 << bufferSize  
  20.                 << ").  "  
  21.                 << numTruncatedBytes  
  22.                 << " bytes of trailing data was dropped!  Correct this by increasing \"OutPacketBuffer::maxSize\" to at least "  
  23.                 << OutPacketBuffer::maxSize + numTruncatedBytes  
  24.                 << ", *before* creating this 'RTPSink'.  (Current value is "  
  25.                 << OutPacketBuffer::maxSize << ".)\n";  
  26.     }  
  27.     unsigned curFragmentationOffset = fCurFragmentationOffset;  
  28.     unsigned numFrameBytesToUse = frameSize;  
  29.     unsigned overflowBytes = 0;  
  30.   
  31.   
  32.     //如果包只已经打入帧数据了，并且不能再向这个包中加数据了，则把新获得的帧数据保存下来。  
  33.     // If we have already packed one or more frames into this packet,  
  34.     // check whether this new frame is eligible to be packed after them.  
  35.     // (This is independent of whether the packet has enough room for this  
  36.     // new frame; that check comes later.)   
  37.     // fNumFramesUsedSoFar>0 表示packet已经存在frame，需要检查是否充许在packet中加入新的frame
  38.     if (fNumFramesUsedSoFar > 0) {  
  39.         //如果包中已有了一个帧，并且不允许再打入新的帧了，则只记录下新的帧。  
  40.         if ((fPreviousFrameEndedFragmentation 
  41.                && !allowOtherFramesAfterLastFragment())  //不充许在前一个分片之后，跟随一个frame
  42.                 || !frameCanAppearAfterPacketStart(fOutBuf->curPtr(), frameSize))  //frame不能出现在非packet的开始位置      
  43.         {  
  44.             // Save away this frame for next time:  
  45.             numFrameBytesToUse = 0;  
  46.             //不充许添加新的frame，则保存为溢出数据,下次处理   
  47.             fOutBuf->setOverflowData(fOutBuf->curPacketSize(), frameSize,  
  48.                     presentationTime, durationInMicroseconds);  
  49.         }  
  50.     }  
  51.       
  52.     //表示当前打入的是否是上一个帧的最后一块数据。   
  53.     fPreviousFrameEndedFragmentation = False;  
  54.   
  55.   
  56.     //下面是计算获取的帧中有多少数据可以打到当前包中，剩下的数据就作为overflow数据保存下来。  
  57.     if (numFrameBytesToUse > 0) {  
  58.         // Check whether this frame overflows the packet  
  59.         if (fOutBuf->wouldOverflow(frameSize)) {  
  60.             // Don't use this frame now; instead, save it as overflow data, and  
  61.             // send it in the next packet instead.  However, if the frame is too  
  62.             // big to fit in a packet by itself, then we need to fragment it (and  
  63.             // use some of it in this packet, if the payload format permits this.)   
  64.     //若frame将导致packet溢出，应该将其保存到packet的溢出数据中，在下一个packet中发送。   
        //如果frame本身大于pakcet 的max size， 就需要对frame进行分片操作。不过需要调用allowFragmentationAfterStart 函数以确定是否充许分片
  65.             if (isTooBigForAPacket(frameSize)  
  66.                     && (fNumFramesUsedSoFar == 0 || allowFragmentationAfterStart())) {  
  67.                 // We need to fragment this frame, and use some of it now:  
  68.                 overflowBytes = computeOverflowForNewFrame(frameSize);  
  69.                 numFrameBytesToUse -= overflowBytes;  
  70.                 fCurFragmentationOffset += numFrameBytesToUse;  
  71.             } else {  
  72.                 // We don't use any of this frame now:  
  73.                 overflowBytes = frameSize;  
  74.                 numFrameBytesToUse = 0;  
  75.             }  
  76.             fOutBuf->setOverflowData(fOutBuf->curPacketSize() + numFrameBytesToUse,  
  77.                     overflowBytes, presentationTime, durationInMicroseconds);  
  78.         } else if (fCurFragmentationOffset > 0) {  
  79.             // This is the last fragment of a frame that was fragmented over  
  80.             // more than one packet.  Do any special handling for this case:  
  81.             fCurFragmentationOffset = 0;  
  82.             fPreviousFrameEndedFragmentation = True;  
  83.         }  
  84.     }  
  85.   
  86.       
  87.     if (numFrameBytesToUse == 0 && frameSize > 0) {  
  88.         //如果包中有数据并且没有新数据了，则发送之。（这种情况好像很难发生啊！）  
  89.         // Send our packet now, because we have filled it up:  
  90.         sendPacketIfNecessary();  
  91.     } else {  
  92.         //需要向包中打入数据。   
  93.           
  94.         // Use this frame in our outgoing packet:  
  95.         unsigned char* frameStart = fOutBuf->curPtr();  
  96.         fOutBuf->increment(numFrameBytesToUse);  
  97.         // do this now, in case "doSpecialFrameHandling()" calls "setFramePadding()" to append padding bytes  
  98.   
  99.         //还记得RTP头中序留的空间吗，将在这个函数中进行填充
  100.         // Here's where any payload format specific processing gets done:  
  101.         doSpecialFrameHandling(curFragmentationOffset, frameStart,  
  102.                 numFrameBytesToUse, presentationTime, overflowBytes);  
  103.   
  104.   
  105.         ++fNumFramesUsedSoFar;  
  106.   
  107.         //设置下一个packet的时间信息，这里若存在overflow数据，就不需要更新时间，因为这是同一个frame的不同分片，需要保证时间一致  
  108.         // Update the time at which the next packet should be sent, based  
  109.         // on the duration of the frame that we just packed into it.  
  110.         // However, if this frame has overflow data remaining, then don't  
  111.         // count its duration yet.  
  112.         if (overflowBytes == 0) {  
  113.             fNextSendTime.tv_usec += durationInMicroseconds;  
  114.             fNextSendTime.tv_sec += fNextSendTime.tv_usec / 1000000;  
  115.             fNextSendTime.tv_usec %= 1000000;  
  116.         }  
  117.   
  118.   
  119.         //如果需要，就发出包，否则继续打入数据。  
  120.         // Send our packet now if (i) it's already at our preferred size, or  
  121.         // (ii) (heuristic) another frame of the same size as the one we just  
  122.         //      read would overflow the packet, or  
  123.         // (iii) it contains the last fragment of a fragmented frame, and we  
  124.         //      don't allow anything else to follow this or  
  125.         // (iv) one frame per packet is allowed:  
  126.         if (fOutBuf->isPreferredSize()  
  127.                 || fOutBuf->wouldOverflow(numFrameBytesToUse)  
  128.                 || (fPreviousFrameEndedFragmentation  
  129.                         && !allowOtherFramesAfterLastFragment())  
  130.                 || !frameCanAppearAfterPacketStart(  
  131.                         fOutBuf->curPtr() - frameSize, frameSize)) {  
  132.             // The packet is ready to be sent now  
  133.             sendPacketIfNecessary();  //发送RTP包   
  134.         } else {              
  135.            // There's room for more frames; try getting another:  
  136.             packFrame();    //packet中还可以容纳frame，这里将形成递归调用 
  137.         }  
  138.     }  
  139. }  

         afterGettingFrame1的复杂之处在于处理frame的分片，若一个frame大于TCP/UDP有效载荷(程序中定义为1448个字节)，就必需分片了。最简单的情况就是一个packet(RTP包)中最多只充许一个frame，即一个RTP包中存在一个frame或者frame的一个分片，H264就是这样处理的。，方法是将剩余的数据记录为buffer的溢出部分。下次调用packFrame函数时，直接从溢出部分复制到packet中。不过应该注意，一个frame的大小不能超过buffer的大小(默认为60000)，否则会真的溢出, 那就应该考虑增加buffer大小了。
      上面的代码中还调用了doSpecialFrameHandling，子类需要重新实现进行一些特殊处理，文章最后还会讨论这个问题。
       在packet中充许出现多个frame的情况下(大多数情况下应该没必要用到)，采用了递归来实现，可以看到afterGettingFrame1函数的最后有调用packFrame的代码。

      再来看RTP的发送函数sendPacketIfNecessary
 
  1. void MultiFramedRTPSink::sendPacketIfNecessary() {  
  2.     //   
  3.     //packet中存在frame，则发送出去   
  4.     //   
  5.   if (fNumFramesUsedSoFar > 0) {  
  6.     // Send the packet:   
  7.     //   
  8.     //可以通过TEST_LOSS宏，模拟10%丢包   
  9.     //   
  10. #ifdef TEST_LOSS   
  11.     if ((our_random()%10) != 0) // simulate 10% packet loss #####  
  12. #endif   
  13.     //   
  14.     //现在通过调用RTPInterface::sendPacket函数发送packet  
  15.     //        
  16.  if (!fRTPInterface.sendPacket(fOutBuf->packet(), fOutBuf->curPacketSize())) {  
  17.     // if failure handler has been specified, call it  
  18.     if (fOnSendErrorFunc != NULL) (*fOnSendErrorFunc)(fOnSendErrorData);    //错误处理  
  19.       }  
  20.     ++fPacketCount;  
  21.     fTotalOctetCount += fOutBuf->curPacketSize();  
  22.     fOctetCount += fOutBuf->curPacketSize()  
  23.       - rtpHeaderSize - fSpecialHeaderSize - fTotalFrameSpecificHeaderSizes;  
  24.   
  25.   
  26.     ++fSeqNo; // for next time  
  27.   }  
  28.   
  29.    //如果还有剩余数据，则调整缓冲区
  30.   if (fOutBuf->haveOverflowData()  
  31.       && fOutBuf->totalBytesAvailable() > fOutBuf->totalBufferSize()/2) {  
  32.     //   
  33.     //为了提高效率，可以直接重置buffer中的packet开始位置，这样就不需要拷贝一遍overflow数据了。  
  34.     //在一个packet只能包含一个frame的情况下，是不是可以考虑修改这里的判断条件呢？  
  35.     //       
  36.     // Efficiency hack: Reset the packet start pointer to just in front of  
  37.     // the overflow data (allowing for the RTP header and special headers),  
  38.     // so that we probably don't have to "memmove()" the overflow data  
  39.     // into place when building the next packet:  
  40.     unsigned newPacketStart = fOutBuf->curPacketSize()  
  41.       - (rtpHeaderSize + fSpecialHeaderSize + frameSpecificHeaderSize());  
  42.     fOutBuf->adjustPacketStart(newPacketStart); //调整buffer中的packet 开始位置  
  43.   } else {  
  44.     // Normal case: Reset the packet start pointer back to the start:  
  45.     fOutBuf->resetPacketStart();    //这种情况，若存在overflow data,就需要进行copy操作了  
  46.   }  
  47.   fOutBuf->resetOffset();   //packet已经发送了，可以重置buffer中的数据offset了  
  48.   fNumFramesUsedSoFar = 0;  //清零packet中的frame数  
  49.     //   
  50.     //数据已经发送完毕(例如文件传输完毕)，可以关闭了
  51.     //    
  52.   if (fNoFramesLeft) {  
  53.     // We're done:   
  54.     onSourceClosure(this);  
  55.   } else {  //如果还有数据，则在下一次需要发送的时间再次打包发送
  56.     //   
  57.     //准备下一次发送任务   
  58.     //   
  59.     // We have more frames left to send.  Figure out when the next frame  
  60.     // is due to start playing, then make sure that we wait this long before  
  61.     // sending the next packet.  
  62.     struct timeval timeNow;  
  63.     gettimeofday(&timeNow, NULL);  
  64.     int secsDiff = fNextSendTime.tv_sec - timeNow.tv_sec;   //若是同一个frame的不同分片，这个值将为0  
  65.     int64_t uSecondsToGo = secsDiff*1000000 + (fNextSendTime.tv_usec - timeNow.tv_usec);  
  66.     if (uSecondsToGo < 0 || secsDiff < 0) { // sanity check: Make sure that the time-to-delay is non-negative:  
  67.       uSecondsToGo = 0;       
  68.     }  
  69.     //   
  70.     //作延时时间，处理函数，将入到任务调试器中，以便进行下一次发送操作  
  71.     //       
  72. // Delay this amount of time:  
  73.     nextTask() = envir().taskScheduler().scheduleDelayedTask(uSecondsToGo, (TaskFunc*)sendNext, this);  
  74.   }  
  75. } 
   
      sendPacketIfNecessary函数处理一些发送的细节，我们来看最重要的两点。
      1)RTP包还是转交给了RTPInterface::sendPacket函数，等下再看其具体实现。
      2)将下一次RTP的发送操作加入到任务调度器中，参数中传递了sendNext函数指针，其实现比较简单，如下
  1. void MultiFramedRTPSink::sendNext(void* firstArg) {  
  2.   MultiFramedRTPSink* sink = (MultiFramedRTPSink*)firstArg;  
  3.   sink->buildAndSendPacket(False);  //现在已经不是第一次调用了  
  4. } 
       可以看到为了延迟包的发送，使用了delay task来执行下次打包发送任务。sendNext()中又调用了buildAndSendPacket()函数，轮回了。。。

总结一下调用过程：

总结一下调用过程：

live555学习（十） --RTP的打包与发送 - 白杨 - 白杨

 

最后，再说明一下包缓冲区的使用：

        MultiFramedRTPSink中的帧数据和包缓冲区共用一个，只是用一些额外的变量指明缓冲区中属于包的部分以及属于帧数据的部分（包以外的数据叫做overflow data）。它有时会把overflow data以mem move的方式移到包开始的位置，有时把包的开始位置直接设置到overflow data开始的地方。那么这个缓冲的大小是怎样确定的呢？是跟据调用者指定的的一个最大的包的大小+60000算出的。这个地方把我搞胡涂了：如果一次从source获取一个帧的话，那这个缓冲应设为不小于最大的一个帧的大小才是，为何是按包的大小设置呢？可以看到，当缓冲不够时只是提示一下.当然此时不会出错，但有可能导致时间戳计算不准，或增加时间戳计算与source端处理的复杂性(因为一次取一帧时间戳是很好计算的)。

现在来看RTPInterface::sendPacket函数

  1. Boolean RTPInterface::sendPacket(unsigned char* packet, unsigned packetSize) {  
  2.   Boolean success = True; // we'll return False instead if any of the sends fail  
  3.   
  4.    //一般情况下，使用UDP发送   
  5.   // Normal case: Send as a UDP packet:  
  6.   if (!fGS->output(envir(), fGS->ttl(), packet, packetSize)) success = False;  
  7.   
  8.   //使用TCP发送   
  9.   // Also, send over each of our TCP sockets:  
  10.   for (tcpStreamRecord* streams = fTCPStreams; streams != NULL;  
  11.        streams = streams->fNext) {  
  12.     if (!sendRTPOverTCP(packet, packetSize,  
  13.             streams->fStreamSocketNum, streams->fStreamChannelId)) {  
  14.       success = False;  
  15.     }  
  16.   }  
  17.   
  18.   
  19.   return success;  
  20. }  

         若是使用UDP方式发送，将调用Groupsock::output函数，可以实现组播功能。groupsock只实现了UDP发送功能，当用TCP方式传送时调用sendRTPOverTcP函数，这个函数中直接调用socket的send函数。
        现在RTP的发送终于结束了，groupsock的实现留待下次分析。现在再来看一个遗留的问题，MultiFramedRTPSink::doSpecialFrameHandling的实现。它是定义在MultiFramedRTPSink中的虚函数，先来看其默认的实现.

  1. void MultiFramedRTPSink::doSpecialFrameHandling(unsigned /*fragmentationOffset*/,  
  2.              unsigned char* /*frameStart*/,  
  3.              unsigned /*numBytesInFrame*/,  
  4.              struct timeval framePresentationTime,  
  5.              unsigned /*numRemainingBytes*/) {  
  6.   // default implementation: If this is the first frame in the packet,  
  7.   // use its presentationTime for the RTP timestamp:  
  8.   if (isFirstFrameInPacket()) {  
  9.     setTimestamp(framePresentationTime);  
  10.   }  
  11. } 
       可以看到默认实现中只是在第一次调用时，设置RTP包中的的时间信息，下面来看H264VideoRTPSink上的实现
  1. void H264VideoRTPSink::doSpecialFrameHandling(unsigned /*fragmentationOffset*/,  
  2.                           unsigned char* /*frameStart*/,  
  3.                           unsigned /*numBytesInFrame*/,  
  4.                           struct timeval framePresentationTime,  
  5.                           unsigned /*numRemainingBytes*/) {  
  6.     //   
  7.     //设置RTP头中的M位   
  8.     //   
  9.   // Set the RTP 'M' (marker) bit iff  
  10.   // 1/ The most recently delivered fragment was the end of (or the only fragment of) an NAL unit, and  
  11.   // 2/ This NAL unit was the last NAL unit of an 'access unit' (i.e. video frame).  
  12.   if (fOurFragmenter != NULL) {  
  13.     H264VideoStreamFramer* framerSource  
  14.       = (H264VideoStreamFramer*)(fOurFragmenter->inputSource());  
  15.     // This relies on our fragmenter's source being a "H264VideoStreamFramer".  
  16.     if (fOurFragmenter->lastFragmentCompletedNALUnit()  
  17.     && framerSource != NULL && framerSource->pictureEndMarker()) {  
  18.       setMarkerBit();  
  19.       framerSource->pictureEndMarker() = False;  
  20.     }  
  21.   }  
  22.     //   
  23.     //设置时间戳   
  24.     //   
  25.   setTimestamp(framePresentationTime);  
  26. }  
         解释一下RTP头中的M位，H264图像可能被封装成多个NALU，这些NALU就拥有相同的同时间。根据RFC3984的定义,当RTP中封装的是同一图像的最后一个NALU时，就需要设置M位
 
                         http://blog.csdn.net/nkmnkm/article/details/6921145
tgy_fujitsu
关注
  • 0
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
MJPEG格式以及RTP打包
Zero丶的专栏
10-24 2227
MJPEG格式和码流分析 MJPEG格式和码流分析 RTP打包传输MJPEG码流
RtspSever传输MJPEG/JPEG/H264/H265
春眠不觉晓
01-17 958
  当前已有RtspServer多数支持H264，但对JPEG支持比较少，LIVE555虽然有JPEG部分代码，但是需要自己去实现对JPEG header的解析部分。   RTSP推流H264、H265时，无需解析SPS、PPS，直接对RTP Header做些处理即可；但是推流JPEG、MJPEG时，则需要根据JPEG Header解析出width、height、qFactor、quantizat...
RTP封装&h264原理&实现传输h264的RTSP服务器
最新发布
control_0317的博客
05-29 684
实现：客户端建立与RTSP服务端的连接后，并且在RTSP服务端回复了客户端的Play请求以后，服务端需要源源不断的读取一个本地h264视频文件，并将读取到的h264视频流封装到RTP数据包中，再推送至客户端。这样我们就实现了一个简单的支持RTSP协议流媒体分发服务。
PES,TS,PS,RTP等流的打包格式解析之RTP流
appledurian的博客
06-12 6088
本篇介绍RTP包封装格式 1.RTP包头格式 RTP包头占位12个字节，其字段组成如下图所示： V字段：RTP协议版本号，占位2bit，当前协议为V=2； P字段：填充字段，占位1bit，如果P=1，则表示此包的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。 X字段：扩展字段，占位1bit，如果x=1，则表示RTP包头后面跟有一个扩展报头； CC字段：C
RTP打包传输MJPEG码流
liuchen1206的专栏
07-22 1万+
一、环境是ubuntu 二、采集视频。 我这里采集的是YUYV422，然后可以通过两种方式转化，1.yuyv422->yuv420->jpeg->rtp->vlc(yuv420解码)。2.yuyv422->rgb->jpeg->rtp->vlc(yuv420解码) V4L2编程可以参考：V4L2编程 YUYV422转RGB参考：YUYV422TORGB 三、代码下载 包含jpeg-9a
Live555_RTSP_RTP_RTP源码
06-02
5. **源码学习与应用**：对于开发者来说，掌握Live555的源码有助于深入理解RTSP和RTP的工作原理，可以自定义功能或优化性能。例如，你可以学习如何处理RTSP会话建立、RTP数据包的发送和接收，以及如何处理不同网络...
Windows下利用live555实现H264实时流RTSP发送
07-23
总的来说，实现"Windows下利用live555实现H264实时流RTSP发送"涉及到理解RTSP协议、H264编码、RTP/RTCP封装以及live555库的使用。这个过程需要对网络编程、多媒体编码和实时通信有深入的理解。通过提供的"live555...
live555 h264和aac rtsp推流
03-04
在"live555 h264和aac rtsp推流"中，live555被用来处理H264编码的视频流和AAC编码的音频流，将这些数据打包成RTP包并通过RTSP协议推送到服务器。开发者可以利用live555提供的API来构建自定义的流媒体服务，实现视频...
live555.zip
12-04
Live555是一个广泛使用的开源多媒体框架，它支持实时流媒体协议如RTSP（Real-Time Streaming Protocol）、RTP（Real-time Transport Protocol）和RTCP（Real-time Transport Control Protocol）。这个版本的目的是...
live555.rar
05-15
通过这个压缩包，用户可以学习到如何利用Live555库搭建RTSP服务器，实现流媒体推流功能，并且通过测试程序的代码，可以深入理解RTSP协议和RTP传输的实现细节。这对于开发实时音视频应用，尤其是需要自建服务器的场景...
MPEG格式之RTP打包
一个VA生的博客
06-11 219
MPEG编码格式，也是视频监控领域使用较多的，其特点是每帧都是IDR帧，类似图像压缩格式，采用帧内压缩编码而无帧间压缩，因此编码压缩效率不高，但图像质量较好。本文主要描述MPEG格式是如何使用RTP打包的。.........
RTP打包G711音频数据发送
Jayson 博客
07-14 3468
G711编码，有两种G711A/G711U，主要在安防中应用，是一帧波形编码的音频数据，只是将PCM压缩一半数据量。一般G711，采样率8000，通道数1。所以G711中1B就是一个样本数据。G711打包RTP非常简单，只要在G711数据前加上RTP头即可。G711没有想AAC那样，按照帧一帧一帧发送，而是设定一个打包频率，打包频率有10ms,20ms,30ms,40ms 等。如40ms的打包频率...
Linux下RTP编程(下)
zjbo_123的专栏
04-23 1171
 3.3 数据发送当RTP 会话成功建立起来之后，接下去就可以开始进行流媒体数据的实时传输了。首先需要设置好数据发送的目标地址， RTP协议允许同一会话存在多个目标地址，这可以通过调用RTPSession类的AddDestination()、 DeleteDestination()和ClearDestinations()方法来完成。例如，下面的语句表示的是让RTP会话将数据发送到本地主
live555源码分析----RTP的打包与发送
热门推荐
gavin的专栏
12-02 2万+
这里主要分析一下，live555中关于RTP打包发送的部分。在处理完PLAY命令之后，就开始发送RTP数据包了(其实在发送PLAY命令的response包之前，就会发送一个RTP包，这里传输就已经开始了)     RTP包的发送是从MediaSink::startPlaying函数调用开始的 Boolean MediaSink::startPlaying(MediaSource& source
嵌入式流媒体音视频服务器EasyIPCamera中live555发送性能优化点
weixin_30691871的博客
09-02 236
EasyIPCamera流媒体服务器 今年EasyDarwin团队在给国内某最大的金融安防公司做技术咨询的时候，开发了一款适用于嵌入式IPCamera、NVR的RTSP流媒体服务器：EasyIPCamera，EasyIPCamera的核心是基于live555进行封装的，外围增加对live555 RTSPServer的调用接口，更加方便海思等安防芯片进行RTSPServer服务...
live555学习笔记－RTP打包与发送
雷霄骅(leixiaohua1020)的专栏
09-20 1万+
RTP打包与发送 rtp传送开始于函数：MediaSink::startPlaying()。想想也有道理，应是sink跟source要数据，所以从sink上调用startplaying（嘿嘿，相当于directshow的拉模式）。 看一下这个函数： [cpp] view plaincopy Boolean MediaSink::startPl
庖丁解牛-----Live555源码彻底解密(RTP打包)
smilestone322的专栏
02-04 3322
本文主要讲解live555的服务端RTP打包流程
RFC 3640：MPEG-4 elementary stream RTP payload format标准
"RFC3640.pdf" 是一份关于实时传输协议(RTP)承载MPEG-4基本流的规范，由Network Working Group J. van der Meer等多位专家联合制定，于2003年11月发布。该文档属于互联网标准跟踪类别，旨在为互联网社区提供一种简单...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值