Yes, there is no such file by default. You should create it and place the content we mentioned in this postIs that correct? I can create it and would it get picked up itself as its present now?
Yes, there is no such file by default. You should create it and place the content we mentioned in this postIs that correct? I can create it and would it get picked up itself as its present now?
If there are no subscribers to RTMP stream in 60 seconds by default, it will be stopped. So we recommend to inscrease this timeout to 12 hours for example (60 seconds * 60 minutes * 12 hours):Another problem we are having is, rtmp_stream auto disconnects after roughly 2mins. In our case there might be times when noone is talking for several mins, as its a news service. How can we stop that? It doesn't happen for the WebRTC stream.
rtmp_activity_timer_timeout=43200000
Yes, it seems like you should disable video rtp activity detection on all serversYou misunderstood me..what I meant was client is connected to the rtmp stream but after 2mins it disconnects itself. As suggested above the rtp timer is also 2mins and its audio only stream. Could the video side of things disconnecting it as there are packets for that?
rtp_activity_video=false
Seems like you had a problems with channel between browser and server while testing, and some packets were lost. This lead to choppy sound.What do you mean by channel issue? and what can we do about it?
Yes, it shoud be enoughIs updating the origin only enough?
But if it was the ISP provider issue, it should happen on WebRTC as well. It's not a random issue, voice is continuously worse on the rtmp re-publishingSeems like you had a problems with channel between browser and server while testing, and some packets were lost. This lead to choppy sound.
If this randomly happens, you probably shold not do something with it. If this occurs regularly, check your network connection, check the last mile from you to provider, change the network or provider.
Please provide SSH access to the server on which the problem is reproduced, we will checkToday, I could not see any packet lost but the sound is still choppy.
We update the origin to latest version 768 and voice on rtmp seems to be good as well. Not sure why it went bad as when we deployed 744 few weeks ago, we didnt had any issues until last few days.Please provide SSH access to the server on which the problem is reproduced, we will check
This is probably one of the audio transcoding issues fixed since build 5.2.764. That's why it can't be reproduced in latest builds.We update the origin to latest version 768 and voice on rtmp seems to be good as well. Not sure why it went bad as when we deployed 744 few weeks ago, we didnt had any issues until last few days.
media_transponder.sdp
tweak from this post on Origin server while upgrading it, so audio is resampled twice: from 48 kHz to 44.1 kHz when republishing as RTMP and back again when playing it on Edge server as WebRTC. Please note that media_transponder.sdp
file should be placed to /usr/local/FlashphonerWebCallServer/conf
foldercodecs_exclude_cdn=mpeg4-generic,alaw,ulaw,g729,speex16,g722,telephone-event,flv
http://localhost:8081/?action=stat
output on both Origin and Edge servers, and send us using this link, we will check the logs.Really sorry, that was a mistype.this is the location you asked to place the file
/usr/local/FlashphonerWebCallServer/conf
is the right place for all the settings.Updated all the settings and server to 768 apart from above ZGC activation. Will see how the performance goes tomorrow during the day. It does seem to be down to load as early in the day when less users are connected its fine and as more users starts to connect around 9am ET then sounds get crackly on rtmp### JVM OPTIONS ###
-Xmx8g
-Xms8g
# tried all the below combinations but server wouldn't start.
#-XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xms2g -Xmx8g -XX:+UseLargePages -XX:ZPath=/hugepages
#-XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xms4g -Xmx8g -XX:+UseLargePages -XX:ZPath=/hugepages
-XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xms8g -Xmx8g -XX:+UseLargePages -XX:ZPath=/hugepages
-XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xms8g -Xmx8g
ZGC should help: it reduces garbage collection pauses and server CPU load.It does seem to be down to load as early in the day when less users are connected its fine and as more users starts to connect around 9am ET then sounds get crackly on rtmp