...

• IP cameras
• Media servers
• Surveillance systems
• Conference servers

Supported codecs

• H.264
• H265 (since 5.2.1579)
• VP8
• AAC
• G.711
• Speex

Supported platforms and browsers

...

h264_check_and_skip_annexb=true

Quick manual on testing

Capturing of a video stream from the IP camera and playing it in a browser

1. For this test we use:

• the demo server at demo.flashphoner.com;
• the Player web application to play the captured stream in the browser.

2. Open the Player web app and specify the URL of the camera in the "Stream" field:

Image Removed

3. Click the "Start" button. Broadcasting of the captured stream begins.

Image Removed

4. WebRTC internals diagrams:

Image Removed

Stream capture from the IP camera management by REST API

Usually, it is enough to set the camera URL as stream name to capture stream from IP camera. However, it is possible to manage RTSP stream capture by REST API if necessary.

Testing

1. For this test we use:

• the demo server at demo.flashphoner.com;
• the Chrome browser and the REST-client to send queries to the server;
• the Player web application to play the captured stream in the browser.

2. Open the REST client. Send the /rtsp/startup query specifying the URL of the web camera in parameters:

Image Removed

3. Make sure the stream is captured by the server. To do this, send the /rtsp/find_all query:

Image Removed

Image Removed

4. Open the Player web app and in the "Stream" field specify the URL of the web camera and click Start. Browser starts to play the stream:

Image Removed

5. Send the /rtsp/terminate query specifying the URL of the web camera in parameters:

Image Removed

6. Stream playback will terminate displaying an error:

Image Removed

REST-queries

A REST-query should be HTTP/HTTPS POST request as follows:

• HTTP: http://test.flashphoner.com:8081/rest-api/rtsp/startup
• HTTPS: https://test.flashphoner.com:8444/rest-api/rtsp/startup

Where:

• test.flashphoner.com - is the address of the WCS server
• 8081 - is the standard REST / HTTP port of the WCS server
• 8444 - is the standard HTTPS port
• rest-api - is the required part of the URL
• /rtsp/startup - REST-method to use

REST-methods and response statuses

...

REST-method

...

Example of REST-query

...

Example of response

...

Response statuses

...

Description

...

/rtsp/startup

...

{
 "uri":"rtsp://myserver.com/live/myStream",
 "toStream": "myRTSPstream"
}

409 - Conflict

500 - Internal error

Pull the RTSP stream by the specified URL

...

Since build 5.2.946, this parameter is removed from settings, and AnnexB frames are detected and played automatically.

Audio codecs exclusion

Sometimes it is necessary to capture a stream from camera without audio, or disable some audio codecs to escapr sound transcoding. This can be done with the following parameter listing audio codec names to be excluded while capturing stream, for example

rtsp_client_strip_audio_codecs=PCMA,PCMU

This setting will exclude PCMA (alaw) and PCMU (ulaw) codecs. A stream with audio track in those codecs will be captured from a camera as video only.

The listed codecs are excluded at SDP level, by names.

H264 packetization mode configuration

According to H264 specifications, if H264 packetization mode is not set explicitly in stream SDP, if should be set to 0. However, some RTSP cameras may send a stream encided with packetization mode 1, and may omit this mode setting in SDP. This behaviour may lead to stream transcoding and picture quality dropping while playing the stream in Safari browser.

Since build 5.2.820 it is possible to set default packetization mode to use such cameras with the following parameter

default_packetization_mode=1

Quick manual on testing

Capturing of a video stream from the IP camera and playing it in a browser

1. For this test we use:

• the demo server at demo.flashphoner.com;
• the Player web application to play the captured stream in the browser.

2. Open the Player web app and specify the URL of the camera in the "Stream" field:

Image Added

3. Click the "Start" button. Broadcasting of the captured stream begins.

Image Added

4. WebRTC internals diagrams:

Image Added

Stream capture from the IP camera management by REST API

Usually, it is enough to set the camera URL as stream name to capture stream from IP camera. However, it is possible to manage RTSP stream capture by REST API if necessary.

Testing

1. For this test we use:

• the demo server at demo.flashphoner.com;
• the Chrome browser and the REST-client to send queries to the server;
• the Player web application to play the captured stream in the browser.

2. Open the REST client. Send the /rtsp/startup query specifying the URL of the web camera in parameters:

Image Added

3. Make sure the stream is captured by the server. To do this, send the /rtsp/find_all query:

Image Added

Image Added

4. Open the Player web app and in the "Stream" field specify the URL of the web camera and click Start. Browser starts to play the stream:

Image Added

5. Send the /rtsp/terminate query specifying the URL of the web camera in parameters:

Image Added

6. Stream playback will terminate displaying an error:

Image Added

REST-queries

A REST-query should be HTTP/HTTPS POST request as follows:

• HTTP: http://test.flashphoner.com:8081/rest-api/rtsp/startup
• HTTPS: https://test.flashphoner.com:8444/rest-api/rtsp/startup

Where:

• test.flashphoner.com - is the address of the WCS server
• 8081 - is the standard REST / HTTP port of the WCS server
• 8444 - is the standard HTTPS port
• rest-api - is the required part of the URL
• /rtsp/startup - REST-method to use

REST-methods and response statuses

