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 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.
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
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.
Below is the call flow when an RTMP stream is broadcast from an external source (Live Encoder)to the WCS server
Parsing stream URL parametersWhen RTMP stream is published or played on WCS, RTMP connection and stream parameters may be set in stream URL like this:
Where
WCS server passes the parameters to backend server in REST hook in
This feature can be used for example to authenticate client on backend server while publishing or playing RTMP-stream on WCS server. Connection parameters passing as stream parametersIn some cases it is necessary to pass RTMP connection parameters as stream parameters, authentication parameter for example
This feature is enabled by the following setting
In this case, the RTMP URL example above will be interpreted as
|
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
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.
Since build 5.2.533, RTP activity checking for RTMP streams can be enabled with the following parameter in flashphoner.properties file:
flash_rtp_activity_enabled=true |
Read timeout is set with the following settings in flashphoner.properties file:
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 is set with the following setting
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 is set with the following setting
rtmp.server_socket_timeout=120 |
In this case RTMP connection will be closed if no data was received and sent in last 120 seconds.
When publishing RTMP stream to WCS, stream picture can be rotated using RTMP metadata. It may be useful for picture handling from mobile publishers.
To turn a picture to a certain angle RTMP metadata containing ‘orientation’ field should be sent. The following orientations are supported:
Orientation value | Rotation angle, degrees |
0 | 0 |
1 | 90 |
2 | 180 |
3 | 270 |
A picture is rotated clockwise.
To enable stream rotation, set the following parameter in flashphoner.properties file:
video_filter_enable_rotate=true |
Note that stream rotation works for transcoded streams only.
1. For test we use:
2. Open Flash Streaming application. Set stream name test and desired stream publishing parameters:
3. Click Login then Start. Stream publishing begins
4. Open Player application in anoter tab or browser, play the stream named test
5. In Flash Streaming application click 180 button in Rotate camera section. The stream rotated to 180 degrees clockwise will be displayed in Player application
Stream orientation metadata sending is implemented in Flash Streaming application as follows:
private function rotate(degree:Number):void {
var metaDataObj:Object = new Object();
switch(degree) {
case 0:
Logger.info("rotate camera to 0");
metaDataObj.orientation = 0;
break;
case 90:
Logger.info("rotate camera to 90");
metaDataObj.orientation = 1;
break;
case 180:
Logger.info("rotate camera to 180");
metaDataObj.orientation = 2;
break;
case 270:
Logger.info("rotate camera to 270");
metaDataObj.orientation = 3;
break;
default:
metaDataObj.orientation = 0;
break;
}
sendMetaData(metaDataObj);
}
private function sendMetaData(data:Object):void{
if (publishStream != null) {
publishStream.send("@setDataFrame", "onMetaData", data);
}
} |
Note that orientation value should be sent but not angle itself.
ffmpeg RTMP encoder allows to send orientation metadata to WCS server using command line switches:
ffmpeg -i input.mp4 -metadata:s:v rotate=90 -vcodec copy -acodec copy -strict -2 -f flv rtmp://test1.flashphoner.com:1935/live/stream_ffmpeg |
Note that ffmpeg sends orientattion value but not angle itself.
When RTMP stream is published from software encoder supportin hardware acceleration on NVIDIA GPU, and contains B-frames, the stream picture can twitch in some RTMP or HLS players. To workaround this, since build 5.2.863 the parameter was added to set the maximum decoding buffer size passed in SPS
h264_sps_max_dec_frame_buffering=-1 |
By default, buffer size is not limited. This eliminates picture twitching, but can inscrease latency due to excessive buffering. In this case, the buffer size can be limited to 2 frames (default value before build 5.2.863)
h264_sps_max_dec_frame_buffering=2 |
or more frames to eliminate twitching without viewable latency.
RTMP stream published with high resolution and bitrate may be played non smoothly via WebRTC with freezes or low FPS if publishers channel is unstable. Incoming stream should be buffered to prevent playback issues
rtmp_in_buffer_enabled=true |
Adaptive RTMP incoming buffer has the following parameters to tune:
| Parameter | Description | Default value |
|---|---|---|
| rtmp_in_buffer_start_size | Minimum buffer volume to start, ms | 300 |
| rtmp_in_buffer_initial_size | Maxumum buffer volume, ms | 2000 |
| rtmp_in_buffer_max_bufferings_allowed | Maximum bufferings amout allowed | -1 (unlimited) |
| rtmp_in_buffer_polling_time | Buffer polling period, ms | 100 |
| rtmp_in_buffer_overflow_allowed_deviation | Maximum difference between minimum and maximum buffer volumes used, ms | 1000 |
| rtmp_in_buffer_overflow_deviation_window | Window size to collect the difference, ms | 30000 |
| rtmp_in_buffer_overflow_rate | Maximum buffer overflow rate | 0.15 |
| rtmp_in_buffer_clear_threshold | Clear all the data exceeding maxumum buffer size when buffer reaches the threshold, ms | 30000 |
RTMP stream timestamps may significally differ from server time, and stream may give a delay if there is not enough systrem perfomance for software stream encoder, or if channel bandwidth decreases. Buffering of such stream will give a periodic freezes while playing it. Since build 5.2.1311 the following parameter was added to disable buffering and pass incoming traffic directly to server engine
rtmp_in_buffer_input_delay_threshold=0 |
By default, RTMP traffic will always be buffered if buffering is enabled. Buffering can be disabled when stream delay reaches a value defined in milliseconds
rtmp_in_buffer_input_delay_threshold=3000 |
In this case, buffer is cleared and goes to the PASSTHROUGH state. Even if stream delay becomes lower, buffer will remain in the state, and stream will not be buffered until publishing is stopped.
By default, a possible RTMP publishing parameters are set according to SDP settings file. Since build 5.2.1862 the following option is added to enable automatic stream publishing parameters detection by stream metadata or media traffic data
flash_detect_metadata_by_traffic=true |
The option is enabled by default. In this case, WCS changes SDP according to a stream metadata received or, if there are no metadata in 1 second, according to media information from the stream media packets received.
4. Some RTMP functions does not supported and will be ignored:
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
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.
8. When stream published with RTMP encoder is played as WebRTC, stream audio has low quality
Symptoms: sound is good enogh for speech but not for music when RTMP is played as WebRTC
Solution: set Opus encoding bitrate as published one, for example
opus.encoder.bitrate=160000 |
if RTMP stream is published with audio bitrate 160 kbps
9. High CPU load when stream H264+speex is published (for example, using Flash client) with audio transcoding
Symptoms: high CPU load while audio transcoding from speex to AAC or Opus
Solution: use native speex decoder implementation
use_speex_java_impl=false |
10. Stream with unsupported codecs cannot be published
Symptoms: RTMP stream with MP3 or AC3 audio is not publishing with the following warnings in server log
11:01:00,921 WARN ServerHandler - RTMP-pool-15-thread-1 Codecs not supported! audio: NoCodec, video: NoCodec |
Solution: reencode stream to supported codecs using corresponding encoder settings