oneboyishappy

live555学习4（转）

十一 h264 RTP传输详解(3)

书接上回：H264FUAFragmenter又对数据做了什么呢？

[cpp] view plain copy print ?

void H264FUAFragmenter::doGetNextFrame()
{
if (fNumValidDataBytes == 1) {
// We have no NAL unit data currently in the buffer. Read a new one:
fInputSource->getNextFrame(&fInputBuffer[1], fInputBufferSize - 1,
afterGettingFrame, this, FramedSource::handleClosure, this);
} else {
// We have NAL unit data in the buffer. There are three cases to consider:
// 1. There is a new NAL unit in the buffer, and it's small enough to deliver
// to the RTP sink (as is).
// 2. There is a new NAL unit in the buffer, but it's too large to deliver to
// the RTP sink in its entirety. Deliver the first fragment of this data,
// as a FU-A packet, with one extra preceding header byte.
// 3. There is a NAL unit in the buffer, and we've already delivered some
// fragment(s) of this. Deliver the next fragment of this data,
// as a FU-A packet, with two extra preceding header bytes.
if (fMaxSize < fMaxOutputPacketSize) { // shouldn't happen
envir() << "H264FUAFragmenter::doGetNextFrame(): fMaxSize ("
<< fMaxSize << ") is smaller than expected\n";
} else {
fMaxSize = fMaxOutputPacketSize;
}
fLastFragmentCompletedNALUnit = True; // by default
if (fCurDataOffset == 1) { // case 1 or 2
if (fNumValidDataBytes - 1 <= fMaxSize) { // case 1
memmove(fTo, &fInputBuffer[1], fNumValidDataBytes - 1);
fFrameSize = fNumValidDataBytes - 1;
fCurDataOffset = fNumValidDataBytes;
} else { // case 2
// We need to send the NAL unit data as FU-A packets. Deliver the first
// packet now. Note that we add FU indicator and FU header bytes to the front
// of the packet (reusing the existing NAL header byte for the FU header).
fInputBuffer[0] = (fInputBuffer[1] & 0xE0) | 28; // FU indicator
fInputBuffer[1] = 0x80 | (fInputBuffer[1] & 0x1F); // FU header (with S bit)
memmove(fTo, fInputBuffer, fMaxSize);
fFrameSize = fMaxSize;
fCurDataOffset += fMaxSize - 1;
fLastFragmentCompletedNALUnit = False;
}
} else { // case 3
// We are sending this NAL unit data as FU-A packets. We've already sent the
// first packet (fragment). Now, send the next fragment. Note that we add
// FU indicator and FU header bytes to the front. (We reuse these bytes that
// we already sent for the first fragment, but clear the S bit, and add the E
// bit if this is the last fragment.)
fInputBuffer[fCurDataOffset - 2] = fInputBuffer[0]; // FU indicator
fInputBuffer[fCurDataOffset - 1] = fInputBuffer[1] & ~0x80; // FU header (no S bit)
unsigned numBytesToSend = 2 + fNumValidDataBytes - fCurDataOffset;
if (numBytesToSend > fMaxSize) {
// We can't send all of the remaining data this time:
numBytesToSend = fMaxSize;
fLastFragmentCompletedNALUnit = False;
} else {
// This is the last fragment:
fInputBuffer[fCurDataOffset - 1] |= 0x40; // set the E bit in the FU header
fNumTruncatedBytes = fSaveNumTruncatedBytes;
}
memmove(fTo, &fInputBuffer[fCurDataOffset - 2], numBytesToSend);
fFrameSize = numBytesToSend;
fCurDataOffset += numBytesToSend - 2;
}
if (fCurDataOffset >= fNumValidDataBytes) {
// We're done with this data. Reset the pointers for receiving new data:
fNumValidDataBytes = fCurDataOffset = 1;
}
// Complete delivery to the client:
FramedSource::afterGetting(this);
}
}

void H264FUAFragmenter::doGetNextFrame()
{
	if (fNumValidDataBytes == 1) {
		// We have no NAL unit data currently in the buffer.  Read a new one:
		fInputSource->getNextFrame(&fInputBuffer[1], fInputBufferSize - 1,
				afterGettingFrame, this, FramedSource::handleClosure, this);
	} else {
		// We have NAL unit data in the buffer.  There are three cases to consider:
		// 1. There is a new NAL unit in the buffer, and it's small enough to deliver
		//    to the RTP sink (as is).
		// 2. There is a new NAL unit in the buffer, but it's too large to deliver to
		//    the RTP sink in its entirety.  Deliver the first fragment of this data,
		//    as a FU-A packet, with one extra preceding header byte.
		// 3. There is a NAL unit in the buffer, and we've already delivered some
		//    fragment(s) of this.  Deliver the next fragment of this data,
		//    as a FU-A packet, with two extra preceding header bytes.

		if (fMaxSize < fMaxOutputPacketSize) { // shouldn't happen
			envir() << "H264FUAFragmenter::doGetNextFrame(): fMaxSize ("
					<< fMaxSize << ") is smaller than expected\n";
		} else {
			fMaxSize = fMaxOutputPacketSize;
		}

		fLastFragmentCompletedNALUnit = True; // by default
		if (fCurDataOffset == 1) { // case 1 or 2
			if (fNumValidDataBytes - 1 <= fMaxSize) { // case 1
				memmove(fTo, &fInputBuffer[1], fNumValidDataBytes - 1);
				fFrameSize = fNumValidDataBytes - 1;
				fCurDataOffset = fNumValidDataBytes;
			} else { // case 2
				// We need to send the NAL unit data as FU-A packets.  Deliver the first
				// packet now.  Note that we add FU indicator and FU header bytes to the front
				// of the packet (reusing the existing NAL header byte for the FU header).
				fInputBuffer[0] = (fInputBuffer[1] & 0xE0) | 28; // FU indicator
				fInputBuffer[1] = 0x80 | (fInputBuffer[1] & 0x1F); // FU header (with S bit)
				memmove(fTo, fInputBuffer, fMaxSize);
				fFrameSize = fMaxSize;
				fCurDataOffset += fMaxSize - 1;
				fLastFragmentCompletedNALUnit = False;
			}
		} else { // case 3
			// We are sending this NAL unit data as FU-A packets.  We've already sent the
			// first packet (fragment).  Now, send the next fragment.  Note that we add
			// FU indicator and FU header bytes to the front.  (We reuse these bytes that
			// we already sent for the first fragment, but clear the S bit, and add the E
			// bit if this is the last fragment.)
			fInputBuffer[fCurDataOffset - 2] = fInputBuffer[0]; // FU indicator
			fInputBuffer[fCurDataOffset - 1] = fInputBuffer[1] & ~0x80; // FU header (no S bit)
			unsigned numBytesToSend = 2 + fNumValidDataBytes - fCurDataOffset;
			if (numBytesToSend > fMaxSize) {
				// We can't send all of the remaining data this time:
				numBytesToSend = fMaxSize;
				fLastFragmentCompletedNALUnit = False;
			} else {
				// This is the last fragment:
				fInputBuffer[fCurDataOffset - 1] |= 0x40; // set the E bit in the FU header
				fNumTruncatedBytes = fSaveNumTruncatedBytes;
			}
			memmove(fTo, &fInputBuffer[fCurDataOffset - 2], numBytesToSend);
			fFrameSize = numBytesToSend;
			fCurDataOffset += numBytesToSend - 2;
		}

		if (fCurDataOffset >= fNumValidDataBytes) {
			// We're done with this data.  Reset the pointers for receiving new data:
			fNumValidDataBytes = fCurDataOffset = 1;
		}

		// Complete delivery to the client:
		FramedSource::afterGetting(this);
	}
}

当fNumValidDataBytes等于１时，表明buffer(fInputBuffer)中没有Nal Unit数据，那么就读入一个新的．从哪里读呢？还记得前面讲过的吗？H264FUAFragmenter在第一次读数据时代替了H264VideoStreamFramer，同时也与H264VideoStreamFramer还有ByteStreamFileSource手牵着脚，脚牵着手形成了链结构．文件数据从ByteStreamFileSource读入，经H264VideoStreamFramer处理传给H264FUAFragmenter．ByteStreamFileSource返回给H264VideoStreamFramer一段数据，H264VideoStreamFramer返回一个H264FUAFragmenter一个Nal unit ．
H264FUAFragmenter对Nal Unit做了什么呢？先看注释：
当我们有了nal unit，要处理３种情况：
１有一个完整的nal unit，并且它小到能够被打包进rtp包中．
２有一个完整的nal unit，但是它很大，那么就得为它分片传送了，把第一片打入一个FU-A包，此时利用了缓冲中前面的一个字节的头部．
３一个nal unit的已被发送了一部分，那么我们继续按FU-A包发送．此时利用了缓冲中前面的处理中已使用的两个字节的头部．
fNumValidDataBytes是H264FUAFragmenter缓冲fInputBuffer中有效数据的字节数．可以看到fNumValidDataBytes重置时被置为１，为什么不是０呢？因为fInputBuffer的第一个字节一直被留用作AU-A包的头部．如果是single nal打包，则从fInputBuffer的第二字节开始把nal unit复制到输出缓冲fTo，如果是FU-A包，则从fInputBuffer的第一字节开始复制．

结合下文，可以很容易地把此段函数看明白（转自http://blog.csdn.net/perfectpdl/article/details/6633841）
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

H.264 视频 RTP 负载格式

1. 网络抽象层单元类型 (NALU)

NALU 头由一个字节组成, 它的语法如下:

      +---------------+
      |0|1|2|3|4|5|6|7|
      +-+-+-+-+-+-+-+-+
      |F|NRI| Type   |
      +---------------+

F: 1 个比特.
forbidden_zero_bit. 在 H.264 规范中规定了这一位必须为 0.

NRI: 2 个比特.
nal_ref_idc. 取 00 ~ 11, 似乎指示这个 NALU 的重要性, 如 00 的 NALU 解码器可以丢弃它而不影响图像的回放. 不过一般情况下不太关心

这个属性.

Type: 5 个比特.
nal_unit_type. 这个 NALU 单元的类型. 简述如下:

0     没有定义
1-23 NAL单元单个 NAL 单元包.
24    STAP-A   单一时间的组合包
25    STAP-B   单一时间的组合包
26    MTAP16   多个时间的组合包
27    MTAP24   多个时间的组合包
28    FU-A     分片的单元
29    FU-B     分片的单元
30-31 没有定义

2. 打包模式

下面是 RFC 3550 中规定的 RTP 头的结构.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V=2|P|X| CC   |M|     PT      |       sequence number         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           timestamp                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           synchronization source (SSRC) identifier            |
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      |            contributing source (CSRC) identifiers             |
      |                             ....                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

负载类型 Payload type (PT): 7 bits
序列号 Sequence number (SN): 16 bits
时间戳 Timestamp: 32 bits

H.264 Payload 格式定义了三种不同的基本的负载(Payload)结构. 接收端可能通过 RTP Payload
的第一个字节来识别它们. 这一个字节类似 NALU 头的格式, 而这个头结构的 NAL 单元类型字段
则指出了代表的是哪一种结构,

这个字节的结构如下, 可以看出它和 H.264 的 NALU 头结构是一样的.
      +---------------+
      |0|1|2|3|4|5|6|7|
      +-+-+-+-+-+-+-+-+
      |F|NRI| Type   |
      +---------------+
字段 Type: 这个 RTP payload 中 NAL 单元的类型. 这个字段和 H.264 中类型字段的区别是, 当 type
的值为 24 ~ 31 表示这是一个特别格式的 NAL 单元, 而 H.264 中, 只取 1~23 是有效的值.

24    STAP-A   单一时间的组合包
25    STAP-B   单一时间的组合包
26    MTAP16   多个时间的组合包
27    MTAP24   多个时间的组合包
28    FU-A     分片的单元
29    FU-B     分片的单元
30-31 没有定义

可能的结构类型分别有:

1. 单一 NAL 单元模式
即一个 RTP 包仅由一个完整的 NALU 组成. 这种情况下 RTP NAL 头类型字段和原始的 H.264的
NALU 头类型字段是一样的.

2. 组合封包模式
即可能是由多个 NAL 单元组成一个 RTP 包. 分别有4种组合方式: STAP-A, STAP-B, MTAP16, MTAP24.
那么这里的类型值分别是 24, 25, 26 以及 27.

3. 分片封包模式
用于把一个 NALU 单元封装成多个 RTP 包. 存在两种类型 FU-A 和 FU-B. 类型值分别是 28 和 29.

2.1 单一 NAL 单元模式

对于 NALU 的长度小于 MTU 大小的包, 一般采用单一 NAL 单元模式.
对于一个原始的 H.264 NALU 单元常由 [Start Code] [NALU Header] [NALU Payload] 三部分组成, 其中 Start Code 用于标示这是一个

NALU 单元的开始, 必须是 "00 00 00 01" 或 "00 00 01", NALU 头仅一个字节, 其后都是 NALU 单元内容.
打包时去除 "00 00 01" 或 "00 00 00 01" 的开始码, 把其他数据封包的 RTP 包即可.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |F|NRI| type   |                                               |
      +-+-+-+-+-+-+-+-+                                               |
      |                                                               |
      |               Bytes 2..n of a Single NAL unit                 |
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               :...OPTIONAL RTP padding        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

如有一个 H.264 的 NALU 是这样的:

[00 00 00 01 67 42 A0 1E 23 56 0E 2F ... ]

这是一个序列参数集 NAL 单元. [00 00 00 01] 是四个字节的开始码, 67 是 NALU 头, 42 开始的数据是 NALU 内容.

封装成 RTP 包将如下:

[ RTP Header ] [ 67 42 A0 1E 23 56 0E 2F ]

即只要去掉 4 个字节的开始码就可以了.

2.2 组合封包模式

其次, 当 NALU 的长度特别小时, 可以把几个 NALU 单元封在一个 RTP 包中.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          RTP Header                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |STAP-A NAL HDR |         NALU 1 Size           | NALU 1 HDR    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         NALU 1 Data                           |
      :                                                               :
      +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               | NALU 2 Size                   | NALU 2 HDR    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         NALU 2 Data                           |
      :                                                               :
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               :...OPTIONAL RTP padding        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.3 Fragmentation Units (FUs).

而当 NALU 的长度超过 MTU 时, 就必须对 NALU 单元进行分片封包. 也称为 Fragmentation Units (FUs).

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | FU indicator |   FU header   |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      |                                                               |
      |                         FU payload                            |
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               :...OPTIONAL RTP padding        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 14. RTP payload format for FU-A

The FU indicator octet has the following format:

      +---------------+
      |0|1|2|3|4|5|6|7|
      +-+-+-+-+-+-+-+-+
      |F|NRI| Type   |
      +---------------+

The FU header has the following format:

      +---------------+
      |0|1|2|3|4|5|6|7|
      +-+-+-+-+-+-+-+-+
      |S|E|R| Type   |
      +---------------+

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

H264FUAFragmenter中只支持single和FU-A模式，不支持其它模式．

