Имеются две камеры. Нужно выводить изображение на экран с одной из них, и одновременно с этим по нажатию кнопки писать видео с обеих камер в два файла.

    

Но потоки работают неодинаково по времени, и, соответственно, в записанных видеофайлах получается разное число кадров, а синхронность крайне важна. В одном потоке весь код реализовать не получится, т.к. превью будет тормозить, нужно распараллеливать. Можно ли как-то синхронизовать потоки без потери быстродействия? Или вообще лучше делать совершенно по-другому?

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

Псевдокод:


Это сообщение отредактировал(а) borisbn - 11.1.2011, 17:24

При таком раскладе частота кадров отрисовки недостаточна. Нужно как-то аккуратно развести процесс записи в два файла по потокам без существенной потери частоты отрисовки.

Ну, тогда так:

Псевдокод:


Но что-то не верится, что в первом варианте не хватит производительности. У тебя КПК что ли ? Или ЦП уже и так загружен на 100% ? Какая нужна частота кадров ? У меня была схожая задача на камерах AXIS. Отрисовывалось так, что глазу было приятно и писалось с 8-ми камер, при этом загрузка ЦП была 20-30%.


Прикинул или проверил ?

ЦП загружен несильно, около 30%. Частота кадров - 25 кадров/с. Но один цикл потока выполняется слишком долго, соответственно частота обработанных и показанных кадров от того снижается. Используя только одну камеру запись в файл + показ видео работает адекватно, но стоит добавить в этот же поток обработку кадра со второй камеры, время работы цикла увеличивается, и частота кадров снижается.

Сейчас попробую по второму алгоритму, спасибо.

Циклы в потоках 2, 3 вновь выполняются разное количество времени, в результате в один файл записывается больше кадров, чем во второй.

Немного видоизменил алгоритм, теперь частота кадров в норме, потерь кадров нет, всё синхронно, но производительность поднялась до 50%. С учетом того, что программа в дальнейшем будет работать в системе с гораздо менее производительным процессором, немного настораживает.



Это сообщение отредактировал(а) bra1ss - 14.1.2011, 11:47

неудивительно. запуск потока в windows'е очень затратная операция. 

А вот это не понятно, потому, что по логике, если sendToWrite( X ) вызвался 1000 раз, то и waitForDataToWrite потока X вызвался 1000 раз, и, соответственно, writeToFile потока X вызвался 1000 раз.
IMHO, если сделаешь всё в точности, как в этом алгоритме ( в моём 2-м ), то всё должно работать как надо

Реализовал следующим образом:



С сихронностью проблем теперь нет, но процессор это особенно не разгрузило, те же 50%. Видимо, проблема в реализации функции appendFrame.

у меня сразу было такое подозрение 

и ты ж не забываешь обращаться к stl-спискам (v1, v2) через критические секции ?

На время пришлось отойти от проекта, теперь снова вернулся к нему. С синхронностью проблем действительно нет, но проблема в другом: почему-то в записанных видеофайлах наблюдаются "проскоки" и зависания изображения на несколько кадров, на превью при этом все в порядке. Опытным путем установлено, что функция appendFrame вместо обычных 10-15 секунд, иногда может выполниться 200-300. Именно поэтому я её и вывел из критической секции в потоке 2. Все кадры из потока 1 последовательно должны добавляться в stl-очередь vect1 (на превью всё в порядке, плавное изображение), и по идее также последовательно оттуда должны в потоке 2 забираться и обрабатываться дальше уже сколько угодно времени, но потерь происходить не должно. А в реале получается, что на превью идут кадры: 1, 2, 3, 4, 5, 6, 7, 8. А в записанном файле получается что-то вроде: 1, 2, 6, 6, 6, 7, 8.





Это сообщение отредактировал(а) bra1ss - 3.2.2011, 09:49

bra1ss, ты показал код только превью, хотя

покажи как пишутся файлы