live555 源码解析 --H264VideoStreamParser 详解

最近要做实时H264 RTP传输,那么如何充分利用live555来做呢?


大家可以看到现有的H264VideoFileServerMediaSubsession中,sink使用了H264VideoRTPSink,source使用了H264VideoStreamFramer,然而这个连接是很复杂的,在这两个节点间要插入了很多其它的节点,其实际情况是这样的:ByteStreamFileSource-->H264VideoStreamParser-->H264VideoStreamFramer-->H264FUAFragmenter-->H264VideoRTPSink.哇!真的这么复杂吗?一点没错!


当然你可以不用理它们的来龙去脉,你只需自己实现一个source,能采集图像并进行h264编码的source(当然你可以用CPU也可以用DSP进行编码),然后用它替代ByteStreamFileSource,就成了,比如你这个source可以叫做H264ByteStreamSource.当然为了提高效率,采集和编码部分应放在另一个线程中执行.


然而,我还是很想了解H264VideoStreamParser到底是什么,Parser到底有什么用?它做了什么?它与H264VideoStreamFramer是如何配合的?它们之间有内存copy发生吗?先设想一个问题:H264VideoStreamFramer是什么角色?跟据H264VideoFileServerMediaSubsession的代码,H264VideoStreamFramer是真正代表source的,Sink所面对的Source就是它.但是它又连接了一个ByteStreamFileSource.look一下这部分代码:

  1: FramedSource* H264VideoFileServerMediaSubsession:: 
  2: createNewStreamSource(unsigned /*clientSessionId*/, 
  3:         unsigned& estBitrate) 
  4: { 
  5:     estBitrate = 500; // kbps, estimate 
  6:  
  7:     // Create the video source: 
  8:     ByteStreamFileSource* fileSource = ByteStreamFileSource::createNew(envir(), 
  9:             fFileName); 
 10:     if (fileSource == NULL) 
 11:         return NULL; 
 12:     fFileSize = fileSource->fileSize(); 
 13:  
 14:     // Create a framer for the Video Elementary Stream: 
 15:     return H264VideoStreamFramer::createNew(envir(), fileSource); 
 16: }

ByteStreamFileSource是从文件取得数据的,它不管是到底什么媒体格式,它只是读文件.所以很明显H264VideoStreamFramer利用ByteStreamFileSource从文件取得数据,然后H264VideoStreamFramer再对数据进行分析.比如找出每个NALU,然后传给Sink.但是H264VideoStreamFramer没有自己去分析,而是利用了Parser,所以那一串中就多了一个H264VideoStreamParser.


H264VideoStreamParser拥有两个source指针,一个是FramedSource* fInputSource,另一个是H264VideoStreamFramer* fUsingSource.可以看出,H264VideoStreamParser把fInputSource和fUsingSource串了起来,那么fInputSource就是ByteStreamFileSource.


我们想像一下H264VideoStreamParser的所作所为:H264VideoStreamFramer把自己的缓冲(其实是sink的)传给H264VideoStreamParser,每当H264VideoStreamFramer要获取一个NALU时,就跟H264VideoStreamParser要,H264VideoStreamParser就从ByteStreamFileSource读一坨数据,然后进行分析,如果取得了一个NALU,就传给H264VideoStreamFramer.唉,H264VideoStreamFramer真是个不劳而获的坏家伙!
看一下实际的流程:

  1: //Sink调用Source(H264VideoStreamFramer)的GetNextFrame()获取数据, 
  2: //H264VideoStreamFramer从MPEGVideoStreamFramer派生,所以下面的函数会被调用: 
  3: void MPEGVideoStreamFramer::doGetNextFrame() 
  4: { 
  5:     fParser->registerReadInterest(fTo, fMaxSize); 
  6:     continueReadProcessing(); 
  7: } 
  8:  
  9: void MPEGVideoStreamFramer::continueReadProcessing(void* clientData, 
 10:         unsigned char* /*ptr*/, 
 11:         unsigned /*size*/, 
 12:         struct timeval /*presentationTime*/) 
 13: { 
 14:     MPEGVideoStreamFramer* framer = (MPEGVideoStreamFramer*) clientData; 
 15:     framer->continueReadProcessing(); 
 16: }

