Issue with RTMP Encoder Compatibility

[5centscdn]

Hello there,

Currently, we are using Wowza and Nimble media servers. Both of these media servers are using the following format:

Wowza: rtmp://server:1935/application/stream Nimble: rtmp://server:1935/application/stream

but the media-framework requires a slightly different format, as follows:

rtmp://server:1935/application/{channel}_{stream}

We are wondering if there is any option to change the format to something like:

rtmp://server:1935/application/{channel}

We hope to hear from you soon! Thank you.

[erankor]

The parsing of the RTMP URL happens here - https://github.com/kaltura/media-framework/blob/master/conf/controller.php#L418

This PHP file is provided as an example, you can (and should...) change it to fit your use case. Notice that it has several open TODOs, like adding an authentication logic for RTMP connect requests.

So, you can change this chunk of code to do -

$channelId = $streamName;
$variantId = 'input';  // or any other constant string...

But you should take into account, that making this change effectively means you won't be able to publish more than one video track and one audio track per channel. An RTMP stream can have at most one video and one audio, and if channel = stream, it means the channel will also be limited to one video and one audio input.

[5centscdn]

Hello there,

It's working, but there is a problem. We have created 2 applications: one for live and another for testing, as shown below:

server { listen 1935;

    application live {
        live on;
        deny play all;

        kmp_ctrl_connect_url http://127.0.0.1:8001/control/;
        kmp_ctrl_publish_url http://127.0.0.1:8001/control/;
        kmp_ctrl_unpublish_url http://127.0.0.1:8001/control/;
        kmp_ctrl_republish_url http://127.0.0.1:8001/control/;
    }
        application testing {
        live on;
        deny play all;

        kmp_ctrl_connect_url http://127.0.0.1:8001/control/;
        kmp_ctrl_publish_url http://127.0.0.1:8001/control/;
        kmp_ctrl_unpublish_url http://127.0.0.1:8001/control/;
        kmp_ctrl_republish_url http://127.0.0.1:8001/control/;
    }

Then, we have published 2 streams to the following endpoint:

rtmp://localhost/live/stream rtmp://localhost/testing/stream

The issue is that both streams from live and testing are being saved in the same location (/tmp/store/channel), causing a conflict. Is there any way to save both streams in different locations, so that we can create separate streams under "live" and "test" categories? like: /tmp/store/channel/live/stream and /tmp/store/channel/testing/stream ?

Hope to hear from you soon.

[erankor]

It's not just the store, you can't have multiple connections to the same track... but what you can do is use different channel ids for the two applications. For example, if you now have $channelId = $streamName; you can change it to $channelId = $streamName . $params['rtmp']['app'];. Or if you only want it in test, you can do something like -

$channelId = $streamName;
if ($params['rtmp']['app'] == 'testing')
{
    $channelId .= '_test';
}

Naturally you will have to change the channel name when playing the stream as well.

[5centscdn]

Hello there,

Thank you for the update, everything is working fine now. Your prompt assistance is truly appreciated. I have a quick question regarding the application for RTMP. Currently, I have created two applications named "live" and "testing." However, I wanted to inquire if there are any limitations on the number of applications we can create using the media-framework. Our current media server already hosts approximately 1000+ applications.

Do we need to change any settings? as per the doc "All stateful nginx-based components (=all except nginx-pckg-module), must be deployed on a single process nginx server (worker_processes 1;)" does this cause any performance issue?

Looking forward to your response.

[erankor]

From what I see, when getting a connect message, nginx-rtmp-module loops over all the applications one-by-one until it finds the right one. I think even with 1000 it shouldn't be a problem. It would have been better to change the code to use a hash table, but not sure I'll have time for it any time soon...