moonfire-nvr

a separate machine if desired Also a couple disadvantages: * two services to set up (main process + subscriber) instead of one. * there's the possibility that an event happens while the main process is running but your subscriber is disconnected, so the event gets committed to the database but you never see it. The easiest thing to do is to accept skipping these (as would happen anyway if the main process is down). Or the main process could buffer events for a while. Or the watcher could have logic to "catch up" (which unfortunately means not only more complex logic but also keeping state somehow). If you'd prefer another approach or want it sooner than I'm likely to implement it, please contribute! I have my priorities & design ideas, but if you chip in, you get a say in both. And I go pretty slowly on my own anyway, so if you're able, it's worth chipping in even if you agree with me about everything. [1] https://github.com/scottlamb/moonfire-nvr/blob/master/design... [2] https://github.com/scottlamb/moonfire-nvr/issues/40

schema design doc talks about that here: https://github.com/scottlamb/moonfire-nvr/blob/master/design... .mp4 serving will aggregate those together (maybe clipping the start and end segment) to give you a .mp4 segment for any time range of interest. It comes up with a mp4::File struct which knows what video segments to serve and maps byte locations to parts of the .mp4 container format. I don't have a good doc about how this works other than the source code right now. https://github.com/scottlamb/moonfire-nvr/blob/master/src/mp... [edit: and you probably won't be successful in understanding it without having a pdf of the ISO/IEC 14496-12 specification open next to it.] Here's some debug output for generating a five-minute video segment: https://pastebin.com/Wzfz7BF7 Storing individual frames as jpegs would be inefficient I agree in all sorts of ways: recording CPU (you have to decode the H.264 and re-encode it as JPEGs), disk space, disk seeks, playback bandwidth, browser CPU, etc. My understanding is this is how Zoneminder currently works. I imagine it worked better with the cameras Zoneminder was originally designed for: low-resolution, low-qps webcams that didn't do their own H.264 encoding.

make this into a nice polished thing other people could use but have given up on the idea for now. The thing is that media components are super finicky, many things need special support written just for them, and you really have to extensively tweak them to see how they function as a whole. (eg does your TV turn off your stereo receiver when it turns off itself. The answer varies based on the model and settings of both components.) HDMI-CEC doesn't live up to its potential in this regard. [edit: fixed hyperlink]