OpenIPC: Alternative open firmware for your IP camera | Hacker News Reader

OpenIPC: Alternative open firmware for your IP camera

github.com

363 pointsdanboarder59 comments

Having looked into this myself prior was mostly asking for disappointment. Getting a random Chinese IP camera to convert to open firmware is great in theory, but the problem is actually buying a camera or 10, or buying more over time.

You never really know what hardware ships internally at any given time, ie what SoC a camera really is. They change frequently in random Chinese manufacturers with internal SoC hardware update with constant improvement (in their margins at least), if reported by someone at a point in time, buying the same model a 6mo-1yr later you cannot expect the same model number to be the same hardware.

It is rarely stated on a site selling them what SoC they use, or the vendors sites, assuming you can find and/or translate anything usable, or if the vendor is even still around more than a few months under that name. Therefore there is no repeatable source of products you can get reliably across time without simply testing a sample and hacking your own as you go.

I really wish someone would take initiative to sell/resell a line of camera hardware with openipc or other open firmware on them. It's a business opportunity sorely missing with nothing to offer home/business users ip cameras with open sterile and guaranteed secure firmware vs. random pure Chinese jank.

> I really wish someone would take initiative to sell/resell a line of camera hardware with openipc or other open firmware on them. It's a business opportunity sorely missing with nothing to offer home/business users ip cameras with open sterile and guaranteed secure firmware vs. random pure Chinese jank.

Manufacturers could do it themselves, but the license prohibits commercial use.

> OpenIPC source code is released under one of the most simple open source license agreements, MIT License, giving users express permission to reuse code for any purpose, even as part of a proprietary software. We only ask you politely to contribute your improvements back to us. We would be grateful for any feedback and suggestions.

Edit: since people are arguing with me, the text I quoted is right of the main page for OpenIPC, and everything here is MIT licensed too: https://github.com/OpenIPC

Except they're not releasing the source of the core parts. They say (or at least very heavily imply they are), but they aren't. See other comments.

> Majestic code while is not open, provides unprecedented performance and capabilities for a wide range of hardware. The author of Majestic streamer is looking into possibilities to open-source the codebase after he secures enough funds to support further open development. You can help to make it happen sooner.

Source: https://openipc.org/

I can't find that text anywhere on the page (the word "Majestic" literally doesn't appear anywhere).

It's right before the "Why OpenIPC Firmware?" headline.

That comes after this:

> OpenIPC Firmware uses Buildroot to build its Linux distro, and utilizes either Majestic, Mini or Venc streamer.

Which makes it sound like Majestic isn't required? Or is it the only good option, or something?

I checked the repos for those alternatives. They state that they are not as feature-complete, nor as widely supported, as Majestic is.

