Jump to content
Калькуляторы

Битрейт IP камер Расчет количества камер/кадров/нагрузки канала

День добрый.

 

Не однократно поднимался вопрос о том какую полосу канала надо закладывать под систему видео-наблюдения.

Собственно в картинке мой способ подсчета. Шпаргалка.

 

Как считать:

1280x1024=1310720 бит

1310720/1024 = 1280 Кбит

1280/1024= 1.25 Мбит (приблизительно 1.3 Mpix)

1.3x25= 32.5 Мбит/сек/25кадров

 

Соответственно будет легко подсчитать какой битрейт выдаст поток из 3,6,12 кадров в секунду.

 

Все данные приблизительны +- 5-10%

post-53733-007883200 1363581436_thumb.jpg

Edited by p9160ff

Share this post


Link to post
Share on other sites

а как зависит битрейт от количества опорных кадров у h264?

Share this post


Link to post
Share on other sites

к примеру :

разрешение - 1280х1024

кодек - h264

кадров в секунду :

1 - поток 0,2 Mbps - скорость записи на диск - 0,0025 Мегабайт/сек

3 - поток 0,6 Mbps - скорость записи на диск - 0,075 Мегабайт/сек

6 - поток 1,2 Mbps - скорость записи на диск - 0,15 Мегабайт/сек

12 - поток 2,4 Mbps - скорость записи на диск - 0,3 Мегабайт/сек

25 - поток 5,0 Mbps - скорость записи на диск - 0,625 Мегабайт/сек

 

К примеру 40 камер при 25 кадрах и упаковке H.264 создадут поток к серверу 200 Mbit/s - соответственно скорость записи на хард будет 25 Мегабайт/сек.

 

Я про опорные кадры ничего не говорил, это немного другая история.

Share this post


Link to post
Share on other sites

смысл 264 как раз в опорных кадрах или у меня неправильная информация?

Share this post


Link to post
Share on other sites

смысл 264 как раз в опорных кадрах или у меня неправильная информация?

точнее не бывает

Share this post


Link to post
Share on other sites

Кстати, интересно. Кто-нибудь сейчас делает камеры с intra-refresh, т.е. без опорных кадров с равномерным битрейтом?

Share this post


Link to post
Share on other sites

Простите, подниму старую тему, т.к у меня получаются немного иные показатели по потокам. в соответствии с ТЗ заказчика мы имеем цветное изображение с камеры 1920х1080 при 30 кадрах в секунду и два потока: MJPEG на запись и h264 просмотр. с записью звука

Методика моего расчета:

умножаем разрешение на глубину 1920х1080х24=49766400

далее делим на 8 49766400/8=6220800

делим на 1024 6220800/1024=6075, т.е получили размер 1го фрейма в кбайтах без сжатия

теперь компресия

mjpeg жмет в 15,4 раза = 394,4 кбайт

h264 "жмет с учетом опорных кадров" в 74,9 раза = 81,1 кбайт

перемножаем данные на фпс

mjpeg = 11,8 мбит/с

h264 = 2,4 мбит/с

суммируя и прибавляя звуковой поток получаем 15 мбит/с

накинул с запасом 20% на "служебный" трафик, по итогу имеем расчетный поток с 1 камеры 18 мбит/с, реальный будет еще меньше. т.к в расчетах не учтены сложность плана и количество движения на камере.

Правильно ли я посчитал? все ли учел, ибо это ниразу не мой профиль. Потому как ребята специализирующиеся на видеонаблюдении насчитали нам 45 мбит/с с 1 камеры. А камер, на минуточку, порядка сотни. представьте суммарную нагрузку на канал в сторону ЦХД. Мне необходимо соблюсти ТЗ не выпадая за рамки рельности.

Edited by rusinsmile

Share this post


Link to post
Share on other sites

А зачем писать MJPEG?

МВД требует?

 

И откуда взялась цифра mjpeg жмет в 15,4 раза = 394,4 кбайт?

Из даташита камеры или из головы?

Share this post


Link to post
Share on other sites

Степень сжатия H.264 оценить очень сложно...точная оценка только "сверху" и это mjpeg (11 мбит/с средний поток с HickVision был). 45 мбит/с с камеры - бред. Такой поток возможен несолько секунд, но ради нескольких секунд вливать бабло в инфраструктуру сети неразумно.

