vlc搭建rtsp服务器不显示路径,VLC搭建服务器推送RTSP流分析

RTSP流媒体服务器搭建

使用VLC播放器搭建RTSP服务器(由于是RTSP协议,即数据客户端拉取,服务器端配置端口和路径即可),RTSP方式是通过RTP进行流媒体数据的传输的,VLC的实现也是基于UDP的(后面抓包分析)。

使用wireshark抓包分析RTSP流

服务器端:ip 192.168.11.127, port:8854,path:1

客户端: ip 192.168.11.189

RTSP信令交互

过滤RTSP:

1a13eba275d9?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation

image.png

显然上面三行是TCP的三次握手;接下来才是RTSP播控通信,首先发送OPTIONS,接着发送DESCRIBE,SETUP,PLAY,TEARDOWN等RTSP播控交互命令。

追踪TCP流发现:

1a13eba275d9?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation

OPTIONS

RTSP播控命令支持:DESCRIBE,SETUP,TEARDOWN,PLAY,PAUSE,GET_PARAMETER。

接着查看DESCRIBE命令的回复发现:

1a13eba275d9?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation

image.png

DESRCIBE命令回复中:

audio 0 RTP/AVP 14

video 0 RTP/AVP 32

即音视频数据推送的协议为RTP/AVP,而且交互通道有4个,即traceID=12-15;具体是包装TCP还是UDP,需要看看SETUP命令回复的Transport字段:

1a13eba275d9?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation

image.png

可以看到RTP/AVP是包装UDP的,服务器和客户端端口都有两个,分别为播控交互和音视频数据推送的端口。

接下来追踪RTP协议UDP流:

1a13eba275d9?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation

RTP

1a13eba275d9?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation

image.png

要想弄清RTP协议,首先要清楚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 |

| .... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RTP报文由两部分组成:报头和有效载荷。RTP报头格式如图6.7所示,其中:

1.V:RTP协议的版本号,占2位,当前协议版本号为2。

P:填充标志,占1位,如果P=1,则在该报文的尾部填充一个或多个额外的八位组,它们不是有效载荷的一部分。

X:扩展标志,占1位,如果X=1,则在RTP报头后跟有一个扩展报头。

CC:CSRC计数器,占4位,指示CSRC 标识符的个数。

M: 标记,占1位,不同的有效载荷有不同的含义,对于视频,标记一帧的结束;对于音频,标记会话的开始。

PT: 有效载荷类型,占7位,用于说明RTP报文中有效载荷的类型,如GSM音频、JPEM图像等,在流媒体中大部分是用来区分音频流和视频流的,这样便于客户端进行解析。

序列号:占16位,用于标识发送者所发送的RTP报文的序列号,每发送一个报文,序列号增1。这个字段当下层的承载协议用UDP的时候,网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序,在helix服务器中这个字段是从0开始的,同时音频包和视频包的sequence是分别记数的。

时戳(Timestamp):占32位,时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动,并进行同步控制。

同步信源(SSRC)标识符:占32位,用于标识同步信源。该标识符是随机选择的,参加同一视频会议的两个同步信源不能有相同的SSRC。

特约信源(CSRC)标识符:每个CSRC标识符占32位,可以有0~15个。每个CSRC标识了包含在该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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| defined by profile | length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| header extension |

| .... |

对比协议或追踪RTP的UDP流数据:

1a13eba275d9?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation

image.png

知道:版本号为2,填充为false,扩展false,负载类型:MPEG-I/II等等信息。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值