我们现在还得出一个结论，我们可以看出RTPSink与Source怎样分工：RTPSink只做形成通用RTP包头的工作，各种媒体格式的Source才是实现媒体数据RTP封包的地方，其实按习惯感觉XXXRTPSink才是进行封包的地方．但是，从文件的安排上，H264FUAFragmenter被隐藏在H264VideoRTPSink中，并在程序中暗渡陈仓地把H264VideoStreamFramer替换掉，其实还是按习惯的架构（设计模式）来做的，所以如果把H264FUAFragmenter的工作移到H264VideoRTPSink中也是没问题的．

十二 h264 rtp包的时间戳

这次我们一起来分析一下live555中是怎样为rtp包打时间戳的．就以h264为例吧．

[cpp] view plain copy print ?

void H264VideoRTPSink::doSpecialFrameHandling(unsigned /*fragmentationOffset*/,
unsigned char* /*frameStart*/,
unsigned /*numBytesInFrame*/,
struct timeval framePresentationTime,
unsigned /*numRemainingBytes*/)
{
// Set the RTP 'M' (marker) bit iff
// 1/ The most recently delivered fragment was the end of (or the only fragment of) an NAL unit, and
// 2/ This NAL unit was the last NAL unit of an 'access unit' (i.e. video frame).
if (fOurFragmenter != NULL) {
H264VideoStreamFramer* framerSource = (H264VideoStreamFramer*) (fOurFragmenter->inputSource());
// This relies on our fragmenter's source being a "H264VideoStreamFramer".
if (fOurFragmenter->lastFragmentCompletedNALUnit()
&& framerSource != NULL && framerSource->pictureEndMarker()) {
setMarkerBit();
framerSource->pictureEndMarker() = False;
}
}
setTimestamp(framePresentationTime);
}

void H264VideoRTPSink::doSpecialFrameHandling(unsigned /*fragmentationOffset*/,
		unsigned char* /*frameStart*/,
		unsigned /*numBytesInFrame*/,
		struct timeval framePresentationTime,
		unsigned /*numRemainingBytes*/)
{
	// Set the RTP 'M' (marker) bit iff
	// 1/ The most recently delivered fragment was the end of (or the only fragment of) an NAL unit, and
	// 2/ This NAL unit was the last NAL unit of an 'access unit' (i.e. video frame).
	if (fOurFragmenter != NULL) {
		H264VideoStreamFramer* framerSource = (H264VideoStreamFramer*) (fOurFragmenter->inputSource());
		// This relies on our fragmenter's source being a "H264VideoStreamFramer".
		if (fOurFragmenter->lastFragmentCompletedNALUnit()
				&& framerSource != NULL && framerSource->pictureEndMarker()) {
			setMarkerBit();
			framerSource->pictureEndMarker() = False;
		}
	}

	setTimestamp(framePresentationTime);
}

函数中先检测是否是一个帧的最后一个包，如果是，打上'M'标记．然后就设置时间戳．这个间戳是哪来的呢？需看函数doSpecialFrameHandling()是被谁调用的，经查找，是被MultiFramedRTPSink::afterGettingFrame1()调用的．MultiFramedRTPSink::afterGettingFrame1()的参数presentationTime传给了doSpecialFrameHandling()．MultiFramedRTPSink::afterGettingFrame1()是在调用source的getNextFrame()时传给了source．传给哪个source呢？传给了H264FUAFragmenter,还记得暗渡陈仓那件事吗？所以H264FUAFragmenter在获取一个nal unit后调用了MultiFramedRTPSink::afterGettingFrame1()．也就是H264FUAFragmenter::afterGettingFrame1()调用了MultiFramedRTPSink::afterGettingFrame1()．
H264FUAFragmenter::afterGettingFrame1()是被它自己的source的afterGettingFrame1()调用的．H264FUAFragmenter的source是谁呢？是H264VideoStreamFramer，是在暗渡陈仓时传给H264FUAFragmenter的构造函数的．
H264VideoStreamFramer的afterGettingFrame1()是没有的，代替之的是MPEGVideoStreamFramer::continueReadProcessin()．它被MPEGVideoStreamParser暗中传给了StreamParser的构造函数．所以StreamParser在分析完一帧（或nal unit)之后，调用的就是MPEGVideoStreamFramer::continueReadProcessin()．以下即是证明：(补充：以下函数并不是在parser分析完一帧（或nal unit）之后调用，而是parser利用ByteStreamFileSuorce获取到原始数据后调用，然后MPEGVideoStreamFramer再调用Parser的parser()函数分析原始数据)

[cpp] view plain copy print ?

void StreamParser::afterGettingBytes(void* clientData,
unsigned numBytesRead,
unsigned /*numTruncatedBytes*/,
struct timeval presentationTime,
unsigned /*durationInMicroseconds*/)
{
StreamParser* parser = (StreamParser*) clientData;
if (parser != NULL)
parser->afterGettingBytes1(numBytesRead, presentationTime);
}
void StreamParser::afterGettingBytes1(unsigned numBytesRead,
struct timeval presentationTime)
{
// Sanity check: Make sure we didn't get too many bytes for our bank:
if (fTotNumValidBytes + numBytesRead > BANK_SIZE) {
fInputSource->envir()
<< "StreamParser::afterGettingBytes() warning: read "
<< numBytesRead << " bytes; expected no more than "
<< BANK_SIZE - fTotNumValidBytes << "\n";
}
fLastSeenPresentationTime = presentationTime;
unsigned char* ptr = &curBank()[fTotNumValidBytes];
fTotNumValidBytes += numBytesRead;
// Continue our original calling source where it left off:
restoreSavedParserState();
// Sigh... this is a crock; things would have been a lot simpler
// here if we were using threads, with synchronous I/O...
fClientContinueFunc(fClientContinueClientData, ptr, numBytesRead,
presentationTime);
}

void StreamParser::afterGettingBytes(void* clientData,
		unsigned numBytesRead,
		unsigned /*numTruncatedBytes*/,
		struct timeval presentationTime,
		unsigned /*durationInMicroseconds*/)
{
	StreamParser* parser = (StreamParser*) clientData;
	if (parser != NULL)
		parser->afterGettingBytes1(numBytesRead, presentationTime);
}

void StreamParser::afterGettingBytes1(unsigned numBytesRead,
		struct timeval presentationTime)
{
	// Sanity check: Make sure we didn't get too many bytes for our bank:
	if (fTotNumValidBytes + numBytesRead > BANK_SIZE) {
		fInputSource->envir()
				<< "StreamParser::afterGettingBytes() warning: read "
				<< numBytesRead << " bytes; expected no more than "
				<< BANK_SIZE - fTotNumValidBytes << "\n";
	}

	fLastSeenPresentationTime = presentationTime;

	unsigned char* ptr = &curBank()[fTotNumValidBytes];
	fTotNumValidBytes += numBytesRead;

	// Continue our original calling source where it left off:
	restoreSavedParserState();
	// Sigh... this is a crock; things would have been a lot simpler
	// here if we were using threads, with synchronous I/O...
	fClientContinueFunc(fClientContinueClientData, ptr, numBytesRead,
			presentationTime);
}

fClientContinueFunc就是MPEGVideoStreamFramer::continueReadProcessin()，而且我们看到时间戳被传入fClientContinueFunc．
然而，MPEGVideoStreamFramer::continueReadProcessin()中跟本就不理这个时间戳，因为这个时间戳是ByteStreamFileSource计算出来的，它跟本就不可能正确．

[cpp] view plain copy print ?

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

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

看来真正的时间戳是在MPEGVideoStreamFramer中计算的，但是H264VideoStreamFramer并没有用到MPEGVideoStreamFramer中那些计算时间戳的函数，而是另外计算，其实H264VideoStreamFramer也没有自己去计算，而是利用H264VideoStreamParser计算的．是在哪个函数中呢？在parser()中！

[cpp] view plain copy print ?

unsigned H264VideoStreamParser::parse()
{
try {
// The stream must start with a 0x00000001:
if (!fHaveSeenFirstStartCode) {
// Skip over any input bytes that precede the first 0x00000001:
u_int32_t first4Bytes;
while ((first4Bytes = test4Bytes()) != 0x00000001) {
get1Byte();
setParseState(); // ensures that we progress over bad data
}
skipBytes(4); // skip this initial code
setParseState();
fHaveSeenFirstStartCode = True; // from now on
}
if (fOutputStartCodeSize > 0) {
// Include a start code in the output:
save4Bytes(0x00000001);
}
// Then save everything up until the next 0x00000001 (4 bytes) or 0x000001 (3 bytes), or we hit EOF.
// Also make note of the first byte, because it contains the "nal_unit_type":
u_int8_t firstByte;
if (haveSeenEOF()) {
// We hit EOF the last time that we tried to parse this data,
// so we know that the remaining unparsed data forms a complete NAL unit:
unsigned remainingDataSize = totNumValidBytes() - curOffset();
if (remainingDataSize == 0)
(void) get1Byte(); // forces another read, which will cause EOF to get handled for real this time
if (remainingDataSize == 0)
return 0;
firstByte = get1Byte();
saveByte(firstByte);
while (--remainingDataSize > 0) {
saveByte(get1Byte());
}
} else {
u_int32_t next4Bytes = test4Bytes();
firstByte = next4Bytes >> 24;
while (next4Bytes != 0x00000001
&& (next4Bytes & 0xFFFFFF00) != 0x00000100) {
// We save at least some of "next4Bytes".
if ((unsigned) (next4Bytes & 0xFF) > 1) {
// Common case: 0x00000001 or 0x000001 definitely doesn't begin anywhere in "next4Bytes", so we save all of it:
save4Bytes(next4Bytes);
skipBytes(4);
} else {
// Save the first byte, and continue testing the rest:
saveByte(next4Bytes >> 24);
skipBytes(1);
}
next4Bytes = test4Bytes();
}
// Assert: next4Bytes starts with 0x00000001 or 0x000001, and we've saved all previous bytes (forming a complete NAL unit).
// Skip over these remaining bytes, up until the start of the next NAL unit:
if (next4Bytes == 0x00000001) {
skipBytes(4);
} else {
skipBytes(3);
}
}
u_int8_t nal_ref_idc = (firstByte & 0x60) >> 5;
u_int8_t nal_unit_type = firstByte & 0x1F;
switch (nal_unit_type) {
case 6: { // Supplemental enhancement information (SEI)
analyze_sei_data();
// Later, perhaps adjust "fPresentationTime" if we saw a "pic_timing" SEI payload??? #####
break;
}
case 7: { // Sequence parameter set
// First, save a copy of this NAL unit, in case the downstream object wants to see it:
usingSource()->saveCopyOfSPS(fStartOfFrame + fOutputStartCodeSize,
fTo - fStartOfFrame - fOutputStartCodeSize);
// Parse this NAL unit to check whether frame rate information is present:
unsigned num_units_in_tick, time_scale, fixed_frame_rate_flag;
analyze_seq_parameter_set_data(num_units_in_tick, time_scale,
fixed_frame_rate_flag);
if (time_scale > 0 && num_units_in_tick > 0) {
usingSource()->fFrameRate = time_scale
/ (2.0 * num_units_in_tick);
} else {
}
break;
}
case 8: { // Picture parameter set
// Save a copy of this NAL unit, in case the downstream object wants to see it:
usingSource()->saveCopyOfPPS(fStartOfFrame + fOutputStartCodeSize,
fTo - fStartOfFrame - fOutputStartCodeSize);
}
}
//更新时间戳变量
usingSource()->setPresentationTime();
// If this NAL unit is a VCL NAL unit, we also scan the start of the next NAL unit, to determine whether this NAL unit
// ends the current 'access unit'. We need this information to figure out when to increment "fPresentationTime".
// (RTP streamers also need to know this in order to figure out whether or not to set the "M" bit.)
Boolean thisNALUnitEndsAccessUnit = False; // until we learn otherwise
if (haveSeenEOF()) {
// There is no next NAL unit, so we assume that this one ends the current 'access unit':
thisNALUnitEndsAccessUnit = True;
} else {
Boolean const isVCL = nal_unit_type <= 5 && nal_unit_type > 0; // Would need to include type 20 for SVC and MVC #####
if (isVCL) {
u_int32_t first4BytesOfNextNALUnit = test4Bytes();
u_int8_t firstByteOfNextNALUnit = first4BytesOfNextNALUnit
>> 24;
u_int8_t next_nal_ref_idc = (firstByteOfNextNALUnit & 0x60)
>> 5;
u_int8_t next_nal_unit_type = firstByteOfNextNALUnit & 0x1F;
if (next_nal_unit_type >= 6) {
// The next NAL unit is not a VCL; therefore, we assume that this NAL unit ends the current 'access unit':
thisNALUnitEndsAccessUnit = True;
} else {
// The next NAL unit is also a VLC. We need to examine it a little to figure out if it's a different 'access unit'.
// (We use many of the criteria described in section 7.4.1.2.4 of the H.264 specification.)
Boolean IdrPicFlag = nal_unit_type == 5;
Boolean next_IdrPicFlag = next_nal_unit_type == 5;
if (next_IdrPicFlag != IdrPicFlag) {
// IdrPicFlag differs in value
thisNALUnitEndsAccessUnit = True;
} else if (next_nal_ref_idc != nal_ref_idc
&& next_nal_ref_idc * nal_ref_idc == 0) {
// nal_ref_idc differs in value with one of the nal_ref_idc values being equal to 0
thisNALUnitEndsAccessUnit = True;
} else if ((nal_unit_type == 1 || nal_unit_type == 2
|| nal_unit_type == 5)
&& (next_nal_unit_type == 1
|| next_nal_unit_type == 2
|| next_nal_unit_type == 5)) {
// Both this and the next NAL units begin with a "slice_header".
// Parse this (for each), to get parameters that we can compare:
// Current NAL unit's "slice_header":
unsigned frame_num, pic_parameter_set_id, idr_pic_id;
Boolean field_pic_flag, bottom_field_flag;
analyze_slice_header(
fStartOfFrame + fOutputStartCodeSize, fTo,
nal_unit_type, frame_num, pic_parameter_set_id,
idr_pic_id, field_pic_flag, bottom_field_flag);
// Next NAL unit's "slice_header":
u_int8_t next_slice_header[NUM_NEXT_SLICE_HEADER_BYTES_TO_ANALYZE];
testBytes(next_slice_header, sizeof next_slice_header);
unsigned next_frame_num, next_pic_parameter_set_id,
next_idr_pic_id;
Boolean next_field_pic_flag, next_bottom_field_flag;
analyze_slice_header(next_slice_header,
&next_slice_header[sizeof next_slice_header],
next_nal_unit_type, next_frame_num,
next_pic_parameter_set_id, next_idr_pic_id,
next_field_pic_flag, next_bottom_field_flag);
if (next_frame_num != frame_num) {
// frame_num differs in value
thisNALUnitEndsAccessUnit = True;
} else if (next_pic_parameter_set_id
!= pic_parameter_set_id) {
// pic_parameter_set_id differs in value
thisNALUnitEndsAccessUnit = True;
} else if (next_field_pic_flag != field_pic_flag) {
// field_pic_flag differs in value
thisNALUnitEndsAccessUnit = True;
} else if (next_bottom_field_flag
!= bottom_field_flag) {
// bottom_field_flag differs in value
thisNALUnitEndsAccessUnit = True;
} else if (next_IdrPicFlag == 1
&& next_idr_pic_id != idr_pic_id) {
// IdrPicFlag is equal to 1 for both and idr_pic_id differs in value
// Note: We already know that IdrPicFlag is the same for both.
thisNALUnitEndsAccessUnit = True;
}
}
}
}
}
//注意！注意！注意！此处计算时间戳！！
if (thisNALUnitEndsAccessUnit) {
usingSource()->fPictureEndMarker = True;
++usingSource()->fPictureCount;
// Note that the presentation time for the next NAL unit will be different:
struct timeval& nextPT = usingSource()->fNextPresentationTime; // alias
nextPT = usingSource()->fPresentationTime;
double nextFraction = nextPT.tv_usec / 1000000.0
+ 1 / usingSource()->fFrameRate;
unsigned nextSecsIncrement = (long) nextFraction;
nextPT.tv_sec += (long) nextSecsIncrement;
nextPT.tv_usec = (long) ((nextFraction - nextSecsIncrement)
* 1000000);
}
setParseState();
return curFrameSize();
} catch (int /*e*/) {
return 0; // the parsing got interrupted
}
}

