### [rtmp url基础](https://pengrl.com/lal/#/RTMPURLVhost?id=rtmp-url%e5%9f%ba%e7%a1%80)
rtmp url的格式类似于http url。格式如下:
~~~cpp
rtmp://<host>[:port]/<appName>/<streamName>[?param1=value1][¶m2=value2]
~~~
*其中rtmp是scheme字段,固定不变。*
我们以rtmp play拉流来说明(publish类似)。rtmp拉流客户端的逻辑:
第一步,如果host部分是domain域名,则先通过域名解析得到对端ip。
第二步,使用对端ip加port建立tcp连接。注意,如果url中不存在port,则使用1935。
第三步,客户端和服务端通过rtmp信令的交互,建立好拉流通道,之后服务端给客户端下发对应流的音视频数据。这里有的同学可能会疑惑,域名解析成ip进行tcp连接后,服务端如何知道客户端连接时用的域名是啥?
答案是客户端通过rtmp信令,将域名传输给了服务端。
具体点,是rtmp connect信令(注意,这个connect不是tcp connect)和play信令。看一个简单的url例子。
*测试前,修改/etc/hosts,使得fake.lal.com这个假的测试域名解析到本地127.0.0.1的*[*lalserver*](https://github.com/q191201771/lal)*上。客户端使用ffmpeg。*
~~~cpp
ffplay rtmp://fake.lal.com/live/test110信令值:connect appName: live tcUrl: rtmp://fake.lal.com:1935/liveplay streamName: test110
~~~
### [vhost](https://pengrl.com/lal/#/RTMPURLVhost?id=vhost)
先说vhost的作用。举个例子,假设你自身有一个rtmp服务器(后面将这个服务器称为源站),上面有很多流。源站由于网络以及负载的原因,并不能服务全国的观众拉流,于是你为了更好的播放效果,使用了阿里CDN做流分发,也即用户从阿里CDN的边缘节点拉流,阿里CDN从你的源站回源拉流。
又由于你担心阿里CDN不可靠,于是你又加了一家腾讯CDN。用户可以上任意一家CDN拉取任意一路你源站上的流。
此时,问题来了,你的源站被拉流时,如何区分是哪家CDN来拉流的呢?简单的做法,你可以申请两个域名,比如阿里使用`alfake.lal.com`,腾讯使用`txfake.lal.com`,它们的DNS解析都指向源站IP。
但这么做有个缺点,就是后续有变化,需要频繁操作域名,比如又要接入CDN3,CDN4...然后说说vhost的做法。其实很简单,就是url的host只用一个,在非host部分,填入一个域名字段。由于不是host,就不涉及到DNS域名解析。你可以任意命名,快速提供给CDN。那么具体放哪呢,这实际上是一个行业潜规则。常见的有两种:
*还拿前面那个例子rtmp://fake.lal.com/live/test110来用*
第一种,在host和appName之间增加了一级目录。服务端需要从rtmp connect信令中解析。
~~~plain
rtmp://fake.lal.com/alfake.lal.com/live/test110信令值:connect appName: alfake.lal.com/live tcUrl: rtmp://fake.lal.com:1935/alfake.lal.com/liveplay streamName: test110
~~~
第二种,更简单些,直接增加一个url参数。服务端需要从rtmp play信令中解析。
~~~plain
rtmp://fake.lal.com/alfake.lal.com/live/test110信令值:connect appName: live tcUrl: rtmp://fake.lal.com:1935/liveplay streamName: test110?vhost=alfake.lal.com
~~~
原创不易,转载请注明文章出自开源流媒体服务器[lal](https://github.com/q191201771/lal),Github:[https://github.com/q191201771/lal](https://github.com/q191201771/lal)官方文档:[https://pengrl.com/lal](https://pengrl.com/lal)yoko,
- 序言
- 编解码
- H264
- HEVC码流解析
- H264编码原理
- 多媒体封装
- MP4
- 学好 MP4,让直播更给力
- AAC
- FLV
- 流媒体协议
- RTSP
- RTCP
- RTP
- H265 RTP封包笔记
- SDP
- RTMP
- RTMP URL
- rtmp url基础
- webrtc
- 编译
- 最简单的编译webrtc方案
- Webrtc音视频会议之Webrtc“不求甚解”
- Webrtc音视频会议之Mesh/MCU/SFU三种架构
- 音频传输之Jitter Buffer设计与实现
- Janus
- Webrtc音视频会议之Janus编译
- Webrtc音视频会议之Janus源码架构设计
- webrtc服务器-janus房间管理
- 源码分析
- WebRTC视频JitterBuffer详解
- 走读Webrtc 中的视频JitterBuffer(一)
- 走读webrtc 中的视频JitterBuffer(二)
- webrtc视频帧率控制算法机制
- 目标码率丢帧-1
- 目标帧率丢帧-2
- 29 如何使用Medooze 实现多方视频会议
- FFmpeg
- FFmpeg编译
- Window10下编译最新版FFmpeg的方法步骤
- FFMPEG静态库编译
- ffmpeg实现画中画
- FFmpeg推流器
- ffmpeg-aac
- OpenCV
- OpenCV学习笔记——视频的边缘检测
- 图像特征点匹配(视频质量诊断、画面抖动检测)
- 图像质量诊断