@taveuni , hi
Sorry for "My bad is English" and the translation, so i might missed many stuff.
But i did few projects with security cameras and recording/handling images software, and want to points few things that can be problem for you to face:
1) The most important thing is to have small code to test the limit of decoding, this code should be portable and included within the software, i mean yes you have hardware (GPU) decoding but there is limit of how many streams can be decoded concurrently, GPU tend to throttle instantly.
2) Crucial thing to do is to not allow or implement any sort of inter-threads communication, i mean 0 interaction between threads them selves or with the main threads, this make no sense at first but will i will explain it further down.
3) the drawing form the main thread should not perform more than fixed frame per second, and definitely should not wait on the background decoding threads, and will not have (or wait for) any notification from them.
4) logging should be lock free.
Now to some details :
GPU decoding can be overwhelmed easily and will stop/slow for each and every stream, so should be throttled, hence the test and benchmark, also after feeding the stream and when you want to decode to different one, make sure to flush the stop decoding for the ones that is not needed, if the application is to save the encoded streams then let them continue to just save only.
The decoding threads will have the decoded images in a ring buffer, lock free would be perfect but any will do, and will not perform any notify for that matter, just drop the image in bucket or list or whatever....
Drawing from the main thread should be happen with a timer, simple as that, remove the images from the buffers then draw then recycle, try to recycle (cache) these Bitmaps, again with lock free list.
That timer must not be more frequent than the Hz of the monitor and the FPS from these streams.
Mainthread will draw/render all the images, if there were new images or not, it will just consume what in the filled buffer from each decoding threads.
Your decoding
DLL might provide two method of decoding synchronous and/or asynchronous, use the synchronous (blocking) one.
As a rule of thumb stay away from sending/posting messages, the interthread communication should be limited to go and stop, and may be , i say be a counter for decoded images, and that is it.
After building that you can go fancy and add features, like watermarks special editing, motion detection ...
Hope that helps.