High CPU usage in the events/timeline views—do they support CUDA/NVDEC?

[WilloftheWind]

Hello! I've set up Viseron 3.4.1 as a 24/7 NVR with motion and person detection configured on some cameras. It's running on a server equipped with a Xeon e3-1245v5 and a GTX 1060 6GB. The system currently has 5 cameras.

Most of the time, including when the Live view is up on another computer, CPU usage on the server is around ~30%. The installed image is one with CUDA enabled and I can confirm it is working with nvidia-smi, which shows processes for Viseron, Darknet, and the ffmpeg instances for all cameras.

My understanding is that all encode and decode should be able to be off-loaded to the GPU, and it generally seems to be so. However, when I select the Timeline or Events view on a viewing machine, the server's CPU usage spikes up to 90-100%. When I run nvidia-smi, I don't see any new ffmpeg instances show up as processes. Both of these suggest to me that the timeline and events views are using the CPU to decode and send frames rather than NVDEC. Is this intended behavior/is there a reason for this?

Since this server also runs file shares and other apps, I'd like to keep CPU resources freed up. Is there any way to get Timeline and Events playback to offload decode to the GPU? Let me know, and thanks! I'm impressed with Viseron overall and want to keep it running smoothly for the long haul.

[roflcoopter]

Frames are not decoded for the Events/timeline, they are simply read from disk as is so that is not the issue.
What process is using the CPU? Is it Viseron + PostgreSQL?

The Timeline works by utilizing HLS playlists, which are reloaded every 5-ish seconds to get new segments.
If you view many cameras at the same time, that all record 24/7 with longer retention periods it is a lot of data to process and the SQL queries will use the CPU.

There is something called HLS Delta playlists that could be implemented to reduce the need to load all segments on each fetch but that is complicated business that i have not looked into yet

[WilloftheWind]

Thanks for the swift reply. I'll get back to you tomorrow (it is 2:30 AM here in USA) when I'm on-site again and will check the processes.

Incidentally, it's interesting to hear that the timeline also uses HLS. I've had some issues getting playback to work in the Recordings view ("No available working or supported playlists" error) and am still troubleshooting that based on feedback to others' old questions. I had thought perhaps my issue was something with HLS in general, but it seems that isn't likely the case since I do get smooth playback in the events & timeline pages (albeit with the high CPU usage). I had wanted all recordings to be in H.265, but will try switching to H.264 tomorrow for troubleshooting purposes—perhaps that will help.

[roflcoopter]

The pages uses different underlying libraries to play the videos.
On the Recordings page, VideoJS is used to play the HLS playlist generated by the API.

On the Events/Timeline page, HLS.js is used to play the playlist.

These two libraries differ a bit in what encodings are supported which causes this confusion.
HLS.js is the "gold standard" here, and in the dev branch/builds the player on the Recordings page has changed to use HLS.js instead of VideoJS which probably will solve your problem.

[WilloftheWind]

I can confirm that the issues I was having were related to a high number of intensive "postgres" processes—so yes, PostgreSQL was the culprit. The good news is that I shouldn't need to sit on the Timeline page unless there's reason to look over old footage, which hopefully won't happen very frequently.

On another note: I just pulled the dev branch and tested it out to see if the HLS behavior is better in the Recordings view and it is! Thanks for making that change. Recordings now play back properly.

[roflcoopter]

Great! Will try to improve the player in the future, right now the controls are all home grown so some functionality is missing from the old player.

And on the performance issues, will see what i can do about the SQL queries and try to improve them