а ничего что в системе в основном тысячи потоков. и как то они работают.
или давайте вспомним одноядерные процессоры.
там как то работал WinAmp и Internet Excplorer и еще система не тормозила.
Хотя часто "осел" забирал почти все ресурсы, звук при этом не останавливался.
это все так...
главное! в любом случае, 6 или 12 физ. ядер, процесс не должен замедлятся!
перебьется система)) а если серьезно, то ресурсы делятся в зависимости от потребностей потока.
у меня проц. Intel Core i7-8700.
какой будет на сервере не знаю.
инициализирующий поток не нагружает ни проц, ни диск, ничего. во всяком случае на графиках этого не видно (до 1 процента).
диск используется примерно на 30% во время работы.
основная нагрузка идет на процессор, там идет сравнение кадров видео с фото экрана. ресурсоемкая задача.
"все в ОЗУ" - это хорошо если видео не большое. но вообще, никаких ограничений на длину видео быть не должно.
да, opencv использует ffmpeg.
в первой версии с одним потоком загружалось только одно ядро.
сейчас каждый поток выбирает себе ядро функцией pthread_setaffinity_np.
в итоге загружены все ядра.
да и фэйлов нету, все работает нормально, только в 10 раз медленнее...
так что проблема явно в другом.
работать должна на выделенном сервере. там не будет мощной видео карты.
OpenCV справляется нормально, непонятно почему при увеличении количества потоков падает производительность.
мютексы не используются, видео доступно на чтение всем потокам во время работы.
может сама система ставит что-то вроде мютексов во время много поточного чтения файла или Qt выделывается?
или давайте вспомним одноядерные процессоры.
там как то работал WinAmp и Internet Excplorer и еще система не тормозила.
Хотя часто "осел" забирал почти все ресурсы, звук при этом не останавливался.
это все так...
главное! в любом случае, 6 или 12 физ. ядер, процесс не должен замедлятся!