unsigned H264VideoStreamParser::parse()
{
	try {
		// The stream must start with a 0x00000001:
		if (!fHaveSeenFirstStartCode) {
			// Skip over any input bytes that precede the first 0x00000001:
			u_int32_t first4Bytes;
			while ((first4Bytes = test4Bytes()) != 0x00000001) {
				get1Byte();
				setParseState(); // ensures that we progress over bad data
			}
			skipBytes(4); // skip this initial code

			setParseState();
			fHaveSeenFirstStartCode = True; // from now on
		}

		if (fOutputStartCodeSize > 0) {
			// Include a start code in the output:
			save4Bytes(0x00000001);
		}

		// Then save everything up until the next 0x00000001 (4 bytes) or 0x000001 (3 bytes), or we hit EOF.
		// Also make note of the first byte, because it contains the "nal_unit_type":
		u_int8_t firstByte;
		if (haveSeenEOF()) {
			// We hit EOF the last time that we tried to parse this data,
			// so we know that the remaining unparsed data forms a complete NAL unit:
			unsigned remainingDataSize = totNumValidBytes() - curOffset();
			if (remainingDataSize == 0)
				(void) get1Byte(); // forces another read, which will cause EOF to get handled for real this time
			if (remainingDataSize == 0)
				return 0;
			firstByte = get1Byte();
			saveByte(firstByte);

			while (--remainingDataSize > 0) {
				saveByte(get1Byte());
			}
		} else {
			u_int32_t next4Bytes = test4Bytes();
			firstByte = next4Bytes >> 24;
			while (next4Bytes != 0x00000001
					&& (next4Bytes & 0xFFFFFF00) != 0x00000100) {
				// We save at least some of "next4Bytes".
				if ((unsigned) (next4Bytes & 0xFF) > 1) {
					// Common case: 0x00000001 or 0x000001 definitely doesn't begin anywhere in "next4Bytes", so we save all of it:
					save4Bytes(next4Bytes);
					skipBytes(4);
				} else {
					// Save the first byte, and continue testing the rest:
					saveByte(next4Bytes >> 24);
					skipBytes(1);
				}
				next4Bytes = test4Bytes();
			}
			// Assert: next4Bytes starts with 0x00000001 or 0x000001, and we've saved all previous bytes (forming a complete NAL unit).
			// Skip over these remaining bytes, up until the start of the next NAL unit:
			if (next4Bytes == 0x00000001) {
				skipBytes(4);
			} else {
				skipBytes(3);
			}
		}

		u_int8_t nal_ref_idc = (firstByte & 0x60) >> 5;
		u_int8_t nal_unit_type = firstByte & 0x1F;

		switch (nal_unit_type) {
		case 6: { // Supplemental enhancement information (SEI)
			analyze_sei_data();
			// Later, perhaps adjust "fPresentationTime" if we saw a "pic_timing" SEI payload??? #####
			break;
		}
		case 7: { // Sequence parameter set
			// First, save a copy of this NAL unit, in case the downstream object wants to see it:
			usingSource()->saveCopyOfSPS(fStartOfFrame + fOutputStartCodeSize,
					fTo - fStartOfFrame - fOutputStartCodeSize);

			// Parse this NAL unit to check whether frame rate information is present:
			unsigned num_units_in_tick, time_scale, fixed_frame_rate_flag;
			analyze_seq_parameter_set_data(num_units_in_tick, time_scale,
					fixed_frame_rate_flag);
			if (time_scale > 0 && num_units_in_tick > 0) {
				usingSource()->fFrameRate = time_scale
						/ (2.0 * num_units_in_tick);
			} else {
			}
			break;
		}
		case 8: { // Picture parameter set
			// Save a copy of this NAL unit, in case the downstream object wants to see it:
			usingSource()->saveCopyOfPPS(fStartOfFrame + fOutputStartCodeSize,
					fTo - fStartOfFrame - fOutputStartCodeSize);
		}
		}

		//更新时间戳变量
		usingSource()->setPresentationTime();

		// If this NAL unit is a VCL NAL unit, we also scan the start of the next NAL unit, to determine whether this NAL unit
		// ends the current 'access unit'.  We need this information to figure out when to increment "fPresentationTime".
		// (RTP streamers also need to know this in order to figure out whether or not to set the "M" bit.)
		Boolean thisNALUnitEndsAccessUnit = False; // until we learn otherwise
		if (haveSeenEOF()) {
			// There is no next NAL unit, so we assume that this one ends the current 'access unit':
			thisNALUnitEndsAccessUnit = True;
		} else {
			Boolean const isVCL = nal_unit_type <= 5 && nal_unit_type > 0; // Would need to include type 20 for SVC and MVC #####
			if (isVCL) {
				u_int32_t first4BytesOfNextNALUnit = test4Bytes();
				u_int8_t firstByteOfNextNALUnit = first4BytesOfNextNALUnit
						>> 24;
				u_int8_t next_nal_ref_idc = (firstByteOfNextNALUnit & 0x60)
						>> 5;
				u_int8_t next_nal_unit_type = firstByteOfNextNALUnit & 0x1F;
				if (next_nal_unit_type >= 6) {
					// The next NAL unit is not a VCL; therefore, we assume that this NAL unit ends the current 'access unit':
					thisNALUnitEndsAccessUnit = True;
				} else {
					// The next NAL unit is also a VLC.  We need to examine it a little to figure out if it's a different 'access unit'.
					// (We use many of the criteria described in section 7.4.1.2.4 of the H.264 specification.)
					Boolean IdrPicFlag = nal_unit_type == 5;
					Boolean next_IdrPicFlag = next_nal_unit_type == 5;
					if (next_IdrPicFlag != IdrPicFlag) {
						// IdrPicFlag differs in value
						thisNALUnitEndsAccessUnit = True;
					} else if (next_nal_ref_idc != nal_ref_idc
							&& next_nal_ref_idc * nal_ref_idc == 0) {
						// nal_ref_idc differs in value with one of the nal_ref_idc values being equal to 0
						thisNALUnitEndsAccessUnit = True;
					} else if ((nal_unit_type == 1 || nal_unit_type == 2
							|| nal_unit_type == 5)
							&& (next_nal_unit_type == 1
									|| next_nal_unit_type == 2
									|| next_nal_unit_type == 5)) {
						// Both this and the next NAL units begin with a "slice_header".
						// Parse this (for each), to get parameters that we can compare:

						// Current NAL unit's "slice_header":
						unsigned frame_num, pic_parameter_set_id, idr_pic_id;
						Boolean field_pic_flag, bottom_field_flag;
						analyze_slice_header(
								fStartOfFrame + fOutputStartCodeSize, fTo,
								nal_unit_type, frame_num, pic_parameter_set_id,
								idr_pic_id, field_pic_flag, bottom_field_flag);

						// Next NAL unit's "slice_header":
						u_int8_t next_slice_header[NUM_NEXT_SLICE_HEADER_BYTES_TO_ANALYZE];
						testBytes(next_slice_header, sizeof next_slice_header);
						unsigned next_frame_num, next_pic_parameter_set_id,
								next_idr_pic_id;
						Boolean next_field_pic_flag, next_bottom_field_flag;
						analyze_slice_header(next_slice_header,
								&next_slice_header[sizeof next_slice_header],
								next_nal_unit_type, next_frame_num,
								next_pic_parameter_set_id, next_idr_pic_id,
								next_field_pic_flag, next_bottom_field_flag);

						if (next_frame_num != frame_num) {
							// frame_num differs in value
							thisNALUnitEndsAccessUnit = True;
						} else if (next_pic_parameter_set_id
								!= pic_parameter_set_id) {
							// pic_parameter_set_id differs in value
							thisNALUnitEndsAccessUnit = True;
						} else if (next_field_pic_flag != field_pic_flag) {
							// field_pic_flag differs in value
							thisNALUnitEndsAccessUnit = True;
						} else if (next_bottom_field_flag
								!= bottom_field_flag) {
							// bottom_field_flag differs in value
							thisNALUnitEndsAccessUnit = True;
						} else if (next_IdrPicFlag == 1
								&& next_idr_pic_id != idr_pic_id) {
							// IdrPicFlag is equal to 1 for both and idr_pic_id differs in value
							// Note: We already know that IdrPicFlag is the same for both.
							thisNALUnitEndsAccessUnit = True;
						}
					}
				}
			}
		}

		//注意！注意！注意！此处计算时间戳！！
		if (thisNALUnitEndsAccessUnit) {
			usingSource()->fPictureEndMarker = True;
			++usingSource()->fPictureCount;

			// Note that the presentation time for the next NAL unit will be different:
			struct timeval& nextPT = usingSource()->fNextPresentationTime; // alias
			nextPT = usingSource()->fPresentationTime;
			double nextFraction = nextPT.tv_usec / 1000000.0
					+ 1 / usingSource()->fFrameRate;
			unsigned nextSecsIncrement = (long) nextFraction;
			nextPT.tv_sec += (long) nextSecsIncrement;
			nextPT.tv_usec = (long) ((nextFraction - nextSecsIncrement)
					* 1000000);
		}
		setParseState();

		return curFrameSize();
	} catch (int /*e*/) {
		return 0; // the parsing got interrupted
	}
}

每当开始一个新帧时，计算新的时间戳．时间戳保存在fNextPresentationTime中，在usingSource()->setPresentationTime()中传给fPresentationTime.
哇，我们看到live555的类之间调用关系曲折复杂，的确有点不易维护啊！同时我写的也不够清析，自己看着都晕，如果把你搞晕了，这很正常哦！

fPresentationTime是64位的时间，经convertToRTPTimestamp转换为32的rtp时间戳，见函数：

[cpp] view plain copy print ?

u_int32_t RTPSink::convertToRTPTimestamp(struct timeval tv)
{
// Begin by converting from "struct timeval" units to RTP timestamp units:
u_int32_t timestampIncrement = (fTimestampFrequency * tv.tv_sec);
timestampIncrement += (u_int32_t)(
(2.0 * fTimestampFrequency * tv.tv_usec + 1000000.0) / 2000000);
// note: rounding
// Then add this to our 'timestamp base':
if (fNextTimestampHasBeenPreset) {
// Make the returned timestamp the same as the current "fTimestampBase",
// so that timestamps begin with the value that was previously preset:
fTimestampBase -= timestampIncrement;
fNextTimestampHasBeenPreset = False;
}
u_int32_t const rtpTimestamp = fTimestampBase + timestampIncrement;
return rtpTimestamp;
}

u_int32_t RTPSink::convertToRTPTimestamp(struct timeval tv)
{
	// Begin by converting from "struct timeval" units to RTP timestamp units:
	u_int32_t timestampIncrement = (fTimestampFrequency * tv.tv_sec);
	timestampIncrement += (u_int32_t)(
			(2.0 * fTimestampFrequency * tv.tv_usec + 1000000.0) / 2000000);
	// note: rounding

	// Then add this to our 'timestamp base':
	if (fNextTimestampHasBeenPreset) {
		// Make the returned timestamp the same as the current "fTimestampBase",
		// so that timestamps begin with the value that was previously preset:
		fTimestampBase -= timestampIncrement;
		fNextTimestampHasBeenPreset = False;
	}

	u_int32_t const rtpTimestamp = fTimestampBase + timestampIncrement;
	
	return rtpTimestamp;
}

其实时间戳的转换主要就是把以秒为单位的时间，提升成按频率为单位的时间．也就是提升后，时间间隔不是以秒为单位，而是以1/fTimestampFrequency为单位，也就是1/9000秒。然后再强转为32。

RTPInterface详解

好几天没写blog了。看源码真累啊，还要把理解的写到纸上，还要组织混乱的思想，令人头痛，所以这需要激情。不过，今天激情又来了。

大家应该已理解了GroupSocket这个类。理论上讲那些需要操作udp socket 的类应保存GroupSocket的实例。但事实并不是这样，可以看一下RTPSink，RTPSource，RTCPInstance等，它们都没有保存GroupSocket型的变量。那它们通过哪个类进行socket操作呢？是RTPInterface！！
这些类接收的GroupSocket指针最后都传给了 RTPInterface 。为什么用RTPInterface而不直接用GroupSocket呢？这里面有个故事...扯远了。

要解答这个问题，让我们先提出问题吧。
首先请问，Live555即支持rtp over udp，又支持rtp over tcp。那么在rtp over tcp情况下，用 GroupSocket 怎么实现呢？GroupSocket可是仅仅代表UDP啊！
那么RTPInterface既然用于网络读写，它就应该既支持tcp收发，也支持udp收发。而且它还要像GroupSocket那样支持一对多。因为服务端是一对多个客户端哦。我们看一下RTPInterface的成员：
Groupsock* fGS;
tcpStreamRecord* fTCPStreams; // optional, for RTP-over-TCP streaming/receiving
嘿嘿，这两个紧靠着，说明它们关系不一般啊（难道他们有一腿？）。fGS－－代表了一个udp socket和它对应的多个目的端，fTCPStreams--代表了多个TCP socket，当然这些socket都是从一个socket accept()出来的客户端socket（tcpStreamRecord是一个链表哦）。
看到这个架式，我想大家都要得出结论了：RTPInterface还真是男女通吃啊！不论你客户端与我建立的是tcp连接，还是udp连接，我RTPInterface一律能接收你们的数据，并向你们发出数据！

证据一：向所有客户端发出数据：

[cpp] view plain copy print ?

Boolean RTPInterface::sendPacket(unsigned char* packet, unsigned packetSize)
{
Boolean success = True; // we'll return False instead if any of the sends fail
// Normal case: Send as a UDP packet:
if (!fGS->output(envir(), fGS->ttl(), packet, packetSize))
success = False;
// Also, send over each of our TCP sockets:
for (tcpStreamRecord* streams = fTCPStreams; streams != NULL;
streams = streams->fNext) {
if (!sendRTPOverTCP(packet, packetSize, streams->fStreamSocketNum,
streams->fStreamChannelId)) {
success = False;
}
}
return success;
}

