"However in Version 6.1, when I encode one stream the CPU approximately takes 10% of the CPU. When I encode two streams (each with its own instance of UMC encoder), the CPU is 99%."
since 10% CPU is enough for the one stream, I suppose you do not need to use internal OpenMP threading in UMC encoder. Is it true?
This is possibly a problem related to the application level. How are the two encoders are the application? Is there waiting()/sleep() API or other threading synchronization API used.
To disable the OMP threaded in the Codec, you can check at the \audio-video-codecs\Makefile file, and remove the following:
CFLAGS += -openmp
CFLAGS += -fopenmp
Setting KMP_BLOCKTIME is not to disable the OpenMP threading, that is because some known problem discussed here:
Also you need to link with non threaded static libraries.
If you disable the OpenMP threading, it does not need to set the KMP_BLOCKTIME environment.
It is not clear that how each thread is calling the H.264 encoder, For each threading, are they just calling Getframe() function, no blocking or waiting at somewhere? If this is true, it looks each is trying to do encoding all the time, surely it will consume all of the CPU.
For the question, "But with dynamic libraries I am fine so far. Any particular reason you had wanted to link static libraries?"
Many functions in the dynamic libraries are internally threaded with OpenMP functions; you can check the threaded function list at: \docThreadedFunctionsList.txt. To use the static non-threaded library will help to avoid the enable the internal threaded with your application. ( It looks that you have implemented the high level thread at your application).
Thanks for sharing the experience here.
For those who also want to using dynamic IPP libraries in case, it can call ippSetNumThreads() in the application to disable the internal threading in the IPP function.