moonfire-nvr VS hashbrown

I think if you've hit this problem and are looking for solutions, this article looks like a helpful read. There are lots of ideas there.

I wouldn't say this is a super common problem (though I have hit it). The opening example here is that logic outside `Parent` is maintaining its summary state based on its children. That's unusual; typically `Parent` itself would be responsible for that, and so you can inline the logic without having to expose the fields.

Sometimes inlining the logic gets impractical though if the logic is super long. In that case it can be helpful to split it into sub-structs so that you can easily call a method on a group of fields. I did that here, for example: <https://github.com/scottlamb/moonfire-nvr/blob/ff383147e4ff7...>

There have been language proposals to define "view types" which are basically groups of fields that are borrowed. <https://smallcultfollowing.com/babysteps/blog/2021/11/05/vie...>

Probably, but I'd like to hear the author's take on a key design decision rather than guess.

My NVR's based on the assumption that you want to record continuously (as called out in the schema design doc here [1]) rather than trust event detection to be perfectly reliable. I've set up other systems in parallel that are based on a different assumption (e.g. Frigate) but have found they miss things, so this is the design I'm comfortable with.

If you are also constrained on upstream bandwidth, continuous recording means you must buy a local hard drive. It costs $100–$200 to buy one that can hold many camera-months of video at good quality, which I find pretty reasonable.

Some folks might want to also upload stuff off-site in case the NVR itself is stolen or destroyed, but I haven't felt the need.

[1] https://github.com/scottlamb/moonfire-nvr/blob/master/design...

Temporal will be really nice in that it supports remote time zones, allows you to iterate through daylight saving transitions, etc.

I can't wait for it to be fully taken advantage of by things such as mui's date time picker. Imagine if after selecting the fall back day, it let you pick a time during the extra hour. If after selecting the spring forward day, it wouldn't let you pick a time during the hour that doesn't exist.

This stuff matters sometimes; a user of my NVR wanted to save a clip during the fall back hour and got the wrong result because these things just don't work right today. https://github.com/scottlamb/moonfire-nvr/issues/244

I've been looking for a camera to recommend for use with my open-source NVR. [1] This sounds promising, but I have a few questions.

* What's the status of Uniview? Are their cameras allowed in the US under the 2019 NDAA? still receiving FCC approvals since the Secure Equipment Act of 2021? Does Uniview participate in the Uyghur genocide?

* Do you have any models with large sensors, e.g. 1/1.8" or wider? I prefer with good night performance if possible, which I believe requires each pixel to be physically somewhat large. These many-megapixel cameras with 1/3" sensors are not so great there.

* What's the pricing? The camera page [2] has "contact us for info" instead of a price, and when that happens I usually assume it's too expensive for the DIY crowd and drop out.

[1] https://github.com/scottlamb/moonfire-nvr

[2] https://monitoreal.com/product/monitoreal-perimeter-cameras-...

How do folks test timing-related stuff with MSW? AFAIK, MSW doesn't get along with jest.useFakeTimers. It drives me nuts; I have a bunch of disabled tests in an open-source project and at least one that is flaky because it uses real timers where I'd like to be using fake timers. [1, 2]

I've been thinking about ripping out MSW from my tests in favor of my own API-level mock for this reason. But it seems like many other folks are happy with MSW. I have to assume there's something I'm not getting. I'm a fish out of water with frontend stuff in general...

[1] https://github.com/scottlamb/moonfire-nvr/blob/5ea5d27908f1a...

[2] https://github.com/scottlamb/moonfire-nvr/blob/5ea5d27908f1a...

> I wonder how hard it would be to run your own streamer pipeline or whatnot on these things?

Agree with the_biot: The actual streaming component is not too hard. If this were the biggest problem, I'd be thrilled to contribute to an open source streaming server to complement my open source NVR. [1] The driver situation is indeed a bit harder—these things don't just have mainline Linux support with v4l2 for the video input and encoder. Or open source drivers of any kind to crib from AFAIK.

The biggest problem IMHO is that there just aren't any good cameras to buy, even completely ignoring the software aspect. I want a camera that:

1. doesn't support genocide. Nothing that involves Dahua, Hikvision, or Huawei. See IPVM articles on the subject. And a lot of available cameras are relabeled Dahua/Hikvision stuff and/or use Huawei components.

2. is legal for sale / authorized for use in the US. (See the Secure Equipment Act of 2021.)

3. has good night mode performance: IR/day switch, a sensor that is at least 1/1.8", reasonable resolution (somewhere from HD to 4k).

4. has an "eyeball" or "turret" form factor rather than "bullet". The latter seems to really attract spiders, so you end up with a really nice video of a web...

5. supports PoE.

6. is weatherized (IP66 or so).

7. is reasonably priced.

If you ignore #1 and #2, there's some nice hardware out there, but I'm not willing to do that. If you ignore #3, there are a few options (GeoVision, maybe Reolink, maybe Hanwha.) If you ignore #4 and #7, there might be a couple (Axis, maybe Hanwha.) Nothing that ticks all the boxes.

Hard to get excited about investing a lot in the software when the hardware isn't there.

[1] https://github.com/scottlamb/moonfire-nvr

saw one nvr project in rust - https://github.com/scottlamb/moonfire-nvr - maybe you can find answer there

Moonfire NVR does basically that. No decoding at all. The configuration process could be smoother, but there's a decent setup guide to follow.

This is exactly what you're looking for: https://github.com/scottlamb/moonfire-nvr

But I would definitely avoid compiling Rust on the Raspberry Pi 3 if you can avoid it. I set up a Docker cross-compile environment for this reason.

That's because you're looking at a wrapper around the actual implementation (which lives in an external package). Notice "use hashbrown::hash_map as base;" at the top.

There's far more unsafe there: https://github.com/rust-lang/hashbrown/blob/f2e62124cd947b5e...

You might want to check out how popular ecosystem crates do some of these things. Particularly relevant to you are probably crates providing collections, such as smallvec, hashbrown, or indexmap.

https://github.com/topics/swisstable

rust-lang/hashbrown: https://github.com/rust-lang/hashbrown

CuPy has array but not yet hashmaps, or (GPU) SIMD FWICS?

NumPy does SIMD:

Thanks, great point indeed. I am looking into this https://github.com/rust-lang/hashbrown

The way I think about it -- rather naively, I suppose -- is that I care more about the references cells make to each other than the actual grid of cells displayed on a table. The latter feels more like a "view" of the data than an actual data structure?

This also seems to align with the relative priority of (sorted from highest to lowest): figuring out the order of evaluation, calculating those evaluations, and finally displaying the results of the evaluation

updated std's hashbrown dependency to 0.14 which contains some optimizations

The std hashmap is actually very fast and uses state of the art hashmap design, namely because it's implemented by hashbrown

I believe Rust uses hashbrown as the underlying implementation now. This just calculates the number of buckets based on the number of items requested:

https://github.com/rust-lang/hashbrown/blob/009969a860290849...

Is it really the case that rehashing can guarantee that the number of buckets allocated will be sufficient for any given set of keys? In principle you could fail to rehash in a way that reduces collisions after k attempted rehashings.

For example, since the hashbrown crate is marked with #![no_std], it can be used as a dependency for the standard library.

To implement something that cannot be expressed in safe Rust, or at least cannot be expressed succinctly in safe Rust, like fundamental datastructures. The hashbrown crate contains a lot of unsafe code, but it's such high quality that it's now the backing implementation for std::collections::HashMap.