Boolean RTPInterface::sendPacket(unsigned char* packet, unsigned packetSize)
{
	Boolean success = True; // we'll return False instead if any of the sends fail

	// Normal case: Send as a UDP packet:
	if (!fGS->output(envir(), fGS->ttl(), packet, packetSize))
		success = False;

	// Also, send over each of our TCP sockets:
	for (tcpStreamRecord* streams = fTCPStreams; streams != NULL;
			streams = streams->fNext) {
		if (!sendRTPOverTCP(packet, packetSize, streams->fStreamSocketNum,
				streams->fStreamChannelId)) {
			success = False;
		}
	}

	return success;
}

很明显啊，先发送udp数据，一对多的问题在GroupSocket中解决。再发送tcp数据，一对多的问题本地解决。
证据二：从所有客户端读取数据：
我现在找不到直接的证据，所以我就憶想一下吧：当udp端口或tcp端口收到数据时，分析后，是哪个客户端的数据就发给对应这个客户端的RTPSink或RTCPInstance。
好像已经把最开始的问题解答完了。下面让我们来分析一下RTPInterface吧。

[cpp] view plain copy print ?

void RTPInterface::setStreamSocket(int sockNum, unsigned char streamChannelId)
{
fGS->removeAllDestinations();
addStreamSocket(sockNum, streamChannelId);
}
void RTPInterface::addStreamSocket(int sockNum, unsigned char streamChannelId)
{
if (sockNum < 0)
return;
for (tcpStreamRecord* streams = fTCPStreams; streams != NULL;
streams = streams->fNext) {
if (streams->fStreamSocketNum == sockNum
&& streams->fStreamChannelId == streamChannelId) {
return; // we already have it
}
}
fTCPStreams = new tcpStreamRecord(sockNum, streamChannelId, fTCPStreams);
}

void RTPInterface::setStreamSocket(int sockNum, unsigned char streamChannelId)
{
	fGS->removeAllDestinations();
	addStreamSocket(sockNum, streamChannelId);
}

void RTPInterface::addStreamSocket(int sockNum, unsigned char streamChannelId)
{
	if (sockNum < 0)
		return;

	for (tcpStreamRecord* streams = fTCPStreams; streams != NULL;
			streams = streams->fNext) {
		if (streams->fStreamSocketNum == sockNum
				&& streams->fStreamChannelId == streamChannelId) {
			return; // we already have it
		}
	}

	fTCPStreams = new tcpStreamRecord(sockNum, streamChannelId, fTCPStreams);
}

setStreamSocket()没必要说了吧，看一下addStreamSocke()。从字面意思应能了解，添加一个流式Socket，也就是添加tcp
socket了。循环中查找是否已经存在了，最后如果不存在，就创建之，在tcpStreamRecord的构造函数中己经把自己加入了链表。对于参数，sockNum很易理解，就是socket()返回的那个SOCKET型
数据呗，streamChannelId是什么呢？我们不防再猜测一下（很奇怪，我每次都能猜对，嘿嘿...）：rtp over tcp时，这个tcp连接是直接利用了RTSP所用的那个tcp连接，如果同时有很多rtp
session，再加上rtsp session，大家都用这一个socket通信，怎么区分你的还是我的?我想这个channel
id就是用于解决这个问题。给每个session分配一个唯一的id，在发送自己的包时为包再加上个头部，头部中需要有session的标记－－也就是这个channel id，包的长度等等字段。这样大家就可以穿一条裤子了，术语叫多路复用，但要注意只有tcp才进行多路复用，udp是不用的，因为udp是一个session对应一个socket（加上RTCP是两个）。
想像一下，服务端要从这个tcp socket读写数据，必须把一个handler加入TaskScheduler中，这个handler在可读数据时进行读，在可写数据时进行写。在读数据时，对读出的数据进行分析，取得数据包的长度，以及其channel id，跟据channel id找到相应的处handler和对象，交给它们去处理自己的数据。
试想两个建立在tcp上的rtp session，这个两个tcp socket既担负着rtsp通讯，又担负着rtp通讯。如果这两个rtp session共用一个stream，那么最终负责这两个session通信的就只有一个RTPInterface，那么这个RTPInterface中的fTCPStreams这个链表中就会有两项，分别对应这两个session。tcpStreamRecord主要用于socket number与channel id的对应。这些tcpStreamRecord是通过addStreamSocket()添加的。处理数据的handler是通过startNetworkReading（）添加的，看一下下：

[cpp] view plain copy print ?

void RTPInterface::startNetworkReading(TaskScheduler::BackgroundHandlerProc* handlerProc)
{
// Normal case: Arrange to read UDP packets:
envir().taskScheduler().turnOnBackgroundReadHandling(fGS->socketNum(),handlerProc,
fOwner);
// Also, receive RTP over TCP, on each of our TCP connections:
fReadHandlerProc = handlerProc;
for (tcpStreamRecord* streams = fTCPStreams; streams != NULL;
streams = streams->fNext) {
// Get a socket descriptor for "streams->fStreamSocketNum":
SocketDescriptor* socketDescriptor = lookupSocketDescriptor(envir(),
streams->fStreamSocketNum);
// Tell it about our subChannel:
socketDescriptor->registerRTPInterface(streams->fStreamChannelId, this);
}
}

void RTPInterface::startNetworkReading(TaskScheduler::BackgroundHandlerProc* handlerProc)
{
	// Normal case: Arrange to read UDP packets:
	envir().taskScheduler().turnOnBackgroundReadHandling(fGS->socketNum(),handlerProc,
		fOwner);

	// Also, receive RTP over TCP, on each of our TCP connections:
	fReadHandlerProc = handlerProc;
	for (tcpStreamRecord* streams = fTCPStreams; streams != NULL;
			streams = streams->fNext) {
		// Get a socket descriptor for "streams->fStreamSocketNum":
		SocketDescriptor* socketDescriptor = lookupSocketDescriptor(envir(),
				streams->fStreamSocketNum);

		// Tell it about our subChannel:
		socketDescriptor->registerRTPInterface(streams->fStreamChannelId, this);
	}
}

用UDP时很简单，直接把处理函数做为handler加入taskScheduler即可。而TCP时，需向所有的session的socket都注册自己。可以想像，socketDescriptor代表一个tcp socket，并且它有一个链表之类的东西，其中保存了所有的对这个socket感兴趣的RTPInterface，同时也记录了RTPInterface对应的channal id。只有向socketDescriptor注册了自己，socketDescriptor在读取数据时，才能跟据分析出的channel id找到对应的RTPInterface，才能调用RTPInterface中的数据处理handler，当然，这个函数也不是RTPInteface自己的，而是从startNetworkReading()这个函数接收到的调用者的。
上述主要讲的是一个RTPInterface对应多个客户端tcp socket的情形。现在又发现一个问题：SocketDescriptor为什么需要对应多个RTPInterface呢？上面已经讲了，是为了多路复用，因为这个socket即负担rtsp通信又负担rtp通信还负担RTCP通信。SocketDescriptor记录多路复用数据（也就是RTPInterface与channel id）用了一个Hash table：HashTable* fSubChannelHashTable。SocketDescriptor读数据使用函数：static void tcpReadHandler(SocketDescriptor*, int mask)。证据如下：

[cpp] view plain copy print ?

void SocketDescriptor::registerRTPInterface(
unsigned char streamChannelId,
RTPInterface* rtpInterface)
{
Boolean isFirstRegistration = fSubChannelHashTable->IsEmpty();
fSubChannelHashTable->Add((char const*) (long) streamChannelId,
rtpInterface);
if (isFirstRegistration) {
// Arrange to handle reads on this TCP socket:
TaskScheduler::BackgroundHandlerProc* handler =
(TaskScheduler::BackgroundHandlerProc*) &tcpReadHandler;
fEnv.taskScheduler().turnOnBackgroundReadHandling(fOurSocketNum,
handler, this);
}
}

void SocketDescriptor::registerRTPInterface(
unsigned char streamChannelId,
		RTPInterface* rtpInterface)
{
	Boolean isFirstRegistration = fSubChannelHashTable->IsEmpty();
	fSubChannelHashTable->Add((char const*) (long) streamChannelId,
			rtpInterface);

	if (isFirstRegistration) {
		// Arrange to handle reads on this TCP socket:
		TaskScheduler::BackgroundHandlerProc* handler = 
			(TaskScheduler::BackgroundHandlerProc*) &tcpReadHandler;
		fEnv.taskScheduler().turnOnBackgroundReadHandling(fOurSocketNum,
				handler, this);
	}
}

可见在注册第一个多路复用对象时启动reand handler。看一下函数主体：

[cpp] view plain copy print ?

void SocketDescriptor::tcpReadHandler1(int mask)
{
// We expect the following data over the TCP channel:
// optional RTSP command or response bytes (before the first '$' character)
// a '$' character
// a 1-byte channel id
// a 2-byte packet size (in network byte order)
// the packet data.
// However, because the socket is being read asynchronously, this data might arrive in pieces.
u_int8_t c;
struct sockaddr_in fromAddress;
if (fTCPReadingState != AWAITING_PACKET_DATA) {
int result = readSocket(fEnv, fOurSocketNum, &c, 1, fromAddress);
if (result != 1) { // error reading TCP socket, or no more data available
if (result < 0) { // error
fEnv.taskScheduler().turnOffBackgroundReadHandling(
fOurSocketNum); // stops further calls to us
}
return;
}
}
switch (fTCPReadingState) {
case AWAITING_DOLLAR: {
if (c == '$') {
fTCPReadingState = AWAITING_STREAM_CHANNEL_ID;
} else {
// This character is part of a RTSP request or command, which is handled separately:
if (fServerRequestAlternativeByteHandler != NULL) {
(*fServerRequestAlternativeByteHandler)(
fServerRequestAlternativeByteHandlerClientData, c);
}
}
break;
}
case AWAITING_STREAM_CHANNEL_ID: {
// The byte that we read is the stream channel id.
if (lookupRTPInterface(c) != NULL) { // sanity check
fStreamChannelId = c;
fTCPReadingState = AWAITING_SIZE1;
} else {
// This wasn't a stream channel id that we expected. We're (somehow) in a strange state. Try to recover:
fTCPReadingState = AWAITING_DOLLAR;
}
break;
}
case AWAITING_SIZE1: {
// The byte that we read is the first (high) byte of the 16-bit RTP or RTCP packet 'size'.
fSizeByte1 = c;
fTCPReadingState = AWAITING_SIZE2;
break;
}
case AWAITING_SIZE2: {
// The byte that we read is the second (low) byte of the 16-bit RTP or RTCP packet 'size'.
unsigned short size = (fSizeByte1 << 8) | c;
// Record the information about the packet data that will be read next:
RTPInterface* rtpInterface = lookupRTPInterface(fStreamChannelId);
if (rtpInterface != NULL) {
rtpInterface->fNextTCPReadSize = size;
rtpInterface->fNextTCPReadStreamSocketNum = fOurSocketNum;
rtpInterface->fNextTCPReadStreamChannelId = fStreamChannelId;
}
fTCPReadingState = AWAITING_PACKET_DATA;
break;
}
case AWAITING_PACKET_DATA: {
// Call the appropriate read handler to get the packet data from the TCP stream:
RTPInterface* rtpInterface = lookupRTPInterface(fStreamChannelId);
if (rtpInterface != NULL) {
if (rtpInterface->fNextTCPReadSize == 0) {
// We've already read all the data for this packet.
fTCPReadingState = AWAITING_DOLLAR;
break;
}
if (rtpInterface->fReadHandlerProc != NULL) {
rtpInterface->fReadHandlerProc(rtpInterface->fOwner, mask);
}
}
return;
}
}
}

void SocketDescriptor::tcpReadHandler1(int mask)
{
	// We expect the following data over the TCP channel:
	//   optional RTSP command or response bytes (before the first '$' character)
	//   a '$' character
	//   a 1-byte channel id
	//   a 2-byte packet size (in network byte order)
	//   the packet data.
	// However, because the socket is being read asynchronously, this data might arrive in pieces.

	u_int8_t c;
	struct sockaddr_in fromAddress;
	if (fTCPReadingState != AWAITING_PACKET_DATA) {
		int result = readSocket(fEnv, fOurSocketNum, &c, 1, fromAddress);
		if (result != 1) { // error reading TCP socket, or no more data available
			if (result < 0) { // error
				fEnv.taskScheduler().turnOffBackgroundReadHandling(
						fOurSocketNum); // stops further calls to us
			}
			return;
		}
	}

	switch (fTCPReadingState) {
	case AWAITING_DOLLAR: {
		if (c == '$') {
			fTCPReadingState = AWAITING_STREAM_CHANNEL_ID;
		} else {
			// This character is part of a RTSP request or command, which is handled separately:
			if (fServerRequestAlternativeByteHandler != NULL) {
				(*fServerRequestAlternativeByteHandler)(
						fServerRequestAlternativeByteHandlerClientData, c);
			}
		}
		break;
	}
	case AWAITING_STREAM_CHANNEL_ID: {
		// The byte that we read is the stream channel id.
		if (lookupRTPInterface(c) != NULL) { // sanity check
			fStreamChannelId = c;
			fTCPReadingState = AWAITING_SIZE1;
		} else {
			// This wasn't a stream channel id that we expected.  We're (somehow) in a strange state.  Try to recover:
			fTCPReadingState = AWAITING_DOLLAR;
		}
		break;
	}
	case AWAITING_SIZE1: {
		// The byte that we read is the first (high) byte of the 16-bit RTP or RTCP packet 'size'.
		fSizeByte1 = c;
		fTCPReadingState = AWAITING_SIZE2;
		break;
	}
	case AWAITING_SIZE2: {
		// The byte that we read is the second (low) byte of the 16-bit RTP or RTCP packet 'size'.
		unsigned short size = (fSizeByte1 << 8) | c;

		// Record the information about the packet data that will be read next:
		RTPInterface* rtpInterface = lookupRTPInterface(fStreamChannelId);
		if (rtpInterface != NULL) {
			rtpInterface->fNextTCPReadSize = size;
			rtpInterface->fNextTCPReadStreamSocketNum = fOurSocketNum;
			rtpInterface->fNextTCPReadStreamChannelId = fStreamChannelId;
		}
		fTCPReadingState = AWAITING_PACKET_DATA;
		break;
	}
	case AWAITING_PACKET_DATA: {
		// Call the appropriate read handler to get the packet data from the TCP stream:
		RTPInterface* rtpInterface = lookupRTPInterface(fStreamChannelId);
		if (rtpInterface != NULL) {
			if (rtpInterface->fNextTCPReadSize == 0) {
				// We've already read all the data for this packet.
				fTCPReadingState = AWAITING_DOLLAR;
				break;
			}
			if (rtpInterface->fReadHandlerProc != NULL) {
				rtpInterface->fReadHandlerProc(rtpInterface->fOwner, mask);
			}
		}
		return;
	}
	}
}

