[issue]Camera stream turning grey after sometime

[mriamnobody]

The camera stream becomes almost grey after sometime. This is happening with all the IP cameras. I have attached an screenshot for your refernece.

Environment:

OS: Windows 11 Python Version: 3.10.7

[mriamnobody]

[sr99622]

Hello, thank you so much for the feedback, it is greatly appreciated. The pictures are a great help in visualizing the issue. It would appear to me that the system is either not receiving all the network packets or is unable to process them for some reason.

This effect can be seen in common situations where the network is dropping packets. Wireless networks are particularly susceptible to this problem. The problem becomes most visible when key frame packets are dropped. The key frame is a compression of the entire video scene, and packets in between key frames represent the difference between frames and require information from the keyframe to build the video scene.

It may also be possible for the application to drop frames if the computer is overloaded and unable to keep up with decoding and processing tasks.

If either of these scenarios is the actual cause of the problem, it may be possible to remedy the issue by reducing the load on the network and computer. If the cameras are wireless, it is a good idea to consider using a wired connection. If the computer has a small number of cores, hardware decoding might improve performance. Limiting network traffic from other sources may improve performance as well.

Another approach can be adjusting the camera GOP interval, which is the number of packets between key frames. This setting is accessible from the video tab. A long GOP will amplify the effect of network packet drops by lengthening the amount of time between keyframes. A good rule of thumb is to match the GOP to the frame rate so that a key frame is sent once per second.

In any event, if this theory is correct, the problem should come and go and the screen eventually clear up, even if only momentarily.

Best Regards,

Stephen

[mriamnobody]

Dear Stephen,

Thank you so much for your comprehensive and insightful explanation. Your detailed breakdown made the complex issue at hand much easier to understand, and I greatly appreciate the time and effort you put into diagnosing the problem.

I wanted to clarify that my camera setup is entirely wired, with all cameras connected to an NVR (Network Video Recorder), which is constantly recording. When viewing the cameras directly on the NVR, there are no frame or packet drops visible, which suggests the setup's integrity up to that point.

Furthermore, my PC setup includes an AMD Ryzen 9 5950X processor with 64GB of RAM, ensuring that there is more than enough computational power to handle decoding and processing tasks without any performance bottlenecks.

The setup is as follows: all my cameras are connected to a PoE (Power over Ethernet) switch using CAT 6 cables, and then a CAT 6 cable connects this switch to the NVR. This switch is also connected to a router (the connection between my PC and router is using WIFI), which allows me to access the IP cameras locally (for this instance im not accessing over the internet) from my PC. This detail might be crucial in understanding the scenario better.

Given your explanation, it seems likely that adjusting the GOP (Group of Pictures) settings could be the solution to the issue I am facing. Your advice on matching the GOP to the frame rate makes perfect sense, and I plan to adjust this setting accordingly. I'll make these adjustments and monitor the system's performance. I will certainly keep you updated on the results.

Again, I appreciate your guidance on this matter and look forward to possibly resolving the issue with your suggested approach.

[mriamnobody]

The GOP settings you provided worked wonderfully. The grey screen issue has been resolved—thank you so much, Stephen. However, for some cameras, the video settings appear greyed out, and I'm unable to modify or adjust them.

[sr99622]

I can see the effect you are describing. What is happening behind the scenes is that onvif-gui is collecting configuration data from the cameras in two phases. The first phase is only concerned with getting the most basic data like the rtsp string so that it can be shown on the list. Once the camera on the list is clicked, a second phase of data collection is started where the application queries the camera for more detailed information that is shown on the tab panels at the bottom. During the time that the application is communicating with the camera for the detailed data, the tab is disabled so that the user cannot attempt changes before the full data set is read. Something to note here is that the user must click on the camera in order to start the second phase of data collection.

The intention is to get the camera in a state where is can be started as quickly as possible with a minimal data set, without waiting for the full data set to be collected. The downside is that if the camera is slow to respond, the tab appears dead when a camera is clicked as you have observed. The data in this state will not even be correct, but will be the leftovers of the camera previously clicked. Eventually, the tab should be updated and enabled for editing, or an error message observed in the log if the camera has failed during the second phase of data collection.

The new version of the program (coming very soon I promise) has a more sophisticated method for achieving this effect. The minimal data set is collected and the camera is shown in the list, and immediately a thread is started in the background to collect the detailed data set without the need for the user to click on the camera. This should help to minimize the time that tabs are disabled as most cameras will respond within a reasonable time. Some cameras will be noticeably slower, which is unfortunate, but hopefully by not waiting for the user to click on the camera to initiate the detailed data collection, the observed length of disabled tab time should be minimized.

Thank you so much for your efforts, the feedback on your experience with the application goes a long way in helping understand field performance of the application.

Best Regards,

Stephen

[mriamnobody]

Dear Stephen,

Your ability to explain complex topics in an easily understandable manner is truly mesmerizing. I am amazed at how accurately you pinpoint the issues I describe. Moreover, the solutions and workarounds you suggest invariably work on the first attempt, further confirming your profound understanding of the subject. Thank you so much, Stephen.