Auto resolution mode automatically switches all streams to HD generating constant CPU 100 usage
AnsweredHi Everyone
Problem: in multi-monitor applications Nx clients generate constant CPU usage at 100%, even on powerful machines (i7-10700), which makes the client useless. So it is impossible to watch large surveillance systems in multi-monitor mode.
Explanation: auto resolution mode automatically switches all streams to HD (megapixel high stream), even if it doesn't make sense, for example in multi-channel screen division.
So when there is only one or max two monitors, system is doing OK with all those HD high streams, but when there are 4,6 or 8 monitors and many cameras, the auto mode on client generates constant CPU usage at 100%, which makes the whole client useless.
From your support I received information that it is impossible to save layout resolution settings to server configuration.
Temporary solution: on the client switch all layouts resolution to LOW, so that high stream is being displayed only when the camera window is maximized, but....
- it applies only to this single client, all other clients must be configured separately, because this setting is local
- after short period of usage time and/or after client restarts, client goes back to auto mode in different situations, so the problem returns every time
Suggested solution no.1: add layout resolution setting to layout settings stored in the server configuration, to make it permanent and respected by all clients. We don't like that solution, because we still have to re-configure all layouts, but at least it is permanent.
Suggested solution no.2 (preferred): add an expert option, so that we can totally disable display of HD streams in multi-channel screen division. When the option is enabled, the client displays HD stream only when there is single camera visible on the screen. When there are two cameras on the screen, client displays lower streams.
See this screenshot to understand which option I'm discussing:
http://www.polvision.com.pl/temp/add-this-option-to-server-stored-layout-settings.png
PS. @Nx Support, if possible, please explain, why do you display HD high streams in multi-channel screen divisions? What is it for ?
In our opinion, it doesn't make sense, just generates higher CPU and GPU usage and higher network bandwidth usage....
-
Tomas, Fredrik,
We had plans to implement quality selection as a layout setting, but this task is currently on hold and it's not clear when we'll be able to do it.
We have quite sophisticated mechanism which automatically switches quality to optimize the CPU usage, but it seems to not be working well with multi-monitors setup. We also will try to improve it in the future.
-
Thank you for honest response. Please open discussion inside your company to find out nearest possible time to implement the fix. Tagir Gadelshin (NX) is also involved in this topic, so pls talk to him as well. Please be aware our largest enterprise projects are affected with this problem, for example our recent projects for 900ch (Dec2020), 500ch(Jan2021) and 10,000ch(Feb2021+). We strongly believe more priority should be put to such large projects with all involve 4-, 6- and 8-monitor stations. Currently these customers are not fully satisfied with the solution because their operating stations are working on 100% CPU..... you can imagine what kind of user experience they get. Thank you for understanding.
-
Guys,
We had more internal discussions on it.
We believe
- 100% CPU is OK.(even desirable, the client uses all resources to deliver the best quality)
- the client's useless is - not OK and unacceptable, must be fixed asap.
By design in case, if they're a lot to display, the CPU usage should stay slightly below 100%, so the client handles the decoding and is not slowed down.
We are going to investigate more, but here is how you can help.
1) in the file C:\Users\user\AppData\Local\nx_ini\desktop_client.ini add the line "showVideoQualityOverlay=1"
If the file does not exist(likely so), please create it.2) launch the client, put task manager with CPU usage around.
3) reproduce the issue and record the video(by your cell phone).
4) share the video with us
This will help us a lot! -
Hi
Sorry for the delay in response. During the last few weeks we have carried out numerous tests at various monitoring stations, both in our laboratory and at external locations. We noticed that in most cases the mechanism described above by Sergey (using 100% CPU is OK.(even desirable, the client uses all resources to deliver the best quality)) did not make monitoring stations unresponsive. So the operator can work normally. However, in some cases this problem of unresponsiveness has occurred, but we don't know what it depends on. We will be investigating these cases even more closely in the coming weeks. We are looking for some repetition of this problem to be able to reproduce it easily. When we get new information on this matter, we will come back to this topic.
-
Tomasz Polus
Thank you, Tomas, for your help! We will be waiting for updates from you.
Meanwhile, we did in-house tests and we received almost the same results as you. We have some improvement ideas that might help. But as we don't know for sure if it will help and there is no room in upcoming releases -- those improvements won't be released at least for a couple of releases (4.2, 4.3). I will emphasize that not knowing if it will help is the main reason we don't include it.
I hope we will soon know what is the root cause and how we can reproduce and fix this and we will be able to eliminate those lags.
Please sign in to leave a comment.
Comments
7 comments