...
- 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
...
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
...
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
Code Block |
---|
|
codecs=opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,h264,vp8,flv,mpv,h265 |
and to exclusion lists
Code Block |
---|
|
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
Warning |
---|
A stream should not contain B-frames! If B-frames occur in the stream, it may be played as RTSP without transcoding only |
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
Code Block |
---|
|
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
Code Block |
---|
|
jitter_buffer_attempt_to_correct_broken_timestamp=true |
In this case RTSP capturing client log may contain a messages as follows
Code Block |
---|
|
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
Excerpt Include |
---|
| From another server via RTMP |
---|
| From another server via RTMP |
---|
nopanel | true |
---|
|
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
...
Code Block |
---|
|
streams_synchronization=camera1/-21800;camera2/2079600704 |
Solution: in build before 5.2.1775 increase synchronization buffers for audio and video tracks
Code Block |
---|
|
audio_incoming_buffer_size=100
video_incoming_buffer_size=100 |
since build 5.2.1775 increase force synchronization timeout for audio and video tracks
Code Block |
---|
|
video_force_sync_timeout=1000
audio_force_sync_timeout=1000 |