WebRTC congestion Network

[michelklingler]

Hi !

I have a wierd thing happening.

I publish with OBS WebRTC to my AWS Server.
On top of that there is a WebRTC 1 way video and 2 way audio that I publish from my computer at the office.

When There is more than 3 peoples at the office watching the stream via their browser in WebRTC there is massive lag going on.
People watching the stream also share their audio.

Basicaly just to make it clear :

REMOTE NETWORK:
1 remote server publish a 1080p 60fps / Birate 3000 - 5000 kbps to an external WC5 AWS Server.

INTERNAL NETWORK
1 PC Publish another webcam audio and video webRTC to the AWS Server + get the 1080p 60fps Remote server WebRTC Stream.
2 PC Publish audio only and receive Audio + Video of the web cam + get the 1080p 60fps Remote server WebRTC Stream.

I tested another external client while it was all laggy internally, the external client did not have any lag.

It is not because of the internet bandwidth, as we have a 100/100 dedicated fiber network.
I checked the router and there is still a lot of bandwidth available.

Is there some possible port conflict or congestion happening ?

How can i track this issue ?

Thank you !
Michel

 

[Max]

Good day.
You're publishing 1080p 60 fps WebRTC stream with huge bitrate (3000 - 6000 kbps bounds are set). Also you are using OBS WebRTC streamer. This streamer supports VP8+Opus publishing only, please see this page.
When subscribers are playing this stream in browser, H264 codec is preferred to play by default, so stream transcoding is starting. Seems like server CPU is not enough to encode "fat" stream, so freezes, lags and artifacts occur.
To escape transcoding, you can lower H264 codec priority and completely disable it for streaming

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

But in this case streams will not be played or published if browser does not support VP8.
We recommend the following if you prefer to use VP8 codec for streaming:
1) Migrate to more powerful instance. We recommend at least c4.2xlarge
2) Exclude H264 codec on client side on per browser basis to minimize transcoding
for publishing:

publishStream = session.createStream({
    ...
    stripCodecs: "h264,H264"
}).on(STREAM_STATUS.PUBLISHING, function (publishStream) {
    ...
});
publishStream.publish();

for playing:

playStream = session.createStream({
    ...
    stripCodecs: "h264,H264"
}).on(STREAM_STATUS.PLAYING, function (playStream) {
    ...
});
playStream.play();

3) Set B-frames to 0 in streamer output settings if available. B-frames are not supported by browsers and can lead to picture twitching and other artifacts while playback.

 

[michelklingler]

Hi Max,

Thanks again for the good support.

I understand OBS WebRTC does not support H.264.

Do you know any other Streamer that does publish in WebRTC and uses H.264 ?

This would solve my problems right ?

Thanks,
M.

 

[Max]

Do you know any other Streamer that does publish in WebRTC and uses H.264 ?
This would solve my problems right ?

Yes, H264 usage should solve transcoding problems.
Unfortunately, H264 codec usage is limited by licensing, so it is fully supported for WebRTC streaming in some browsers only. But not at all: latest builds of Firefox on Android does not support H264 for publishing.
So you have to use either Chrome browser to stream H264 or OBS WebRTC streamer to stream VP8 with transcoding.
Another option is to stream RTMP (OBS, XSplit, ffmpeg etc), in this case, you will have a little delay (1-3 seconds), but H264 with good quality.