live555学习笔记17

十七：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一下这部分代码：

FramedSource* H264VideoFileServerMediaSubsession::
createNewStreamSource(unsigned /*clientSessionId*/,
unsigned& estBitrate)
{
estBitrate = 500; // kbps, estimate

// Create the video source:
ByteStreamFileSource* fileSource = ByteStreamFileSource::createNew(envir(),
fFileName);
if (fileSource == NULL)
return NULL;
fFileSize = fileSource->fileSize();

// Create a framer for the Video Elementary Stream:
return H264VideoStreamFramer::createNew(envir(), fileSource);
}

是吧？我没有忽悠吧？
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真是个不劳而获的坏家伙！

看一下实际的流程：

//Sink调用Source(H264VideoStreamFramer)的GetNextFrame()获取数据，
//H264VideoStreamFramer从MPEGVideoStreamFramer派生，所以下面的函数会被调用：
void MPEGVideoStreamFramer::doGetNextFrame()
{
fParser->registerReadInterest(fTo, fMaxSize);
continueReadProcessing();
}

void MPEGVideoStreamFramer::continueReadProcessing(void* clientData,
unsigned char* /*ptr*/,
unsigned /*size*/,
struct timeval /*presentationTime*/)
{
MPEGVideoStreamFramer* framer = (MPEGVideoStreamFramer*) clientData;
framer->continueReadProcessing();
}

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

void MPEGVideoStreamFramer::continueReadProcessing()
{
//调用Parser的parser()分析出一个NALU.如果得到了一个NALU,则
//用afterGetting(this)返回给Sink.
unsigned acquiredFrameSize = fParser->parse();
if (acquiredFrameSize > 0)
{
// We were able to acquire a frame from the input.
// It has already been copied to the reader's space.
fFrameSize = acquiredFrameSize;
fNumTruncatedBytes = fParser->numTruncatedBytes();

// "fPresentationTime" should have already been computed.

// Compute "fDurationInMicroseconds" now:
fDurationInMicroseconds =
(fFrameRate == 0.0 || ((int) fPictureCount) < 0) ?
0 : (unsigned) ((fPictureCount * 1000000) / fFrameRate);
fPictureCount = 0;

// Call our own 'after getting' function.  Because we're not a 'leaf'
// source, we can call this directly, without risking infinite recursion.
afterGetting(this);
}
else
{
//执行到此处并不代表parser()中没有取得数据!!
// We were unable to parse a complete frame from the input, because:
// - we had to read more data from the source stream, or
// - the source stream has ended.
}
}

上面这个函数的else{}中的注释大家注意了没有?这里关连到一个很难搞懂的现象,后面会解释之.这里先看一下parser()函数是怎样取得数据并进行分析的.

parser()中读新数据是由那些test4Bytes(),skipBytes()之类的函数引起的,它们都最终调用了ensureValidBytes1():

void StreamParser::ensureValidBytes1(unsigned numBytesNeeded)
{
// We need to read some more bytes from the input source.
// First, clarify how much data to ask for:
unsigned maxInputFrameSize = fInputSource->maxFrameSize();
if (maxInputFrameSize > numBytesNeeded)
numBytesNeeded = maxInputFrameSize;

// First, check whether these new bytes would overflow the current
// bank.  If so, start using a new bank now.
if (fCurParserIndex + numBytesNeeded > BANK_SIZE)
{
// Swap banks, but save any still-needed bytes from the old bank:
unsigned numBytesToSave = fTotNumValidBytes - fSavedParserIndex;
unsigned char const* from = &curBank()[fSavedParserIndex];

fCurBankNum = (fCurBankNum + 1) % 2;
fCurBank = fBank[fCurBankNum];
memmove(curBank(), from, numBytesToSave);
fCurParserIndex = fCurParserIndex - fSavedParserIndex;
fSavedParserIndex = 0;
fTotNumValidBytes = numBytesToSave;
}

// ASSERT: fCurParserIndex + numBytesNeeded > fTotNumValidBytes
//      && fCurParserIndex + numBytesNeeded <= BANK_SIZE
if (fCurParserIndex + numBytesNeeded > BANK_SIZE)
{
// If this happens, it means that we have too much saved parser state.
// To fix this, increase BANK_SIZE as appropriate.
fInputSource->envir() << "StreamParser internal error ("
<< fCurParserIndex << "+ " << numBytesNeeded << " > "
<< BANK_SIZE << ")\n";
fInputSource->envir().internalError();
}

// Try to read as many new bytes as will fit in the current bank:
unsigned maxNumBytesToRead = BANK_SIZE - fTotNumValidBytes;
fInputSource->getNextFrame(&curBank()[fTotNumValidBytes], maxNumBytesToRead,
afterGettingBytes, this, onInputClosure, this);

throw NO_MORE_BUFFERED_INPUT;
}

可以看到一个奇怪的现象:这个函数没有返回值,但最终抛出了一个异常,而且只要执行这个函数,就会抛出这个异常.

还是先分析一下这个函数做了什么吧:

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

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

可见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,如果你的帧太大,就改这个宏吧.

在此公布一下
live555 QQ群号:
185130569.欢迎研究流媒体的人类加入,在其中可以讨论流媒体相关的任何东西,live555,ffmpeg,vlc,rtmp等等....

$(document).ready(function(){dp.SyntaxHighlighter.HighlightAll('code');});

原文链接：
http://blog.csdn.net/nkmnkm/article/details/7212181