Here are the observations:
* You don’t actually need hardware decoding or a Coral, but they do help. You will of course need to provision more CPU horse-power for NVR. * Motion detection uses the usual implementation from OpenCV. Unfortunately this algorithm is not very good in my experience. Many things I would consider as motion are missed (false negative), many things I would not consider motion are being detected (false positive). These factors mean that one is tempted to go ham on masking to filter out false positives, which then leads to further false negatives. I’m genuinely surprised the motion algorithm that’s implemented in OpenCV is still the state of art of what’s available openly. * Object detection is somewhat knee-capped by the models available publicly. They are not very good either. Frigate has built its behaviour around these models with an assumption that these models are largely pretty accurate, which in my experience has ended up with quite a few missed recordings for important events, which led me to switch to create recordings based on motion (I’m not in a very densely populated area and reviewing the recordings isn’t too onerous.) * Support for coral is… shaky at best. There are some indications that the production of these devices has largely stopped (and finding them to purchase is hard and expensive,) and maintenance of the drivers and libraries to interface with coral seems to be minimal or non-existent to the point where some Linux distributions have started dropping the relevant packages from their repositories. On the upside, running these models on the CPU isn’t that expensive, especially considering that the models are invoked very sparingly.
I’m currently thinking of moving over to continuous recording, perhaps trying out moonfire-nvr or mayhaps handwriting a gstreamer pipeline. Simple software -> fewer failure modes.
(NB: I worked at a computer vision startup in the past, my views are naturally influenced by that experience.)