0.10.0 Beta 6

[blakeblackshear]

Major Changes for 0.10.0

Updated docs are available for preview here.

Changes since beta 5

• Fix issue with migrations for new users
• Remove disk sync on startup

Retain modes

This release adds the ability to define retain modes for the initial retention period and for event data beyond the initial retain period. There are three modes:

• all: retain all recording segments. This is consistent with the previous behavior
• motion: retain only the recording segments that have some motion
• active_objects: retain only the recording segments that have a moving true positive object that is being tracked

The default record settings will retain only segments that have active_objects for events.

Note that the retain_days config entry has been DEPRECATED. This release includes backwards compatibility, but you should migrate to the new format.

Example: Store all segments with motion for 7 days and events with active objects for 14 days.

record:
  enabled: True
  retain:
    days: 7
    mode: motion
  events:
    retain:
      default: 14
      mode: active_objects

Stationary objects

Frigate will now continue to track objects after they are stationary. This enables use cases such as presence detection. After an object has been stationary for 10 frames, object detection for the object will be throttled to 1 frame every 10 seconds (this is adjustable with the new stationary_interval setting) until there is new movement. An object is determined to be stationary if the bounding box in the current frame overlaps almost entirely with the previous frame. I have been testing this in my home office, and it works quite well.

I expect this to disrupt the way a few people are using Frigate. For example, a car that enters the driveway, parks, and then leaves 5 hours later will be one continuous event. The zones will stay with the tracked object over this lifetime, so when the car leaves, it will still have zones associated from when it first arrived. Ensure you use the right retain mode to ensure you only capture the segments you want.

Depending on the specifics of your room, you may need to tune your resolution and motion settings to get the results you want. In my office, I reduced the resolution to 640x360 and increased the contour_area setting for motion detection up to 125 to reduce the sensitivity. I recommend watching the debug view and adjusting as needed.

fixes #841

In progress events and cache handling

Events are now stored in the database while in progress, so you can expect to see In progress for some events under end time in the Events view.

Recording segments written to the cache are now only moved to the recordings folder if they overlap with an event (in-progress events too). For those with retain_days set to 0, this eliminates disk I/O when there are no events. Frigate will no longer store a minimum of 5 minutes of recording segments for each camera, so now you can enable recording without worrying about SD/SSD wear.

Lastly, more proactive cache maintenance was implemented to prevent the cache disk from filling up. You should never see more than 7 segments in the cache for each camera. If the cache maintenance job is too slow, you will get a warning in the logs. You can also see the time it takes to copy to the recordings disk by setting frigate.record: debug in the logger config. Additional error handling was also implemented to prevent the cache maintenance thread from stopping on errors.

Now that recordings are managed proactively, recordings are expired according to the retention settings once per hour.

fixes #1885

Motion detection improvements

0.9.0 introduced dynamic motion sensitivity which didn't work out well. For many users, this made motion detection too sensitive which increased CPU usage due to more motion causing more object detection. It also increased false positive detections due to the increased frequency for detections on areas without substantial motion.

In this release, motion detection has been reset back to better defaults for frame_height and contour_area. If you have customized either frame_height or contour_area in the past, it is recommended that you remove those for your camera and let them revert back to the new defaults. For most users, the sensitivity can be tuned by adjusting contour_area (smaller numbers are more sensitive and larger numbers are less sensitive). For very high resolutions with very small objects, the frame_height may need to be increased.

In addition, this release brings about dynamic contrast adjustment for motion detection. Based on my testing, this substantially improves night time detection with IR lights and other low contrast situations.

Other changes

• Improved logic for merging motion, bounding boxes, and regions
• Report coral temperature stats when available (USB Coral not supported)
• Limit the cache time for playlist urls to avoid recording playback failures
• Allow yaml extension in addition to yml
• Sync database recordings with the disk on startup
• Store motion and objects data in database
• Entered zones in mqtt messages are now sorted based on the order the object entered zones

Fixes

• fixes [Support]: Recording breaks if disabled by MQTT on Frigate start #2129

