Is your feature request related to a problem? Please describe.
many a time we run into an issue where host has multiple cores available but a module runs on a single core, e.g. a JPEGDecoder. Let's say the JPEGDec takes 50ms to process a frame => it can process 20 fps. However the source runs at 60 fps. and let's say host has 8 cores... so there is compute resource available but a single instance of module can not use it.

Describe the solution you'd like
Define a higher order concept: ModulePool. A ModulePool maintains multiple instances of a module. All instances of modules in the pool have same props and they all feed the same outputs. However these instances each run on a separate thread. So when a frame is queued on the ModulePool, it is served by any of it's constituents in a round robin fashion. A simple approach is that ModulePool's process function simply forwards to the constituents queue, but in a round robin fashin, 1->2->3. This way the load gets dstributed. On the output side we make sure that the delivery of output frames is still in the same order in which they were recieved.

Describe alternatives you've considered
Currently we do the same thing as described above but we manunally make multiple instances of a module and use 1/3, 2/3, 3/3 distribution logic to distribute the load and then on the output side we use a frame Muxer and arrnage the frames... this becomes too clumsy to maintain and every needs to know the correct steps.

Additional context
We should think of ModulePool as a class which offers the same interface as Module, but internally makes use of multiple instances of Module. While making the pool we pass XYZProps, and an initial and max pool size. Internally it instantiates the Module instances using the same props. Like wise it forwards init(), term(), setProp() etc... to the internal instances.

Another idea is to make the pool start with an initial size and make it grow if all internal queues get full. The growthe should be limited to max pool size