gdbstub VS moonfire-nvr

now integrate gdbstub to support debugging code inside the emulator :)

Shameless plug, but have you considered integrating gdbstub rather than rolling your own debugger? I know a couple folks out there have successfully integrated it into their PS1 emulators with great success.

I've worked really hard to keep gdbstub panic free in its minimal configuration, going so far as to write some informal scripts that parse rustc's asm output to scan for the presence of panicking code paths.

crates.io | docs | repo

As a totally shameless plug, I'm the maintainer of gdbstub, a bare-metal, no_std, no_alloc, and size-optimized implementation of the GDB Remote Serial Protocol. One of the major changes slated for the upcoming release 0.6 is support for a new state-machine based API, which makes it possible to drive gdbstub directly via bare metal interrupt handlers (i.e: send/recv data over UART, handling breakpoints via the undefined instruction trap interrupt, etc...).

Continue working on a new API in gdbstub that'll make it easier to use directly from an interrupt handler when debugging code in a no_std, bare-metal OS environment.

I ran into almost this exact same problem while working on gdbstub, whereby I an API that allowed users to mix/match protocol features however they wanted, while also preventing users from accidentally implementing mutually-exclusive features. Moreover, I wanted to have a "zero cost" way to enable/disable API features without relying on cargo features. The solution I came up with is something I've been calling "Inlineable Dyn Extension Traits", or IDETs.

For a concrete example of how smart the Rust compiler is, I have a small writeup + test-repo that benchmarks a technique I came up with while working on gdbstub that [ab]uses the compiler's devirtualization and inlining optimizations to create runtime feature flags that are entirely compiled out if hard-coded to false at runtime.

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.

Moonfire may be what you're looking for otherwise.

That last bit's not quite true: another option is to just use the cameras as a dumb stream source and do all the fanciness in an open source NVR. I've been slowly working on moonfire-nvr. Help welcome!

Moonfire