Full Changelog: v0.9.4...v0.10.0-beta6

Images:

• x86: blakeblackshear/frigate:0.10.0-beta6-amd64
• x86 w/ nvidia (for ffmpeg only): blakeblackshear/frigate:0.10.0-beta6-amd64nvidia
• Raspberry Pi 3/4 (32bit): blakeblackshear/frigate:0.10.0-beta6-armv7
• Raspberry Pi 4 (64bit): blakeblackshear/frigate:0.10.0-beta6-aarch64

---

This discussion was created from the release 0.10.0 Beta 6.

[ozett]

"An object is determined to be stationary if the bounding box in the current frame overlaps almost entirely with the previous frame"

is there a config-option to tweak the overlapping (in percent)?

( i think i dont want reduce resolution or sensitivy for the cam in general, as you did:
"In my office, I reduced the resolution to 640x360 and increased the contour_area setting for motion detection up to 125 to reduce the sensitivity")

updated every 10.beta up to nr 6 now, but none of them catched this as stationary:

[blakeblackshear]

Even if it was stationary, it still be a false positive. I can't quite tell what that is, but is it at a fixed location? If so, I would make a small object filter mask around the bottom center of it's bounding box.

[ozett]

its a moveable dustbin. but mostly standing still.
i assume that the some lights falling to one side of the dustbin at night (you can see it at the right side of the container) make the motion-trigger active (and causes re-detection). but how does the algorythm looses that "stationary"-state?

maybe the frame-intervall for stationary object is too short for me ??

for such cases: maybe there could be a configurable option (stationary zone?) where i can define the xy-coordinates of an re-appearing object-type as "stationary" (for a time-period, i.e. night) by definition?

[blakeblackshear]

I don't think that will work well. It must only get detected as a person under some conditions, so it keeps getting lost and getting re-detected. Stationary objects can go missing if it isn't found when the stationary_interval is up. You could try increasing that value to a very high number like 999999.

[Minglarn]

For your info @blakeblackshear my frozen RTMP and WebUI are gone with the Beta6.
However, still getting some (not as quite often as before):

frigate    | [2021-12-14 18:31:21] frigate.record                 WARNING : Cache is taking longer than 5 seconds to clear. Your recordings disk may be too slow.
frigate    | [2021-12-14 18:31:52] frigate.record                 WARNING : Cache is taking longer than 5 seconds to clear. Your recordings disk may be too slow.

[blakeblackshear]

I am probably just being too aggressive in that check, so I doubt it's anything to worry about.

[t0ny-peng]

Is it too late for a feature request? It'd be nice to have a configurable recording length for each .mp4 files in the recording folder. Currently each video last for 10 seconds, meaning that there'll be ~8640 files each day. This adds some extra cost if the video if the video is backed up to AWS S3 Instant Glacier.

Thanks

@blakeblackshear

---

I search int the source code. Looks like the temp recording is first written to /tmp/cache, then copied to the actual RECORD_DIR by RecordingMaintainer. This seems to be the only place where a hard-coded 10 seconds is used. Could you verify this?

[blakeblackshear]

This isn't really the right place for a feature request, and it's been requested before.

It's not hard coded. You can override it in the output args for the record role. I don't really recommend changing it though. If ffmpeg exits while writing the file you lose all of it. Also, your cache will need to be increased accordingly. Frigate will also have to track and retain more information in memory for each segment. It will also introduce a delay for when the event will be viewable in the UI. There may also be other negative side effects I'm not considering. It's kind of like messing with the internal database structure of the app.

I would look at using tar or something to bundle segments

[t0ny-peng]

I see. Thanks for the explanation and sorry for the wrong place to post feature request . I'll probably write a script using ffmpeg to concatenate the videos hourly.

[blakeblackshear]

You can use the following endpoint as an input to ffmpeg and frigate will handle all the concatenation work for you:

/vod/2021-12/14/06/<camera_name>/index.m3u8

That will give you all the segments in the 6AM hour from 12/14.

[eatoff8]