When in doubt, I take for granted that every camera with closed firmware contains malware that phones home or waits dormant to be used to steal sensitive video+audio or to take part in a botnet, which already happened several times. The solution as of today is to put a firewall in between that blocks any traffic to the LAN and from the outside, except from trusted applications. There are many multi ETH port mini PCs that can be repurposed as firewalls so that the video surveillance subnet can be physically separated from the rest by connecting all cameras (for obvious reasons I wouldn't take WiFi into consideration) to a switch, possibly with PoE support.

Couldn't agree more with this comment. I've had exactly the same frustration trying to get cameras months/years apart that will work. You have to open each one up and hack it yourself (and OpenIPC may support it or not), and nowadays they are protected from loading firmware easily (tiny UART/debug ports, disabled UBoot loader, etc.).

I also wish there were an option for someone to buy cameras with open HW/SW, to get away from the random cloud services they want you to open your network up to with cheap cameras.

Not just that; I'd be OK with closed source firmware if I can just put it on an isolated network and be done with it, but from typical listings on Amazon et al you cannot even tell if the camera works without a mandatory cloud connection.

I've bought a router from TPlink a while ago that wanted me to install a fucking app, create a TPlink account and send all comms over some cloud servers to configure a router that's sitting right next to me, that all the traffic from the very fucking phone is going through. It did have a classic web interface, but it was completely crippled and basically just allowed changing the Wifi SSID and doing a firmware update. There was nothing in the product description about this, and none of the customer reviews mentioned it, because obviously this shit is now completely normal to the average joe.

I’ve been thinking about something like this. Anyone else interesting in working on this?

I'd be interested. Even if it's just a Linux SBC + camera module, an OS image preconfigured as an IP cam would really reduce the DIY overhead.

Me me I'm interested.

In case some other folks who are in need, we have a side-project dedicated to the completely open source camera: hardware: https://github.com/maxlab-io/tokay-lite-pcb firmware and software layer: https://github.com/maxlab-io/tokay-lite-sdk

And we will eventually ship them form here Crowd Supply at: https://www.crowdsupply.com/maxlab/tokay-lite

Stupid question from a noob: why not just use some raspberry pi zero, a camera sensor and some ONVIF server? That's what most of those cheap chinese IP camera are: a linux board, a camera sensor and some compression chip.

Because the camera comes in a neat box with resonable weather tightness and it is easier to setup and connect. IP cameras also have the advantage of not needing a power brick.

Your other points withstanding but there are some slick PoE boards available for the RP0s.

The Wyze cams seem cheap enough at ~35€ and with a stable SoC. A replacement for their (insecure) cloud stuff would be nice, otherwise the software is actually pretty decent.

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

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.

https://openipc.org/support-open-source

>It's Open Source

>Price of the Firmware

>The right to use the OpenIPC firmware and its components is granted to all users free of charge and only for personal, non-commercial purposes. If you are interested in using OpenIPC for your business projects, please contact our team.

That's confusing, because the GitHub repo has an MIT license. Is there some kind of secret sauce they add to the compiled binaries that the non-commercial clause applies to maybe?

Their "Magestic" app, which sounds like it provides key functionality, is closed source.

I wonder whether they really want open source, or this is a commercial effort that's trying to leverage 'the community' to get the hard part of the engineering for free.

For really wanting open source, the OpenWrt model has seemed pretty good, and the nature of the engineering work seems similar. Some hardware vendors use OpenWrt for their firmware, which seems to help the mainline open source OpenWrt also have good support for that hardware.

For those curious if their devices are supported. The list is here:

https://github.com/OpenIPC/wiki/blob/master/en/guide-support...

Finally, a way to decide which IP camera to buy.

Wow. I've only heard of two of those brands of cameras.

And I didn't recognize any that were among the known thousands of re-brands/sub-brands of HikVision and Daihua, both of which have been implicated in the suppression of the Uighur people in China (and which have been banned by the NDAA, see https://ipvm.com/reports/ban-law).

Totally random question there but... Any recommendations of cameras that are currently easily available(say amazon, aliexpress, etc) and support this while having good/verygood image quality?

Seconded. I previously bought some that I thought were supported, before finding out that they are not. It'd be great to know whether anyone has had success with particular hardware.

They have a device/chip compatibility list here: https://github.com/OpenIPC/wiki/blob/master/en/guide-support...

A long time ago, I built a business around off-the-shelf IP cameras. The field was full of buggy firmware with enormous security holes (biggest I found was to be able to acquire pictures without even being authorised!). Hardly none of these firmware would get updated, they were abondonware right out of the package.

Even though this doesn't seem to be entirely open, any kind of move into that direction is a bit of fresh air.

OpenIPC really didn't mean what I thought it did.

I was 100% sure it would be some kind of inter-process communication abstraction / framework.

Yeah I think IPC has too much of an established meaning here. Something like OpenIPCam might be a little safer.

Majestic, the main streaming "core" component of the camera (which does RTSP, HLS, etc...) is closed source, the rest is open, except some third party SDK blobs.

The interesting thing about this project is that they're repurposing cheap ip camera hardware to work as surprisingly decent, low latency digital video system for fpv drones:

https://m.youtube.com/watch?v=wZAHkWHfBF4

Mostly a continuation of the OpenHD project. But it's quite promising.

Related: I was hacking Ambarella action cameras a while back: https://github.com/petabyt/liemoth

Eventually I stopped not because of how low quality action cameras were, there were hundreds of different vendors publishing rebranded Chinese cheap cams. And not to mention how crap the firmware is. The whole thing gets hot and the battery only lasts a few minutes.

OpenIPC: Alternative open firmware for your IP camera - https://news.ycombinator.com/item?id=35975383 - May 2023 (1 comment)

I was really hoping that the Pine64 PineCube cameras would gain traction in this space, but it seems like they only ever really shipped small batches of them. They'd need an enclosure/software to make them a reasonable choice.

Wiki: https://wiki.pine64.org/wiki/PineCube

I think they mentioned in a blog post that they didn't get as much community support as they hoped so they gave up on it.

Another IP Camera thread: https://news.ycombinator.com/item?id=36447024

OpenIPC is one of those projects where the core team is Russian, and their communication is Russian, and they use Telegram (or a bridge) for everything. As a non-Russian speaker you're pretty lost trying to contribute, and as a result they attract hardly anyone outside the russosphere. I've tried telling them they're artifically limiting their project, but was predictably ignored. This project has so much potential, but it will never be achieved.

I've seen this before; projects like that tend to stagnate and die. Openinkpot comes to mind.

BTW not a rant against Russians; open source projects do best when they have a lot of contributors from across the world, and that means English.

First of all, software projects in general tend to stagnate and die.

If you really want to contribute, I'm sure you can figure out a way. You can always fork it and do your own thing, that's potentially a contribution in itself. It's a little selfish to expect other people to become fluent in technical English and rearrange their project to suit your desires.

Something tells me being closed source while naming it OpenIPC and pretending to be under MIT license mighty be a bigger factor.

Being russian and clearly trying to steer project towards drone use https://github.com/OpenIPC/sandbox-fpv doesnt help either, we all know what russian drones are used for right now.

Reply on news.ycombinator.com