libdatachannel VS openmiko

You can use https://github.com/paullouisageneau/libdatachannel for your C/C++ integration needs. It's 10k lines. So the answer is 0. Its required dependencies (I assume this as they are git submodules in deps) are more than 100k lines, though, srtp support making the bulk of it. On my machine it took 11 seconds to compile it.

Irssi is 64k lines (plus its dependencies), so I guess that makes WebRTC complicated.

Can't argue that DCC isn't simple, but perhaps the protocol deviced decades ago is a bit too simple.

Most of the work happened in the libdatachannel! You can check out my PR here[0]

[0] https://github.com/paullouisageneau/libdatachannel/commit/a6...

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.

This is not true, there are actually multiple WebRTC implementations in different languages besides the reference library: aiortc (python), libdatachannel (C++), sipsorcery (C#),webrtc-rs (rust), werift (Typescript), and Amazon Kinesis (C)

Use any means necessary to transfer your data across devices. Could be IPFS, could be FTP, could be EventSource, WebSocket, WebTransport, Fetch, whatever. See https://github.com/guest271314/secure-file-transfer; offscreen-webrtc, https://github.com/paullouisageneau/libdatachannel.

I've successfully used libdatachannel to Web pages to connect native applications and stream data to the browser.

Alternatively you can use your server as a signaling server for WebRTC (Insertable Streams ("Breakout Box"), or data channels https://github.com/paullouisageneau/libdatachannel), then users (peers) can exchange data themselves and you don't need to store anything, see True End-to-End Encryption with WebRTC Insertable Streams, A complete example for a WebRTC datachannel with manual signaling.

there is also a c++ library that can be used to open a data channel connection, I think a number of SFU “servers?” use this library (I wish I had) https://libdatachannel.org/

For networking and terminating WebRTC connections from cpp libdatachannel is you easiest bet. For transcoding you can pick whatever library you like, if any. The other way would be to use the chrome WebRTC stack and modify it for server use. It can and has been done but is very involved.

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

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.

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

I bought a used Wyze Cam V2 relatively cheap and installed OpenMiko on it for example.

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

OpenMiko is one example.

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.