Loving the hourly footage deletion, can we please get the same for snapshots? I can see the footage getting deleted every hour, but the snapshots and images are getting deleted at differing intervals.

And then can we get options for longer intervals as per this request - #2365

[shred86]

Just updated to this beta from 0.90.0 and everything seems to be running well so far. As it's already been mentioned, noticing a lot of the "Cache is taking longer than 5 seconds to clear" but that's about it. I do like the new stationary object logic. I have a zone setup that covers the sidewalk in front of our house and just a small part of the street. The idea was to record vehicles that would park in front of our house but ignore everything driving by on the street. Previously, this would cause a ton of events for a vehicle parked in front of our house whenever a car drove by (especially at night when lights hit the parked car). Now there seems to be a lot less of those false events since it's tracking the parked car continuously, but it does seem to end every once in a while and start a new event when a vehicle drives by.

[blakeblackshear]

Perfect. I was expecting these updates to help in these situations quite a bit. I would disregard the warning about the cache.

[cpuks]

Can you share a config for that camera as I'm bit confused - wanted to use zones for specific cameras but only way I've got this working is list zones I want to record inside required_zones (record->events->required_zones), as I understand this I'll have events recorded only for those zones - what if I want to use zones for lets say two cameras and for rest rely on mask with no zones?

[Daniel-dev22]

Is there a difference in how frigate handles notifications in v.0.10 as it's not sending the snapshots for notification previews and when I press view snapshot I get an error 502 bad gateway. It was working fine on v.0.9.

I'm using the notification blueprint.

[Daniel-dev22]

Any idea when the next beta rlease will be?

[blakeblackshear]

I have been busy with other things, so it may be a couple weeks.

[Daniel-dev22]

Sounds good no rush. Excited for the next release and frigate plus when that's ready.

[Daniel-dev22]

Do you have an idea when you'll be releasing the next beta or will it be awhile still?

I ask because I'm eager to use the stationary object detection. If I didn't have those issues on outside cameras on 0.10.0b6 I'd be using it right now but instead I'll have to wait for a new release.

[blakeblackshear]

I haven't had time to start these changes yet.

[packetinspector]

You note: " For example, a car that enters the driveway, parks, and then leaves 5 hours later will be one continuous event. "

This is definitely happening to me and its consuming a great deal of disk space. Under retain you use "active-objects" which is confusing since its also recording stationary objects.

Perhaps I misinterpreted? My record config:

record:
  enabled: True
  retain:
    days: 0
    mode: active_objects
  events:
    # Optional: Maximum length of time to retain video during long events. (default: shown below)
    # NOTE: If an object is being tracked for longer than this amount of time, the retained recordings
    #       will be the last x seconds of the event unless retain_days under record is > 0.
    max_seconds: 600
    # Optional: Number of seconds before the event to include (default: shown below)
    pre_capture: 5
    # Optional: Number of seconds after the event to include (default: shown below)
    post_capture: 5
    # Optional: Objects to save recordings for. (default: all tracked objects)
    # objects:
    #   - person
    # Optional: Restrict recordings to objects that entered any of the listed zones (default: no required zones)
    required_zones: []
    # Optional: Retention settings for recordings of events
    retain:
      # Required: Default retention days (default: shown below)
      default: 7
      mode: active_objects
      # Optional: Per object retention days
      objects:
        person: 10

[packetinspector]

It does move, not a great deal though. The overlap of matches is quite significant.

Eventually the clip/event gets so long the GUI won't playback the event. Once a car parks in front of one of the cameras, i use 8x the disk space per hour its parked. I either cut down retention drastically or turn off recordings all together?

I read a previous request to add a fudge factor to the subsequent object matches, that would likely help here. Perhaps by box center deviation or box area?

[packetinspector]

On these long running events, I also get an error in the UI when clicking "event details". I have to reload the page to recover.

Uncaught (in promise) TypeError: Cannot read properties of null (reading 'toLocaleString')

(Have an event in progress for 7 hours now.)

[blakeblackshear]