最开始的注释中解释了多路复用头的格式。这一段引起了我的兴趣：

[cpp] view plain copy print ?

case AWAITING_DOLLAR: {
if (c == $) {
fTCPReadingState = AWAITING_STREAM_CHANNEL_ID;
} else {
// This character is part of a RTSP request or command, which is handled separately:
if (fServerRequestAlternativeByteHandler != NULL) {
(*fServerRequestAlternativeByteHandler)(
fServerRequestAlternativeByteHandlerClientData, c);
}
}
break;
}

case AWAITING_DOLLAR: {
		if (c == $) {
			fTCPReadingState = AWAITING_STREAM_CHANNEL_ID;
		} else {
			// This character is part of a RTSP request or command, which is handled separately:
			if (fServerRequestAlternativeByteHandler != NULL) {
				(*fServerRequestAlternativeByteHandler)(
						fServerRequestAlternativeByteHandlerClientData, c);
			}
		}
		break;
	}

啊！原来ServerRequestAlternativeByteHandler是用于处理RTSP数据的。也就是从这个socket收到RTSP数据时，调用ServerRequestAlternativeByteHandler。如果收到RTP/RTCP数据时，先查看其channel id，跟据id找到RTPInterface(RTCP也是用了RTPIterface进行通信)，设置RTPInterface中与读缓冲有关的变量，然后当读到包数据的开始位置时，调用rtpInterface中保存的数据处理handler。还记得吧，rtpInterface中的这个数据处理handler在UDP时也被使用，在这个函数中要做的是读取一个包的数据，然后处理这个包。而SocketDescriptor把读取位置置于包数据开始的位置再交给数据处理handler，正好可以使用与UDP相同的数据处理handler！
还有，socketDescriptor们并不属于任何RTPInterface，而是单独保存在一个Hash table中，这样多个RTPInterface都可以注册到一个socketDescriptor中，以实现多路复用。
总结一下通过RTPInterface，live555不仅实现了rtp over udp，还实现了rtp over tcp，而且还实现了同时即有rtp over tcp，又有rtp over udp！
最后，channel id是从哪里来的呢？是在RTSP请求中指定的。在哪个请求中呢？自己找去吧。

十三：RTPInterface详解

好几天没写blog了。看源码真累啊，还要把理解的写到纸上，还要组织混乱的思想，令人头痛，所以这需要激情。不过，今天激情又来了。

大家应该已理解了GroupSocket这个类。理论上讲那些需要操作udp socket 的类应保存GroupSocket的实例。但事实并不是这样，可以看一下RTPSink，RTPSource，RTCPInstance等，它们都没有保存GroupSocket型的变量。那它们通过哪个类进行socket操作呢？是RTPInterface！！
这些类接收的GroupSocket指针最后都传给了 RTPInterface 。为什么用RTPInterface而不直接用GroupSocket呢？这里面有个故事...扯远了。

要解答这个问题，让我们先提出问题吧。
首先请问，Live555即支持rtp over udp，又支持rtp over tcp。那么在rtp over tcp情况下，用 GroupSocket 怎么实现呢？GroupSocket可是仅仅代表UDP啊！
那么RTPInterface既然用于网络读写，它就应该既支持tcp收发，也支持udp收发。而且它还要像GroupSocket那样支持一对多。因为服务端是一对多个客户端哦。我们看一下RTPInterface的成员：
Groupsock* fGS;
tcpStreamRecord* fTCPStreams; // optional, for RTP-over-TCP streaming/receiving
嘿嘿，这两个紧靠着，说明它们关系不一般啊（难道他们有一腿？）。fGS－－代表了一个udp socket和它对应的多个目的端，fTCPStreams--代表了多个TCP socket，当然这些socket都是从一个socket accept()出来的客户端socket（tcpStreamRecord是一个链表哦）。
看到这个架式，我想大家都要得出结论了：RTPInterface还真是男女通吃啊！不论你客户端与我建立的是tcp连接，还是udp连接，我RTPInterface一律能接收你们的数据，并向你们发出数据！

证据一：向所有客户端发出数据：

[cpp] view plain copy print ?

Boolean RTPInterface::sendPacket(unsigned char* packet, unsigned packetSize)
{
Boolean success = True; // we'll return False instead if any of the sends fail
// Normal case: Send as a UDP packet:
if (!fGS->output(envir(), fGS->ttl(), packet, packetSize))
success = False;
// Also, send over each of our TCP sockets:
for (tcpStreamRecord* streams = fTCPStreams; streams != NULL;
streams = streams->fNext) {
if (!sendRTPOverTCP(packet, packetSize, streams->fStreamSocketNum,
streams->fStreamChannelId)) {
success = False;
}
}
return success;
}

Boolean RTPInterface::sendPacket(unsigned char* packet, unsigned packetSize)
{
	Boolean success = True; // we'll return False instead if any of the sends fail

	// Normal case: Send as a UDP packet:
	if (!fGS->output(envir(), fGS->ttl(), packet, packetSize))
		success = False;

	// Also, send over each of our TCP sockets:
	for (tcpStreamRecord* streams = fTCPStreams; streams != NULL;
			streams = streams->fNext) {
		if (!sendRTPOverTCP(packet, packetSize, streams->fStreamSocketNum,
				streams->fStreamChannelId)) {
			success = False;
		}
	}

	return success;
}

[cpp] view plain copy print ?

void RTPInterface::setStreamSocket(int sockNum, unsigned char streamChannelId)
{
fGS->removeAllDestinations();
addStreamSocket(sockNum, streamChannelId);
}
void RTPInterface::addStreamSocket(int sockNum, unsigned char streamChannelId)
{
if (sockNum < 0)
return;
for (tcpStreamRecord* streams = fTCPStreams; streams != NULL;
streams = streams->fNext) {
if (streams->fStreamSocketNum == sockNum
&& streams->fStreamChannelId == streamChannelId) {
return; // we already have it
}
}
fTCPStreams = new tcpStreamRecord(sockNum, streamChannelId, fTCPStreams);
}

void RTPInterface::setStreamSocket(int sockNum, unsigned char streamChannelId)
{
	fGS->removeAllDestinations();
	addStreamSocket(sockNum, streamChannelId);
}

void RTPInterface::addStreamSocket(int sockNum, unsigned char streamChannelId)
{
	if (sockNum < 0)
		return;

	for (tcpStreamRecord* streams = fTCPStreams; streams != NULL;
			streams = streams->fNext) {
		if (streams->fStreamSocketNum == sockNum
				&& streams->fStreamChannelId == streamChannelId) {
			return; // we already have it
		}
	}

	fTCPStreams = new tcpStreamRecord(sockNum, streamChannelId, fTCPStreams);
}

[cpp] view plain copy print ?

void RTPInterface::startNetworkReading(TaskScheduler::BackgroundHandlerProc* handlerProc)
{
// Normal case: Arrange to read UDP packets:
envir().taskScheduler().turnOnBackgroundReadHandling(fGS->socketNum(),handlerProc,
fOwner);
// Also, receive RTP over TCP, on each of our TCP connections:
fReadHandlerProc = handlerProc;
for (tcpStreamRecord* streams = fTCPStreams; streams != NULL;
streams = streams->fNext) {
// Get a socket descriptor for "streams->fStreamSocketNum":
SocketDescriptor* socketDescriptor = lookupSocketDescriptor(envir(),
streams->fStreamSocketNum);
// Tell it about our subChannel:
socketDescriptor->registerRTPInterface(streams->fStreamChannelId, this);
}
}

void RTPInterface::startNetworkReading(TaskScheduler::BackgroundHandlerProc* handlerProc)
{
	// Normal case: Arrange to read UDP packets:
	envir().taskScheduler().turnOnBackgroundReadHandling(fGS->socketNum(),handlerProc,
		fOwner);

	// Also, receive RTP over TCP, on each of our TCP connections:
	fReadHandlerProc = handlerProc;
	for (tcpStreamRecord* streams = fTCPStreams; streams != NULL;
			streams = streams->fNext) {
		// Get a socket descriptor for "streams->fStreamSocketNum":
		SocketDescriptor* socketDescriptor = lookupSocketDescriptor(envir(),
				streams->fStreamSocketNum);

		// Tell it about our subChannel:
		socketDescriptor->registerRTPInterface(streams->fStreamChannelId, this);
	}
}

[cpp] view plain copy print ?

void SocketDescriptor::registerRTPInterface(
unsigned char streamChannelId,
RTPInterface* rtpInterface)
{
Boolean isFirstRegistration = fSubChannelHashTable->IsEmpty();
fSubChannelHashTable->Add((char const*) (long) streamChannelId,
rtpInterface);
if (isFirstRegistration) {
// Arrange to handle reads on this TCP socket:
TaskScheduler::BackgroundHandlerProc* handler =
(TaskScheduler::BackgroundHandlerProc*) &tcpReadHandler;
fEnv.taskScheduler().turnOnBackgroundReadHandling(fOurSocketNum,
handler, this);
}
}

void SocketDescriptor::registerRTPInterface(
unsigned char streamChannelId,
		RTPInterface* rtpInterface)
{
	Boolean isFirstRegistration = fSubChannelHashTable->IsEmpty();
	fSubChannelHashTable->Add((char const*) (long) streamChannelId,
			rtpInterface);

	if (isFirstRegistration) {
		// Arrange to handle reads on this TCP socket:
		TaskScheduler::BackgroundHandlerProc* handler = 
			(TaskScheduler::BackgroundHandlerProc*) &tcpReadHandler;
		fEnv.taskScheduler().turnOnBackgroundReadHandling(fOurSocketNum,
				handler, this);
	}
}

可见在注册第一个多路复用对象时启动reand handler。看一下函数主体：

[cpp] view plain copy print ?

void SocketDescriptor::tcpReadHandler1(int mask)
{
// We expect the following data over the TCP channel:
// optional RTSP command or response bytes (before the first '$' character)
// a '$' character
// a 1-byte channel id
// a 2-byte packet size (in network byte order)
// the packet data.
// However, because the socket is being read asynchronously, this data might arrive in pieces.
u_int8_t c;
struct sockaddr_in fromAddress;
if (fTCPReadingState != AWAITING_PACKET_DATA) {
int result = readSocket(fEnv, fOurSocketNum, &c, 1, fromAddress);
if (result != 1) { // error reading TCP socket, or no more data available
if (result < 0) { // error
fEnv.taskScheduler().turnOffBackgroundReadHandling(
fOurSocketNum); // stops further calls to us
}
return;
}
}
switch (fTCPReadingState) {
case AWAITING_DOLLAR: {
if (c == '$') {
fTCPReadingState = AWAITING_STREAM_CHANNEL_ID;
} else {
// This character is part of a RTSP request or command, which is handled separately:
if (fServerRequestAlternativeByteHandler != NULL) {
(*fServerRequestAlternativeByteHandler)(
fServerRequestAlternativeByteHandlerClientData, c);
}
}
break;
}
case AWAITING_STREAM_CHANNEL_ID: {
// The byte that we read is the stream channel id.
if (lookupRTPInterface(c) != NULL) { // sanity check
fStreamChannelId = c;
fTCPReadingState = AWAITING_SIZE1;
} else {
// This wasn't a stream channel id that we expected. We're (somehow) in a strange state. Try to recover:
fTCPReadingState = AWAITING_DOLLAR;
}
break;
}
case AWAITING_SIZE1: {
// The byte that we read is the first (high) byte of the 16-bit RTP or RTCP packet 'size'.
fSizeByte1 = c;
fTCPReadingState = AWAITING_SIZE2;
break;
}
case AWAITING_SIZE2: {
// The byte that we read is the second (low) byte of the 16-bit RTP or RTCP packet 'size'.
unsigned short size = (fSizeByte1 << 8) | c;
// Record the information about the packet data that will be read next:
RTPInterface* rtpInterface = lookupRTPInterface(fStreamChannelId);
if (rtpInterface != NULL) {
rtpInterface->fNextTCPReadSize = size;
rtpInterface->fNextTCPReadStreamSocketNum = fOurSocketNum;
rtpInterface->fNextTCPReadStreamChannelId = fStreamChannelId;
}
fTCPReadingState = AWAITING_PACKET_DATA;
break;
}
case AWAITING_PACKET_DATA: {
// Call the appropriate read handler to get the packet data from the TCP stream:
RTPInterface* rtpInterface = lookupRTPInterface(fStreamChannelId);
if (rtpInterface != NULL) {
if (rtpInterface->fNextTCPReadSize == 0) {
// We've already read all the data for this packet.
fTCPReadingState = AWAITING_DOLLAR;
break;
}
if (rtpInterface->fReadHandlerProc != NULL) {
rtpInterface->fReadHandlerProc(rtpInterface->fOwner, mask);
}
}
return;
}
}
}

void SocketDescriptor::tcpReadHandler1(int mask)
{
	// We expect the following data over the TCP channel:
	//   optional RTSP command or response bytes (before the first '$' character)
	//   a '$' character
	//   a 1-byte channel id
	//   a 2-byte packet size (in network byte order)
	//   the packet data.
	// However, because the socket is being read asynchronously, this data might arrive in pieces.

	u_int8_t c;
	struct sockaddr_in fromAddress;
	if (fTCPReadingState != AWAITING_PACKET_DATA) {
		int result = readSocket(fEnv, fOurSocketNum, &c, 1, fromAddress);
		if (result != 1) { // error reading TCP socket, or no more data available
			if (result < 0) { // error
				fEnv.taskScheduler().turnOffBackgroundReadHandling(
						fOurSocketNum); // stops further calls to us
			}
			return;
		}
	}

	switch (fTCPReadingState) {
	case AWAITING_DOLLAR: {
		if (c == '$') {
			fTCPReadingState = AWAITING_STREAM_CHANNEL_ID;
		} else {
			// This character is part of a RTSP request or command, which is handled separately:
			if (fServerRequestAlternativeByteHandler != NULL) {
				(*fServerRequestAlternativeByteHandler)(
						fServerRequestAlternativeByteHandlerClientData, c);
			}
		}
		break;
	}
	case AWAITING_STREAM_CHANNEL_ID: {
		// The byte that we read is the stream channel id.
		if (lookupRTPInterface(c) != NULL) { // sanity check
			fStreamChannelId = c;
			fTCPReadingState = AWAITING_SIZE1;
		} else {
			// This wasn't a stream channel id that we expected.  We're (somehow) in a strange state.  Try to recover:
			fTCPReadingState = AWAITING_DOLLAR;
		}
		break;
	}
	case AWAITING_SIZE1: {
		// The byte that we read is the first (high) byte of the 16-bit RTP or RTCP packet 'size'.
		fSizeByte1 = c;
		fTCPReadingState = AWAITING_SIZE2;
		break;
	}
	case AWAITING_SIZE2: {
		// The byte that we read is the second (low) byte of the 16-bit RTP or RTCP packet 'size'.
		unsigned short size = (fSizeByte1 << 8) | c;

		// Record the information about the packet data that will be read next:
		RTPInterface* rtpInterface = lookupRTPInterface(fStreamChannelId);
		if (rtpInterface != NULL) {
			rtpInterface->fNextTCPReadSize = size;
			rtpInterface->fNextTCPReadStreamSocketNum = fOurSocketNum;
			rtpInterface->fNextTCPReadStreamChannelId = fStreamChannelId;
		}
		fTCPReadingState = AWAITING_PACKET_DATA;
		break;
	}
	case AWAITING_PACKET_DATA: {
		// Call the appropriate read handler to get the packet data from the TCP stream:
		RTPInterface* rtpInterface = lookupRTPInterface(fStreamChannelId);
		if (rtpInterface != NULL) {
			if (rtpInterface->fNextTCPReadSize == 0) {
				// We've already read all the data for this packet.
				fTCPReadingState = AWAITING_DOLLAR;
				break;
			}
			if (rtpInterface->fReadHandlerProc != NULL) {
				rtpInterface->fReadHandlerProc(rtpInterface->fOwner, mask);
			}
		}
		return;
	}
	}
}

