Table of Contents |
---|
To run online broadcasts you can use special hardware or software video capturing devices (Live Encoder). Such devices or programs capture a video stream and send it to the server via the RTMP protocol.
Web Call Server 5.1 can receive an RTMP video stream from such a device or software (Wirecast, ffmpeg, OBS Studio, FMLE etc.) encoded to H.264 + AAC or Sorenson Spark + Speex and broadcast this video stream to browsers and mobile devices.
Overview
Technical specifications
Receiving incoming audio- and video streams via the RTMP protocol
Broadcasting of the received video stream to browsers and platforms: any among ones supported by WCS
Uses video stream playback technologies: any among ones supported by WCS
Codec support
- Video H.264 + audio AAC
- Video Sorenson Spark + audio Speex 16 kHz
Operation flowchart
1. Live Encoder establishes a connection to the server via the RTMP protocol and sends the publish command.
2. Live Encoder sends the RTMP stream to the server.
3. The browser establishes a connection via Websocket and sends the play command.
4. The browser receives the WebRTC stream and plays that stream on the page.
...
Call flow
Below is the call flow when an RTMP stream is broadcast from an external source (Live Encoder)to the WCS server
...
Parsing stream URL parameters
When RTMP stream is published or played on WCS, RTMP connection and stream parameters may be set in stream URL like this:
Code Block | ||||
---|---|---|---|---|
| ||||
rtmp://host:1935/live?connectParam1=val1&connectParam2=val2/streamName?streamParam1=val1&streamParam2=val2 |
Where
- host is WCS server hostname;
- connectParam1, connectParam2 are RTMP connection parameters;
- streamName is stream name on server;
- streamParam1, streamParam2 are stteam parameters.
WCS server passes the parameters to backend server in REST hook in custom
field, for example:
...
Code Block | ||||
---|---|---|---|---|
| ||||
URL:http://localhost:8081/apps/EchoApp/connect
OBJECT:
{
"nodeId" : "Qb3rAjf3lzoy6PEl1WZkUhRG1DsTykgj@192.168.1.1",
"appKey" : "flashStreamingApp",
"sessionId" : "/127.0.0.1:5643/192.168.1.1:1935",
"useWsTunnel" : false,
"useWsTunnelPacketization2" : false,
"useBase64BinaryEncoding" : false,
"keepAlive" : false,
"custom" : {
"connectParam1" : "val1",
"connectParam2" : "val2"
},
"login" : "rQq83sodiCPY0pJXCxGO"
} |
...
Code Block | ||||
---|---|---|---|---|
| ||||
URL:http://localhost:8081/apps/EchoApp/publishStream
OBJECT:
{
"nodeId" : "Qb3rAjf3lzoy6PEl1WZkUhRG1DsTykgj@192.168.1.1",
"appKey" : "flashStreamingApp",
"sessionId" : "/127.0.0.1:5643/192.168.1.1:1935",
"mediaSessionId" : "627990f9-8fe5-4e92-bb2a-863cc4eb43de",
"name" : "stream1",
"published" : true,
"hasVideo" : false,
"hasAudio" : true,
"status" : "NEW",
"record" : true,
"width" : 0,
"height" : 0,
"bitrate" : 0,
"minBitrate" : 0,
"maxBitrate" : 0,
"quality" : 0,
"mediaProvider" : "Flash",
"custom" : {
"streamParam1" : "val1",
"streamParam2" : "val2"
}
} |
...
Code Block | ||||
---|---|---|---|---|
| ||||
URL:http://localhost:8081/apps/EchoApp/playStream
OBJECT:
{
"nodeId" : "Qb3rAjf3lzoy6PEl1WZkUhRG1DsTykgj@192.168.1.1",
"appKey" : "flashStreamingApp",
"sessionId" : "/127.0.0.1:5643/192.168.1.1:1935",
"mediaSessionId" : "stream1/127.0.0.1:5643/192.168.1.1:1935",
"name" : "stream1",
"published" : false,
"hasVideo" : true,
"hasAudio" : true,
"status" : "NEW",
"record" : false,
"width" : 0,
"height" : 0,
"bitrate" : 0,
"minBitrate" : 0,
"maxBitrate" : 0,
"quality" : 0,
"mediaProvider" : "Flash",
"custom" : {
"streamParam1" : "val1",
"streamParam2" : "val2"
}
} |
This feature can be used for example to authenticate client on backend server while publishing or playing RTMP-stream on WCS server.
...
Using RTMP connection timeouts
In some cases, if RTMP encoder does not support Keep Alive packets sending, or Keep Alives are disabled due to another reason with the following parameter
Code Block | ||
---|---|---|
| ||
keep_alive.algorithm=NONE |
it is necessary to control RTMP connection and close it when no data was transmitted for a long time. To do this, use the following parameters.
Read timeout
Read timeout is set with the following settings in flashphoner.properties file:
Code Block | ||
---|---|---|
| ||
rtmp.server_read_socket_timeout=120 |
In this case RTMP connection will be closed if no data was received in last 120 seconds.
Write timeout
Write timeout is set with the following setting
Code Block | ||
---|---|---|
| ||
rtmp.server_write_socket_timeout=120 |
In this case RTMP connection will be closed if no data was sent in last 120 seconds.
Read and write timeout
Read and write timeout is set with the following setting
Code Block | ||
---|---|---|
| ||
rtmp.server_socket_timeout=120 |
In this case RTMP connection will be closed if no data was received and sent in last 120 seconds.
Known issues
...
4. Some RTMP functions does not supported and will be ignored:
- FCSubscribe
- FCPublish
- FCUnpublish
- onStatus
- onUpstreamBase
- releaseStream
5. Some RTMP-encoders does not support KeepAlive.
Symptoms: disconnection occurs often while stream publishing with RTMP-encoder.
Solution: switch KeepAlive off for RTMP on the server using the following parameter in flashphoner.properties file
Code Block | ||||
---|---|---|---|---|
| ||||
keep_alive.enabled=websocket,rtmfp |
7. When stream published with RTMP encoder is played as HLS, freezes may occur if GOP is not multiple of FPS of file published
Symptoms: freezes occur when RTMP stream is played as HLS
Solution: in RTMP encoder settings, assign GOP to value equal or multiple of FPS of file published. For example, when publishing file with FPS 25 set GOP to 50.
Include Page | ||||
---|---|---|---|---|
|