Dropped Frames (Network) vs Frames missed due to redering log vs Skipped frames due to encoding log

easykey

New Member
Please excuse my ignorance - I have spent hours searching for the answer to this and cannot seem to find anything.

I am using OBS for live streaming funerals and have the Stats panel docked to keep an eye on things.
When I carry out a test I get the following:
1. The Dropped Frames (Network) = 0%
2. Frames missed due to rendering lag = 0%
3. Skipped frames due to encoding lag = 0%

Then when I click Start Streaming I get:
1. The Dropped Frames (Network) = 0%
2. Frames missed due to rendering lag = between 3% to 10%
3. Skipped frames due to encoding lag = between 0 to 0.5%

My question is what is the difference between the three?
Why does number 1 = 0% dropped frames yet the resulting livestream video is choppy?
 
What kind of "test" are you running?
If you aren't streaming or locally recording, the encoder is not actually doing any work. I'm not sure if the renderer is either (as the Preview window is pre-renderer output).

Rendering lag normally indicates either an over-loaded GPU, or (a) slow source(s) preventing the renderer from handling its tasks within the timeframe necessary for the chosen streaming/recording framerate (ex: for 60fps video, each frame must be completed in less than 16.7 milliseconds, preferably far less).

Encoding lag depends on which encoder you are using, but if rendering lag is present, can cause encoding lag as the encoder is not 'fed' frames fast enough to maintain a steady framerate.


Most common 'slow' sources are things like browser sources with very slow/heavy webpages loaded, and those garbage 'use your phone as a wifi webcam' apps. But can be caused by capture conflicts, or just not having a discrete GPU and using the built-in integrated GPU instead; iGPUs don't have dedicated VRAM (they tend to use system memory as VRAM, which is FAR slower) and their data bus speeds tend to be very low, increasing the chances of bus bottlenecking for frame sources (since your camera(s) need to be sent to video memory on each frame).

We would need a logfile from a streaming or recording session to be able to troubleshoot the problem, rather than throwing out random might-be comments.
 
If you aren't streaming or locally recording, the encoder is not actually doing any work. I'm not sure if the renderer is either (as the Preview window is pre-renderer output).
I know you know a lot more than I, but it only makes sense to me that Rendering is taking place regardless of Recording/Streaming as the rendered output is what displays in the OBS Window. Then the work-load is double if using Studio Mode
So I've assumed (and grant that I can be wrong) that Rendering is essentially always taking place, regardless of Recording/Streaming state. Then one encodes that Render depending on Stream and/or Recording settings. Do I have that wrong?

As for original poster...
1. beware that Stats window is good for what OBS is doing, but not the computer as a whole. For that, you should be monitoring hardware resource (CPU, GPU, RAM, etc) utilization [for ex. using Task manager’s Performance tab and/or Resource Monitor] to see if your system is bottlenecking with your settings
2. As for OBS and its settings, per pinned post in this forum
As noted in prior reply, the Rendering lag can cause Encoding issues, and that is your 'choppiness'. You are sending (and if recording, saving) a 'choppy' video, and that 'choppy' video is sent without issue (ie no network dropped frames).
FYI - I livestream House of Worship services, and recently livestreamed a funeral as well. Another possibility is that you have scenes/filters/effects that don't come into play until you are streaming. So under your 'test' conditions all is well, but you aren't actually testing your full workload? For example, if you are recording to a HDD that is also you OS & App disk drive, and not pushing it to a point of contention, that can then cause other follow-on impacts. So are you testing using all video & audio inputs, all OBS effects, etc, and for a similar perio dof time (or at least well more than 15 minutes)?
real-time video encoding is VERY computationally demanding. One possibility is that your test is after a recent reboot, and PC recently settled down, then later after playing a pre-recorded video, or other activity, you start having memory problems? or you have background tasks that you haven't turned off and those activate? There are LOTS of possibilities (having nothing to do with OBS) that could impact system resource utilization
 