最开始的注释中解释了多路复用头的格式。这一段引起了我的兴趣：

[cpp] view plain copy print ?

case AWAITING_DOLLAR: {
if (c == $) {
fTCPReadingState = AWAITING_STREAM_CHANNEL_ID;
} else {
// This character is part of a RTSP request or command, which is handled separately:
if (fServerRequestAlternativeByteHandler != NULL) {
(*fServerRequestAlternativeByteHandler)(
fServerRequestAlternativeByteHandlerClientData, c);
}
}
break;
}

case AWAITING_DOLLAR: {
		if (c == $) {
			fTCPReadingState = AWAITING_STREAM_CHANNEL_ID;
		} else {
			// This character is part of a RTSP request or command, which is handled separately:
			if (fServerRequestAlternativeByteHandler != NULL) {
				(*fServerRequestAlternativeByteHandler)(
						fServerRequestAlternativeByteHandlerClientData, c);
			}
		}
		break;
	}

十四:live555多线程论

江湖传闻:live555如果不改为多线程,在多核心机器上效率会降低.
虽然我没做过测试,但比较相信此传闻的真实性 .

所以在我试论述一下live555如何对多核进行支持,其实就是改为多线程,嘿嘿.

先看此文:http://www.live555.com/liveMedia/faq.html#threads

跟据它的说法,live555改多线程似乎不难,因为所有全局性的东西几乎都保存在UsageEnvironment的liveMediaPriv和groupsockPriv中,groupsockPriv里面放所有的GroupSock,而liveMediaPriv指向了一个HashTab类:_Tables,_Tables中有两个变量:mediaTable和socketTable.分别指向两个Hash Tab,mediaTable中存放所有从Meduim派生出来的类对象,socketTable存放的是StreamSocket们(我猜的,嘿嘿),比如SocketDescriptor.总之,全局性的东西们都放在UsageEnvironment内.

所以,如果开了多线程,为每个线程创建一个UsageEnvironment,然后调用各自UsageEnvironment的TaskSchedule的EventLoop(),理论上应该能实现各线程各自为战,互不干扰.
但是RTSPServer却只能有一个,所以,各线程之间还必须有少量的交集.而且,RTSPServer最好单独放在一个线程中吧?因它总揽全局,所以正好放在主线程中.当然主线程也要有自己的UsageEnvironment和event loop.

如果真的实现了多线程,我们完全可以跟据CPU的数量确定线程的个数.那在什么时机,如何创建新线程呢?
想一下各RtspClientSession 的创建过程:RTSPServer收到新客户端请求后,先创建与客户对应的RTSPClientSession,RTSPClientSession在收到DESCRIBE请求后查找对应的ServerMediaSession,如果找不到,就创建一个新的,那么这几个对象的创建过程,从哪个开始进入新线程呢?
其实从RTSPClientSession开始,就可以放入新线程中,无非是RTSPServer要操作RTSPClientSession时进行同步保护而已.但是我还发现一个问题,那就是RTSPServer中并没有保存RTSPClientSession的列表.RTSPClientSession被创建出来就不管了,哦!从RTSPClientSession开始进入另外线程真是绝佳的时机!那RTSPClientSession被保存在哪里呢?它其实最终被保存在ServerMediaSusession的stremstate中了.当一个流播放完毕时,它自然就要被销毁了,是吧?

但是还有问题:RTSPServer中还担负者查找所有ServerMediaSession的任务,当然它是受RTSPClientSession委托的,因为ServerMediaSession们保存在RTSPServer中是理所当然的事.如果RTSPClientSession在不同的线程中呢?RTSPClientSession再查找ServerMediaSession就要进行同步保护了.还有个更严重的问题:我们希望把各个StreamState分散到不同的线程中,但它们又被保存在ServerMediaSub session中,麻烦又来了...

如果把ServerMediaSession保存到不同的线程中呢?看起来是可以的!但是又带来了问题,一个线程中的RTSPClientSession只能在自己线程的ServerMediaSession列表中查找是否已存在某个ServerMediaSession,其它线程中即使已存在了,也不能用,只能另创建一个,因为RTSPClientSession在被创建后应马上找到其UsageEnvironment,否则它就不能利用event loop接收数据了.所以ReuseSource是否能真正起作用,只能靠运气了.可不可以这样:先在主线程中执行RTSPClientSession的OPTION和DESCRIBE响应,再跟据其ServerMediaSession所在的线程,把它移到那个线程中去?我认为,这是完全能够做到的!看起来这样做,似乎有点完美了....
当然真正的实现上,如果能做到各线程之间的交互只是把DelayTask Handle放到目的线程的EventLoop中的话,并行计算的能力就真的要发挥出来了.

在此抛砖引玉,望有人拍砖.

十五：RTCPInstance类小结

RTCPInstance是对rtcp通信的封装．RTCP主要是功能是统计包的收发为流量控制提供依据．RTCPInstance统计数据的取得仅依赖于RTPSink的一些函数（因为RTPSink发送RTP包），所以RTCPInstance与其它类（GroupSock,RTPInterface等基础类除外）基本关系不大，封装的比较完整．

RTCPInstance靠RTPInterface提供网络通讯支持，所以它既支持rtcp over udp,又支持rtcp over tcp．
RTCPInstance接收到的包在函数static void incomingReportHandler(RTCPInstance* instance, int /*mask*/)中处理．
最值得关注的是这个成员函数：void setSpecificRRHandler(netAddressBits fromAddress, Port fromPort,TaskFunc* handlerTask, void* clientData)．它的作用是让调用者可以设置回调函数，调用者就可以在收到RR包时做出一定的动作．参数fromAddress和fromPort指明要对哪个客户端的RR包做出响应．
利用这个机制的例子是RTSPServer::RTSPClientSession．它会把自己的RRHandler函数经过层层传递，最终传给RTCPInstance．于是RTSPServer::RTSPClientSession就可以在每次收到对应的客户端的RR包时调用它传入的函数，这个函数是void RTSPServer::RTSPClientSession::noteClientLiveness(RTSPClientSession* clientSession).此函数只是以下函数的过渡：

[cpp] view plain copy print ?

void RTSPServer::RTSPClientSession::noteLiveness()
{
#ifdef DEBUG
fprintf(stderr, "Liveness indication from client at %s\n", our_inet_ntoa(fClientAddr.sin_addr));
#endif
if (fOurServer.fReclamationTestSeconds > 0) {
envir().taskScheduler().rescheduleDelayedTask(fLivenessCheckTask,
fOurServer.fReclamationTestSeconds * 1000000,
(TaskFunc*) livenessTimeoutTask, this);
}
}

void RTSPServer::RTSPClientSession::noteLiveness()
{
#ifdef DEBUG
	fprintf(stderr, "Liveness indication from client at %s\n", our_inet_ntoa(fClientAddr.sin_addr));
#endif
	if (fOurServer.fReclamationTestSeconds > 0) {
		envir().taskScheduler().rescheduleDelayedTask(fLivenessCheckTask,
				fOurServer.fReclamationTestSeconds * 1000000,
				(TaskFunc*) livenessTimeoutTask, this);
	}
}

可以看到，每收到一次指定客户端的RR包，就重置一下livenessTimeoutTask()的运行时间，如果livenessTimeoutTask()一旦运行，看一下livenessTimeoutTask():

[cpp] view plain copy print ?

void RTSPServer::RTSPClientSession::livenessTimeoutTask(RTSPClientSession* clientSession)
{
// If this gets called, the client session is assumed to have timed out,
// so delete it:
#ifdef DEBUG
fprintf(stderr, "RTSP client session from %s has timed out (due to inactivity)\n", our_inet_ntoa(clientSession->fClientAddr.sin_addr));
#endif
delete clientSession;
}

void RTSPServer::RTSPClientSession::livenessTimeoutTask(RTSPClientSession* clientSession)
{
	// If this gets called, the client session is assumed to have timed out,
	// so delete it:
#ifdef DEBUG
	fprintf(stderr, "RTSP client session from %s has timed out (due to inactivity)\n", our_inet_ntoa(clientSession->fClientAddr.sin_addr));
#endif
	delete clientSession;
}

那么RTSPServer::RTSPClientSession就会自杀（真是想不开啊）．也就是说fOurServer.fReclamationTestSeconds * 1000000是超时时间（默认好像是60秒）．

如果你想监视一个客户端，最好的方式就是向RTCPInstance注册RRHandle．

十六　几个重要对象的生命期

live555中很多类，类与类之间的关系复杂，从属关系不明显，层次上看起来也有些乱．所以源代码读起来比较困难，对于一些对象生命的来龙去脉也很难厘清．
但这并不能说明live555的架构不好，最适合的才是最好的，对于流媒体的处理来说，live555架构已是相当精巧，当然，这是在你深入了解它的基础上才会有的体会．

live555作为服务器，大家都很关心对内存的利用效率，是否过多的吃内存？是否造成太多的内存碎片？
我个人认为不必太担心这方面的事，live555对于内存的使用效率还是比较高的，当然要求太高的可能要自己实现内存池之类的东西．
然而，我在使用它的过程中，还是发现了一点小小的问题，这个问题只在某些情况下起作用．

在此不对内存管理做全面的阐述，只是探讨一下live555中一些重要类的对象实体是怎样被销毁的，同时说明那点小问题．

首先说创世者：是RTSPServer：它需永存，其余对象都是由它创建或由它引起了它们的创建．
RTSPServer直接掌管的是ServerMediaSession和RTSPClientSession(只主其生，不掌其死)．
ServerMediaSession对应一个媒体文件，而RTSPClientSession对应一个RTSP客户连接．RTSPClientSession在客户发出RTSP的TCP连接时建立，而ServerMediaSession在客户发出对一个新文件的DESCRIBE时建立．建立ServerMediaSession的同时也建立了ServerMediaSubsession们，被ServerMediaSession所管理，代表一个文件中的track们．
ServerMediaSession的建立规则值得一说：RTSPClientSession在收到客户的DESCRIBE请求时，跟据地址中的媒体名字，去查找ServerMediaSession的列表，如果已有对应此媒体名字的ServerMediaSession，则利用它获取SDP信息．如果没找到，则跟据媒体名字中的扩展名部分，建立对应此类媒体的新ServerMediaSession对象．所以可以明确一点：一个ServerMediaSubsession对应一个文件！
但是，如果测试，你会发现当一个文件播放完毕之后，并没有删除对应的ServerMediaSession．同时，与ServerMediaSubsession相关的那一坨东西（Demux和ServerMediaSubsession)也没有被销毁．但是它们终究还是要面临死亡的．什么时候死呢？RTSPServer销毁的什候（或对应的文件不存在了时）！哦，看到问题了吧？如果你做点播服务器，每打开一个文件就会创建一个ServerMediaSession以及相关的一坨东西们，如果文件太多，内存终究有用完的时候．
再说一下RTSPClientSession，RTSPClientSession有两种结束生命的方式，一是在对应流(StreamState)接收不到RTCP数据了，还记得前面讲过RTCPInstance的setSpecificRRHandler()吗？RTSPClientSession就是通过它来监视客户端的心跳的．二种方式是收到客户端的TEARDOWN请求时自杀．RTSPClientSession自杀的同时会把流对象StreamState以及流上的Source和sink全干掉．
所以说，除了RTSPClientSession那一坨之外，其余的对象还是可以在适当的时候销毁的．基本上是代表静态数据的对象不销毁，而代表动态数据的对象销毁．
如果你做的是实时流媒体，那么这正是所需要的．而做点播服务呢？总不能文件关了，代表文件的对象还在内存中吧？
那我们如何去改呢？
其实很简单，我们只要在没有任何对ServerMediaSession的引用时把它删除不就行了．而且ServerMediaSession中已经实现了引用计数，见如下三个函数：

[cpp] view plain copy print ?

unsigned referenceCount() const
{
return fReferenceCount;
}
void incrementReferenceCount()
{
++fReferenceCount;
}
void decrementReferenceCount()
{
if (fReferenceCount > 0)
--fReferenceCount;
}

	unsigned referenceCount() const
	{
		return fReferenceCount;
	}
	void incrementReferenceCount()
	{
		++fReferenceCount;
	}
	void decrementReferenceCount()
	{
		if (fReferenceCount > 0)
			--fReferenceCount;
	}

现在的问题是何时减少这个引用计数．可以想象，基本情况是在建立一个新的StreamState时或建立RTSPClientSession时，ServerMediaSession的引用就会增加１.那么理应在RTSPClientSession关闭时减去１.我们看看源码，是否是这样做了？
经查找，是在建立新的StreamState时．在函数void RTSPServer::RTSPClientSession::handleCmd_SETUP(char const* cseq,char const* urlPreSuffix, char const* urlSuffix,char const* fullRequestStr)中可以看到．再找一下减少引用的代码：

[cpp] view plain copy print ?

RTSPServer::RTSPClientSession::~RTSPClientSession()
{
closeSockets();
if (fSessionCookie != NULL)
{
// We were being used for RTSP-over-HTTP tunneling. Remove ourselves from the 'session cookie' hash table before we go:
fOurServer.fClientSessionsForHTTPTunneling->Remove(fSessionCookie);
delete[] fSessionCookie;
}
reclaimStreamStates();
if (fOurServerMediaSession != NULL)
{
fOurServerMediaSession->decrementReferenceCount();
if (fOurServerMediaSession->referenceCount() == 0
&& fOurServerMediaSession->deleteWhenUnreferenced())
{
fOurServer.removeServerMediaSession(fOurServerMediaSession);
fOurServerMediaSession = NULL;
}
}
}

RTSPServer::RTSPClientSession::~RTSPClientSession()
{
	closeSockets();


	if (fSessionCookie != NULL)
	{
		// We were being used for RTSP-over-HTTP tunneling.  Remove ourselves from the 'session cookie' hash table before we go:
		fOurServer.fClientSessionsForHTTPTunneling->Remove(fSessionCookie);
		delete[] fSessionCookie;
	}


	reclaimStreamStates();


	if (fOurServerMediaSession != NULL)
	{
		fOurServerMediaSession->decrementReferenceCount();
		if (fOurServerMediaSession->referenceCount() == 0
				&& fOurServerMediaSession->deleteWhenUnreferenced())
		{
			fOurServer.removeServerMediaSession(fOurServerMediaSession);
			fOurServerMediaSession = NULL;
		}
	}
}

