tauraamui / dragondaemon Goto Github PK

Empty interfaces take up at least 4kb of memory compared to 0 of an empty struct.

At the moment when a signal interrupt has been received, the daemon begins to shutdown. It waits until the last in progress clip file is done saving to disk before closing as otherwise the persist location would be littered with random unreadable clip files and the user would experience footage loss. It also waits for until a couple of other processes have finished closing, it does this by passing manually instantiated and passed goroutines, it would be much better instead of this to pass contexts to facilitate this.

Go requires a specific date and time within the format descriptor string when calling .format() on time structs. The config file should only support the traditional pattern of "YYYY-MM-dd ...." and convert from that to the required time string.

Each actual persist process should be processed on its own separate goroutine so this doesn't back up the stream receive process which will likely result in footage loss.

It is possible to define a connection's schedule only within which the connection should be able to stream or not. At this time the schedule is ignored.

I suspect that the code is frequently using function pointer receives unnecessarily, that is probably a poor practice so should be investigated and tidied up.

Currently all CCTV footage is written to disk no matter what. The previous refactor of the stream to disk process has now made it possible to logically process a collection of stream frames as a logical clip entity in memory. It would be silly to not take advantage of this to now decide to save the clips based on whether they contain motion. This will need to still allow for a future continuous live stream of each feed to be shown on a display however, so that should be kept in mind whilst actioning this feature.

Not all video streams will be overlaid by a date/time label. We should draw one on if required.

At the moment, the server gives a connection a reference to it's now open stream. Unless this turns out to be a bad idea, this should be refactored into something that the connection manages. It is pretty confusing otherwise, and the overloads in the test don't make sense for the mock video capture instances for this reason.

The current structure of the logic, project and resulting layout of the code leaves a lot to be desired. Whilst the functionality code is all working fine and is practically there, the actual package structure can be massively improved.

Dragon daemon has a built in facility to fake/mock a video stream to ensure the whole process is working correctly without requiring the use or access to real camera connections. In order to more easily observe dropped frames or lag the footage content should include moving elements/an animation. For example the three colour circles could rotate slowly within the clip.

Because saving clips takes more time than 2 seconds occasionally, the time stamp used to save a clip file is unlikely to match the actual timeframe that it contains. This should be fixed by mapping buffer content with a time reference so instead of using time.Now to get the filename we use a correct time reference instead. This is probably going to be really hard to solve.