Thanks for these detailed answers!

So if I have understood correctly...

Just because Dropped Frames (Network) may = 0% doesn't mean there are no frames missing.
As any Frames missed due to rendering lag and/or Skipped frames due to encoding lag are removed before they are successfully pushed up my Internet connection - is that right?

So I used Premiere Pro to resample all my pre-recorded videos for Mass (some 4k, some 1080p) to 720p
Then I changed the Video Base (Canvas) Resolution and Output (Scaled) Resolution both to 1280 x 720
Also changed the two cameras to 720p
It just seemed logical to make everything match so there would be less processing.

The Result:
1. The Dropped Frames (Network) = 0%
2. Frames missed due to rendering lag = 0%
3. Skipped frames due to encoding lag = 0%

And nice smooth video :)
 
Just because Dropped Frames (Network) may = 0% doesn't mean there are no frames missing.
As any Frames missed due to rendering lag and/or Skipped frames due to encoding lag are removed before they are successfully pushed up my Internet connection - is that right?
I wouldn't say frames are removed, they aren't processed/available, and therefore not sent to network to be streamed

I ran into issues with an older (5 yrs) PC when using a mix of pre-recorded content and live video. Re-rending all the video might have helped, but easier to simply get a new PC. Being that we livestream to FB, i rescale the streaming output to be 720p, but leave base canvas and output resolution at 1080p for local recording

Yes, what you did certainly reduced system workload, and I'm happy to hear that stream is steady now. Now, if you have the inclination, would be time to start increasing some settings to see if you can find a happy place of higher resolution with stable video
 
I know you know a lot more than I, but it only makes sense to me that Rendering is taking place regardless of Recording/Streaming as the rendered output is what displays in the OBS Window. Then the work-load is double if using Studio Mode
So I've assumed (and grant that I can be wrong) that Rendering is essentially always taking place, regardless of Recording/Streaming state. Then one encodes that Render depending on Stream and/or Recording settings. Do I have that wrong?
That WOULD make sense! Problem is, it isn't necessarily the case. The Preview window is NOT showing the post-Render output. I only know this as I noticed a resolution disparity between the preview and post-output video, and made side-by-side screenshot comparisons to prove it when one of the Devs told me that couldn't possibly be the case. The Preview window uses full-resolution versions of the sources it has available, even when they are rescaled down, and is NOT showing the Rendered frames being sent to the encoder.
1622620665874.png


That said, the renderer MIGHT still be active when not encoding. But it does not have to be, just because the Preview window is showing something, as the Preview is not showing the post-Render frames.
 
That WOULD make sense! Problem is, it isn't necessarily the case. The Preview window is NOT showing the post-Render output. I only know this as I noticed a resolution disparity between the preview and post-output video, and made side-by-side screenshot comparisons to prove it when one of the Devs told me that couldn't possibly be the case. The Preview window uses full-resolution versions of the sources it has available, even when they are rescaled down, and is NOT showing the Rendered frames being sent to the encoder.
....
That said, the renderer MIGHT still be active when not encoding. But it does not have to be, just because the Preview window is showing something, as the Preview is not showing the post-Render frames.

Ok, maybe I was too casual when saying "rendered". The OBS Preview window is showing a 'composited' video [as mine has Text overlays, camera and window capture, image, etc], all of that has to be 'rendered'/created/processed. Not being a dev, I won't guess where in the render pipeline that is grabbed, though I'd suspect late in the pipeline... but before compression/encoding.. would make sense.. again, I'm not a dev, so I'm only guessing. But from an efficiency standpoint, rendering 2 separate 'videos' (a 3rd if putting OBS into Studio Mode) wouldn't to make any sense to me for what I understand to be a very computationally intensive task (especially the final? encoding/compression step). So showing a Preview window at 'native' resolution would make logical sense to me
 
Back
Top