一、采集
SRS支持两种方式得到RTMP直播源。
一种是使用FFmpeg， 设备或其它方式将流推送到SRS。
另一种方式是SRS本身带采集功能。
采集(Ingest)指的是将文件（flv，mp4，mkv，avi，rmvb等等），
流（RTMP，RTMPT，RTMPS，RTSP，HTTP，HLS等等），设备等的数据，
转封装为RTMP流（若编码不是h264/aac则需要转码），推送到SRS。
采集基本上就是使用FFMPEG作为编码器，或者转封装器，将外部流主动抓取到SRS。
采集的部署实例参考：Ingest
1.1 应用场景
采集的主要应用场景包括：
1.虚拟直播：
将文件编码为直播流。可以指定多个文件后，SRS会循环播放。
2.RTSP摄像头对接：
以前安防摄像头都支持访问RTSP地址，RTSP无法在互联网播放。
可以将RTSP采集后，以RTMP推送到SRS，后面的东西就不用讲了。
3.直接采集设备：
SRS采集功能可以作为编码器采集设备上的未压缩图像数据，
譬如video4linux和alsa设备，编码为h264/aac后输出RTMP到SRS。
4.将HTTP流采集为RTMP：
有些老的设备，能输出HTTP的ts或FLV流，可以采集后转封装为RTMP，支持HLS输出。
总之，采集的应用场景主要是“SRS拉流”；
能拉任意的流，只要ffmpeg支持；
不是h264/aac都没有关系，ffmpeg能转码。
SRS默认是支持“推流”，即等待编码器推流上来，
可以是专门的编码设备，FMLE，ffmpeg，xsplit，flash等等。
如此，SRS的接入方式可以是“推流到SRS”和“SRS主动拉流”，
基本上作为源站的功能就完善了。
1.2 编译
Ingest需要在编译时打开：--with-ingest。参考：Build
Ingest默认使用自带的ffmpeg，也可以不编译ffmpeg，使用自己的编转码工具。
禁用默认的ffmpeg在编译时指定--without-ffmpeg即可。
参考：Build
1.3 配置
Ingest的配置如下：
vhost your_vhost {
# ingest file/stream/device then push to SRS over RTMP.
# the name/id used to identify the ingest, must be unique in global.
# ingest id is used in reload or http api management.
ingest livestream {
# whether enabled ingest features
# default: off
enabled on;
# input file/stream/device
# @remark only support one input.
input {
# the type of input.
# can be file/stream/device, that is,
# file: ingest file specifies by url.
# stream: ingest stream specifeis by url.
# device: not support yet.
# default: file
type file;
# the url of file/stream.
url ./doc/source.200kbps.768x320.flv;
}
# the ffmpeg
ffmpeg ./objs/ffmpeg/bin/ffmpeg;
# the transcode engine, @see all.transcode.srs.com
# @remark, the output is specified following.
engine {
# @see enabled of transcode engine.
# if disabled or vcodec/acodec not specified, use copy.
# default: off.
enabled off;
# output stream. variables:
# [vhost] current vhost which start the ingest.
# [port] system RTMP stream port.
output rtmp://127.0.0.1:[port]/live?vhost=[vhost]/livestream;
}
}
}
ingest指令后面是ingest的id，全局需要唯一，用来标识这个ingest。
在reload/http-api管理时才知道操作的是哪个。
譬如，reload时用来检测哪些ingest更新了，需要通知那些已经存在的ingest，停止已经不存在的ingest。
其中，type指定了输入的几种类型：
file: 输入为文件，url指定了文件的路径。srs会给ffmpeg传递-re参数。
stream: 输入为流，url指定了流地址。
device: 暂时不支持。
engine： 指定了转码引擎参数：
enabled: 指定是否转码，若off或者vcodec/acodec没有指定，则不转码，使用ffmpeg-copy。
output： 输出路径。
有两个变量可以使用：
port为系统侦听的RTMP端口，
vhost为配置了ingest的vhost。
其他参考转码的配置：FFMPEG
注意：engine默认为copy，当：
engine的enabled为off，没有开启转码engine，则使用copy。
engine的vcodec/acodec没有指定，则使用copy。
采集多个文件。
实现方法：
可以把输入文件变成文件列表。自己写工具实现采集列表。
二、Forward模式搭建小型集群
srs定位为直播服务器，其中一项重要的功能是forward，即将服务器的流转发到其他服务器。
备注：SRS的边缘RTMP参考Edge，支持访问时回源，为大规模并发提供最佳解决方案。
注意：edge可以从源站拉流，也可以将流转发给源站。
也就是说，播放edge上的流时，edge会向源站拉流；
推流到edge上时，edge会直接将流转发给源站。
注意：若只需要中转流给源站，不必用forward，直接使用edge模式即可。
可以直接支持推流和拉流的中转，简单快捷。
Forward应用于目标服务器是多个，譬如将一路流主动送给多路服务器；
edge虽然配置了多台服务器，但是只用了一台，有故障时才切换。
注意：优先使用edge，除非知道必须用forward，才使用forward。
forward本身是用做热备，即用户推一路流上来，可以被SRS转发（或者转码后转发）到多个slave源站，
CDN边缘可以拉多个slave源站的流，实现故障热备的功能，构建强容错系统。
转发的部署实例参考：Usage: Forward
2.1 词汇
为了和edge方式区分，forward定义一次词汇如下：
master：主服务器，
编码器推流到这个服务器，或者用ingest流到服务器。
总之，master就是主服务器，负责转发流给其他服务器。
slave： 从服务器，主服务器转发流到这个服务器。
如果结合edge集群方式，一般而言master和slave都是origin（源站服务器），
edge边缘服务器可以从master或者slave回源取流。
实际上master和slave也可以是edge，但是不推荐，这种组合方式太多了，测试没有办法覆盖到。
因此，强烈建议简化服务器的结构，只有origin（源站服务器）才配置转发，edge（边缘服务器）只做边缘。
2.2 For Small Cluster
forward也可以用作搭建小型集群。架构图如下：
+-------------+ +---------------+
+-->+ Slave(1935) +->--+ Player(3000) +
| +-------------+ +---------------+
| +-------------+ +---------------+
|-->+ Slave(1936) +->--+ Player(3000) +
publish forward | +-------------+ +---------------+
+-----------+ +--------+ | 192.168.1.6
| Encoder +-->-+ Master +-->-|
+-----------+ +--------+ | +-------------+ +---------------+
192.168.1.3 192.168.1.5 +-->+ Slave(1935) +->--+ Player(3000) +
| +-------------+ +---------------+
| +-------------+ +---------------+
+-->+ Slave(1936) +->--+ Player(3000) +
+-------------+ +---------------+
192.168.1.7
2.3 下面是搭建小型集群的实例。
1. Encoder编码器
编码器使用FFMPEG推流。编码参数如下：
for((;;)); do\
./objs/ffmpeg/bin/ffmpeg \
-re -i doc/source.200kbps.768x320.flv \
-vcodec copy -acodec copy \
-f flv -y rtmp://192.168.1.5:1935/live/livestream; \
done
2. SRS-Master服务器
SRS（192.168.1.5）的配置如下：
listen 1935;
pid ./objs/srs.pid;
max_connections 10240;
vhost __defaultVhost__ {
gop_cache on;
forward 192.168.1.6:1935 192.168.1.6:1936 192.168.1.7:1935 192.168.1.7:1936;
}
源站的流地址播放地址是：rtmp://192.168.1.5/live/livestream
将流forward到两个边缘节点上。
3. SRS-Slave节点
Slave节点启动多个SRS的进程，每个进程一个配置文件，侦听不同的端口。
以192.168.1.6的配置为例，需要侦听1935和1936端口。
配置文件srs.1935.conf配置如下：
listen 1935;
pid ./objs/srs.1935.pid;
max_connections 10240;
vhost __defaultVhost__ {
gop_cache on;
}
配置文件srs.1936.conf配置如下：
listen 1936;
pid ./objs/srs.1936.pid;
max_connections 10240;
vhost __defaultVhost__ {
gop_cache on;
}
启动两个SRS进程：
nohup ./objs/srs -c srs.1935.conf >/dev/null 2>&1 &
nohup ./objs/srs -c srs.1936.conf >/dev/null 2>&1 &
播放器可以随机播放着两个流：
rtmp://192.168.1.6:1935/live/livestream
rtmp://192.168.1.6:1936/live/livestream
另外一个Slave节点192.168.1.7的配置和192.168.1.6一样。
4. 服务的流
此架构服务中的流为：
流地址 服务器 端口 连接数
rtmp://192.168.1.6:1935/live/livestream 192.168.1.6 1935 3000
rtmp://192.168.1.6:1936/live/livestream 192.168.1.6 1936 3000
rtmp://192.168.1.7:1935/live/livestream 192.168.1.7 1935 3000
rtmp://192.168.1.7:1936/live/livestream 192.168.1.7 1936 3000
这个架构每个节点可以支撑6000个并发，两个节点可以支撑1.2万并发。 还可以加端口，可以支持更多并发。
2.4. Forward VS Edge
Forward架构和CDN架构的最大区别在于，CDN属于大规模集群，
边缘节点会有成千上万台，源站2台（做热备），还需要有中间层。
CDN的客户很多，流也会有很多。
所以假若源站将每个流都转发给边缘，会造成巨大的浪费（有很多流只有少数节点需要）。
可见，forward只适用于所有边缘节点都需要所有的流。CDN是某些边缘节点需要某些流。
forward的瓶颈在于流的数目，假设每个SRS只侦听一个端口：
系统中流的数目 = 编码器的流数目 × 节点数目 × 端口数目
考虑5个节点，每个节点起4个端口，即有20个SRS边缘。编码器出5路流，则有20 * 5 = 100路流。
同样的架构，对于CDN的边缘节点来讲，系统的流数为用户访问边缘节点的流，
假设没有用户访问，系统中就没有流量。某个区域的用户访问某个节点上的流，
系统中只有一路流，而不是forward广播式的多路流。
另外，forward需要播放器随机访问多个端口，实现负载均衡，或者播放器访问api服务器，
api服务器实现负载均衡，对于CDN来讲也不合适（需要客户改播放器）。
总之，forward适用于小型规模的集群，不适用于CDN大规模集群应用。
2.5 高级应用
forward还可以结合hls和transcoder功能使用，即在源站将流转码，
然后forward到Slave节点，Slave节点支持rtmp同时切HLS。
因为用户推上来的流，或者编码器（譬如FMLE）可能不是h264+aac，
需要先转码为h264+aac（可以只转码音频）后才能切片为hls。
需要结合vhost，先将流transcode送到另外一个vhost，这个vhost将流转发到Slave。
这样可以只转发转码的流。
参考vhost，hls和transcoder相关wiki。
三、Edge边缘服务器
SRS的Edge提供访问时回源机制，在CDN/VDN等流众多的应用场景中有重大意义，
forward/ingest方案会造成大量带宽浪费。
同时，SRS的Edge能对接所有的RTMP源站服务器，
不像FMS的Edge只能对接FMS源站（有私有协议）；
另外，SRS的Edge支持SRS源站的所有逻辑 （譬如转码，转发，HLS，DVR等等），
也就是说可以选择在源站切片HLS，也可以直接在边缘切片HLS。
备注：Edge一般负载高，SRS支持的并发足够跑满千兆网带宽了。
3.1 Edge的主要应用场景：
CDN/VDN大规模集群，客户众多流众多需要按需回源。
小规模集群，但是流比较多，需要按需回源。
骨干带宽低，边缘服务器强悍，可以使用多层edge，降低上层BGP带宽。
注意1.：
edge可以从源站拉流，也可以将流转发给源站。
也就是说，播放edge上的流时，edge会回源拉流；
推流到edge上时，edge会直接将流转发给源站。
注意2.：
若只需要中转流给源站，不必用forward，直接使用edge模式即可。
可以直接支持推流 和拉流的中转，简单快捷。
Forward应用于目标服务器是多个，譬如将一路流主动送给多路服务器；
edge虽然配置了多台服务器，但是只用了一台，有故障时才切换。
注意：优先使用edge，除非知道必须用forward，才使用forward。
3.2 概念
所谓边缘edge服务器，就是边缘直播缓存服务器，
配置时指定为remote模式和origin（指定一个或多个源站IP），
这个边缘edge服务器就是源站的缓存了。
当用户推流到边缘服务器时，边缘直接将流转发给源站。
譬如源站在北京BGP机房，湖南有个电信ADSL用户要推流发布自己的直播流，
要是直接推流到北京BGP可能效果不是很好，可以在湖南电信机房部署一个边缘，
用户推流到湖南边缘，边缘转发给北京源站BGP。
当用户播放边缘服务器的流时，边缘服务器看有没有缓存，若缓存了就直接将流发给客户端。
若没有缓存，则发起一路回源链接，从源站取数据源源不断放到自己的缓存队列。
也就是说， 多个客户端连接到边缘时，只有一路回源。
这种结构在CDN是最典型的部署结构。
譬如北京源站， 在全国32个省每个省都部署了10台服务器，
一共就有320台边缘，假设每个省1台边缘服务器都有2000用户观看，那么就有64万用户，
每秒钟集群发送640Gbps数据；而回源链接只有320个，实现了大规模分发。
边缘edge服务器，实际上是解决大并发问题产生的分布式集群结构。
SRS的边缘可以指定多个源站，在源站出现故障时会自动切换到下一个源站，
不影响用户观看，具有最佳的容错性，用户完全不会觉察。
3.3 Config
edge属于vhost的配置，将某个vhost配置为edge后，
该vhost会回源取流（播放时）或者将流转发 给源站（发布时）。
vhost __defaultVhost__ {
# the mode of vhost, local or remote.
# local: vhost is origin vhost, which provides stream source.
# remote: vhost is edge vhost, which pull/push to origin.
# default: local
mode remote;
# for edge(remote mode), user must specifies the origin server
# format as: [:port]
# @remark user can specifies multiple origin for error backup, by space,
# for example, 192.168.1.100:1935 192.168.1.101:1935 192.168.1.102:1935
origin 127.0.0.1:1935 localhost:1935;
# for edge, whether open the token traverse mode,
# if token traverse on, all connections of edge will forward to origin to check(auth),
# it's very important for the edge to do the token auth.
# the better way is use http callback to do the token auth by the edge,
# but if user prefer origin check(auth), the token_traverse if better solution.
# default: off
token_traverse off;
}
可配置多个源站，在故障时会切换到下一个源站。
3.4 集群配置
下面举例说明如何配置一个源站和集群。
源站配置，参考origin.conf：
listen 19350;
pid objs/origin.pid;
srs_log_file ./objs/origin.log;
vhost __defaultVhost__ {
}
边缘配置，参考edge.conf：
listen 1935;
pid objs/edge.pid;
srs_log_file ./objs/edge.log;
vhost __defaultVhost__ {
mode remote;
origin 127.0.0.1:19350;
}
3.5 HLS边缘
Edge指的是RTMP边缘，也就是说，配置为Edge后，流推送到源站（Origin）时，Edge不会切片生成HLS。
HLS切片配置在源站，只有源站会在推流上来就产生HLS切片。
边缘只有在访问时才会回源（这个时候 也会生成HLS，但单独访问边缘的HLS是不行的）。
也就是说，HLS的边缘需要使用WEB服务器缓存，譬如nginx反向代理，squid，或者traffic server等。
3.6 下行边缘结构设计
下行边缘指的是下行加速边缘，即客户端播放边缘服务器的流，边缘服务器从上层或源站取流。
SRS下行边缘是非常重要的功能，需要考虑以下因素：
以后支持多进程时结构变动最小。
和目前所有功能的对接良好。
支持平滑切换，源站和边缘两种角色。
权衡后，SRS下行边缘的结构设计如下：
客户端连接到SRS
开始播放SRS的流
若流存在则直接播放。
若流不存在，则从源站开始取流。
其他其他流的功能，譬如转码/转发/采集等等。
核心原则是：
边缘服务器在没有流时，向源站拉取流。
当流建立起来后，边缘完全变成源站服务器，对流的处理逻辑保持一致。
支持回多个源站，错误时切换。这样可以支持上层服务器热备。
备注：RTMP多进程（计划中）的核心原则是用多进程作为完全镜像代理，
连接到本地的服务器 （源站或边缘），完全不考虑其他业务因素，透明代理。
这样可以简单，而且利用多CPU能力。 HTTP多进程是不考虑支持的，用NGINX是最好选择，
SRS的HTTP服务器只是用在嵌入式设备中， 没有性能要求的场合。
3.7 上行边缘结构设计
上行边缘指的是上行推流加速，客户端推流到边缘服务器，边缘将流转发给源站服务器。
考虑到下行和上行可能同时发生在一台边缘服务器，所以上行边缘只能用最简单的代理方式，
完全将流代理到上层或源站服务器。也就是说，只有在下行边缘时，边缘服务器才会启用其他的功能，
譬如HLS转发等等。
上行边缘主要流程是：
客户端连接到SRS
开始推流到SRS。
开始转发到源站服务器。
EdgeState
边缘的状态图分析如下：
RTMP-HLS-latency
注意：这种细节的文档很难保持不变，以代码为准。
3.8 边缘的难点
RTMP边缘对于SRS来讲问题不大，主要是混合了reload和HLS功能的边缘服务器，会是一个难点。
譬如，用户在访问边缘上的HLS流时，是使用nginx反向代理回源，还是使用RTMP回源后在边缘切片？
对于前者，需要部署srs作为RTMP边缘，nginx作为HLS边缘，管理两个服务器自然是比一个要费劲。
若使用后者，即RTMP回源后边缘切片，能节省骨干带宽，只有一路回源，
难点在于访问HLS时要发起 RTMP回源连接。
正因为业务逻辑会是边缘服务器的难点，所以SRS对于上行边缘，采取直接代理方式，
并没有采取 边缘缓存方式。所谓边缘缓存方式，即推流到边缘时边缘也会当作源站直接缓存（作为源站），
然后转发给源站。边缘缓存方式看起来先进，这个边缘节点不必回源，实际上加大了集群的逻辑难度，
不如直接作为代理方式简单。
四、RTMP 集群(源/边缘) 架构
SRS集群支持两种模式： forward 和 edge
步骤一:
Any RTMP encoder push RTMP stream to RTMP (origin/edge)server,
where SRS RTMP Edge server will forward stream to origin.
RTMP编码器推送RTMP流有两个目的地址:
1. RTMP源服务器，
2. SRS RTMP边缘服务器；
推送到SRS RTMP边缘服务器的RTMP流会被再forward到RTMP源服务器；
+---------+ +-----------------+ +-----------------------+
+ Encoder +--+-->-+ SRS(RTMP Edge) +--->-+ (RTMP Origin) |
+---------+ | +-----------------+ | SRS/FMS/NGINX-RTMP |
| | Red5/HELIX/CRTMP |
+-------------------------->-+ ...... |
+-----------------------+
步骤二:
SRS边缘服务器从RTMP源服务器或上游SRS边缘服务器拉流，
这时，当前的SRS边缘服务器即可以为客户端提供直播播放服务，
也可以做为下一级SRS边缘服务器的源；
+-------------+ +-----------------+ +--------------------+
| RTMP Origin +-->-+ SRS(RTMP Edge) +--+->-+ Client(RTMP/HLS) |
+-------------+ +-----------------+ | | Flash/IOS/Android |
| +--------------------+
|
| +-----------------+
+->-+ SRS(RTMP Edge) +
+-----------------+
