obsproject
Slow frame rate when displaying PNG
Operating System Info
Windows 10
Other OS
No response
OBS Studio Version
27.1.3
OBS Studio Version (Other)
No response
OBS Studio Log URL
OBS Studio Crash Log URL
No response
Expected Behavior
Frame rate remains 30 fps
Current Behavior
When the image is refreshed every second, the frame rate drops to 28-29
Steps to Reproduce
- Create an image in the scene and specify a PNG file.
- Refresh this PNG file every second.
- The frame rate drops.
If use media source with network file (http), not local file, everything works perfectly. Media source is refreshed by the script every second. But from 26+ version it is impossible to use Media source for displaying static images from a network.
Anything else we should know?
No response
PNGs are quite slow to decompress relatively speaking, for frequently updated files try using uncompressed PNG or another raw format like BMP. I'm not sure it's worth the complexity to add threaded loading for image sources just for this.
In the OBS version 25- everything works without problems (media source + http). Therefore, the problem is not at all in PNG unpacking. And CPU usage is only 1.5%
PNGs are quite slow to decompress relatively speaking, for frequently updated files try using uncompressed PNG or another raw format like BMP. I'm not sure it's worth the complexity to add threaded loading for image sources just for this.
@notr1ch Unfortunately it doesn't get better with BMP. For me the image source really is only usable in one single scenario right now: a static image is loaded at the beginning and then never unloaded. Both the option "Unload image when not showing" and the fact that it has a file watch and automatically refreshes when the underlying image changed are unusable if I don't want frame drops (and I really want to avoid them, since they can cause other issues like A/V desyncs).
I use it for my reproduction scenario in #6673 because I needed something that is part of OBS base functionality and performs extremely bad (in contrast to OBS otherwise usually performing great). I use a very large image there to increase the probability of the issue occurring, but even loading a 1080p BMP image from a fast SSD (which shouldn't be something uncommon or extreme for a 1080p stream/recording) will cause frame drops.
"Loading" here includes all of these scenarios:
- Adding the image source and therefore loading an image the first time regardless of its options and file watch features
- Hiding and Showing the image with "Unload image when not showing" enabled
- Changing the underlying image file, triggering an automatic reload of the image source
I was really wondering why this happens, but if I understand your comment right then this is done on the main thread and with a 60 FPS recording/stream will always make OBS drop frames as soon as it takes longer than 16.66 ms (and usually less, since OBS also got other stuff to render in the same time frame).
Right now what I do is to avoid using image sources like the plague and use browser sources with a simple html that loads the image instead.
So investing the time and adding the complexity wouldn't be "just for this", it would be to turn the image source for many common scenarios from "unusable" to "useful" (at least for people who care about frame drops).
I tested in OBS 25 and current release. In order to trigger the framerate drop I need to check the "unload image when not showing", and then show/hide.
It performs worse for me in OBS 25 (substantially) compared to 28.1.2.
As mentioned in this thread already, if you're hammering OBS to reload a full image source every frame, degraded performance is to be expected (also for reference, this is by no means a common scenario). There have been optimizations (see flaeri's comment), but this really isn't what the image source is meant to be used or will be optimized for.
As mentioned in this thread already, if you're hammering OBS to reload a full image source every frame, degraded performance is to be expected (also for reference, this is by no means a common scenario). There have been optimizations (see flaeri's comment), but this really isn't what the image source is meant to be used or will be optimized for.
The optimizations sound good, I have yet to repeat a test with the current version (last time I tested was with an early self-compiled 28'ish build).
But closing this based solely on a straw man? I think everyone here would agree that reloading a full image source every frame is not a common scenario, I don't know who you are telling this.
By OPs screenshot the scenario here apparently is an image file that displays a game score. Makes perfect sense to me that this is updated in the background according to the current score and OBS is then expected to refresh the image to always reflect the latest score, without causing frame drops every single time. Also for a reproduction scenario it's quite normal to exaggerate the things a bit (here: refreshing every second), making the problem more obvious and/or occur faster for easier testing. But even if that would be the real scenario (because a script refreshes the score every second regardless of whether it has changes) I can understand that someone would file an issue when this has worked fine on one OBS version and suddenly has bad performance in another. Also, refreshing something that is supposed to show up-to-date information every second doesn't sound all too crazy to me either.
Don't get me wrong, personally I think the world doesn't end if it's closed, it's always important to choose wisely what to invest time in and especially if optimizations are already showing effects this might already be enough for that the image source is meant to do. Also, people who make quite extensive use of extra features from the image source like the automatic reloading on file update probably also have the technical skills to move on to a browser source with a simple HTML that loads the image or update text sources through obs-websocket like I did to fix this (though I wonder in which scenario someone is actually ever supposed to make use of the "automatic reload on change" feature then).
I just was really confused about the reason given here.
And of course if I wouldn't have the mentioned workarounds I'd be a bit in a dead end now, being told in #6673 that it can happen due to encoding lag and I should rather find out what causes encoding lag and fix this - and when I traced it down to an OBS image source (where even a single reload of an uncompressed 1080p BMP from an SSD can trigger this already, mind you) now being told something along the lines of "well, with its current implementation it's causing encoding lag, it is what it is, closing this".