libdatachannel VS openmiko

Node.js node JavaScript runtime itself provides a means to interface with native applications. Plenty of people write their own WebSocket or WebRTC data channel libraries https://github.com/paullouisageneau/libdatachannel.

Fourtunately some technologies and API's are extensible enough to do whatever you want in spite of and to overcome limitations; e.g., WebRTC (particularly data channels https://github.com/paullouisageneau/libdatachannel), Native Messaging, WebTransport, fetch(), Trasnferable Streams, Media Capture Transform, File API, File System Access API, Web extensions.

To be fair, C++ has libdatachannel which I like using too.

https://github.com/paullouisageneau/libdatachannel ?

Or use something specific like libdatachannel https://libdatachannel.org/

If you’re using WebRTC data channels in a client server config then infra is no more complex than a regular setup because the server will almost certainly have an external facing IP address.

People should really try using WebRTC as well because you can get the full pipeline setup for a toy demo in a couple of slow days. I did whilst also writing my own signalling server in Go without having used Go before!

It’s certainly not any more complex than rolling all the stuff the article is talking about on top of raw UDP.

This does use a real WebRTC stack (specifically libdatachannel - https://libdatachannel.org). Under the hood this is making real WebRTC connections.

But I guess you mean why it doesn't mock using real peers in the browser where the tests are happening, using the browser's existing stack there?

There's a few reasons I've avoided that:

* Primarily: I want to do things that the browser APIs won't let you do. E.g. sending invalid data, or intentionally causing various types of errors. The browser APIs are designed to stop you doing the wrong thing, by keeping the raw data at arm's length. Very sensible for normal WebRTC usage, but bad for testing edge cases and breaking things.

Building WebRTC tends to be hell. If your use case is simple enough, it might be interesting to switch to an alternative C++ library like libdatachannel (I'm the author).

You can, in theory, get UDP-like characteristics out of a different web API - with a WebRTC datachannel configured to be unreliable and unordered. I haven't seen anybody use that API just because it's a pretty big pain to use. The developer of Agar IO called it too hard to use in a HackerNews comment, but nowadays there's simpler libraries than the ones he had in 2016 like webrtc-unreliable and libdatachannel. You still need to run a STUN/TURN server and the integration is easier than it was back then, but still much harder than raw UDP sockets though.

exit(EXIT_SUCCESS); } char message[message_length]; fread(message, message_length, sizeof(char), stdin); string m(message, message + sizeof message / sizeof message[0]); return json::parse(m); } // Encode a message for transmission, given its content. message_t encode_message(json content) { string encoded_content = content.dump(); message_t m; m.content = encoded_content; m.length = (uint32_t)encoded_content.length(); return m; } // Send an encoded message to stdout. void send_message(message_t encoded_message) { char *raw_length = reinterpret_cast(&encoded_message.length); fwrite(raw_length, 4, sizeof(char), stdout); fwrite(encoded_message.content.c_str(), encoded_message.length, sizeof(char), stdout); fflush(stdout); } int main(int argc, char *argv[]) { while (true) { json message = get_message(); auto command = message.get(); // https://github.com/paullouisageneau/libdatachannel/issues/544#issuecomment-1024739214 // https://www.reddit.com/r/cpp\_questions/comments/swr1tk/comment/hxral9f/ FILE *pipe = popen(command.c_str(), "r"); while (true) { size_t bufferSize = 1024; byte buffer[bufferSize]; size_t count; while ((count = fread(buffer, 1, bufferSize, pipe)) > 0) { stringstream data; // S16NE PCM from parec to integers in JSON array data << "["; for (size_t i = 0; i < count; i++) { data << (int)buffer[i]; if (i < count - 1) { data << ","; } } data << "]"; // send JSON array to Native Messaging local client send_message(encode_message(data.str())); } } } }

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).

That's why I only use cameras flashed with open firmware: https://github.com/openmiko/openmiko

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.

I think OpenMiko is what you're looking for.

You probably want a custom firmware. Something like dafang or openmikothat would give you full control over the camera.

For open source and self-hosted, I've been pretty pleased with openmiko (https://github.com/openmiko/openmiko). I put this on a couple $20-ish wyze cams that are used adhoc right now, but will be combined with frigate and home assistant when I can get ahold of a Coral USB device.

OpenMiko - New, appears to be the most actively developed firmware rn

Even better, go check out https://github.com/openmiko/openmiko. I found it much more reliable.