openmiko
libpeer
Our great sponsors
openmiko | libpeer | |
---|---|---|
28 | 11 | |
615 | 774 | |
2.8% | - | |
3.8 | 8.1 | |
4 months ago | 4 months ago | |
C | C | |
GNU General Public License v3.0 only | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
openmiko
- I found 3 Wyze cameras and haven't used them before. Is there anything for the home tinkerer to do?
-
Can't stream video
Have a Wyze Cam V2 running openmiko. I can pull the feed via the camera's IP, but Klipper (Fluidd, Mainsail on BTT CB1) shows like below. Additionally, moonraker-timelapse throws an error. This was working fine until I tried Hyperlapse. Now I can't wrap my head around this
-
IP webcam and external access
I'm running MainsailOS, and a Wyze cam v2 running openmiko. I have Tailscale installed on the Pi for remote access. In Mainsail config, I have the camera configured via private IP. When I access the web control panel externally, I do not get video output. Is there a way to get this to work? I do not think there's a way to connect the Wyze cam to my tailnet.If it's not possible, have any good recommendations for a good, cheap, wide-angle (110 degrees FOV or better) camera I can purchase? I wouldn't want to spend more than $25 for one. Quick search yielded this one, but don't know if there's a Klipper-community recommended one that everyone uses.
-
Octo4a or OctoPI?
you wish lol. the mod allows you to get highest possible resolution video out of it without all the compression pixelation. its super easy to install. but it does take a little bit of linux knowledge to edit config files and stuff. heres the link if interested: https://github.com/openmiko/openmiko
-
Can I still buy an actual IP camera?
I bought a used Wyze Cam V2 relatively cheap and installed OpenMiko on it for example.
-
Docker instance won't connect to IP cam
I have a WyzeCamV2 running OpenMiko firmware, which supports (and I have configured for) H264 RTSP streaming. I can view the video stream through VLC with the url rtsp://192.168.1.199:8554/video3_unicast. I am executing the command docker run -p 8081:80 --name mycamera -e AGENT_CAPTURE_IPCAMERA_RTSP="rtsp://192.168.1.199:8554/video3_unicast" kerberos/agent:latest on my host. The agent seems to run fine and I can connect via browser. With our without AGENT_CAPTURE_IPCAMERA_RTSP... set, I cannot add the RTSP stream; no cameras show attached and when I try to connect one via dashboard->settings, it just spins. The logs aren't really helpful (see below).
-
Does a hardware webcam over IP exist?
OpenMiko is one example.
-
Ultra popular Linus Tech Tips abruptly drops their sponsor, Eufy Home Security Cameras, when it's revealed that Eufy has been secretly uploading images of the home owner, despite explicitly stating that the product only stores images locally.
That's why I only use cameras flashed with open firmware: https://github.com/openmiko/openmiko
-
[Security Camera] WYZE Cam v3 with 3-Months Cam Plus (2-Pack) $35 free shipping
If all else fails, you can flash different firmware and use them locally. I'm using [OpenMiko](https://github.com/openmiko/openmiko) on my Wyze Cam v1 (I'd assume there's a similar open-source project for the v3), and Wyze themselves publishes an RTSP firmware. Without a bit of technical know-how and some supporting hardware (namely a router than supports OpenVPN) you won't have access to the stream off your local network, but you can stream locally with VLC Player.
- Disassembling an Amazon Blink Mini Camera
libpeer
- VoRS: Vo(IP) Simple Alternative to Mumble
-
Pure C WebRTC
I am really excited about https://github.com/sepfy/libpeer. It has examples ready for ESP32 etc....
When working on KVS I wasn't familiar with the embedded space at all. I saw 'heavyweight' embedded where you were running on Linux. Then you had RTOS/No OS at all. I wasn't prepared for these devices at all. If we can make WebRTC work in the embedded space I think it will really accelerate what developers are able to build!
Remotely driven cars, security cameras, robots in hospitals that bring iPads to infectious patients etc... Creative people are building amazing things. The WebRTC/video space needs to work harder and support them :)
-----
I love how diverse the WebRTC space is now. Outside of this implementation you have plenty of other options!
* https://github.com/shinyoshiaki/werift-webrtc (Typescript)
* https://github.com/pion/webrtc (Golang)
* https://github.com/webrtc-rs/webrtc (Rust)
* https://github.com/algesten/str0m (Rust)
* hhttps://github.com/sepfy/libpeer (C/Embedded)
* https://webrtc.googlesource.com/src/ (C++)
* https://github.com/sipsorcery-org/sipsorcery (C#)
* https://github.com/paullouisageneau/libdatachannel (C++)
* https://github.com/elixir-webrtc (Elixir)
* https://github.com/aiortc/aiortc (Python)
* GStreamer’s webrtcbin (C)
See https://github.com/sipsorcery/webrtc-echoes for examples of some running against each other.
- WebRTC for the Curious
- Show HN: Bring phone calls into the browser (sip-to-WebRTC)
-
Drop packet
I am experimenting based on the pear project (https://github.com/sepfy/pear) and using the clumsy tool to simulate the case of dropping packets.
- Pear - A WebRTC Toolkit for IoT/Embedded Devices (a work-in-progress)
-
Hacker News top posts: Apr 8, 2021
A simple C implementation to stream H.264 to browser using WebRTC\ (61 comments)
-
A simple C implementation to stream H.264 to browser using WebRTC
I think there's some truth in what as-j is saying. Rust binaries (and C++ ones) tend to be larger than C ones. I think the major reasons are (a) Rust dependencies being statically linked due to a lack of ABI stability, (b) inclusion of portions of the (statically linked, see a) Rust standard library used by the program where C code uses libc, (c) code bloat due to monomorphization, (d) the ease of just using a full-featured library where someone writing in C might cheat a little bit. As an example of what I mean by the last point, see sdp_attribute_get_answer in this codebase. [1] It's writing JSON, but it doesn't use a JSON library that actually escapes the included string. It just assumes the included string doesn't have a quote character in it. Is that assumption valid? Will it always be valid? I'm not sure on quick inspection.
There are ways around all of these:
* a. Static vs dynamic linkage: in an embedded system, it'd be reasonable to just produce a single userspace binary that does everything. It can change its behavior based on argv[0]. I think this is not too unusual for constrained systems even with C binaries. Eg busybox does it. If you only have one binary, you don't need dynamic linking. Also, I think it's not strictly true that Rust doesn't support dynamic linking. I think you can dynamically link everything if you ensure the whole system is built with the same compiler version.
* b. Standard library. You don't have to use it at all, or you can use it sparingly, paying only for what you use.
* c. Monomorphization. You could write (for example) a Go-like map [2] rather than relying so heavily on monomorphization. I'd love to see someone take this idea as far as possible; it might be a good idea for a lot of non-inner-loop code in general, not just on tight embedded systems.
* d. Using full-featured libraries. Obviously no one is making you do this; the same cheats available in C are available in Rust.
but in fairness, the further you go down this path, the further you are from just being able to just take advantage of the whole Rust ecosystem.
Personally, I'd still rather develop or use a #![no_std] Rust codebase than a C one. Memory safety is important to me. IOT devices are no exception to that. Their security is historically horrible but I'd like to change that.
[1] https://github.com/sepfy/pear/blob/b984c8dccaafdcdd1b181786a...
[2] https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...
What are some alternatives?
Xiaomi-Dafang-Hacks
libdatachannel - C/C++ WebRTC network library featuring Data Channels, Media Transport, and WebSockets
WyzeHacks - Hacks I discovered allowing Wyze camera owners to do customizations
tiny-webrtc-gw - tiny/fast webRTC video conferencing gateway
docker-wyze-bridge - WebRTC/RTSP/RTMP/LL-HLS bridge for Wyze cams in a docker container
spchcat - Speech recognition tool to convert audio to text transcripts, for Linux and Raspberry Pi.
exomind - A personal knowledge management tool hosted on your own personal cloud
cpufetch - Simple yet fancy CPU architecture fetching tool
openipc-firmware - OpenIPC Firmware for Wyze Cameras
Ory Keto - Open Source (Go) implementation of "Zanzibar: Google's Consistent, Global Authorization System". Ships gRPC, REST APIs, newSQL, and an easy and granular permission language. Supports ACL, RBAC, and other access models.
libjuice - JUICE is a UDP Interactive Connectivity Establishment library