是在RTSPClientSession销毁时减少引用．同时我们还看到

[cpp] view plain copy print ?

if (fOurServerMediaSession->referenceCount() == 0
&& fOurServerMediaSession->deleteWhenUnreferenced())
{
fOurServer.removeServerMediaSession(fOurServerMediaSession);
fOurServerMediaSession = NULL;
}

		if (fOurServerMediaSession->referenceCount() == 0
				&& fOurServerMediaSession->deleteWhenUnreferenced())
		{
			fOurServer.removeServerMediaSession(fOurServerMediaSession);
			fOurServerMediaSession = NULL;
		}

这样的语句，翻译过来就是：当引用为０并且可以在引用为０时删除，那么就删除它！原来在这里！我们只要让他deleteWhenUnreferenced()能返回True就解决上面所说的那个小问题了．
等等，似乎还有问题，ServerMediaSession是RTSPClientSession在建立StreamState时增加引用，而在RTSPClientSession销毁时减少引用，如果有多个Track，StreamState是要被创建多次的？好像引用增加与减少对不起来啊！真的是这样吗？我没测试我不敢说，嘿嘿，那就先留个悬念吧．

你可能感兴趣的:(流媒体)

调研App里的WebDAV功能@FE File Explorer 文件管理器（二） jaminezhong
今天我又淘到一款特容易链接WebDAV的软件：FEFileExplorer我觉得它最大好处是在Mac版电脑、Android、iOS上，一个全功能的文件上管理app。而且还可以在您的iOS、安卓和Mac电脑上使用流媒体方式播放网络共享、NAS里面的视频和音乐。FEFileExplorerPro+穿越派=个人私有云需要穿越派的，在这里下：https://www.huluer.com/usercente
推荐项目：Monibuca（m7s）—— 开源直播服务器框架的明日之星陶真蔷Scott
推荐项目：Monibuca（m7s）——开源直播服务器框架的明日之星monibucaMonibucaisaModularized,ExtensibleframeworkforbuildingStreamingServer项目地址:https://gitcode.com/gh_mirrors/mo/monibuca随着在线视频和流媒体服务的日益普及，高质量且灵活的直播服务器框架成为了开发者眼中的瑰宝
从吉利星越车名的发布，看吉利新车宣传的套路 wakechy
这两天，吉利代号为FY11的车型终于公布了正式的中文名称——星越，车型外观采用类似宝马X6式的溜背设计，很是吸睛，令人相信会是吉利又一辆走量的车型。今天就借星越中文名发布这个契机，聊聊吉利这几年的营销宣传方式，或者说营销宣传套路。首先，在新车上市前一年的某个时刻，你会发现微信公众号，今日头条等平台，无论是自媒体账号，还是主流媒体账号，忽然之间出现了吉利某款车型的概念图。比如现在这款星越，早在201
视频的容器格式和编码格式详解半桶水专家音视频音视频
视频的容器格式和编码格式是视频文件的两个核心概念，它们相互关联但具有不同的功能。以下是详细的解释：1.容器格式(ContainerFormat)容器格式，又称封装格式，指的是视频文件的外壳或容器，它用于封装视频、音频、字幕、元数据（如标题、章节信息等）等各种流媒体内容。容器格式本质上决定了文件的扩展名。常见的容器格式：MP4：支持多种编解码器，广泛用于互联网和移动设备。MKV：支持多轨音频、字幕，
Android平台轻量级RTSP服务之GStreamer还是SmartRtspServer 音视频牛哥大牛直播SDK Android RTSP服务器安卓rtsp服务器 android rtsp服务安卓启动rtsp服务 android网络摄像头 android内网采集摄像头大牛直播SDK
技术背景Android上启动一个轻量级RTSP服务，让Android终端像网络摄像头一样提供个外部可供RTSP拉流的服务，在内网小并发又不希望部署单独流媒体服务的场景下非常适用，在Android终端实现这样的流媒体服务，决定了，只能是轻量级的服务。可以通过集成第三方库或编写自定义的RTSP服务器代码来实现这一功能。今天我们介绍两种方案，一种是GStreamer，另外一种，大牛直播SDK的Smart
ios流媒体直播整个框架介绍（HLS、RTSP）少一些浮躁__ IOS
一、HTTP（WebService）基于HTTP的渐进下载ProgressiveDownload流媒体播放仅是在完全下载后再播放模式基础上做了一些小的改进。与下载播放模式中必须等待整个文件下载完毕后才能开始播放不同，渐进下载客户端在开始播放之前仅需等待一段较短的时间用于下载和缓冲该媒体文件最前面的一部分数据，之后便可以一边下载一边播放。在正式开始播放之前的这一小段缓冲应使得后续即使在网络较为拥塞的
MediaStream 的媒体流对象 (stream) 和流媒体轨道 (track) 详解 Wu Youlu 前端
navigator.mediaDevices.getUserMedia和MediaStream是实时音视频处理的重要API。通过这些API，可以从摄像头、麦克风或其他设备捕获音视频流，应用于视频通话、录制等场景。本文将介绍navigator.mediaDevices.getUserMedia的参数配置、MediaStream的传参、属性和方法，配合详细的代码示例，特别是如何动态添加和移除音视频轨道
Kafka，构建TB级异步消息系统 Fern977 牛客论坛学习笔记 kafka java 分布式
1.阻塞队列BlockingQueue解决线程通信的问题阻塞方法：put、take。生产者消费者模式生产者：产生数据的线程消费者：使用数据的线程实现类ArrayBlockingQueueLinkedBlockingQueuePriorityBlockingQueue、SynchronousQueue、DelayQueue等2.Kafka入门Kafka简介Kafka是一个分布式的流媒体平台应用：消息
仿论坛项目--Kafka，构建TB级异步消息系统 HUT_Tyne265 kafka 分布式
阻塞队列•BlockingQueue解决线程通信的问题。阻塞方法：put、take。•生产者消费者模式生产者：产生数据的线程。消费者：使用数据的线程。•实现类ArrayBlockingQueueLinkedBlockingQueuePriorityBlockingQueue、SynchronousQueue、DelayQueue等。Kafka入门•Kafka简介Kafka是一个分布式的流媒体平台。
25万人，30个亿，割韭菜，割到了体育界黑熊爱折腾
黑熊/文0125万人被骗30个亿。其实在今年整个投资市场来说，并不是什么特别大的案子。30亿的涉案资金，在今年的网贷爆雷事件中，已经没有什么新闻价值了。恐怕只有上百亿的涉案资金量，主流媒体才会提起一点点的兴趣吧。不过，今天，我之所以想写一篇，关于25万人被骗30个亿的文章。原因就在于，这次，这25万被割韭菜的人，竟全都是体育界的人，而我自己，差点就变成了众多受害者之一。02之前一直关注我的朋友知道
推荐书籍：FFmpeg从入门到精通微创光电技术团队音视频
本书是一本介绍FFmpeg的实战技术指南，全书共10章，分为两个部分。第一部分部分（第1～7章）为FFmpeg的命令行使用篇，介绍了FFmpeg的基础组成部分、FFmpeg工具使用、FFmpeg的封装操作、FFmpeg的转码操作、FFmpeg的流媒体操作、FFmpeg的滤镜操作、FFmpeg的设备操作。第二部分（第8～10章）为FFmpeg的API使用篇，介绍了FFmpeg封装部分的API使用操作
Qt/C++ 音视频开发 - FFmpeg保存裸流鱼弦人工智能时代 qt c++音视频
Qt/C++音视频开发-FFmpeg保存裸流介绍FFmpeg是一个开源的多媒体框架，能够处理音频、视频及其他多媒体文件和流。裸流指的是未经封装处理的原始音视频数据。使用FFmpeg保存裸流，可以通过高效的方式处理并存储音视频数据。应用使用场景实时流媒体传输：在没有时间进行复杂封装的情况下，将音视频数据直接传输。低延迟应用：减少因为封装产生的冗余数据和延迟。数据分析：对原始音视频数据进行深入分析时，
只需四步轻松教你绕过校园WiFi认证上网！ 2401_85752865 网络 php 开发语言微信 c语言 c#
仅适用于安卓/鸿蒙/澎湃系统/win电脑！打开软件注册账号，使用WiFi连接到校园网，不验证，返回软件，点击连接即可WiFi助手是一款专为学生设计的高效软件，旨在提升网络连接的速度与稳定性，减少延迟，从而优化日常的在线活动体验。不论是在线游戏、流媒体观影还是软件下载，它都能为你提供便利。这款软件的一大亮点是它能够简化复杂的校园网登录过程，为用户创造一个无障碍的上网环境。传统的校园网验证往往复杂且耗
SRS：流媒体服务器如何实现负载均衡音视频开发老马音视频开发流媒体服务器 Android音视频开发服务器负载均衡 java 音视频视频编解码
当我们的业务超过单台流媒体服务器的承受能力，就会遇到负载均衡问题，一般我们会在集群中提供这种能力，但实际上集群并非是唯一的实现方式。有时候负载均衡还会和服务发现等时髦词汇联系起来，而云服务的LoadBalancer无疑不可回避，因此，这个问题其实相当复杂，以至于大家会在多个场合询问这个问题，我打算系统地阐述这个问题。如果你已经知道了以下问题的所有答案，并且深刻了解背后的原因，那么你可以不用看这篇文
FFmpeg源码解析系列（一）目录和编译头快撑不住了 FFmpeg 源码解析 ffmpeg 音视频视频编解码实时音视频图像处理
引言当我们欣赏一部电影、观看一段视频或者享受一首音乐时，很少有人会停下来思考这一切是如何呈现在我们眼前的。然而，在每一帧的画面、每一秒的声音背后，有着一个不可思议的技术世界这个充满音视频的世界的核心之一，就是FFmpeg。FFmpeg是一个强大而复杂的多媒体处理工具，它为视频和音频编解码、流媒体传输、格式转换等提供了优秀的解决方案。在这个系列博客中，我们将深入探讨FFmpeg源码，解析它的工作原理
pcma和pcmu pcm编码_GitHub - mackenbaron/EasyAACEncoder: 简单、高效、稳定的开源音频编码库，支持将各种音频数据(G.711A/PCMA、G.711U/P... CLOUDU pcma和pcmu pcm编码
EasyAACEncoderEasyAACEncoder是EasyDarwin开源流媒体服务团队整理、开发的一款音频转码到AAC的工具库，目前支持G711a/G711u/G726/PCM等音频格式的转码，跨平台，支持Windows/Linux/arm.调用示例testEasyAACEncoder：通过EasyAACEncoderAPI对G711A/G711U/G726进行AAC转码；Windows
浏览器播放h.265 rtsp流媒体解决方案 LiveWeb视频管理平台 h.265 html5 音视频 web播放器 h.266
近期研究在VUE中播放RTSP实时视频，客户要求延迟低于300毫秒，并且要求支持多路同时播放，支持H.265格式视频，比较了下目前市场上常见的几种方案，以供大家参考！一、海康威视官方WEB解决方案：海康威视官方提供了两种WEB解决方案，即无插件方案和有插件方案。1.无插件方案，实际采用的是服务器转码推流的方式，因为需要转码两次，导致延迟比较高，多路播放或者播放高清视频容易卡顿或者花屏，无法满足客户
前端播放RTSP视频流，使用FLV请求RTSP视频流播放（Vue项目，在Vue中使用插件flv.js请求RTSP视频流播放）北城笑笑 JavaScript VueJS javascript vue.js
简述：在浏览器中请求RTSP视频流并进行播放时，直接使用原生的浏览器API是行不通的，因为它们不支持RTSP协议。为了解决这个问题，开发者通常会选择使用像flv.js这样的库，它专为在浏览器中播放FLV和其他流媒体格式设计。然而，flv.js本身并不直接支持RTSP，这意味着我们需要一个额外的步骤来桥接RTSP和flv.js。这里来记录一下详细介绍：在Vue中使用flv.js插件播放RTSP视频流
go srs 流媒体服务器_Go语言实现的流媒体服务器开发框架西风吹浮华 go srs 流媒体服务器
Monibucamonibuca.com背景市面上的流媒体服务器不可谓不多，从本人的第一份工作起，就一直接触和研究了形形色色的流媒体服务器，从最早的FCS(全称FlashCommunicationServer),后来改名为FMS(全称FlashMediaServer),到Red5(java语言开发)，到CrtmpServer(C++开发)，让我对流媒体服务器的基本原理有了深刻的认识。当时本人痴迷C
强大的Monibuca RTMP插件：实时流媒体处理的新星颜殉瑶Nydia
强大的MonibucaRTMP插件：实时流媒体处理的新星在现代数字时代，实时流媒体已经成为各种在线活动的核心部分，从在线会议、直播游戏到远程教育等不胜枚举。Monibuca是一个轻量级、高效的开源实时通信系统，而它的RTMP插件更是为实时流媒体传输添加了强大的翅膀。本文将深入探讨这个项目的背景、技术特性以及其应用场景，以期吸引更多开发者和使用者。MonibucaRTMP插件是什么？Monibuca
Qt/C++ 音视频开发 - VLC 解码播放（代码+部署测试）鱼弦人工智能时代 qt c++音视频
Qt/C++音视频开发-VLC解码播放介绍Qt是一个跨平台的C++应用程序框架，广泛用于GUI程序和跨平台应用。VLC是一个开源的跨平台多媒体播放器及框架，可以播放大多数多媒体文件及流媒体协议。结合两者可以实现强大的音视频处理功能。在Qt/C++项目中集成VLC可以实现高效的音视频解码和播放功能，从而增强了应用的多媒体处理能力。应用使用场景多媒体播放器：开发支持多种格式的音视频播放器。实时流媒体播
【GB28181】 SDP 报文内容（UDP、TCP主动、TCP被动）废人一枚 #GB28181 udp tcp/ip 网络 GB28181 SDP
GB28181SDP报文UDP预览回放下载TCP主动预览回放下载TCP被动预览回放下载根据《GB/T28181—2016》4.3.1、5.2的要求，SIP和流媒体都应该支持TCP和UDP两种方式以下是抓取GB28181分别在视频预览、回放和下载时交互的SDP信息。UDP预览v=0o=3402000000132000001100INIP4192.168.10.128s=Playc=INIP4192.
《Java核心技术:卷I 基础知识》第1章 Java 程序设计概述阅读与重点标记 EdwardPan1999 笔记 java
第1章Java程序设计概述1996年Java第一次发布就引起了人们的极大兴趣。关注Java的人士不仅限于计算机出版界，还有诸如《纽约时报》《华盛顿邮报》《商业周刊》这样的主流媒体。Java是第一种也是唯一一种在NationalPublicRadio（全国公共广播电视台）上占用了10分钟时间来进行介绍的程序设计语言，并且还得到了$100000000的风险投资基金。这些基金全部用来支持用这种特别的计算
Centos安装netcat 羋学僧
Centos安装netcatnetcat是网络工具中的瑞士军刀，它能通过TCP和UDP在网络中读写数据。通过与其他工具结合和重定向，你可以在脚本中以多种方式使用它。使用netcat命令所能完成的事情令人惊讶。netcat所做的就是在两台电脑之间建立链接并返回两个数据流，在这之后所能做的事就看你的想像力了。你能建立一个服务器，传输文件，与朋友聊天，传输流媒体或者用它作为其它协议的独立客户端。安装下载
破解青少年心理健康难题亟需整体社会性方案2023-05-10 清语宛如
破解青少年心理健康难题亟需整体社会性方案原创本刊编辑部人民教育2023-05-0914:56发表于北京人民教育《人民教育》杂志官方订阅号。《人民教育》是教育部主管、中国教育报刊社主办的全国性教育主流媒体，拥有73年历史。定位“思想高地、行动智库”，宣传解读党和国家教育方针政策，引导社会教育观念，提供专业解决方案，推动教育现代化。2041篇原创内容公众号心理健康与人的生活质量、智力水平，以及幸福和美
RK3588——网口实时传输视频张飞飞飞飞飞 RK3588 音视频
由于通过流媒体服务器传输画面延迟太高的问题，不知道是没有调试到合适的参数还是其他什么问题。诞生了这篇博客。RK3588板端上接摄像头，采集画面，通过网口实时传输给上位机并显示。第一代版本RK3588代码importcv2importsocketimportstruct#配置SERVER_IP='192.168.137.1'#上位机的IP地址PORT=5000#端口号#创建一个socket对象cli
ffmpeg.exe命令行参数的简单介绍香菇滑稽之谈 FFmpeg命令行 ffmpeg ffmpeg命令行 ffmpeg音视频 ffmpeg.exe
关于ffmpeg.exeffmpeg.exe是一个开源的多媒体处理工具，广泛应用于音视频的录制、转换、流媒体处理等领域。它由FFmpeg项目开发，支持多种音视频格式，并提供了丰富的命令行选项，使其功能强大且灵活。功能应用格式转换：支持几乎所有常见的音视频格式之间的转换。视频录制：可以从摄像头或屏幕录制视频。音频提取：可以从视频文件中提取音频，并保存为单独的音频文件。视频剪辑：可以对视频进行剪辑，截
利用命令行从youtube下载影片，并用huggingface的大语言模型翻译成中文 SteveMiller 语言模型人工智能自然语言处理
今天，从网络流媒体上下载字幕，并把它翻译成各种语言是一个非常常规的操作。我创建了一个工作流程。可以根着这个工作流程，从网上先下载影片，然后转出字幕，最后再做翻译。https://github.com/victorspaceRMW/download-Youtube-with-yt-dlp-and-translate-with-HuggingFace-s-whisper-model/tree/main
多人音视频实时通讯架构从零开始学习人工智能音视频架构
直播中的协议与格式在直播系统中，协议和格式的选择对于传输效率、画面质量和用户体验都至关重要。以下是直播中常见的协议与格式：协议RTSP(RealTimeStreamingProtocol)RTSP是一个网络流媒体协议，常用于视频监控和IPTV等场景。它本身并不传输数据，而是充当媒体服务器与客户端之间的通信协议。RTSP支持TCP和UDP传输，通常使用RTP（Real-timeTransportPr
2020-06-05《学习究竟是什么》学习总结清单5 魔域之晶
你不是在找答案，而是在做研究。通过各种方式获取信息，然后以我为主，做出自己的判断，这是做研究。三种找书方法：看推荐，看主流媒体的书评，追作者。思维导图不是整理和记忆工具，而是思考工具。思维导图更高级的用法是决策和判断。借助智能化记录和储存信息，大脑用来思考。强力研读笔记法第一，清晰表现每一章的逻辑脉络；第二，带走书中所有的亮点；第三，大量自己的看法和心得；第四，发现这本书和以前读过的其他书或文章的
微信开发者验证接口开发 362217990 微信开发者 token 验证
微信开发者接口验证。 Token，自己随便定义，与微信填写一致就可以了。根据微信接入指南描述 http://mp.weixin.qq.com/wiki/17/2d4265491f12608cd170a95559800f2d.html 第一步：填写服务器配置第二步：验证服务器地址的有效性第三步：依据接口文档实现业务逻辑这里主要讲第二步验证服务器有效性。建一个
一个小编程题-类似约瑟夫环问题 BrokenDreams 编程
今天群友出了一题：一个数列,把第一个元素删除,然后把第二个元素放到数列的最后,依次操作下去,直到把数列中所有的数都删除,要求依次打印出这个过程中删除的数。 &
linux复习笔记之bash shell (5) 关于减号-的作用 eksliang linux关于减号“-”的含义 linux关于减号“-”的用途 linux关于“-”的含义 linux关于减号的含义
转载请出自出处： http://eksliang.iteye.com/blog/2105677 管道命令在bash的连续处理程序中是相当重要的，尤其在使用到前一个命令的studout（标准输出）作为这次的stdin（标准输入）时，就显得太重要了，某些命令需要用到文件名，例如上篇文档的的切割命令（split）、还有
Unix(3) 18289753290 unix ksh
1)若该变量需要在其他子进程执行，则可用"$变量名称"或${变量}累加内容什么是子进程？在我目前这个shell情况下，去打开一个新的shell，新的那个shell就是子进程。一般状态下，父进程的自定义变量是无法在子进程内使用的，但通过export将变量变成环境变量后就能够在子进程里面应用了。 2)条件判断： &&代表and ||代表or&nbs
关于ListView中性能优化中图片加载问题酷的飞上天空 ListView
ListView的性能优化网上很多信息，但是涉及到异步加载图片问题就会出现问题。具体参看上篇文章http://314858770.iteye.com/admin/blogs/1217594 如果每次都重新inflate一个新的View出来肯定会造成性能损失严重，可能会出现listview滚动是很卡的情况，还会出现内存溢出。现在想出一个方法就是每次都添加一个标识，然后设置图
德国总理默多克：给国人的一堂“震撼教育”课永夜-极光教育
http://bbs.voc.com.cn/topic-2443617-1-1.html德国总理默多克：给国人的一堂“震撼教育”课　安吉拉—默克尔，一位经历过社会主义的东德人，她利用自己的博客，发表一番来华前的谈话，该说的话，都在上面说了，全世界想看想传播——去看看默克尔总理的博客吧！　　德国总理默克尔以她的低调、朴素、谦和、平易近人等品格给国人留下了深刻印象。她以实际行动为中国人上了一堂
关于Java继承的一个小问题。。。随便小屋 java
今天看Java 编程思想的时候遇见一个问题，运行的结果和自己想想的完全不一样。先把代码贴出来！ //CanFight接口 interface Canfight { void fight(); } //ActionCharacter类 class ActionCharacter { public void fight() { System.out.pr
23种基本的设计模式 aijuans 设计模式
Abstract Factory：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。　　Adapter：将一个类的接口转换成客户希望的另外一个接口。A d a p t e r模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。　　Bridge：将抽象部分与它的实现部分分离，使它们都可以独立地变化。　　Builder：将一个复杂对象的构建与它的表示分离，使得同
《周鸿祎自述：我的互联网方法论》读书笔记 aoyouzi 读书笔记
从用户的角度来看,能解决问题的产品才是好产品,能方便/快速地解决问题的产品,就是一流产品. 商业模式不是赚钱模式一款产品免费获得海量用户后,它的边际成本趋于0,然后再通过广告或者增值服务的方式赚钱,实际上就是创造了新的价值链. 商业模式的基础是用户,木有用户,任何商业模式都是浮云.商业模式的核心是产品,本质是通过产品为用户创造价值. 商业模式还包括寻找需求
JavaScript动态改变样式访问技术百合不是茶 JavaScript style属性 ClassName属性
一:style属性格式: HTML元素.style.样式属性="值"; 创建菜单:在html标签中创建或者在head标签中用数组创建 <html> <head> <title>style改变样式</title> </head> &l
jQuery的deferred对象详解 bijian1013 jquery deferred对象
jQuery的开发速度很快，几乎每半年一个大版本，每两个月一个小版本。每个版本都会引入一些新功能，从jQuery 1.5.0版本开始引入的一个新功能----deferred对象。 &nb
淘宝开放平台TOP Bill_chen C++c 物流 C#
淘宝网开放平台首页：http://open.taobao.com/ 淘宝开放平台是淘宝TOP团队的产品，TOP即TaoBao Open Platform，是淘宝合作伙伴开发、发布、交易其服务的平台。支撑TOP的三条主线为： 1.开放数据和业务流程 * 以API数据形式开放商品、交易、物流等业务； &
【大型网站架构一】大型网站架构概述 bit1129 网站架构
大型互联网特点面对海量用户、海量数据大型互联网架构的关键指标高并发高性能高可用高可扩展性线性伸缩性安全性大型互联网技术要点前端优化 CDN缓存反向代理 KV缓存消息系统分布式存储 NoSQL数据库搜索监控安全想到的问题： 1.对于订单系统这种事务型系统，如
eclipse插件hibernate tools安装白糖_ Hibernate
eclipse helios(3.6)版 1.启动eclipse 2.选择 Help > Install New Software...> 3.添加如下地址： http://download.jboss.org/jbosstools/updates/stable/helios/ 4.选择性安装：hibernate tools在All Jboss tool
Jquery easyui Form表单提交注意事项 bozch jquery easyui
jquery easyui对表单的提交进行了封装，提交的方式采用的是ajax的方式，在开发的时候应该注意的事项如下： 1、在定义form标签的时候，要将method属性设置成post或者get，特别是进行大字段的文本信息提交的时候，要将method设置成post方式提交，否则页面会抛出跨域访问等异常。所以这个要
Trie tree(字典树)的Java实现及其应用-统计以某字符串为前缀的单词的数量 bylijinnan java实现
import java.util.LinkedList; public class CaseInsensitiveTrie { /** 字典树的Java实现。实现了插入、查询以及深度优先遍历。 Trie tree's java implementation.(Insert,Search,DFS) Problem Description Igna
html css 鼠标形状样式汇总 chenbowen00 html css
css鼠标手型cursor中hand与pointer Example：CSS鼠标手型效果 <a href="#" style="cursor:hand">CSS鼠标手型效果</a><br/> Example：CSS鼠标手型效果 <a href="#" style=&qu
[IT与投资]IT投资的几个原则 comsci it
无论是想在电商,软件,硬件还是互联网领域投资,都需要大量资金,虽然各个国家政府在媒体上都给予大家承诺,既要让市场的流动性宽松,又要保持经济的高速增长....但是,事实上,整个市场和社会对于真正的资金投入是非常渴望的,也就是说,表面上看起来,市场很活跃,但是投入的资金并不是很充足的......
oracle with语句详解 daizj oracle with with as
oracle with语句详解转在oracle中，select 查询语句，可以使用with,就是一个子查询，oracle 会把子查询的结果放到临时表中，可以反复使用例子:注意，这是sql语句，不是pl/sql语句，可以直接放到jdbc执行的 ----------------------------------------------------------------
hbase的简单操作 deng520159 数据库 hbase
近期公司用hbase来存储日志,然后再来分析 ,把hbase开发经常要用的命令找了出来. 用ssh登陆安装hbase那台linux后用hbase shell进行hbase命令控制台! 表的管理 1）查看有哪些表 hbase(main)> list 2）创建表 # 语法：create <table>, {NAME => <family&g
C语言scanf继续学习、算术运算符学习和逻辑运算符 dcj3sjt126com c
/* 2013年3月11日20:37:32 地点：北京潘家园功能：完成用户格式化输入多个值目的：学习scanf函数的使用 */ # include <stdio.h> int main(void) { int i, j, k; printf("please input three number:\n"); //提示用
2015越来越好 dcj3sjt126com 歌曲
越来越好房子大了电话小了感觉越来越好假期多了收入高了工作越来越好商品精了价格活了心情越来越好天更蓝了水更清了环境越来越好活得有奔头人会步步高想做到你要努力去做到幸福的笑容天天挂眉梢越来越好婆媳和了家庭暖了生活越来越好孩子高了懂事多了学习越来越好朋友多了心相通了大家越来越好道路宽了心气顺了日子越来越好活的有精神人就不显
java.sql.SQLException: Value '0000-00-00' can not be represented as java.sql.Tim feiteyizu mysql
数据表中有记录的time字段（属性为timestamp）其值为：“0000-00-00 00:00:00” 程序使用select 语句从中取数据时出现以下异常： java.sql.SQLException:Value '0000-00-00' can not be represented as java.sql.Date java.sql.SQLException: Valu
Ehcache（07）——Ehcache对并发的支持 234390216 并发 ehcache 锁 ReadLock WriteLock
Ehcache对并发的支持在高并发的情况下，使用Ehcache缓存时，由于并发的读与写，我们读的数据有可能是错误的，我们写的数据也有可能意外的被覆盖。所幸的是Ehcache为我们提供了针对于缓存元素Key的Read（读）、Write（写）锁。当一个线程获取了某一Key的Read锁之后，其它线程获取针对于同
mysql中blob,text字段的合成索引 jackyrong mysql
在mysql中，原来有一个叫合成索引的，可以提高blob,text字段的效率性能，但只能用在精确查询，核心是增加一个列，然后可以用md5进行散列，用散列值查找则速度快比如： create table abc(id varchar(10),context blog,hash_value varchar(40)); insert into abc(1,rep
逻辑运算与移位运算 latty 位运算逻辑运算
源码：正数的补码与原码相同例+7 源码：00000111 补码：00000111 （用8位二进制表示一个数）负数的补码：符号位为1，其余位为该数绝对值的原码按位取反；然后整个数加1。 -7 源码： 10000111 ，其绝对值为00000111 取反加一：11111001 为-7补码已知一个数的补码，求原码的操作分两种情况：
利用XSD 验证XML文件 newerdragon java xml xsd
XSD文件（XML Schema 语言也称作 XML Schema 定义（XML Schema Definition，XSD）。具体使用方法和定义请参看： http://www.w3school.com.cn/schema/index.asp java自jdk1.5以上新增了SchemaFactory类可以实现对XSD验证的支持，使用起来也很方便。以下代码可用在J
搭建 CentOS 6 服务器(12) - Samba rensanning centos
（1）安装 # yum -y install samba Installed: samba.i686 0:3.6.9-169.el6_5 # pdbedit -a rensn new password:123456 retype new password:123456 …… （2）Home文件夹 # mkdir /etc
Learn Nodejs 01 toknowme nodejs
（1）下载nodejs https://nodejs.org/download/ 选择相应的版本进行下载（2）安装nodejs 安装的方式比较多，请baidu下我这边下载的是“node-v0.12.7-linux-x64.tar.gz”这个版本（1）上传服务器（2）解压 tar -zxvf node-v0.12.
jquery控制自动刷新的代码举例 xp9802 jquery
1、html内容部分复制代码代码示例: <div id='log_reload'> <select name="id_s" size="1"> <option value='2'>-2s-</option> <option value='3'>-3s-</option