You can also use OSS Rust Neolink with unmodified Reolink PoE/WiFi cameras, to proxy their proprietary streaming protocol to standard RTSP for NVRs. For security, keep the cameras on their own VLAN.
They have a list of specific chips the firmware supports which is very useful but I couldn't find any concrete camera models this was for or the features the firmware supports.
Maybe I missed it but it'd be nice to raise the visibility of that a bit more.
> I had the same problem. Which camera should I buy if I want to use this?
Their docs have a general "we don't provide specifics because $OEM can change the internals on a whim" disclaimer.
That is true. OEMs can/will change the internals out but leave the model number the same. You see this ALL THE TIME with the cheap SOHO routers.
However, those changes are _usually_ paired with a bump in version / revision on the product label.
In any case, a community sourced page of devices that were - at one point in time - known to contain a supported chip would be helpful. Even if the OEM had changed the internals, at least you'd know that the internals have changed and that scouring eBay for an older serial number of the same model might get you a supported one.
In any case, I opened up a few of the amcrest cameras I have lying around and found a poorly support ambrella SoC and another SoC that is not supported at all.
--
EDIT: after talking with a friend that does a lot of hardware reverse engineering:
```
Plug the chipset that's well supported into Ali Express and then just hope that sellers put it in the listing and that it's accurate.
You'll get lots of hits on bare boards / dev-kits where the SoC ID is the only unique thing about it but you might get a few "finished" devices that are listed as using the chip as well.
```
It's not perfect, but that might be _a_ way to find devices that should be supported.
That’s something every project like this should highlight at the top - the robot firmware replacement for vacuums had that after the warning that it was a personal project and you get what he wants and that’s it.
https://github.com/EliasKotlyar/Xiaomi-Dafang-Hacks is a particularly good example, the top of the README is a list of camera models and pictures of the camera. (It also mentions "Any other Device with Ingenic T10/T20" at the end of the list, so it might overlap with OpenIPC somewhat?)
Assuming the license they stuck on it actually means anything that is. AFAIK there is no legal decision on whether weights are IP (yet another thing to shovel under copyright? lol)
Majestic, the main streamer binary is not opensource and even connects to remote servers it Hetzner among other shenanigans, so it should be called OpenIPC/ClosedMagestic.
I thought the last time this project was posted here, people pointed out that at least some of it uses closed-source binary blobs from the manufacturers? Are they even building their own kernels? If not, this doesn't remotely fix the trust issues.
All kernels, libraries and applications are open source and built from source code. Only the part of the streamer that intersects with the chip manufacturer’s SDK, uses its calls, and is under NDA is closed. Thus, even if theoretically you open that part of the Majestic streamer that is closed, it will not give much, since everything else from the chip manufacturer will be closed and cannot be published openly officially
Fun fact: This firmware is also being used to currently repurpose cheap IP Camera hardware + Off the shelf wifi hardware to get digital FPV on racing drones: https://www.youtube.com/watch?v=jMFqk3vMupE ( Feel free to scroll to the parts that interest you ).
Its not that "fun" when you consider what that entails. My comment how shady this is last time "OpenIPC" came up:
Something tells me being closed source (majestic) 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.
Unfortunately the latency is nowhere near good enough for racing - best case actual results are ~100ms E2E. The project authors have claimed some absurdly low latency numbers in the past but they're laden with asterisks, like using a wired connection.
The latency numbers were indeed shady .. like he advertised "cheapest digital fpv" and for that price they were doing 720p60fps with the latency around 80-100 indeed.. but with the more expensive 120fps setup, they were getting closer to interesting latency: https://youtu.be/i_Wz9oAK5z4?t=224
The other issue is that a lot of their source code isn't open source yet. The majestic etc.. bits.
What I am hopeful is that: once there is easy to use hardware for people to tinker around with, the project will actually improve to the point of being a real system like ExpressLRS.
DJI/Caddx are using basically LTE radios, I doubt WiFi chipsets will have acceptable perf. Still, for fixed wing this might be acceptable and cheaper than existing systems. For freestyle/racing.. forget it.
Typically speaking, even if you are getting around 10-12Mbps over wifi that means each 720p raw frame takes only ~2-3ms to transmit. Most of the time is spent in encoding and decoding the video frames, waiting for retransmissions etc..
Also they aren't exactly using Wifi. They're using just the chipset to broadcast. Here's the interesting talk from the original author of wifibroadcast . The challenges they fixed to use wifi hardware for transmission: https://media.ccc.de/v/36c3-10630-wifibroadcast .
It’s interesting, but I’m curious if they’re ever going to target higher end cameras from the likes of dahua. Those cameras are all Linux based and most have serial headers so it should be doable.
It appears the list indicates various SoCs, not the devices employing them. It is possible Dahua cameras already use one or more of these chips, but the only way to tell would be to tear apart one or find someone who did. Before flashing, however, one should triple-check anyway that the SoC is the same, as models could switch from a SoC to another one without any noticeable difference to the user apps.
I would also 2nd for Hikvision cameras support as they're cheap and ubiquitous.
They already offer downloadable firmware and SDK that can be examined to infer the employed SoC: https://www.hikvision.com/en/support/download/software/
Super cool. Embedded camera software is tough. Number one issue when I worked on it was dropping frames. You have 10 ms or so to get the frame to the next I/O stage - for example for streaming - and a lot has to happen. Double the challenge for stereo cameras.
I've been working on getting openipc compiling libusb and rtl-sdr packages so I can flash it to the $15 chinese sbc dvr w/sata port (ICsee Xmeye XM Nvr Board 4K 10Ch Hisilicon chip Hi3536E IP Recorder Embedded Linux) that's openipc compatible and just use those boards for running my rtl-sdr software defined radio dongles instead of $50-100 rpis or odroids. Their build system is a bit weird but it's not bad. Having to flash over serial to install is tedious but well worth it for the price and functionality.
That said, the actual FPV/camera stuff with openipc is cool too. I definitely would rather pay $50-80 for a 2k 90fps camera/transceiver/receiver system I can hack on in linux than than $300 for a (much better) dji o3 pro. I'm hoping I can get the HDMI out formatted properly to use with my HTC Vive head mounted display instead of having to fork out for something new I can't buy (-11 diopter) prescription lenses for. There's basically no support for glasses wearers in any FPV goggles except the dji ($$$$) stuff.
What is the cheapest option for a barebones IP camera that can install this? My biggest criteria is cheap as possible but also internal power source and wifi so I don’t have to run any wires. It’s fine if I have to wipe proprietary stuff off it first. Waterproof would be a plus for outdoor cameras too.
Smartphones with the camera on for cheap probably last 45 minutes on battery. My last no name amazon cam (unfortunately on proprietary software) could last almost a month fueled by two 18650s in its housing.
What is the gap? I had some no name amazon one that was almost OK but it was in its own walled garden. Maybe I could flash it, who knows? But either way it was like $35 and connected to my wifi, lasted 3-4 weeks, and had a good enough video quality to see if I got a package or not. I would continue using it but a recent change of terms of service rendered it next to useless unless I subscribe. I would assume similar hardware would be available with maybe no os preinstalled?
Dude you just listed several issues with toy cameras. That's the gap.
PoE cameras are only slightly more expensive, don't hog wifi airtime and cause latency spikes for all the other devices, last decades instead of weeks, have much better video quality during day and night, and don't rely on any cloud services
PoE cameras (and doorbell) is something I’ve been looking at, but from the looks of it running ethernet in my house, which is a newer build (~2005) and wasn’t designed with things like that in mind isn’t going to be fun. Might as well go this route since I’ll be running regular ethernet between rooms anyway, but seems like it might be enough of a pain to be worth hiring a professional to do it instead of trying to DIY it.
It may be easier than it looks, but talk to a few people about costs. Anyone who has done any wiring (elechicken or no) can do low voltage and leave the ends for you to terminate/deal with.
But permits might be needed in some areas.
Usually the trick is UP the wall into an attic or DOWN the wall into a basement, over, and up or down.
If necessary tricks like hiding thin cables behind molding or even shoved into the carpet edge can work.
You don't have to run the ethernet inside the walls. I used coaxial ties to run my ethernet cable along the surface of the wall and it works just fine.
That’s true, but external runs can be challenging to do in a way that doesn’t look bad (e.g. cable runners not matching paint well) and could have a negative impact on resale value later on.
I was really hoping to see my Google cameras on the list of supported models. I'm expecting them to be EOL'd any day.
I am slowly migrating and replacing my way to an entirely self-hosted smart home setup, but my Google cameras were expensive and it would be fantastic to be able to flash and integrate them with the rest.
Why do you think they will be EOLd? https://support.google.com/product-documentation/answer/1023...? Shows they are guaranteed to be updated for at least 5 years after release, so you have at least 2 more years, but hopefully longer. Only 1 nest product has stopped receiving updates so far and there are several that are 4 years past their guarantee date so precedent would indicate you still have a fairly long support window. This isn't the same as supporting a phone.
I would like to see what's going on with my house when I'm not home, keep track of deliveries, visitors, who's parked in my driveway, keep an eye on my dog outside, etc.
I demand firmware that I control because plenty of the normal enshittified ip cams mine your data and brick the device when they feel like.
True. I could definitely be convinced, even, that instructions per cycle was the somehow “stronger” association.
I think the reason I went to inter process communication is that is seems like the sort of thing that would benefit from libraries to standardize. OpenIPC could be a great name for such a library. For instructions per cycle—maybe a benchmarking suite? Haha.
"Hacking Reolink cameras for fun and profit", https://news.ycombinator.com/item?id=33091698
https://github.com/thirtythreeforty/neolink
https://support.reolink.com/hc/en-us/articles/900000617826-W...