У крупных вендоров для H.264 есть калькуляторы расчета, там всегда указывается тип сцены (или %времени, когда есть движения в кадре...величина крайне непонятная) и уровень кодека (как раз кол-во опорных кадров). Лучше пользоваться ими...ну или калькуляторами ПО Intellect и Milestone.

Поток в 2,4 мбит/с для H.264 - цифра не очень понятная...в моей практике H.264 и 8 мбит/с выдавал на раз на некторых объектах...2,4 мбит/с + звук - это 15 мбит/с?! Что ж за звук такой?

 

P.S. Цифру в 15,9 сжатия Mjpeg я видел у Aviglion в документации к их камерам. Это максимальный коэффициент сжатия, при котором искажения еще не очень заметны. Опять же формулировка расплывчата, но каких-то четких критериев качества видео я вообще не встречал...если вы знаете, поделитесь:)

Edited by Cheshire

Share this post


Link to post
Share on other sites

Cheshire, да понятно, калькуляторы гуглятся отлично) но, для полноты картины хочется еще и понимать как оно считается. Неужели от производителя будет сильно зависеть итоговый объем данных передаваемых с камеры, при прочих равных настройках конечно же? И я правильно понимаю что "стадартом" является переменный битрейт?

Share this post


Link to post
Share on other sites

От производителя камер (точнее, от чипсета) будет зависить битрейт и MJPEG и H.264

Уточните модель камеры, тогда что-то можно будет посоветовать

Share this post


Link to post
Share on other sites

Ну в даташите до 10 Мбит/с на поток.

Так что 20 Мбит/с на камеру (с учетом двух потоков)

Похоже, она то ли не умеет 25 к\с MJPEG то ли сильно пережимает поток, так что возможны артефакты

Share this post


Link to post
Share on other sites

Невнимательно прочитал. Не увидел, что 2 потока отправляете. Прошу прощения. Но 45 мбит/с цифра явно завышенная.

 

10 мбит/с - цифра реальная вполне при 25 к/с и с хорошим качеством, если JPeG2000 используется, согласитесь?

Edited by Cheshire

Share this post


Link to post
Share on other sites

К сожалению граница на которой видеозапись не годится для доказательной базы в суде мне не известна. Обладаю этой информацией вопроса бы не возникло. Судя по даташиту к камере Data Rate 9.6 kbps to 10 Mbps (per stream) и вот тут получается что это 10 мегабайт. судя по всему не сжатых либо с минимальным сжатием. А если это переводить в мбиты, то получается 80мбит/с с одного потока. Коэффициэнты сжатия указаны в моем первом посте... Короче это все теория получается. Обнаружить бы где нибудь испытания зависимости искажений от степени сжатия. Для себя решил, применительно к моему случаю использовать коэффициент 7. как усредненное значение. Хоя разницу между MBps и Mbps я понимаю, но что имел ввиду производитель, не ясно.

Edited by rusinsmile

Share this post


Link to post
Share on other sites

В Datasheet максимум 10 Мбит/с на поток.

А камеру на тестироване нет возможности взять? Это был бы оптимальный вариант.

Mbps - это Мбит/с

Edited by Cheshire

Share this post


Link to post
Share on other sites

не понимаю зачем что-то считать? во всех камерах которые я помню, есть установка битрейта, я ставлю 4 мегабита и столько камера и выдает

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Честно я ваще не понимаю смысла темы... как что считалось и зачем она.. укаждого производителя камер по разному жмется один и тот же когдек.. H 264 имеет три профиля, которые по разному жмут так же.. о чем тема? пофлудить али как?

Топик стартер

1280x1024=1310720 бит

Это как так?

может быть пикселей? а пиксель у нас бит? попрошу закрыть тему.. она ни о чем

Share this post


Link to post
Share on other sites

а как считать тогда правильно? Какой ширины канал требует 2мегапиксельная камера / 25к/с. для максимально качественного раскрытия картинки так сказать?

Как оптимизировать входящий поток на камеру, который тоже не мало набегает (на случай платного входящего трафика)?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this