Quick update: we have decided to quickly prototype a IP Camera (think “open-source DropCam”) from cheap parts. Let’s see if our work on Project Link can be used to rig together that kind of device!
https://github.com/fxbox/standalone-ipcam does enough of an IP Camera to do
snapshots. It doesn’t do streaming, but I’m sure that could be added.
For streaming, I’ll try to wrap the WebRTC C++ library in Rust. I’m hoping that you’ll provide the frames 
1 Like
Change of plan for streaming.
I’ve brainstormed our use case with @padenot, from team WebRTC. According to him, WebRTC is way too sophisticated (and hard to embed) for our use case. It seems that just providing an environment for the execution of WebRTC code is a work of ~50kloc.
Following @padenot’s suggestion, I’m currently investigating gstreamer:
- it’s simpler;
- it can build/stream HTML5 video out-of-the-box;
- if we find out that we need WebRTC’s advanced network-piercing capabilities, there are gstreamer<->WebRTC bridges around (I have found Janus and OpenWebRTC);
- as a bonus, someone already wrote Rust bindings for gstreamer.
I’m currently attempting to get these bindings to work (they don’t build too nicely on my Mac atm).
This 50k LOC number doesn’t match at all the peerconnection_client samples in the webrtc tree. I’m absolutely unconvinced.
One reason to use webRTC instead of http streams is to not have the media traffic go through our bridge/tunnel.
Ok, I have a first script (not an adapter yet, but it’s a start) that can stream video from a built-in/webcam to HTML5. I’m now trying to turn this into WebRTC.