Hacker News Reader

Hacker News

Comment by tpmx | Hacker News Reader

Full thread

tpmx

Seems like e.g. (most of) the sensor drivers are binary blobs.

Some examples:

Ambarella S3L: https://github.com/OpenIPC/firmware/tree/master/general/pack...

Some HiSilicon chipset: https://github.com/OpenIPC/firmware/tree/master/general/pack...

Edit: A smaller subset of sensors have some code here:

https://github.com/OpenIPC/sensors

View on HN

Yup, also the userspace application that does the actual streaming is closed-source as well: https://github.com/OpenIPC/majestic

(The git repo is for bug reports only, no source-code there)

Oh man I didn't realize that when I last ran into this project.

I wonder how hard it would be to run your own streamer pipeline or whatnot on these things? How far a starting place do we get when we install our own Linux; do peripherals (camera networking) work or is there a bunch of special sauce in userland running half the hardware?

That's the problem right there: the Linux kernel situtation. As OP noted they just use the vendor's (long outdated) Linux kernel, with the vendor's (typically crap) kernel drivers. They just don't clean up that situation in that project, let alone try to mainline the drivers. It's where I thought I could help, but... see my other post on why that didn't work out.

With mainline-supported cameras using a standard API, a userland application that does streaming and all kinds of neat stuff is just much more doable IMHO.

They're not the only project that builds a ton of userland stuff on top of a rotten kernel foundation: oe-alliance has nine distros downstream from it, and hundreds of supported hardware platforms. As far as I can tell it's all ancient vendor kernels with un-upstreamable drivers.

That's the rotten situation with embedded Linux. Nearly all silicon vendors ship a highly modified kernel with proprietary drivers and firmware. Nothing gets upstreamed. The code quality is low and the changes are not architecturally sound, so patches wouldn't get accepted by OSS maintainers in their current state. Vendors end up with countless forks of the kernel, system libraries and system services (at least one for each SoC), which they don't maintain because it's too much work (of course).

Security in this space is a absolute disaster.

And this is one of the big reasons that Raspberry Pis are so popular despite an endless supply of alternatives - it's basically the only well-documented and supported embedded linux. Almost every other dev board that competes with them has limited support and outdated kernels and countless other issues.

This is such a weird market. Most embedded devices are purchased by randos who don't know what they're getting themselves into.

By contrast, security cameras are disproportionately purchased by, I'm guessing, security professionals. Often the security staff at large corporations that are buying cameras in volume. If there was any camera that was otherwise competitive and had mainline kernel drivers and open source firmware, would anybody even buy anything else?

Do the manufacturers not realize this?

The camera manufacturers don't make the silicon and the silicon makers don't care about any specific camera manufacturer.

Not even Google can get Qualcomm to upstream their drivers. Let that sink in. And it's not because of confidential IP, because many of the drivers are already open source.

Silicon vendors could save a lot of time by mainlining their code rather than having hundreds of forks of every library. Security would dramatically improve. OEMs could update their products.

Maybe it will take legislation or a special interpretation of the 2021 executive order on cyber security [1] to force silicon vendors to take this seriously.

[1] https://www.whitehouse.gov/briefing-room/presidential-action...

> 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 (or just write) 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 capture and encoding. 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.) Mostly this excludes the same companies.

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 (IP54 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

I expect you'll get flak for #1, but the morality aspect of it bothers me a great deal as well. Not just supporting products of companies that contribute to China's surveillance state, but I worry that writing open source software contributes to surveillance everywhere as well. I don't have an answer :-(

> Not just supporting products of companies that contribute to China's surveillance state, but I worry that writing open source software contributes to surveillance everywhere as well.

This part doesn't bother me. Making open source software available for general purpose needs equalizes things, which I consider an improvement. See e.g. what happens when folks have cameras pointed at the cops slowly murdering George Flynn.

But directly giving my money to the companies that are writing software specifically to support genocide (e.g. Uighur classification) and are doing the installations for contract at what's essentially concentration camps...that's way over my personal ethical line, even if my few dollars are insignificant.

Sorry, but I think you meant George Floyd? I can't find anything about a "George Flynn" being murdered by cops.

Indeed I did.

For me, I want cameras that will meet most of these same requirements, but are battery powered WiFi cameras, and don't require the use of a cloud service to operate.

Reolink makes decent cameras, but their battery models don't work with the Reolink NVR.

Arlo requires a cloud service.

Eufy has a home hub, but I don't know yet how well it actually works. I've seen some reviews, and I've actually bought a hub plus a couple of cameras, but I haven't tried to put it into actual use yet.

And I want this system to also support regular WiFi cameras, as well as PoE cameras.

Eufy has been a pretty great experience for me. Except for the fact that they recently used their notifications (normally used for camera/motion events) to push a marketing message[1], which really ticked me off. Hence my interest in these threads now :-)

[1]https://twitter.com/dietervds/status/1707473093445230803

They are using the ancient vendor kernels too, anything from 3.x to 4.x to 5.x which sort of defeats the purpose. Most of those are pretty small too, they would be better off reversing them..

Strong Android homebrew firmware vibe.

Reply on news.ycombinator.com