Помогите рассчитать минимальную ширину канала.

[Pet]

Всем привет!

Прошу помочь в следующем:
Есть центральный офис и есть удаленный филиал, связанные между собой IPVPN, с гарантированной пропускной способностью в 1Мб/с.

Требуется в филиале установить IP камеру. Требования к качеству картинки:
Мин. разрешение: 640:480, 25 Fps.

Вопрос: хватит ли существующего канала, для удовлетворения этой потребности?

Мои расчеты таковы:

640*480(разрешение)*8 (бит.градации серого)*25 (кол-во кадров в секунду)*3 (цветное изображение)= 184 320 000 бит /8= 23 040 000 байт / 1024= 22 500 кбайт.сек /1024=21.98 мб.сек

21.98 мб.сек – это скорость потока от матрицы до процессора камеры."

Ниже считаем скорость потока для сети.
1500(MTU)/1500-192 (служебная информация до 192 бит)=1.15 (служебная информация TCP пакета)* 21.98 = 25.277 мб.сек

25.277 мб.сек - скорость потока без применения кодеков.

Если использовать кодек H.264, то можно сжать трафик на 50 - 90%.
Следовательно, необходимая ширина канала - 2,5 - 12,5 Мб/с.

Правильно ли посчитал?

Заранее спасибо!

[Plague]

развиваем мысль, и считаем тоже самое, но для фильма в таком случае, т.е. умножаем ещё и на 7200 (секунд в 2 час) = 154,5 Гб -тут все верно для uncompressed

Сообщение от Pet

H.264, то можно сжать трафик на 50 - 90%.

= 77-16ГБ - Вы где инфу о этих процентах взяли-то?
Вы хоть один фильм видели с разрешением 640х480 и таким адским объёмом?


1-1,5 Мбит/с (128-192 кБ/с) - съедает просмотр фильма с онлайн-сервиса (ivi.ru) в хорошем качестве.

[Pet]

Plague, спасибо за ответ! )

Видимо кодек намного эффективней сжимает видео. Прошу прощения, если задал ламерский вопрос. )

[Plague]

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

С онлайн-камерами/трансляциями, если и есть отличия, то не глубоко принципиальные.

[Borland]

В ту же тему: сетевая камера 3/4 соединения съедает.
Там экспериментально получен поток ~1,5Mbit/s для 30fps@640x480x8bit в MJPEG.
А вообще говоря - такая характеристика как скорость видеопотока с IP-камеры должна бы быть отражена в документации на неё...

[Pet]

Хорошо, спасибо за ответы.
А можете подсказать какой коэффицент сжатия у кодека H.264? И как расчитать примерный поток создаваемый камерой.

[Plague]

По-моему, Вы ставите лошадь позади телеги.

Кодеку задается результирующий битрейт (и, опционально, более тонкие настройки, касающиеся обработки блоков кадра, векторов движения, итд).
Соответственно, какой ему битрейт задан, столько он и будет держать, утаптывая поток не выше этих рамок.
С другой стороны, если видеоряд представляет собой медленно ползущую улитку на ровном фоне да еще и в затемненном помещении - вам для передачи такого за глаза хватит скорости антикварного dial-up модема конца 80х; если же в кадре большое количество деталей да еще и с высокой динамикой перемещения - даже БлюРея с его стандартами может не хватить (попадалось и такое).

В настройках камеры так же опора в первую очередь даётся на битрейт.

Чисто для информации: стандарт максимального битрейта для DVD - 9,8Mbit (это вместе со всеми треками звуков и титров, чисто для видео потолок 8)
для BluRay (тоже, максимум) - 40.0Mbit (для видео) и 54Mbit (со всей клюквой).
Отсель и делайте выводы о качестве картинки.

Калькуляторами и коэффициентами никогда не интересовался, ибо я практик, а не теоретик; да и сомневаюсь что они вообще существуют, по причинам описанным выше. Хотя если кто нароет - тож почитаю

[Pet]

Благодарю еще раз за ответы!
Решили покупать камеру и ставить ее в одном из объектов для тестов. Если интересно - отпишусь о результатах тестирования.