rtmp协议中的stream_id，chunk_id的区别与联系

初看rtmp协议，对stream_id、chunk_id的认知很浅薄，而且很混乱，搞不懂之间的联系与区别，直到找到这篇文章：rtmp中的各种ID。
应原文要求，特注明文章出自开源流媒体服务器lal，Github：https://github.com/q191201771/lal 官方文档：https://pengrl.com/lal。

---

chunk stream id

设计思想

按rtmp的设计思想，是可以在一条链路上传输多路流，比如最常见的一路音频流和一路视频流，音频流和视频流可独立打开关闭。 那么当某一路流中的message特别大时（比如视频的关键帧），可能会导致音频流的message需要等待这个特别大的message传输完毕后才能传输。 rtmp为了解决这个问题，选择将对应用层有意义的message切割成chunk，那么传输时就不需要一个message接一个message传输了，而可以一个chunk接一个chunk传输。 （注意，chunk必须是完整的，不能发送chunk1的前半部分再发chunk2然后再发送chunk1的后半部分） 接收端将chunk stream id相同的chunk组合成完成的message再返回给应用层。

下面是一个简单的例子

• 假设Video message 1很大

• 最原始的多路流传输方式，Audio Message 2只能等待Video message 1传输完毕后才能传输

  | Audio message 1 | Video message 1 | Audio Message 2 | Video message2 |

• 将Video Message 1切割成两个chunk（这里为了简化，其实可能不止两个chunk）

• 这样，Audio Message 2就不需要等待整个Video message 1发送完毕再发送了

• 另外，其他的message也是chunk的形式了

  | Audio message 1 | first chunk of Video meesage 1 | Audio Message 2 | last chunk of Video message 2 | Video message 2 |

• 以下这种是错误的，chunk必须保持完整

  | chunk1的前半部分 | chunk2的前半部分 | chunk1的后半部分 | chunk2的后半部分 |

思考
那我们来思考一下，按现在常见的rtmp over tcp的方案，当应用层有一个message需要传输时，我们会将它切割成chunk，然后发送切割出的所有chunk，然后再循环处理下一个message。 （具体实现会跟网络io部分相关，但也是按message进入发送队列的） 事实上，一个message的chunk是连续的，并不会插入其他chunk。所以，并没有达到上面大message不阻塞其他stream的message的设计。 那么理论上rtmp的这个设计思路可不可行呢？是可行的，比如发送队列不使用FIFO的大buffer，而是以chunk组成的更细粒度的管理。或者使用UDP传输，一般都会按MTU切割应用层的message，基本和chunk的概念类似。

实践

下面是一些常见的rtmp项目使用chunk stream id的情况

obs推流

csid 2 用于传输 SetChunkSize。
csid 3 用于传输信令，比如 connect | releaseStream | FCPublish | createStream | publish
csid 4 用于传输 metaData + 音频数据 + 视频数据。

ffmpeg推流

csid 2 SetChunkSize
csid 3 connect | releaseStream | FCPublish | createStream
csid 8 publish
csid 4 metaData + 视频数据
csid 6 音频数据
csid 3 FCUnpublish | deleteStream

注意，ffmpeg推流时，是先发的connect，再发SetChunkSize，接收端在没有收到SetChunkSize时，应该假定对端的chunk size为128。

从nginx rtmp module拉流

csid 2 Window ACk Size | SetPeerBandwidth | SetChunkSize
csid 3 onBWDone | _result for Connect | _result for createStream
csid 5 onStatus for Play
csid 5 metaData e.g. len 24
csid 2 user control message
csid 5 metaData e.g. len 699
csid 7 视频数据
csid 6 音频数据
可以看到，obs推流的音频和视频数据共用一个csid，ffmpeg则是两个csid，nginx rtmp module则是metaData也单独使用一个csid。

chunk stream id如何获取，message如何切割成chunk，chunk如何重组成message可以参见lal(https://github.com/q191201771/lal)的实现。

message stream id

obs推流

msid 0 信令
msid 1 publish信令 | 音视频数据

ffmpeg推流

和obs一样

从nginx rtmp module拉流

msid 0 信令
msid 1 onStatus of play信令 | 音视频数据

可以看到，三个项目都是使用msid 1传输音视频数据。

lal中，_result for createStream的msid使用1，publish 和 play 使用 _result 中返回msid

transaction id

command类型message中的一个字段。

尽管文档中将大部分message都定义为0了，比如:

connect tid: 1
onStatus: 0
play: 0
deleteStream: 0
publish: 0

但是各rtmp软件的具体实现却不是这样，比如：

obs推流

connect tid: 1
releaseStream: 2
FCPublish: 3
createStream: 4
publish: 5
FCUnpublish: 6
deleteStream: 7

可以看到是自增的过程。 测试时服务端使用lal，lal是按照接收到的tid原样回复message。

ffmpeg推流

结果和obs推流一样

从nginx rtmp module拉流

onBWDone tid: 0
_result of connect: 1
_result of createStream: 2
onStatus of Play: 0

测试时客户端使用lal，lal按递增的方式处理tid：

connect tid: 1
createStream: 2
play or publish: 3
message type id

这个是最简单的，标明应用层的message是什么类型，比如音频(8)、视频(9)、metadata(18)、特定信令(比如1是SetChunkSize)、Command类型的信令(20)等。