上两个是过渡,最终在这里执行:

  1: void MPEGVideoStreamFramer::continueReadProcessing() 
  2: { 
  3:     //调用Parser的parser()分析出一个NALU.如果得到了一个NALU,则 
  4:     //用afterGetting(this)返回给Sink. 
  5:     unsigned acquiredFrameSize = fParser->parse(); 
  6:     if (acquiredFrameSize > 0) 
  7:     { 
  8:         // We were able to acquire a frame from the input. 
  9:         // It has already been copied to the reader's space. 
 10:         fFrameSize = acquiredFrameSize; 
 11:         fNumTruncatedBytes = fParser->numTruncatedBytes(); 
 12:  
 13:         // "fPresentationTime" should have already been computed. 
 14:  
 15:         // Compute "fDurationInMicroseconds" now: 
 16:         fDurationInMicroseconds = 
 17:                 (fFrameRate == 0.0 || ((int) fPictureCount) < 0) ? 
 18:                         0 : (unsigned) ((fPictureCount * 1000000) / fFrameRate); 
 19:         fPictureCount = 0; 
 20:  
 21:         // Call our own 'after getting' function.  Because we're not a 'leaf' 
 22:         // source, we can call this directly, without risking infinite recursion. 
 23:         afterGetting(this); 
 24:     } 
 25:     else 
 26:     { 
 27:         //执行到此处并不代表parser()中没有取得数据!! 
 28:         // We were unable to parse a complete frame from the input, because: 
 29:         // - we had to read more data from the source stream, or 
 30:         // - the source stream has ended. 
 31:     } 
 32: }

上面这个函数的else{}中的注释大家注意了没有?这里关连到一个很难搞懂的现象,后面会解释之.这里先看一下parser()函数是怎样取得数据并进行分析的.parser()中读新数据是由那些test4Bytes(),skipBytes()之类的函数引起的,它们都最终调用了ensureValidBytes1():

  1: void StreamParser::ensureValidBytes1(unsigned numBytesNeeded) 
  2: { 
  3:     // We need to read some more bytes from the input source. 
  4:     // First, clarify how much data to ask for: 
  5:     unsigned maxInputFrameSize = fInputSource->maxFrameSize(); 
  6:     if (maxInputFrameSize > numBytesNeeded) 
  7:         numBytesNeeded = maxInputFrameSize; 
  8:  
  9:     // First, check whether these new bytes would overflow the current 
 10:     // bank.  If so, start using a new bank now. 
 11:     if (fCurParserIndex + numBytesNeeded > BANK_SIZE) 
 12:     { 
 13:         // Swap banks, but save any still-needed bytes from the old bank: 
 14:         unsigned numBytesToSave = fTotNumValidBytes - fSavedParserIndex; 
 15:         unsigned char const* from = &curBank()[fSavedParserIndex]; 
 16:  
 17:         fCurBankNum = (fCurBankNum + 1) % 2; 
 18:         fCurBank = fBank[fCurBankNum]; 
 19:         memmove(curBank(), from, numBytesToSave); 
 20:         fCurParserIndex = fCurParserIndex - fSavedParserIndex; 
 21:         fSavedParserIndex = 0; 
 22:         fTotNumValidBytes = numBytesToSave; 
 23:     } 
 24:  
 25:     // ASSERT: fCurParserIndex + numBytesNeeded > fTotNumValidBytes 
 26:     //      && fCurParserIndex + numBytesNeeded <= BANK_SIZE 
 27:     if (fCurParserIndex + numBytesNeeded > BANK_SIZE) 
 28:     { 
 29:         // If this happens, it means that we have too much saved parser state. 
 30:         // To fix this, increase BANK_SIZE as appropriate. 
 31:         fInputSource->envir() << "StreamParser internal error (" 
 32:                 << fCurParserIndex << "+ " << numBytesNeeded << " > " 
 33:                 << BANK_SIZE << ")\n"; 
 34:         fInputSource->envir().internalError(); 
 35:     } 
 36:  
 37:     // Try to read as many new bytes as will fit in the current bank: 
 38:     unsigned maxNumBytesToRead = BANK_SIZE - fTotNumValidBytes; 
 39:     fInputSource->getNextFrame(&curBank()[fTotNumValidBytes], maxNumBytesToRead, 
 40:             afterGettingBytes, this, onInputClosure, this); 
 41:  
 42:     throw NO_MORE_BUFFERED_INPUT; 
 43: }

