Suggestions on the future architecture of the library

[peterpaulis]

I am studding the architecture of the library, more exact it's recording part and few notes maybe on the future architecture

• one IOVideo should correspond to one video input only (camera 1 / multicamera 2 / screencapture)
  Currently: one IOVideo can host the primary cam and the multicam... screen capture is injected into the IOVideo from the Stream which breaks principles
  Problem: the IOVideo class has possibly outgrown after adding second cam and screen capture and would not hold if other inputs are added as well

• the IOMixer should use all IO, like VideoIO 1, VideoIO 2, AudioIO... to produce the final result and manage the codec
  Currently: the mixing of different video inputs is done inside a single IOVideo and passed to the codec, also managed by IOVideo
  Problem: the mixer should be the "mixer", and controlling the mixer should enable to adjust the final screen mix (like the combination of different videos)

Currently there are 2 main problems arising from this

• creating custom video mixes is not possible without library change (the IOVideo is inaccessible and lazy assigned, so the only solution would be to change the source directly, moreover, changing the mixer doesn't help either as the mix is done in IOVideo)

• using the recorder to record just raw inputs without modifications, is not possible... but this is also an issue on the IOMixer<->IOUnit<->IORecorder architecture as well

[shogo4405]

Based on YAGNI principles. I don't think there are problems because I will change the design when I actually provide that feature. If you need this features NOW. Please fork this project. Thank you.

[peterpaulis]

yes, i did already fork...

i need to use a more advanced recorder, where the current interface is not sufficient

i will than create a Push request enabling better extensibility of the recorder