Camera abstraction layer

[AusOcean developer]

As we add support for new cameras (such as RTSP cameras) it will be beneficial to have a camera abstraction layer.

Different cameras will support (1) different capabilities, (2) different mechanisms for setting those capabilities and (3) different parameter names and values for those capabilities.

For example, whereas the Pi Camera is configured entirely via command line flags, RTSP cameras are configured by the RTSP SETUP command.

The Android camera hardware abstraction layer may provide some pointers:

https://source.android.com/devices/camera/camera3

[Alan Noble]

As we add support for new cameras (such as RTSP cameras) it will be beneficial to have a camera abstraction layer.

Different cameras will support (1) different capabilities, (2) different mechanisms for setting those capabilities and (3) different parameter names and values for those capabilities.

For example, whereas the Pi Camera is configured entirely via command line flags, RTSP cameras are configured by the RTSP SETUP command.

[Saxon Milton]

My thoughts are that we should have an input interface with methods like Setup, Start and Read. Then we have a camera struct that implements this. I say that it might be good to have input interface, because we have inputs other than cameras, like files or microphones, which would have their own implementations of the input interface.

[Alan Noble]

An InputDevice interface sounds good.

[Saxon Milton]

Design doc: https://docs.google.com/document/d/1y4ECyCDhY6bzPDxnGt64KLLcGeWMcrafjk1xDydvr4g/edit#heading=h.jz8kjf9da2ac

[Saxon Milton]

Resolved in PR #270 and PR #280.