Russian Qt Forum

есть объек класса QPixmap с размерами (2500,2000), на котором я рисую какие-то кракозябры с высокой частотой(50-60 fps),потом этот объект я сохраняю в буфер (buffer->open(QIODevice::WriteOnly);pixmap->save(buffer, "PNG");).Частота сохранения изображения в буфеп порядка 1 fps. Как мне ускорить этот процесс?(картинка рисуется на сервера и передается клиентом чрес сокет).

2500*2000*4 это 2*10^6 байт. Вполне помоему нормальная скорость записи (да я знаю про lossless сжатие).

На мой взгляд вы пытаетесь заново изобрести аналог X11 или RDP.

Тоесть это вполне нормально?Просто от меня требуют чтобы частота соранения была тоже порядка 50 раз в секунду, я подумал, может я че не так делаю.Может использовать другой формат?

Ну посмотрите как реализованы X Windows System и RDP, там идет передача не изображений, а команд соответственно X11 и GDI. Правда все равно 50 fps... К чему такие сложности, зачем вообще нужно создавать проблемы с передачей изображений по сети и затем с ними бороться?

Я например не понял такой момент. По сокету передается несжатый QPixmap, затем сервер его его пожимает в PNG?
Если так, то выход я вижу в следующем:
- на сервер передается размер картинки и её параметры
- вместо того, чтобы передавать картинку целиком - на сервер передаются команды рисования мышкой. Кликнул по какому-то пикселю - через сокет передался индекс пикселя и цвет. Можно сделать небольшой буффер, который будет отправляться после того как заполнится необходимым количеством действий.
Если не хочется нагружать сервер, то передавать только QRect измененной области (как diff в svn/cvs/git), предварительно пожав его через qCompress.

qCompress достаточно медленно работает.

Мне надо передавать именно картинку, большого размера, с частотой 50 раз в секунду.

не знаю на сколько это будет производительно,
но что если насобирать 50 картинок и потом раз в секунду их отсылать,
а уже на стороне клиент их показывать по очереди.

/*думает что скоро обсуждение дойдет до кодирования видеопотока*/

+1  ;D

можно и так, но вся проблема на данном этапе заключается именно в том, что при сохранении картинки проходит много времени( 1 секунда), думаю если в секунду сохранять 50 картинок, то этот интервал увеличится )))и толку не будет.

Тяжело мне, да и, возможно, не только мне, давать советы не зная контекста использования. Может быть вы нам расскажете немного об использовании.

А где можно увидеть полный код получения\сохранения\передачи изображения?

пробуй уменьшать качество.

А можно подробней о предназначении программы?

А что qCompress будет все-равно медленным, если степень сжатия поставить 1?

а толку от него, если png уже пожат?

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

ааа, ну тогда есть смысл конечно. не понял сначала.  :)

А вообще 60 картинок (fps) размером 2500x2000 это даже самый оптимизированный видео-кодек быстро не сожмет. Конечно на скорость будет влиять количество разнообразия пикселей. Если создать белую картинку с одним черным пикселем в центре, то операция будет достаточно быстрой. Но когда 10 человек начнут рисовать что-то свое на таком здоровом поле, то скорость упадет очень быстро.

Формат изображения не обязательно PNG. Размер сегодня уменьшили до  1600*1200.И как вы считаете, если применять методы bits,scanLineбьуьсзн, возможно повысить производительнность?Сейчас важно сгенерированную картинку запихнуть в сокет с частотой 50 fps.'nj сейчас самое слабое место.При сохранении картинки в формате PNG с разрешением 2560*2048 частота была порядка 1 fps, картинку в формате BMP "передавал" в 4-5 раз быстрее.Возможно изменение размера повлияет на частоту, но думаю не в десятки раз.

Я так и не понял предназначения подобной программы. 50 fps человеческий глаз не воспринимает. Оптимально 25-30. А если надо просто видеть как человек линию ведет, то там все 5 fps подойдут, просто видео будет рывками. А к чему такая точность?

Камрад Серега!
Давай определимся, и не будем множить темы на форуме об одном и том же - у тебя уже штук восемь постов по одной конкретной задаче . Давай, если ты не против, сделаем так:
Ты излагаешь здесь свою задачу: а именно - для чего нужна программа, зачем архитектура клиент-сервер, зачем OpenGL, зачем передавать по сети 4-х мегапиксельные картинки с FPS = 50?
Если ты это сделаешь - сразу снимется хренова туча вопросов (libastral, к сожалению, собирается не у всех). И, я уверен, на все твои проблемы найдется хоть один, но дельный совет.
Лично я могу дать совет по использованию OpenGL, передачи данных по сети, и кодированию/декодированию видеопотока, но только в том случае, если задача поставлена нормально.

