Enhance the handling of the returned result from the API hook.

[jarod]

Refer to nginx-rtmp-module at https://github.com/arut/nginx-rtmp-module/wiki/Directives#on_play

'
Please ensure to preserve the markdown structure.

HTTP 3xx redirects RTMP to another stream whose name is taken from Location HTTP response header. If new stream name is started with rtmp:// then remote relay is created instead. Relays require that IP address is specified instead of domain name and only work with nginx versions greater than 1.3.10. See also notify_relay_redirect.

HTTP 3xx is very useful. With support for this, on_play/on_publish can be used in conjunction with the application system to create a master-master cluster.

'
Please ensure to preserve the markdown structure.

TRANS_BY_GPT3

[winlinvip]

This is RTMP302, but what you mentioned about the master-master cluster requires more than just 302.
Please refer to this bug: #464

TRANS_BY_GPT3

[jarod]

I am not very familiar with the RTMP protocol. If RTMP302 is similar to HTTP redirect, it is different from the redirect in NRM. The redirect in NRM API response is more like a reverse proxy in HTTP. It is the current video server that pulls the target video and returns it to the client, instead of letting the client pull the target video.

TRANS_BY_GPT3

[winlinvip]

If the server is used for relay, SRS's edge can be used, which can perform source merging and reduce the pressure on the origin server.

TRANS_BY_GPT3

[jarod]

origin/edge mode is not very suitable for live show mode because the host and the audience are both dispersed. We hope that the host can connect to any node for uploading and the audience can connect to any node for viewing.

I have previously used NRM+ to implement a web application with NRM HTTP API to achieve this effect. It can be easily implemented with a simple program, thanks to the flexible HTTP API of NRM.

1. Host A connects to any node A to upload a video. When node A finishes publishing, it calls the application interface, and the application records that stream A was published on node A.
2. Audience A connects to node A to watch stream A. When node A starts playing, it calls the application interface. The application checks if the requested node is the same as the publishing node and returns a 2XX response to play the stream directly on this node.
3. Audience B connects to node B to watch stream A. When node B starts playing, it calls the application interface. The application checks if the requested node is different from the publishing node and returns a 3XX response with Location=rtmp://node A/. Node B pulls stream A from node A and returns it to audience B.

TRANS_BY_GPT3

[jarod]

If the API could be more flexible, even if you don't want to do master-master, just want to do multi-origin like #464, it would be better to leave this choice to the user (SRS user) instead of making SRS itself too complicated.

TRANS_BY_GPT3

[winlinvip]

edge can support multiple origin + multiple edge clusters, and it can also support live streaming shows. SRS is widely used in many CDNs, and this is a basic function.

Multiple origin + multiple edge, this is what #464 needs to do for multiple origin.

TRANS_BY_GPT3

[winlinvip]

The switching strategy of multiple source stations is reasonable and makes sense. I will consider this when I am working on it.

TRANS_BY_GPT3

[jarod]

Maybe I didn't make it clear in my writing. The pattern I'm referring to is where each node simultaneously acts as both an origin and an edge. In this context, the node represents an SRS process.
On Thu, Oct 22, 2015, 11:33 winlin notifications@github.com wrote:

The edge can support both an origin and multiple edge clusters, and it can also support live streaming. SRS is widely used in many CDNs, and this is a basic functionality.

Multiple origin + multiple edge, this is what #464 is going to do for multiple origins.

—
Reply to this email directly or view it on GitHub
#507 (comment)
.

TRANS_BY_GPT3

[winlinvip]

No, you wrote it very clearly. It is about the design differences between the handling solution of NRM and the solution of SRS. Let me reiterate:

1. The anchor pushes the stream to Node A, which becomes the source station with the stream.
2. Users play the stream from Node A, matching it, and retrieve the stream from Node A.
3. Users play the stream from Node B, which doesn't match. Node B learns that the stream is on Node A, retrieves it from Node A, and delivers it to the user.

Is that correct? If there are no network issues between Node A and B, it's actually quite good because it serves as both the source and the edge. For a general CDN:

1. The network between all nodes may not be good, so the CDN divides the source stations and retrieves from the source stations at the edge.
2. If HLS support is required, this solution becomes a bit complicated. The centralized source stations can use the CDN's existing HTTP distribution solution.

For the SRS solution, it is done as follows:

1. The anchor pushes the stream to the edge, and the edge retrieves it from Source Station A. (SRS already supports this)
2. Users play the stream from the edge, and the edge merges and retrieves it from Source Station A, matching it. (SRS already supports this)
3. Users play the stream from the edge, and the edge retrieves it from Source Station B, which doesn't match. The system informs the edge that the stream is on Source Station A. The edge retrieves it from Source Station A and delivers it to the user. (SRS3 plans to support this, i.e., multiple source stations)

The benefits of this solution are:

1. Similar to the previous HTTP distribution solution of CDN, it has a multi-layer structure, which is easy for operation and maintenance to understand and manage.
2. The edge can retrieve from multiple source stations and merge the streams. It can achieve load balancing and hot backup.
3. The source station can output RTMP, HTTP-FLV, and HLS streams, supporting multiple business scenarios.
4. The edge can output RTMP and HTTP-FLV streams. HLS streams are delivered through HTTP edge.
5. If the source station supports multiple source stations and the edge supports HLS streams, the entire cluster will be more comprehensive.

I don't know if what I said is correct or not?

TRANS_BY_GPT3

[winlinvip]

So I think what you said is just different ideas for two different solutions, namely NRM and SRS, regarding load balancing and hot backup.

TRANS_BY_GPT3

[jarod]

Understood, thank you for clarifying.

TRANS_BY_GPT3