RTMPS：Support RTMPS for security transport.

[github8808]

Description

Platforms like Facebook abroad require encrypted transmission for security reasons, and they require support for the RTMPS protocol for streaming. It is hoped that SRS can also add this protocol.

Expected Behavior

It is hoped that SRS can add support for the RTMPS protocol to ensure the security of streaming.

[github8808]

流媒体服务器nginx-http-live-module支持RTMPS：https://blog.csdn.net/winshining/article/details/93606585 不过没有开源要收费！！

[winlinvip]

The Nginx-http-live-module streaming server supports RTMPS: https://blog.csdn.net/winshining/article/details/93606585 But it's not open-source and requires a fee!

For a commercial version, it's better to use server brands like Wowza and AMS, and for convenience, security, and stability, it's better to use Alibaba Cloud and Tencent Cloud.

[winlinvip]

From an open-source perspective, whether RTMPS must be supported, I have thought about it for a while:

1. Facebook needs to support RTMPS, which seems to be SRS forwarding to platforms like Facebook, and this scenario is likely to have some applications.
2. If forwarding is not required and only security is needed, WebRTC streaming to RTMP can be considered, which can provide a very high level of security and a better streaming experience.
3. If considering H265 and AV1, RTMP is currently not supported, and RTMPS won't work either, so there may be other protocols in the future.

Note: Master Zhihong said that the SRT function submitted by Master Shiwei can be considered, which is also encrypted for streaming and can be converted to RTMP. This is similar to the second point mentioned above, but it does not solve the problems mentioned in points 1 and 3.

So I think the value of this issue may not be as great as everyone imagines. Some friends in the WeChat group also said that it is actually very quick to support RTMP by referring to SRS's HTTPS implementation. If any friends have supported it, please feel free to submit a patch, and I will consider opening a branch.

Whether to merge it into the main branch, I need to think about it some more, please give me some time.

[tongaoao]

可以带我进群吗？大神 最近我们在搞H265的事情但是没啥成熟的推流工具RTSP丢包太高 RTMP不支持

发自我的iPhone

在 2021年4月19日，上午11:37，Winlin @.***> 写道：

 从开源来说，是否一定要支持RTMPS，我想了一段时间：

Facebook要支持RTMPS，看起来是SRS转推给Facebook等平台，这个场景估计是有一定应用的。 如果不需要转推，只是需要安全的话，是可以考虑WebRTC推流转RTMP，这样可以做非常高级别的安全，而且推流体验更佳。 如果考虑H265和AV1，目前RTMP肯定不支持了，RTMPS也不行，那未来可能有其他的协议。 所以我想这个事情价值，可能不如大家想象的那么大。微信群里也有朋友说，其实参考SRS的HTTPS自己实现RTMP也很快就能支持，如果有朋友支持了，欢迎提Patch，我会考虑开一个分支。

是否合并到主干，我需要再考虑考虑，请给我点时间。

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[winlinvip]

The method for NGINX to support RTMPS is to use a separate tunnel:

Configure a pre-RTMPS to plaintext streaming service:

stream {
    upstream publish {
        server 127.0.0.1:19361;
    }
    server {
        listen 1936 ssl;        # additional port for publishing
        proxy_pass publish;
        ssl_certificate /etc/letsencrypt/live/rtmp.example.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/rtmp.example.com/privkey.pem;

        allow 192.0.2.1;        # allow publish from this IP
        allow 192.0.2.0/24;     # -- also supports CIDR notation!
        deny all;               # deny publish from the rest
    }

    upstream live {
        server 127.0.0.1:19351;
    }
    server {
        listen 1935 ssl;        # standard RTMP(S) port
        proxy_pass live;
        ssl_certificate /etc/letsencrypt/live/rtmp.example.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/rtmp.example.com/privkey.pem;

        allow all;              # this is public (this is also the default)
    }
}

Then it's the RTMP service behind:

rtmp {
    server {
        listen 127.0.0.1:19361;
        chunk_size 4096;

        application secret-key {
            live on;
            record off;
            allow publish 127.0.0.1;  # publishing through rtmps://rtmp.example.com:1936
            allow play 127.0.0.1;     # for the pull from rtmp://localhost:19351/live
        }
    }

    server {
        listen 127.0.0.1:19351;
        chunk_size 4096;

        application live {
            live on;
            record off;
            deny publish all;         # no need to publish on /live -- IMPORTANT!!!
            allow play 127.0.0.1;     # playing through rtmps://rtmp.example.com:1935/live

            pull rtmp://127.0.0.1:19361/secret-key;
        }
    }
}

For more details, you can refer to this link

It's quite complicated to use, and it's worth making it simpler. For example, in Cloud SRS, FFmpeg is used to directly forward:

However, it needs to support key matching and cannot randomly select streams.

Also, it needs to support forwarding of multiple streams, and currently, it can only support one stream.