I will be trying to come up with a more accurate way to determine if an object is actually active in the next release. Hopefully that resolves this issue. The goal is for the event to stay in progress, but only retain segments worth saving. You may want to try motion rather than active_objects. It might be better.

[ozett]

It uses the bounding box to determine whether or not the object is moving. When watching debug view, is the bounding box jumping around a lot even though the object is stationary?

for debug the bounding-boxes should maybe show big marker of their state:
like A (for Active) or T (for Tracking) ... or Numbers (for tracked Objects)?

https://www.pyimagesearch.com/2018/08/13/opencv-people-counter/

[packetinspector]

After recording a car for a whole day, i ran out of disk space. I might use the API to auto-delete any in-progress event longer than X time. I'd rather get notified more than once than run out of space.

[kiat-huang]

Just migrated from the latest stable to this beta and looking good so far.

Anyone got an automated method for deleting all the 24/7 clips that do not have any motion associated with them?

I'd like to trim down all of the clips rather than just delete entire days or have to manually go through and work out which clips correspond to which events.

Is there a way to pull the info out of the DB? I can then automate from there.

[NickM-27]

@kiat-huang You should read the docs for the beta, that is already something that is supported within frigate itself:

record:
  retain:
    days: x
    mode: [all, motion, active_objects]

[DomiStyle]

Anyone knows why the recordings of my events stop working after a few hours since 0.10?

I changed my retain settings like this:

record:
  enabled: True
  retain:
    days: 0
  events:
    max_seconds: 300
    pre_capture: 10
    post_capture: 10
    retain:
      default: 14
      mode: all
      objects:
        person: 30
        car: 14

snapshots:
  enabled: True
  timestamp: True
  retain:
    default: 30
    objects:
      person: 100
      car: 100

If a new event is triggered it shows up in the events tab and works perfectly, if I come back a few hours the event and snapshot are still there but the recording is gone.

Trying to stream the m3u8 file returns an nginx 404. Trying to download the MP4 gets a timeout with the following error being logged:

frigate    | [2022-01-22 11:14:50] frigate.http                   ERROR   : ffmpeg version 4.3.1 Copyright (c) 2000-2020 the FFmpeg developers
frigate    |   built with gcc 9 (Ubuntu 9.3.0-17ubuntu1~20.04)
frigate    |   configuration: --disable-debug --disable-doc --disable-ffplay --enable-shared --enable-avresample --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-gpl --enable-libfreetype --enable-libvidstab --enable-libmfx --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libxcb --enable-libx265 --enable-libxvid --enable-libx264 --enable-nonfree --enable-openssl --enable-libfdk_aac --enable-postproc --enable-small --enable-version3 --enable-libzmq --extra-libs=-ldl --prefix=/opt/ffmpeg --enable-libopenjpeg --enable-libkvazaar --enable-libaom --extra-libs=-lpthread --enable-vaapi --extra-cflags=-I/opt/ffmpeg/include --extra-ldflags=-L/opt/ffmpeg/lib
frigate    |   libavutil      56. 51.100 / 56. 51.100
frigate    |   libavcodec     58. 91.100 / 58. 91.100
frigate    |   libavformat    58. 45.100 / 58. 45.100
frigate    |   libavdevice    58. 10.100 / 58. 10.100
frigate    |   libavfilter     7. 85.100 /  7. 85.100
frigate    |   libavresample   4.  0.  0 /  4.  0.  0
frigate    |   libswscale      5.  7.100 /  5.  7.100
frigate    |   libswresample   3.  7.100 /  3.  7.100
frigate    |   libpostproc    55.  7.100 / 55.  7.100
frigate    | [concat @ 0x55aacc75f740] Impossible to open '/media/frigate/recordings/2022-01/22/08/entrance/17.10.mp4'
frigate    | pipe:: No such file or directory

If I look into the /media/frigate folder I can see that the recordings folder is completely empty but the clips folder has the clips saved. Any ideas why it's trying to access the empty recordings folder?

If I look into the folder directly after recording I can see the recording there just fine.