可以看到一个奇怪的现象:这个函数没有返回值,但最终抛出了一个异常,而且只要执行这个函数,就会抛出这个异常.还是先分析一下这个函数做了什么吧:首先判断自己的缓冲区是否能容纳所需的数据量,如果实在不能,也只能提示一下,最后从ByteStreamFileSource获取一坨数据.curBack()返回的就是Parser自己的缓冲.而afterGettingBytes这个回调函数是H264VideoStreamFramer传入的,所以获取数据之后会执行H264VideoStreamFramer的函数,中转几下后,最终执行的就是上面的void MPEGVideoStreamFramer::continueReadProcessing().哇,看到了一个问题:Parser()中嵌套执行Parser()!而第二次执行Parser()完成后,返回到ensureValidBytes1(),然后由于抛出异常而退出,退出到哪里了呢?退回到上次调用的Parser()中了,因为Parser()中写了try{}catch{}.catch{}中的代码如下:

  1: catch (int /*e*/) 
  2: { 
  3: #ifdef DEBUG 
  4:         fprintf(stderr, "H264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error)\n"); 
  5: #endif 
  6:         return 0; // the parsing got interrupted 
  7: }

可见parser()此时返回0,parser()返回0就执行到MPEGVideoStreamFramer::continueReadProcessing()中的else{}部分了,回去看看吧,其实啥也没做.也就是说,第一次调用parser()时,它只是从ByteStreamFileSource获取数据,那么这个parser()获取数据后什么也不做,但实际上对NALU分析和处里在这次Parser()的调用中已经完成了,不是在它本身完成的,而是在它引起了parser()的嵌套调用中完成.好迷糊,理顺一下过程就知道了:
sink要获取数据,执行到MPEGVideoStreamFramer::continueReadProcessing(),MPEGVideoStreamFramer::continueReadProcessing调用parser(),parser()要使用数据时发现没有,于是ensureValidBytes1()被调用来从ByteStreamFileSource获取数据,取得数据后MPEGVideoStreamFramer::afterGettingBytes()被调用,并中转到MPEGVideoStreamFramer::continueReadProcessing(),MPEGVideoStreamFramer::continueReadProcessing()被嵌套调用!,MPEGVideoStreamFramer::continueReadProcessing()中又会调用parser(),此时parser()要使用数据时发现有数据了,所以就进行分析,分析出一个NALU后,返回到MPEGVideoStreamFramer::continueReadProcessing(),MPEGVideoStreamFramer::continueReadProcessing()会调用afterGetting(this)把数据返回给sink.sink处理完数据后返回到MPEGVideoStreamFramer::continueReadProcessing(),MPEGVideoStreamFramer::continueReadProcessing()再返回到ensureValidBytes1(),ensureValidBytes1()抛出异常返回到第一次被调用的parser()的catch{}中,parser()返回到第一次调用的MPEGVideoStreamFramer::continueReadProcessing()中,MPEGVideoStreamFramer::continueReadProcessing()发现parser()没有取得NALU,于是啥也不做,返回到sink中,sink会继续通过source->getNextFrame()->MPEGVideoStreamFramer::continueReadProcessing()...这样再次获取NALU.

可以看到,parser中是有自己的缓冲的,而且其大小是固定的:#define BANK_SIZE 150000
你自己写Source时,每次输出的是一帧数据,包含多个NALU,所以你只要确定你的一帧不超过150000字节,你就可以放心的往fTo中copy,如果你的帧太大,就改这个宏吧.

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值