На ffmpeg относительно не сложно насколько помню. Времени сейчас на эту либу просто не хватает. Более того текущая реализация как то синхронизирована, нужно понять насколько хорошо, есть ощущения что могут быть пробои в логике.

Оговариваем персонально с разработчиком. Это партами, можем договориться на цена\час или после оценки того что есть, на какой то бюджет.

Спасибо за коментарий. Реализуем свою библиотеку для записи видео с экрана. Которая разделена условно на две части. Сам съем(звук с микрофона, картинка с экрана) и запись этого в файл выбранный пользователем(mp4, gif).

Для windows сейчас реализован съем картинки, различными способами. Запись в файл происходит через ffmpeg, точно знаю что есть проблемы синхронизации звука и картинки.

На первом этапе, нужно
1. Синхронизировать картинку и звук
2. Оптимизировать работу
3. Проверить на deadlock старт\остановка записи (в приложении несколько потоков, могут быть проблемы с синхронизацией).
4. Убедиться в корректности записываемых данных в файл

На следующих этапах, нужно будет адаптировать под другие ос, сам съем картинки и возможно звука. Сейчас сделано через Qt
Так же нужно будет добавить съем изображения с камеры, возможно переключение экрана на камеру.

Необходим разработчик который сможет доделать библиотеку по записи видео. Стек C++ + Qt + ffmpeg

На первом этапе доделать по windows
На втором под мак
На третьем под linux

Спасибо, поправил.

Если я верно понимаю как работает TCP. То в корне неверно с одной стороны слать 1000 байт, с другой всегда забирать 1000 байт. Пакеты могут быть разбиты. Отсюда нужен протокол. Отправляем пакет, в заголовке пишем размер пакета. На принимающей стороне, должны вычитать данные размером с пакет, после этого все что читается, идет в следующий. Такое заметили не только на tcp, но и на протоколах поверх tcp типа sctp которые якобы гарантируют доставку. Все они могут разбить ваш пакет. Если не путаю бьет размером с MTU, но на это лучше не закладываться.

Qml и есть формоклепание :-)

Если для себя тогда дерзайте, удачи вам в этом не легком деле. Но я бы предложил посмотреть в сторону готовых решений типа keras, и т.д

ТС, у тебя задача какая? Побаловаться с нейронками или что то в прод. сделать?

Судя по коду имеет смысл почитать про треды для начала )))) У вас тут не будет "параллельной" работы.

1. 10000 потоков создать можно, но из за конкуренции между ними, работать быстрее не станет. Кол-во потоков выставляй кол-ву ядер процессора, в этом случае будет прирост, дальше либо без прироста скорости либо тормоза.
2. Можешь выносить вычисления по нейрону в QtConcurrent например, он возьмет поток из готового пула и отдаст ему расчет, создавай по QtConcurrent на вычисление. Когда все QtConcurrent завершились переходишь к следующему слою. В этом случае у тебя часть нейронов будут считаться в одном потоке, часть в другом и т.д. Не больше тредов чем кол-во ядер, насколько помню.
3. На CPU считать нейросети крайне затратная вещь. Не предназначен он для этого. Если это баловство с сетками или задача в универе, тогда вопросов нет. Иначе подрубай GPU для расчета.

Верно, составлял hr


редко тут бываю, уже не обращаю внимание на это, спасибо, уберу.

Если внутри проекта(либы) только интерфейс, то что находится внутри библиотеки? :-) По идее внутри либы как раз и лежит реализация, а тут ее как таковой нет судя по всему. В этом случае по идее нет смысла выносить это в библиотеку, сделайте папку с .h файлами и инклудьте их где нужно. Если все верно понял.

ага, опечатался.