rtmpUrl

darndt

New Member
I am running the simple screen sharing demo described here:


In screen-sharing-min.js I pass an rtmpUrl to the session.CreateStream() function:

function startStreaming() {
var constraints = {
video: {},
};
constraints.video.type = "screen";
constraints.video.withoutExtension = true;
session.createStream({
name: "mystream",
display: document.getElementById("screen-sharing"),
constraints: constraints,
rtmpUrl: "rtmp://myserver.com/my-stream-key"
}).publish();
}

However, when I start streaming, it runs for a second then stops. If I remove the rtmpUrl it streams to flashphoner's server.

Is this the correct method to specify the target RTMP server?

Is it not possible to use this parameter in demo?
 

Max

Administrator
Staff member
Good day.
Is this the correct method to specify the target RTMP server?
Yes. But demo server uses default parameters for all examples to work:
- stream published name is always used as a part of stream key
- stream key is always prefixed by rtmp_ to allow republishing to localhost
So the example above publishes a stream as rtmp://myserver.com/rtmp_mystream
To fully customize RTMP republishing, please use REST API query when stream is published
Code:
POST /rest-api/push/startup HTTP/1.1
Host: demo.flashphoner.com:8081
Content-Type: application/json
 
{
    "streamName": "mystream",
    "rtmpUrl":"rtmp://myserver.com/my-stream-key",
    "rtmpTransponderFullUrl": true,
    "rtmpFlashVersion": "LNX 76.219.189.0"
}
Or you can deploy your own WCS instance in AWS EC2 and set up the following server properties in /usr/local/FlashphonerWebCallServer/conf/flashphoner.properties file:
Code:
rtmp_transponder_full_url=true
rtmp_transponder_stream_name_prefix=
rtmp_flash_ver_subscriber=LNX 76.219.189.0
rtmp_transponder_send_metadata=true
 

darndt

New Member
If NOT using AWS EC2...

So first I start publishing to your server with this code:

constraints.video.type = "screen";
constraints.video.withoutExtension = true;
session.createStream({
name: "mystream",
display: document.getElementById("screen-sharing"),
constraints: constraints
}).publish();



Then I do a POST to have it forwarded to our server:

POST /rest-api/push/startup HTTP/1.1
Host: demo.flashphoner.com:8081
Content-Type: application/json

{
"streamName": "mystream",
"rtmpUrl":"rtmp://myserver.com/my-stream-key",
"rtmpTransponderFullUrl": true,
"rtmpFlashVersion": "LNX 76.219.189.0"
}

Yes?

I'm assuming that the 2nd step (the POST) is NOT necessary in the production version? But rather, we specify the rtmpUrl when creating the stream?

Thanks,

-da
 

darndt

New Member
I tried this, and the POST returns a 500 (Internal Server Error).

Here is the fully formulated post:

demo.flashphoner.com:8081/rest-api/push/startup?streamName=mystream&rtmpUrl=rtmp://live.volume.com/live-origin/310.92b9dc27bec56c74db295a6ae7daaa93fd7129f28d1d927982c791bbfbef69d8&rtmpTransponderFullUrl=true&rtmpFlashVersion=LNX 76.219.189.0

I notice your example hast the POST as "/rest-api/push/startup HTTP/1.1" with a space between startup and HTTP? is that correct??

I tried this:

demo.flashphoner.com:8081/rest-api/push/startup?streamName=mystream&rtmpUrl=rtmp://live.volume.com/live-origin/stream-key&rtmpTransponderFullUrl=true&rtmpFlashVersion=LNX 76.219.189.0

And I get back a 500

Please advise.
 

Max

Administrator
Staff member
when I start streaming, it runs for a second then stops
If rtmpUrl is specified when the stream is created, and the push fails (e.g., if the RTMP server is unavailable), then the WebRTC publishing also fails.

Please verify that the server rtmpUrl and stream key are valid, and streaming not from the WCS is working. With the rtmpUrl from the example, publishing from OBS Studio fails.

"/rest-api/push/startup HTTP/1.1" with a space between startup and HTTP
That's the raw content of the HTTP POST.

In a POST request, send the parameters in the body.
Code:
curl -H "Content-Type: application/json" -X POST http://localhost:9091/rest-api/push/startup -d '{"streamName": "mystream", "rtmpUrl": "rtmp://<server>/<app>/mystream", "rtmpTransponderFullUrl": true}'
the 2nd step (the POST) is NOT necessary in the production version
Both ways are usable: push can be auto started when a WebRTC stream is published (if rtmpUrl is specified when the stream is created), or an already published stream can be pushed later using the /rest-api/push/startup request (then additional parameters like rtmpFlashVersion can be specified, and the stream can be pushed to more than one RTMP server using several requests).
 
Top