LibRTMP库优化之调整输出块大小

1. 为什么要调整输出块大小

首先在RTMP_Connect0函数中LibRTMP是关闭了Nagle算法这个TCP选项的，为了实时性这样做是好的，但是要注意到LibRTMP的结构体RTMP的成员是有m_outChunkSize，并且在RTMP_Init函数中被初始化了默认值128，然后整个LibRTMP代码没有改变m_outChunkSize的接口函数，内部也没有改变m_outChunkSize的实现逻辑，也没有发送改变块大小的消息给流媒体服务器的代码逻辑，关闭Nagle加如此小的块大小会导致很多小包，而以太网的MTU是1500，这样如果用在播放客户端由于主要是接收媒体流到也没有什么，但是如果用在发布媒体流的推流客户端网络效率就太低了，并且IP小包太多还会引起流媒体的服务器软中断升高，导致内核占用的CPU过高。m_outChunkSize在发送给流媒体服务器消息会用于分块，所以从这个方面来说LibRTMP还是部分支持改变块大小的，这部分逻辑实现不需要任何改变。

2. 调整输出块大小的函数

static int

ChangeChunkSize(RTMP *r,int outChunkSize)

{

RTMPPacket packet;

char pbuf[RTMP_MAX_HEADER_SIZE + 4];

packet.m_nBytesRead = 0;

packet.m_body = pbuf + RTMP_MAX_HEADER_SIZE;

packet.m_packetType = RTMP_PACKET_TYPE_CHUNK_SIZE;

packet.m_nChannel = 0x04;

packet.m_headerType = RTMP_PACKET_SIZE_LARGE;

packet.m_nTimeStamp = 0;

packet.m_nInfoField2 = 0;

packet.m_hasAbsTimestamp = 0;

packet.m_nBodySize = 4;

r->m_outChunkSize = outChunkSize;

r->m_outChunkSize = htonl(r->m_outChunkSize);

memcpy(packet.m_body, &r->m_outChunkSize, 4);

r->m_outChunkSize = ntohl(r->m_outChunkSize);

return RTMP_SendPacket(r, &packet, TRUE);

}

注1：RTMP协议的消息类型01（RTMP_PACKET_TYPE_CHUNK_SIZE宏的值）就是用于改变输出块大小的消息类型，结合MTU

注2：outChunkSize大小可以选择1500-20(IP头)-20（TCP头）=1460，考虑到IP头、TCP头有扩展选项，加之PPPoE，为保证起见可选为1360，也可以设为大于MTU的其它值，不过这样的话就会出现IP分片了，也不是好习惯。

注3：每当调用本函数后就顺便修改了RTMP的成员变量m_outChunkSize，以保持与服务器收到的一致。

3. 调用调整输出块大小的函数的时机

随时可以调整，只不过在调用ChangeChunkSize函数后，要注意到这个函数内部已经改变了RTMP的成员变量m_outChunkSize，这样在调用这个函数之后的所有发给流媒体服务器的消息要以这个块大小来分块，由于TCP的有序性，服务器在收到该改变块大小的消息后也会以此块大小来解析后序的所有消息，由于播放客户端主要是拉流，播放端需要传给服务器的数据不多，可以不修改，基于此可以在收到connect的响应后的处理逻辑中调用ChangeChunkSize函数，具体如下（HandleInvoke函数中部分代码）：

if (r->Link.protocol & RTMP_FEATURE_WRITE)

{

ChangeChunkSize(r, 1360);//若不改拉流时的输出块大小在这里调用ChangeChunkSize

SendReleaseStream(r);

SendFCPublish(r);

}

else

{

RTMP_SendServerBW(r);

RTMP_SendCtrl(r, 3, 0, 300);

}

//ChangeChunkSize(r,1360);//若推、拉流时的输出块大小都改变在这里调用ChangeChunkSize

4. 调整输出块大小带来的变化

主要用于发布媒体的源流媒体服务器CPU下降10%

通过调整流媒体服务器的输出块大小与媒体流发布客户端一致，流媒体不再需要分块了，而是可以直接转发，这样也会节省一定CPU

每一路媒体流流量下降15%

5 音频小包如何处理

对于44.1KHZ双声音，对于采集周期为2048个样本的音频数据通过AAC+SBR音频编码后大小在100到300字节之间结合实时性，有两个处理策略，1 小包就小了，为了实时也就这样了，必竟音频数据量不大 2 RTMP本身是基于RTMP块流协议的，可以在应用层将音频块与视频块合包，当接近MTU时才通过socket 发送给流媒体服务器。