передача нескольких изображений по сети

← →
night_light © (2010-06-23 10:20) [0]

необходимо передвать изображения с нескольких видеокамер (плата видеозахвата) на другой компьютер по сети,
пересылаю последовательность JPEG-сжатий кадров,
использую компоненты TClientSocket, TServerSocket,
вижу два варианта их использования:
1) на каждый канал (одну камеру) завести своё сокетное соединение;
2) сокетное соединение одно, кадры передаются циклически.
Подскажите, пожалуйста, как правильней организовать передачу кадров? Как получиться быстрее, меньше задержки при передаче? Как такие задачи обычно решают? Делаю такое впервые, поэтому слегка не в теме.

← →
Сергей М. © (2010-06-23 10:28) [1]

> Как получиться быстрее, меньше задержки при передаче?

1. Отказаться от TCP в пользу UDP.
2. Передавать поток сжатых опорных кадров, сопровождаемых сжатыми дельтами, а не поток всех подряд сжатых полных кадров.

← →
night_light © (2010-06-23 10:50) [2]

спасибо за ответ!
1) про UDP уже думал, тем более, что возможна передача одной и той же информации двум приёмникам, но останавливает сложность обработки принимаемой информации, т.к. в UDP, насколько я понял, пакеты могут прихоть в порядке, отличном от того, который необходим для построения передаваемого файла, также не гарантируется передача, а потеря пакета для JPEG означает потерю кадра, поэтому из принципа "от простого к сложному" решено ПОКА ограничиться TCP;
2) интересная мысль, но пока до реализации дело не дошло из того же принципа.
Хотелось бы понять, если всё таки TCP, то какой из приведённых мною в вопросе вариантов предпочтительнее?

← →
Сергей М. © (2010-06-23 11:08) [3]

> возможна передача одной и той же информации двум приёмникам

Тем более : UDP + IGMP

Правда, для работы в межсетевой среде IGMP не годится, но зато ощутимо упрощается реализация передающей стороны.

> потеря пакета для JPEG означает потерю кадра

Именно поэтому поток дельт "разбавляют" опорными кадрами.

> если всё таки TCP, то какой из приведённых мною в вопросе
> вариантов предпочтительнее?

Фиолетово.
Выигрываешь в ресурсах (меньшее кол-во сокетных соединений) - проигрываешь в сложности реализации. И наоборот.
И в том и в другом варианте узкое место - сам TCP.
К тому же во втором варианте потеря соединения будет означать потерю потоков всех камер сразу.

← →
night_light © (2010-06-24 09:39) [4]

ещё, по поводу дельт,
обнаружил, JPEG-сжатие полезного цветного кадра имеет размер 19 кбайт (сам кадр в формате RGB 24 - 1,3 Мбайт, коэф. сжатия - 50 унылых енотов),
а JPEG-сжатие чистого синего кадра 9 кбайт, экономия не на порядок,
что-то мне подсказывает, что JPEG-сжатие картинки дельт будет не сильно
меньше сжатия самой картинки, или надо действовать как-то иначе?

> night_light ©

Советую не изобретать свой протокол, а воспользоваться уже устоявшимися методами, что позволит хоть смотреть твой видеопоток существующими плейерами/средствами:

1) SnapshotJpeg over HTTP
2) MJPEG over HTTP
3) MJPEG/MPEG4/H264 over RTP over RTSP
4) MJPEG/MPEG4/H264 over RTP over RTSP over HTTP
5) MJPEG/MPEG4/H264 over RTP
6) MMS
7) Всякие там Flash и QuickTime (что вобщем то разновидности 3-5)

3) и 5) допускают UDP, 5) - возможен мультикаст.

Самый простой вариант - 1) или 2)

3-5) весьма сложны и судя по тому что у тебя возник вопрос - тебе не по силам.

> night_light © (24.06.10 09:39) [4]

Я вообще-то ни разу не произнес слово "jpeg".
А уж если ты в него вцепился, то тогда нужен MJPEG (Motion JPEG)

передача нескольких изображений по сети Найти похожие ветки