Filmstrip / animated previews performance

[bagobones]

Currently running 0.14.1

I was looking into the performance of the film strip at the top and I am a little confused as to how it is working / intended to work / might have some suggestions

First the current performance..

1. If you haven't opened frigate in a while or are on a mobile connection the strip can take 10-20s to load, with some stripps failing.
2. If you do a normal refresh it does appear the browser caches the result which IS good, at first I thought that wasn't working.
3. If you force cache clear however it appears the server is dynamicly building the fimstrip EVERY TIME which is really slow like item 1.. Looking at the loading view I am not sure why that would be, you would think a static low res asset would be generated and cached for a while vs dynamically building from the source segments.
4. Nginx which is embedded in frigate is not configured to cache these segments.
5. For some reason the browser appears to download BOTH a small preview AND a full segment file of several MB every time it does a fresh load without cache.
6. The more Unique cameras are "recent" the worse performance gets.

Testing with browser client cache disabled / which also simulates what happens when you open frigate fresh after a hour and don't have any cached content anyway.

Why are the full segments which can be a few MB fully downloaded by the client?

Why arn't the small clips being cached in nginx / the server when they seem to take a good 10-20s to generate?

My frigate box is a dedicated frigate machine with an i7 CPU and frigate storage is on an SSD. It appears these optimized low res previews are being generated on the file every time which is very slow.

Thoughts....

Instead of generating them based on requests, why not generate them automatically for events / segments as they end and ONLY generate in progress ones on the fly?

[NickM-27]

It seems you have some misunderstandings on how things are working. The generated event mp4 videos are only created on the server and used for events that happened during the current clock hour. any events that occurred prior to the current hour already have a preview generated for that full hour and are just using the existing preview to loop through.

The full hour previews are loaded with partial content (http code 206) so the full preview video file is not downloaded, the browser is responsible for deciding how much of the video is necessary to load at a time.

For the generated event mp4 videos they are cached on the server for 5 minutes before they are cleaned up. It would make no sense to create / save these because they are irrelevant once the current hour is over and they are unlikely to be needed again since a user will mark the item as reviewed or not and not see them again.

However, there is a bug in the frontend which while the list of existing preview files is being loaded causes the in progress preview video to be generated even when it is not needed, I have put up a PR to fix that.

[bagobones]

I didn't dig any further than the NGINX config, so my observations on behaviour where mostly client based, as you have noted it there is a bug which explains that.

Having said that.

The full hour previews are loaded with partial content (http code 206) so the full preview video file is not downloaded, the browser is responsible for deciding how much of the video is necessary to load at a time.

Instead of passing the browser to the back end to request a byte-range directly this could also be cached by nginx

Smart and Efficient Byte-Range Caching with NGINX & NGINX Plus

It appears the copy of nginx compiled in Frigate does not have --with-http_slice_module but it might be useful for both the privies and other places where video content is loaded.

If you read how nginx deals with video files there are 3 methods, the first it will grab the whole media file, the second with locking it will just pass the request to the backend and the 3rd slicing is specifically optimized for video segments.

After the PR is committed it will be interesting to see what the performance is like.

For the generated event mp4 videos they are cached on the server for 5 minutes before they are cleaned up. It would make no sense to create / save these because they are irrelevant once the current hour is over and they are unlikely to be needed again since a user will mark the item as reviewed or not and not see them again.

When I am out of the house or first thing in the morning the LAST EVENT can be hours old. Normally the previews would not bother me much but I spent a week from home recently and have had some night time events I have been checking up on lately.. The current bug was very apparent as I was constantly seeing the same previews at the top of the screen load in slowly.