Good day.
Please, do the following:
1. Check if publishing resolution and bitrate fit to the channel bandwidth between publisher and server. Channel bandwidt can be measured using iperf utility as described
here. TCP bandwidth should be tested for RTMP publishing. For example, if you're publishing 1080p stream with 10 Mbps, and the channel bandwidth is 10 Mbps, publishing bitrate should be lowered to 5-7 Mbps.
2. Check is there packet loss between publisher and server. Please get the published stream metrics as described
here and check the value of VIDEO_LOST metric, it should not grow between metrics requests. For example, if VIDEO_LOST value is 1% of VIDEO_P_FRAMES, the channel is bad and should be changed (migrate to another network, provider etc).
3. Check are there B-frames in stream published. If stream metric VIDEO_B_FRAMES is not zero, there are B-frames. They cannot be decoded by browser while playing WebRTC, so they should be excluded. Please choose baseline profile with ultrafast preset to publish a stream, or set B-frames parameter to 0 if available.
4. Check if stream published is transcoding on server while playing. For example if you're publishing RTMP stream you probably use H264 video codec. If a viewer plays the stream using VP8 codec, the stream will be transcoded from H264 to VP8. All the possible reasons for stream transcodin are listed
here. You should either escape transcoding (use the same video codec, resolution and bitrate to play) or upgrade you server meaning 1 CPU core to encode 2 720p streams or 3 480p streams or 5 360p streams.
5.
Tune Java heap memory to 1/2 of server RAM to reduce garbage collection pauses.
