RTMP server configuration

[rickKoch]

Hello.
I'm trying to do rtmp stream with 720p over phone, but I have some video glitches.

Once I updated the codes the glitches are gone, but the quality is bad.
codecs=opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,vp8,h264,flv,mpv

The rest of my server config is
rtmp_transponder_stream_name_prefix=
rtmp_flash_ver_subscriber=LNX 76.219.189.0
ice_tcp_transport=true
webrtc_cc_min_bitrate=3000000
webrtc_cc_max_bitrate=10000000
webrtc_sdp_min_bitrate_bps=6000000
webrtc_sdp_max_bitrate_bps=14000000

Can you please tell me what I'm doing wrong, or help me to set up the configuration.
Thank you.

 

[Max]

Good day.

webrtc_sdp_min_bitrate_bps=6000000
webrtc_sdp_max_bitrate_bps=14000000

This bitrate seems too high. This will require a t lease 20 Mbps upload channel from publisher to WCS server, so those setting cannot be used to publish a stream from phone via mobile networks. Please use lower bitrate constraints:

webrtc_cc_min_bitrate=500000
webrtc_cc_max_bitrate=1500000

and remove webrtc_sdp_... settings.
Also, you've set codecs priority as vp8,h264. In this case, stream can be published as VP8, but RTMP republishing requires H264, so transcoding will be enabled on server. Therefore, server should have at least 1 CPU per 2 720p streams + 1 CPU core for common tasks. 8 CPU / 16 Gb RAM (8 Gb Java heap) seems to be minimal configuration in this case.
Or you can change priority to h264,vp8 and publish H264, in this case, no video transcoding is required.

 

[rickKoch]

This worked, but the quality is still bad.

 

[Max]

This worked, but the quality is still bad.

Please check if channel quality and bandwidth is good enough to publish 720p stream. For example, use a different network (Wi-Fi instead of LTE) to publish a stream, ore try to use lower resolution to publish (360p for example). Switchin to TCP transport may also help to reduce packet loss:

session.createStream({
    name: streamName,
    display: localVideo,
    ...
    transport: "TCP"
}).on(STREAM_STATUS.PUBLISHING, function (stream) {
...
}).publish();

Also, please check CPU load during RTMP republishing. If this is high, it means transcoding may be enabled. In this case, check server statistics page http://wcs:8081/?action=stat for video encoders:

-----Native Resources-----
...
native_resources.video_decoders=0
native_resources.video_encoders=0
...

If those values are not 0, it means video transcoding is still enabled. In this case, please consider to upgrade the server as we recommended above, or exclude transcoding by disabling VP8 codec:

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

 

[rickKoch]

I've excluded the VP8 by updating:
codecs=opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,h264,flv,mpv

but I can still see the:
native_resources.video_decoders=1
native_resources.video_encoders=1

I'm using as you recomended:
webrtc_cc_min_bitrate=500000
webrtc_cc_max_bitrate=1500000

 

[Max]

Please clarify how do you testing:
- using WebRTC as RTMP republishing example
- or using REST API /push/startup
For REST API, provide your query example.
Also, collect a report as described here including client debug logs and send using this form.

 

[rickKoch]

I'm using WebRTC as RTMP republising(on AWS EC2 instance - c5.large)

 

[Max]

I'm using WebRTC as RTMP republising(on AWS EC2 instance - c5.large)

Please collect a report as described here including client debug logs and send using this form.