During a funeral livestream today we had the bitrate fall to zero for long enough that YouTube ended the stream. This has not happened before. We have been using this setup for about 2-1/2 years. After a little bit the bitrate came back and then YouTube started the stream again. When that happened I uploaded the current log file. OBS Log File I also was able to screenshot the stats page which is attached. We didn't have any dropped frames. I didn't think to screen shot the screen when it was happening. But I noticed that the CPU usage was the normal 33%. Thanks for any help you can give.
Low Bitrate Issues
- Thread starter davdue
- Start date
TwistedBoii
New Member
Same it has happened to me also many times
Lawrence_SoCal
Active Member
Please clarify - you said no dropped frames but the screenshot you shared shows 1.4% dropped frames (Network) and 0.2% due to encoding lag?
10:52:27.350: Output 'simple_stream': Number of dropped frames due to insufficient bandwidth/connection stalls: 9676 (13.0%)
clearly you were having network congestion issues
That is an ancient CPU for real-time video encoding which is VERY computationally demanding and you don't have a Turing NVENC GPU for encoding offload (though you do on an input source??).
And you are adding NDI processing workload on top of that. Ugh, and chroma-keying... Dang, I'm impressed it has worked for you up til now.
I recommend real-time monitoring hardware resource (CPU, GPU, RAM, Disk I/O, etc) utilization [for ex. using Task manager’s Performance tab and/or Resource Monitor] to see if your system is being maxed out with your settings [which I'm sure it is.. The OBS Stats window CPU is for the OBS process ONLY, not NDI, not the OS, etc. On my PC, OBS sits under 2%.
These are good OBS troubleshooting resources to be aware of
- https://obsproject.com/wiki/General-Performance-and-Encoding-Issues and https://obsproject.com/wiki/GPU-overload-issues
- https://obsproject.com/wiki/Dropped-Frames-and-General-Connection-Issues
Just curious - do you have guest Wi-Fi enabled and using same Internet connection as your livestream? if yes, do you have Quality of Service (QoS) to prioritize the stream, or doing real-time network traffic monitoring to make sure guest (or Office PCs, or whatever) isn't causing network traffic congestion?
Log (which you should review) shows massive # of errors on what appears to be 2 RTSP (I'm assuming cheap IP security) cameras?
10:51:59.458: MP: Failed to open media: 'rtsp://192.168.0.175/'
10:52:06.873: error: method DESCRIBE failed: 404 Stream Not Found
10:52:06.873: MP: Failed to open media: 'rtsp://192.168.0.200/1'
09:25:39.608: [Media Source 'Tethys 1080P Camera']: settings:
09:25:39.608: input: rtsp://192.168.0.175/
and a non descript Media source for .200
So I'm a bit confused
That OBS streaming has worked with those settings at all is impressive, and indicates a sophisticated level of OS and OBS optimizations. But there seems to be a bit of a mess in terms of sources, which would indicate an opposite level of sophistication regarding OBS
10:52:27.350: Output 'simple_stream': Number of dropped frames due to insufficient bandwidth/connection stalls: 9676 (13.0%)
clearly you were having network congestion issues
That is an ancient CPU for real-time video encoding which is VERY computationally demanding and you don't have a Turing NVENC GPU for encoding offload (though you do on an input source??).
And you are adding NDI processing workload on top of that. Ugh, and chroma-keying... Dang, I'm impressed it has worked for you up til now.
I recommend real-time monitoring hardware resource (CPU, GPU, RAM, Disk I/O, etc) utilization [for ex. using Task manager’s Performance tab and/or Resource Monitor] to see if your system is being maxed out with your settings [which I'm sure it is.. The OBS Stats window CPU is for the OBS process ONLY, not NDI, not the OS, etc. On my PC, OBS sits under 2%.
These are good OBS troubleshooting resources to be aware of
- https://obsproject.com/wiki/General-Performance-and-Encoding-Issues and https://obsproject.com/wiki/GPU-overload-issues
- https://obsproject.com/wiki/Dropped-Frames-and-General-Connection-Issues
Just curious - do you have guest Wi-Fi enabled and using same Internet connection as your livestream? if yes, do you have Quality of Service (QoS) to prioritize the stream, or doing real-time network traffic monitoring to make sure guest (or Office PCs, or whatever) isn't causing network traffic congestion?
Log (which you should review) shows massive # of errors on what appears to be 2 RTSP (I'm assuming cheap IP security) cameras?
10:51:59.458: MP: Failed to open media: 'rtsp://192.168.0.175/'
10:52:06.873: error: method DESCRIBE failed: 404 Stream Not Found
10:52:06.873: MP: Failed to open media: 'rtsp://192.168.0.200/1'
09:25:39.608: [Media Source 'Tethys 1080P Camera']: settings:
09:25:39.608: input: rtsp://192.168.0.175/
and a non descript Media source for .200
So I'm a bit confused
That OBS streaming has worked with those settings at all is impressive, and indicates a sophisticated level of OS and OBS optimizations. But there seems to be a bit of a mess in terms of sources, which would indicate an opposite level of sophistication regarding OBS
Thanks for the in depth explanation and suggestions. I looks like we need to upgrade this computer. True there are some dropped frames but for me 1.4% is very low. Here is another screenshot and a new log file. They show a typical Sunday morning. Normally the only issue we have is a YouTube not receiving enough data for smooth watching. When we do a speed test we find that our upload speed has dropped below 10Mbps. When it happens it is between 10-10:15 am. We have had Cox come out and they didn't find anything wrong, of course, on their side. We believe it is a bandwidth issue with the our little town with several churches livestreaming.
We are hardwired to the network. We looked in our wireless router and found a setting for streaming priority but that won't help with this since we are on a switcher off the cable modem. Will need to look into this some more.
The Tethys isn't used. It was an attempt to use that security camera for my daughters wedding. I couldn't get it to work since it didn't support RSTP. I have removed that scene & source. I also cleaned out some other old scenes. We use an ATEM mini with 3 cameras. 2 Aida PTZ-X20-IP (HDMI connection, IP for adjusting settings), & a Canon Vixia (HDMI). We started out with a Canon EOS Rebel T6 via USB and window capture and then go one Aida camera and a Black Magic Devics deck link capture card while waiting on the 2nd camera and ATEM to arrive. So the mess was old things there as we upgraded. I have cleaned most of that up now.
OBS Log File
Lawrence_SoCal
Active Member
Dave,
what you didn't comment on is who/what else might be using that Cox Internet connection during the service? if anyone/anything
When pandemic first hit in early 2020, our AT&T DSL dropped to 5Mb/s, and I could stream at 2,500->3000kb/s just fine. I also made sure OBS PC was the only device using Internet. Now that upload limit is back to around 10Mb/s, and Facebook allows 1080p, I bumped us up to streaming at 7200kb/s every Sanday service. I get 0 dropped frames. The only time we have dropped network frames is if someone leave OneDrive on backing up/syncing a video
A SpeedTest is by intent and design, highly optimistic, whereas for streaming what counts is the sustained throughput (so least optimistic / worst case value).
what you didn't comment on is who/what else might be using that Cox Internet connection during the service? if anyone/anything
When pandemic first hit in early 2020, our AT&T DSL dropped to 5Mb/s, and I could stream at 2,500->3000kb/s just fine. I also made sure OBS PC was the only device using Internet. Now that upload limit is back to around 10Mb/s, and Facebook allows 1080p, I bumped us up to streaming at 7200kb/s every Sanday service. I get 0 dropped frames. The only time we have dropped network frames is if someone leave OneDrive on backing up/syncing a video
A SpeedTest is by intent and design, highly optimistic, whereas for streaming what counts is the sustained throughput (so least optimistic / worst case value).
Well we have assumed that no one is using the network outside of anyone on the wifi. Plus we always thought that they would be using the download wouldn’t affect the upload bandwidth. But maybe that is a wrong assumption and understanding. The reason we use YouTube is because a lot of people don’t use social media so they can watch the stream without needing a Facebook account. We have 9 computers on the network. All but 3 of those are setting idle during our stream. 2 of them are in the sound booth. One running easyworship and driving our projectors. The other one is the OBS computer. The 3rd one is in our chapel where children’s church is held. I really don’t have any specifics on what that computer is doing. I think it may be a PowerPoint or it could be more. I will have to ask to find out. All the rest are staff computers and one is in the library running the library software that is offline. Hope this helps.
Lawrence_SoCal
Active Member
Correct - bad assumption. True most bandwidth usage is typically download _but_ TCP reply packets go the other way. And without monitoring, you won't know. All it takes is one nincompoop attendee with the 'geez I didn't/know/think about that' [this includes clueless teenagers] or 'I forgot I had that (always) on' or other ID10T/PEBKAC stupidity to cause havoc.
As for Office PCs, not logged in/person not sitting at keyboard does not necessarily mean idle. Updates, telemetry, etc. Don't assume what they are (not) doing... I typically make sure office laptop are in Airplane mode, and desktops powered off, that way I know they can't use the network. As for the children's chapel PC - check it to see if it truly needs Internet connectivity during service. If yes, check out that PC thoroughly in terms of what EXACTLY is running. [too many (most) users have no idea, and stuff can be running unexpectedly]
As for network, What I recommend is setting up a monitor at either the cable modem or the router for upstream traffic. Watching it in real-time is preferred, but logging may need to suffice, if it has accurate enough timestamps to correlate with your OBS log. What you will be looking for is if upstream traffic is exceeding (by more than a couple of single-digit %) your streaming bitrate (ie something else using upload bandwidth). You are not using enough bandwidth, I'd think, that a single stream of yours would be impacting your ISP upstream. The far greater likelihood (though not a certainty) is a network bottleneck onsite before the modem.
I say go where your users are. That said, Facebook Scheduled live video does NOT require being a Facebook user (or being logged in) to watch, including comments (when not logged into FB, a watcher can see, but not make, comments). With Scheduled (vs ad-hoc/Go Live now) we have a static URL on our FB livestream services. This FB livestream URL is published on our website, and in newsletter, etc. ... hasn't change in 2 years. Folks set it up on their smart TVs, Roku, etc. I always recommend using a browser InCognito mode (I do not have a FB account). Works fine. The downside to FB used to be a max 720p video (other than special gamer program), but now we can stream in 1080p without issue to FB.
As for Office PCs, not logged in/person not sitting at keyboard does not necessarily mean idle. Updates, telemetry, etc. Don't assume what they are (not) doing... I typically make sure office laptop are in Airplane mode, and desktops powered off, that way I know they can't use the network. As for the children's chapel PC - check it to see if it truly needs Internet connectivity during service. If yes, check out that PC thoroughly in terms of what EXACTLY is running. [too many (most) users have no idea, and stuff can be running unexpectedly]
As for network, What I recommend is setting up a monitor at either the cable modem or the router for upstream traffic. Watching it in real-time is preferred, but logging may need to suffice, if it has accurate enough timestamps to correlate with your OBS log. What you will be looking for is if upstream traffic is exceeding (by more than a couple of single-digit %) your streaming bitrate (ie something else using upload bandwidth). You are not using enough bandwidth, I'd think, that a single stream of yours would be impacting your ISP upstream. The far greater likelihood (though not a certainty) is a network bottleneck onsite before the modem.
I say go where your users are. That said, Facebook Scheduled live video does NOT require being a Facebook user (or being logged in) to watch, including comments (when not logged into FB, a watcher can see, but not make, comments). With Scheduled (vs ad-hoc/Go Live now) we have a static URL on our FB livestream services. This FB livestream URL is published on our website, and in newsletter, etc. ... hasn't change in 2 years. Folks set it up on their smart TVs, Roku, etc. I always recommend using a browser InCognito mode (I do not have a FB account). Works fine. The downside to FB used to be a max 720p video (other than special gamer program), but now we can stream in 1080p without issue to FB.