{
 "uri": "rtsp://myserver.com/live/myStream",
 "statuslocalStreamName": "PLAYING",
"toStream": "myRTSPstream"
}

{
"uri": "rtsp://myserver.com/live/myStream",
"status": "PLAYING",
"localStreamName": "myRTSPstream"
}

Parameters

{
"uri":"rtsp://myserver.com/live/myStream"
}

Parameters

Call flow

...

RTSP stream repeatedly capturing with the same URI

/rtsp/startup query returns 409 Conflict while trying to repeatedly capture RTSP stream with the same URI. If the stream from the IP camera is already published on the server, it is necessary to subscribe to it.

Call flow

Below is the call flow when using the Player example

...

If the name is set to the RTSP stream pulled, this stream can be played in CDN by its name (by default, CDN playback is not available for RTSP streams because they always are pulled locally).

Known issues

...

5. Connection to the IP camera is lost on error in any track (audio or video)

Symptoms: connection to the IP camera is lost if one of tracks returns error 4**.
Solution: this behavior is enabled by default. However if one-time errors are not critical and should not terminate broadcasting, in the flashphoner.properties files set

rtsp_fail_on_error_track=false
rtp_force_synchronization=true

6. All the characters in a stream name, that are not allowed in URI, should be escaped

Symptoms: RTSP stream is not played with 'Bad URI' error
Solution: any character that is not allowed in URI, should be escaped in stream URL, for example

rtsp://hostname/c@@lstream/channel1

should be set as

rtsp://hostname/c%40%40lstream/channel1

7. Some IP cameras do not support cnonce field in RTSP connection message header.

Symptoms: RTSP stream is played with VLC, but is not played with WCS.

Solution: set the following parameter in flashphoner.properties file

rtsp_auth_cnonce=

...

Capturing H265 RTSP stream

Since build 5.2.1579 it is possible to capture RTSP stream published by camera as H265. To enable this, H265 should be added to supported codecs list

codecs=opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,h264,vp8,flv,mpv,h265

and to exclusion lists

codecs_exclude_sip=mpeg4-generic,flv,mpv,h265
codecs_exclude_sip_rtmp=opus,g729,g722,mpeg4-generic,vp8,mpv,h265
codecs_exclude_sfu=alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,flv,mpv,h265

Stream captured may be played as WebRTC, RTMP, MSE, HLS with transcoding and as RTSP without transcoding

A first subscriber issue

Before WCS build 5.2.1760 RTSP streams may start to play with a huge delay for the first subscriber. This was due to key frames missing caused by subscriber thread starting after publisher thread. Since build 5.2.1760 the behavior was changed: publisher thread starts after subscriber thread. This may be reverted if necessary by the following parameter

agent_use_subscriber_listener=false

Stream timestamp fix

In some RTSP streams a frame timestamps may be in wrong order, for example two subsequent frames may have the same timestamp. Such stream may not be displayed or periodically display a gray square while playing via WebRTC. Since build 5.2.1794 the following parameter is availbel to fix a broken timestamps

jitter_buffer_attempt_to_correct_broken_timestamp=true

In this case RTSP capturing client log may contain a messages as follows

Non-monotonous timestamp in input stream; previous: 453424, current: 453424; changing to 453425. This may result in incorrect timestamps in the output

and the problem stream should play normally.

Known issues

5. Connection to the IP camera is lost on error in any track (audio or video)

Symptoms: connection to the IP camera is lost if one of tracks returns error 4**.
Solution: this behavior is enabled by default. However if one-time errors are not critical and should not terminate broadcasting, in the flashphoner.properties files set

rtsp_fail_on_error_track=false
rtp_force_synchronization=true

6. All the characters in a stream name, that are not allowed in URI, should be escaped

Symptoms: RTSP stream is not played with 'Bad URI' error
Solution: any character that is not allowed in URI, should be escaped in stream URL, for example

rtsp://hostname/c@@lstream/channel1

should be set as

rtsp://hostname/c%40%40lstream/channel1

7. Some IP cameras do not support cnonce field in RTSP connection message header.

Symptoms: RTSP stream is played with VLC, but is not played with WCS.

Solution: set the following parameter in flashphoner.properties file

rtsp_auth_cnonce=

with empty value.

8. Streams from some cameras cannot be played due to buffer size lack to write RBSP

Symptoms: RTSP stream is not playing with exceptions in server log

13:10:16,988 ERROR  BitstreamNormalizer - pool-56-thread-1 Failed to normalize SPS 674d002a95a81e0089f950
java.lang.RuntimeException: Failed to write sps rbsp

Solution: increase RBSP buffer size setting (1.5 by default)

h264_sps_rbsp_scale=2

9. Some camera streams can loose audio and video sync

Symptoms: RTSP stream freezes or cannot be played by HLS (some segments cannot be written), in stream statistics there are ubnormally big AV syncronization values

streams_synchronization=camera1/-21800;camera2/2079600704

Solution: in build before 5.2.1775 increase synchronization buffers for audio and video tracks

audio_incoming_buffer_size=100
video_incoming_buffer_size=100

since build 5.2.1775 increase force synchronization timeout for audio and video tracks

video_force_sync_timeout=1000
audio_force_sync_timeout=1000