SRS 流媒体服务器部署及设计思路和一些想法

1、参考地址

SRS github地址：https://github.com/ossrs/srs
自带的信令github地址：https://github.com/ossrs/signaling#usage
中文文档：https://ossrs.net/lts/zh-cn/docs/v4/doc/introduction
安卓ios客户端demo：https://github.com/ossrs/flutter_live

2、环境部署

我是在centos上使用的源码编译模式，官方还提供了docker模式的，看文档中有介绍。

2.1 下载源代码

git clone  https://gitee.com/ossrs/srs.git

2.2 下载后手动编译

cd srs/trunk
./configure
make

这里需要说明一下，在手动编译过程中，可能会提示报错，看报错日志安装对应的依赖环境即可。

2.3 修改配置文件，我这里要测试webrct的功能，就在conf目录下找到srs.conf，编辑文件，把如图位置改为自己服务器的ip地址。

 官方提供了动态获取ip地址的方式，需要的话可以看文档。

2.4 启动服务，需要在trunk目录下执行

./objs/srs -c conf/srs.conf #使用srs配置文件启动

　./etc/init.d/srs status #查看状态

　./etc/init.d/srs stop #停止

启动后有如下输出：

 

2.5 检查启动状态，我这里直接关闭了服务器的防火墙，否则需要开放8080端口，如果需要改端口改配置文件即可。

浏览器输入：http://192.168.101.139:8080 访问控制台，如果能访问到则说明启动成功了。

 2.6 配置浏览器https支持，由于webrtc需要https，本地测试配置证书又很麻烦，需要修改下浏览器配置。

在谷歌浏览器地址栏输入：chrome://flags/#unsafely-treat-insecure-origin-as-secure

 启用功能，输入框中输入你对应的地址，多个用英文逗号隔开。在这里配置后。浏览器会在访问这个地址的时候，会以https的方式去访问http网站。

2.7 推拉流测试

http://192.168.101.138:8080/players/rtc_publisher.html?vhost=r.ossrs.net&server=r.ossrs.net&port=1985&autostart=true

 http://192.168.101.138:8080/players/rtc_player.html?vhost=r.ossrs.net&server=r.ossrs.net&port=1985&autostart=true

 

浏览器测试后已经能正常的推拉流了

2.8 关于多人通话，多人通话需要用到信令和房间等概念，官方提供了一个信令服务器，是用go语言开发的，如果要使用，需要提前安装好go的环境。

在trunk目录下执行命令：

cd /3rdparty/signaling && make && ./objs/signaling

安装信令并启动服务。

访问地址：http://192.168.101.139:1989/demos/room.html?autostart=true&room=32f9e6c

就可以实现多人视频通话了。

2.9 关于录制

修改配置文件

# main config for srs.
# @see full.conf for detail config.

listen              1935;
max_connections     1000;
#srs_log_tank        file;
#srs_log_file        ./objs/srs.log;
daemon              on;
http_api {
    enabled         on;
    listen          1985;
}
http_server {
    enabled         on;
    listen          8080;
    dir             ./objs/nginx/html;
}
rtc_server {
    enabled on;
    listen 8000; # UDP port
    # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/webrtc#config-candidate
    candidate 192.168.101.138;
}
vhost __defaultVhost__ {
    hls {
        enabled         on;
    }
    http_remux {
        enabled     on;
        mount       [vhost]/[app]/[stream].flv;
    }
    rtc {
        enabled     on;
        # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/webrtc#rtmp-to-rtc
        rtmp_to_rtc off;
        # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/webrtc#rtc-to-rtmp
        rtc_to_rtmp on;
    }
     dvr {
        enabled             on;
        dvr_path            /application/srs_record/[app]/[stream].[timestamp].mp4;
        dvr_plan            segment;
        dvr_duration        600;
        dvr_wait_keyframe   on;
    }

    http_remux {
        enabled     on;
        mount       [vhost]/[app]/[stream].flv;
    }
    http_hooks {
        enabled          off;
        on_connect     https://192.168.101.87:8080/connect;
        on_close       https://192.168.101.87:8080/close;
        on_publish     https://192.168.101.87:8080/publish;
        on_unpublish   https://192.168.101.87:8080/unpublish;
        on_play        https://192.168.101.87:8080/play;
        on_stop        https://192.168.101.87:8080/stop;
        on_dvr         https://192.168.101.87:8080/ondvr;
    }
}

其中dvr是视频录制的配置，配置录制时间、路径等。在rtc节点中rtc_to_rtmp必须要开启，否则无法录制。

http_hook是SRS服务器回调，enabled控制开关，关键几个事件触发时，通过接口推送到服务器接口，通过接口实现业务。关于录制服务端代码：srs_hook: 基于SRS的HTTP回调，接入了connect、ondvr、close、publish、unpublish、play、stop事件，内部实现了一部分简单的处理，可以在这个基础上扩展自己的业务代码。 (gitee.com)

这这部分代码中可以加入自己的业务控制。

3..0 关于多人视频通话的一些想法

使用上面的多人视频通话测试过后发现，其实相当于每个人都有一个对应的视频流，这样确实能实现通话。这就有个问题，想象有无限个客户端来通话，那每个客户端都要持有一个除自己以外的其他所有人的音视频流，并且要播放出来，设备会不会有性能问题？关于这个问题，其实就是Room to Live模式，官方给出的解决方案是先通过SRS把webrtc转成rtmp，再用ffmpeg把多个rtmp合并成一个rtmp，且不说中间经历过转换加合流，是否会增加延时，这样视频通话的及时性就得不到保证。而且我之前使用nginx+rtmp+ffmpeg

做过多音视频流的合并测试，效果不是很理想，音频合流的延迟达到了5s。当时测试我使用的虚拟服务器可能配置太差了。不知道这种方案是否在生产环境可行。