Не знаю как вам, а мне подобная задача напоминает попытку сделать полноэкранную 3d игру типа Call of Duty, только вся работа с граффикой идет не на видео-карте клиента, а на сервере. Что-то типа thin client для игр.

Прохожу практику на фирме, занимающейся видеонаблюдением.Руководитель, человек неглупый, дал задание: Создать программу, которая сможет отображать КАРТИНКИ размером (уже 1600*1200) с частотой 50 fps ну и в дальнейшем еще и на несольких мониторах разные картинки.Чтобы видеть, что мы картинки в дейцствивельности получаем надо сделать анимацию, например средствами OPenGL, так как это быстро, чтобы получать картинки и не загружать программу их генерацией,можно организовать  клиента и сервера, сервер генерит, клиент получает и отображает.Картинка уже известным рамером отображаем с известной частотой.Теперь что касается необходимости этого "проекта".Возможно в дальнейшем сервр с генерацией будет заменен на поток данных с камер,которые бдут передавать изображения с подобным разрешнием и подобной частотой.

значит все-таки видео поток.

Камеры уже в каком-то формате передают видео-поток. По сути ты пытаешься на Qt написать свой алгоритм сжатия этого видео-потока, вместо того, чтобы заняться поиском кроссплатформенного декодера для потока с камеры и проверить насколько хватает пропускной способности сети и мощности компьютера, чтобы передать какой-нибудь сгенеренный фильм в Sony Vegas с подобной частотой и разрешением.

Какого сжатия? вы о чем? мне надо картинку нарисовать, записать во что-то, это что-то передать, и потом отобразить, все.

Ага картинку... Если быть точнее, то 50 картинок в секунду с разрешением 1600*1200 по сети и видимо, чтобы не лагало и без задержек. А это уже ну никак не картинка, а видео-поток.

У тебя узкое место - нехватка ресурсов компьютера и отсутствие оптимального алгоритма потокового видео. В видео-камерах кодированием потока занимается железка, а не программа, засчет этого поток камера сжимает гораздо быстрее компьютера.

Если действительно ограничиваться рамками нарисовать картинку и передать, то какой смысл вообще за это браться, если это изначально неверный подход, который в итоге приведет к тому о чем тебе уже сказали. Лишняя трата времени. Надо подстраиваться под реальную ситуацию, а не под абстрактную. Или создать искусственные условия.
Поставь в сети VLC сервер настрой мультикастинг, сгенери в Sony Vegas или virtualdub видео поток с фрейм-рейтом 50 фпс и разрешением 1600*1200, затем настрой бесконечную прокрутку этого потока в VLC и поставь кодек, аналогичный тому, что стоит в системе видео-наблюдения. Изучи протокол, по которому идет передача видео-потока и начинай дешифровывать его с помощью средств Qt.

Только, если бы я взялся за это, то изначально потребовал бы за программу энную сумму.

Куда-то все не туда. касеры, видео, суммы.

Нормальный такой поток данных: 1600*1200*3*50 / 2^20 ~ 275 MBytes/sec. Внутри компа такой поток можно гонять довольно просто между CPU/GPU/RAM. Но уже не всякий жесткий диск осилит чтение данных с такой скоростью. По сетке такое гонять далеко не по всякой получится.

Так что надо определиться с задачей. Для видеонаблюдения такой поток какой-то не реальный просто. Но, скажем, создавать картинки с указанной скоростью в одном процессе и отображать в другом процессе на одном и том же компе вполне реально - пример X Window system.

Камрад Серега!
Я сейчас работаю в конторе, которая занимается системами видеонаблюдения, в связи с этим рекомендую узнать у научного руководителя, со скольких мегапиксельных камер он хочет получать поток чтоб 1600х1200 и 50 fps.
По поводу твоей конкретной задачи: для эмулирования видеопотока сеть вообще не нужна, сделай картинку в QImage  и что-нить на ней двигай - этого  достаточно. OpenGL здесь нафиг не нужен - его вообще разумно применять только тогда когда нужен рендеринг трехмерных сцен.

Вообще, если у тя практика не типа не на отъебись - рекмендую книгу Яна Ричардсона, при желании, найдешь в djvu, ну или, на озоне купи.

Как раз мне это надо, мне и самому как-то интересно ) молодой развивающийся )))Спасибо.Проект пока приостановлен в связи с дипломной работой, но тема отнюдь не закрыта, временный перерыв.а там углУбимся и расширимся )))Пока всем спасибо за поддержку ОГРОМНОЕ ))) ;)