关闭

rtmp协议(1)--消息语法

207人阅读 评论(0) 收藏 举报
分类:

学过很多的协议。看过很多的文档。基本都看完就忘记。今天尝试下新方法,看看能不能彻底理解这些消息 信息。


rtmp的基本结构有两种:message 和chunk ,一系列的交互,一系列的语法,都基于这两种消息。下面看着两种结构的具体语法和关系


message:



chunk



二者之间的关系



这个关系就像我们说话都有间隔,写文字都有标点符号意义。许多个chunk,可以表达一个message,message堆积起来,就是一篇文章,一个交互。


下面理解chunk的四种写法,就像我们写文章都有句号,逗号一样,如果只有一个标点符号,文字岂不很无趣么?


chunk比较绕弯的地方就是有个header of header,名字叫做basic header .格式如下



还可以变形如下


如下



这就是所谓的basic header的长度在1-3个字节,都是为了表示所谓的csid啦。不过我们用的最多的是第一种形式,就是只有8小位一大位的。而且我们重点关注的只是高两位,他表示了chunk的四种格式。我们称之为fmt


首先欢迎最复杂 最完整 长度也最长的fmt=0的格式。



基本就是复制了message head的情况。所以,这种格式也不常用,基本用在第一个包。要是经常使用这种格式,那么数据冗余得多大啊,因为msg type ,msg stream id 都不是每个包都需要传的,在某些场合,msg length也不需要传,在某些极端场合,比如大包拆小包,time更不要传输。下面我我们就看看最极端的场合。

fmt=3的包格式


啥也没有。对。这就是=3的时候,是不需要chunk head 头的。那么,在我们常用的音频传输中,有时候采用cbr来编码,每个包的大小一致,各种id也都一样。只是时间戳不一样。这种情况下怎么传,请出我们的下一种包格式

fmt=2


没错,只有三个字节的时间增量。大大减少了数据量,比那rtp协议要少的多了。当然,rtp协议主要是基于udp使用的,考虑到丢包的情况,需要每个包都带完整的信息。rtmp是tcp的,丢包基本不用考虑。所以可以能少则少。


那么在视频和vbr传输过程中,每个包大小是不一样的,但id都一样。这种情况下怎么解决?有请fmt=1的包格式


什么不一样,把什么传出去。7个字节。其实我觉得那个msg type id 也完全不必要,6个字节就可以了。


下面我们举例子来说明各种情况

例子一,有下面数据要发送


这个是我们发cbr音频数据时,经常碰到的情况。大小 id 都一样,只有时间戳有增量。那么发送情况如下




第一个包还是一个完整信息的包,第二包,就优化到只有一个时间戳增量了。到第三个包,时间戳增量也不需要了。直接一个包头加数据。。


在看一个拆包的例子


307个字节,我们默认的chunk size是128个字节,当然要拆了



可以看到。rtmp在网络传输优化上,是很有针对性的。专门对视频 音频传输的特点来优化。试想,如果只是一个文件传输。只要有格式1和格式3就可以了。


那么问个问题rtmp包是怎么检查丢包的呢?

答案是rtmp根本就没考虑这些,因为这些rtmp是基于tcp的,这些工作,tcp层以及做了。所以,想rtmp over udp的同学,要自己做好丢包检测算法。


另外。我们会注意到每个包都有两个id,一个是msg的stream id,一个是chunk的csid。这两个id有啥区别?

这两id没有任何关系。streamid是服务器随机生成的,用于标识一个会话的id,而csid,某种情况下是系统自用id,表示chuank类型,和msg type倒是有些关联。


0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:38317次
    • 积分:850
    • 等级:
    • 排名:千里之外
    • 原创:43篇
    • 转载:26篇
    • 译文:0篇
    • 评论:9条
    文章分类
    最新评论