edit: Looking at a recording with debug logs enabled it seems that it gets deleted during routine cleanup but Frigate then complains that it can't find the file it just deleted?

frigate    | [2022-01-22 11:26:21] frigate.record                 DEBUG   : Start camera: entrance.
frigate    | [2022-01-22 11:26:21] peewee                         DEBUG   : ('SELECT "t1"."id", "t1"."camera", "t1"."path", "t1"."start_time", "t1"."end_time", "t1"."duration", "t1"."motion", "t1"."objects" FROM "recordings" AS "t1" WHERE (("t1"."camera" = ?) AND ("t1"."end_time" < ?)) ORDER BY "t1"."start_time"', ['entrance', 1642846881.691337])
frigate    | [2022-01-22 11:26:21] peewee                         DEBUG   : ('SELECT "t1"."id", "t1"."label", "t1"."camera", "t1"."start_time", "t1"."end_time", "t1"."top_score", "t1"."false_positive", "t1"."zones", "t1"."thumbnail", "t1"."has_clip", "t1"."has_snapshot", "t1"."region", "t1"."box", "t1"."area" FROM "event" AS "t1" WHERE ((("t1"."camera" = ?) AND ("t1"."start_time" < ?)) AND "t1"."has_clip") ORDER BY "t1"."start_time"', ['entrance', 1642846881.691337])
frigate    | [2022-01-22 11:26:21] frigate.record                 DEBUG   : Expiring 0 recordings
frigate    | [2022-01-22 11:26:21] peewee.sqliteq                 DEBUG   : received query DELETE FROM "recordings" WHERE (0 = 1)
frigate    | [2022-01-22 11:26:21] peewee                         DEBUG   : ('DELETE FROM "recordings" WHERE (0 = 1)', [])
frigate    | [2022-01-22 11:26:21] frigate.record                 DEBUG   : End camera: entrance.
frigate    | [2022-01-22 11:26:21] frigate.record                 DEBUG   : End all cameras.
frigate    | [2022-01-22 11:26:21] frigate.record                 DEBUG   : End expire recordings (new).
frigate    | [2022-01-22 11:26:21] frigate.record                 DEBUG   : Start expire files (legacy).
frigate    | [2022-01-22 11:26:21] peewee                         DEBUG   : ('SELECT "t1"."id", "t1"."camera", "t1"."path", "t1"."start_time", "t1"."end_time", "t1"."duration", "t1"."motion", "t1"."objects" FROM "recordings" AS "t1" ORDER BY "t1"."start_time" LIMIT ? OFFSET ?', [1, 0])
frigate    | [2022-01-22 11:26:21] frigate.record                 WARNING : Unable to find file from recordings database: /media/frigate/recordings/2021-12/23/12/entrance/41.57.mp4
frigate    | [2022-01-22 11:26:21] frigate.record                 DEBUG   : Oldest recording in the db: 1642847181.728057
frigate    | [2022-01-22 11:26:21] frigate.record                 DEBUG   : End expire files (legacy).

Even though it says "Expiring 0 recordings" the files are gone afterwards?

[blakeblackshear]

All recorded video is written to the recordings folder since 0.9.x. You shouldn't see any new mp4 files in the clips folder. You should read the release notes if you haven't already.

None of these logs show a problem that would cause recordings to stop. If you don't see other related log messages, please open an issue rather than continuing to the thread here.

[tbrausch]

I have a question regarding CPU utilization in Frigate. I have 4 cameras setup, and when there is no motion detected, my cpu utilization is about 35%. If I look at the process specifics in Glances, most of this is used by 4 "ffmpeg" processes. This makes sense, since these are required to detect motion. However, if I turn off the detection switches for all 4 cameras, the cpu utilization remains the same. Is this expected? I would think that if detection were disabled these processes would not be required. Just trying to understand how this works.

BTW, this is true even if I disable snapshots and recordings for all 4 cameras.

Thanks

[blakeblackshear]

This is expected. The streams are always decoded. There is no way to turn off a camera entirely, but there is an existing feature request for it.

[blakeblackshear]

Locking this discussion and moving to beta 7