koto VS moonfire-nvr

Putting the finishing touches on a procedural macro to bind Rust code to koto we want to use in synth. Also a blog post about it is on the way.

I'm currently trying to improve the vtable dispatch in koto (because I want to use it in synth).

I've been working on Koto which is intended for this kind of use case. I've been thinking about extending Rust applications with scripting, and I have games in mind but more generally I'm interested in rapid iteration in creative applications. It's still very early so I haven't shared it more widely but I'd be curious to hear what you think.

https://github.com/koto-lang/koto

But I would definitely avoid compiling Rust on the Raspberry Pi 3 if you can avoid it. I set up a Docker cross-compile environment for this reason.

Moonfire may be what you're looking for otherwise.

That last bit's not quite true: another option is to just use the cameras as a dumb stream source and do all the fanciness in an open source NVR. I've been slowly working on moonfire-nvr. Help welcome!

Moonfire

ONVIF isn't really that important IMHO.

Configuring your camera is something you do rarely, and if you have to put up with some crappy web interface, proprietary plugin, or desktop software for it, oh well. So the ONVIF SOAP APIs aren't really the most important part.

The most important part is RTSP. Many of these have astonishingly poor RTSP implementations. See https://github.com/scottlamb/moonfire-nvr/wiki/Cameras:-Reol... for some of what I'm talking about. That ONVIF page says everything is fine for several Reolink models, but I don't believe it!

If you don't need restreaming or mjpeg support, check out moonfire. It's the only alternative I'm aware of that doesn't use FFmpeg.

MSE is entirely unsupported on iPhones. window.MediaSource is undefined. https://github.com/scottlamb/moonfire-nvr/issues/121

> WebRTC largely prefers dropping packets to stay real-time

Tangent, but in my experience, the dropping packets approach doesn't work as well as people say. I haven't played with WebRTC, but my understanding is it's based on RTP over an unreliable transport, which I am familiar with. Dropping packet by packet (no mechanism to either retransmit the dropped packet or skip sending the rest of the packets in the frame) isn't great. When you lose one packet, you lose one frame, and all the other frames are janky until the next reference frame. RTP over TCP (interleaved RTSP channels) can be better, by retransmitting lost packets belonging to a frame once you've decided to send that frame, and by skipping whole frames at once when things fall behind (observed within the application as insufficient buffer space). TCP has more rapid feedback, too. (ACKs are far more frequent than RTCP RRs.)

> while HLS buffers and preserves every frame by default rather than drop frames to stay real-time. One is designed for calls (real-time) and one is not (streaming). That’s why HLS seems over-complicated. It’s not designed around real-time signalling, instead it’s designed around making requests for frames/bytes effectively sequentially.

Sure, and the WebSocket protocol I mentioned also can preserve every frame, more simply.

> MSE would be a way of capturing packets, but if the protocol doesn’t let you sequentially access bytes starting from a timestamp, you’re stuck when trying to resume a stream, no?

MSE lets you specify your own protocol. Mine [1] lets you seek to arbitrary timestamps.

[1] https://github.com/scottlamb/moonfire-nvr/blob/master/design...