Для того, что бы определить размер архива или суммарный объем жестких дисков требуемый для хранения архива системы видеонаблюдения первым делом необходимо определится с кодеком сжатия. Именно от него будет зависть размер архива.
Разные кодеки имеют разную степень сжатия информации исходного файла. Основные кодеки применяемые в системах видеонаблюдения: H.264, MJPEG, MPEG4, Motion Wavelet, JPEG2000, MxPEG.
Для того, чтобы определить степень сжатия кодеков вначале расскажу о том как определяется размер несжатого кадра изображения.
Определение размера несжатого кадра
Размер несжатого кадра это произведение ширины и высоты изображения в пикселях умноженное на глубину цвета. Размер кадра не зависит от того, что изображено в кадре, т.е. размер файла без сжатия будет одинаков для любого изображения.
Online калькулятор расчёта архива (ёмкости HDD) системы видеонаблюдения.
С произведением ширины и высоты изображения сложностей не должно возникнуть, для видеокамер с разрешением 704 х 576 получим 405 504 пикселей.
Глубина цвета задаётся количеством битов, используемым для кодирования цвета точки.
Для кодирования черно-белого изображения используется 1 бит (2^1 = 2 цвета), для 16 цветов — 4 бит (2^4 = 16 цветов), для 256 цветов – 8 бит (2^8 = 256 цветов), для 16 миллионов цветов — 24 бита (2^8 = 256 различных вариантов представления цвета для каждого канала (256×256×256=16 777 216 цветов).
Современные IP видеокамеры отображают изображение с глубиной 24 бита.
Таким образом, получаем следующий размер несжатого изображения 405 504 х 24 = 9 732 096 бита.
- 1 байт = 8 бит, тогда получаем 9 732 096 / 8 = 1 216 512 байт.
- 1 килобайт = 1024 байта
В итоге получаем, что наше изображение в разрешении 704х576 пикселей в несжатом виде весит 1 216 512 / 1024 = 1 188 (тысяча сто восемьдесят восемь) кбайт.
Для закрепления, размер изображения из 16 цветов будет весить – 704 х 576 х 4 / 8 / 1024 = 198кбайт.
Определение размера сжатого кадра
Размер будет зависеть от типа используемого кодека. Кодеки можно поделить на два типа:
- Покадровые — выполняющие сжатие каждого кадра (MJPEG, JPEG2000);
2. Межкадровые — выполняющие сжатие последовательности изображений (H.264, MPEG4, Motion Wavelet, MxPEG)
Преимущества покадровых перед межкадровыми кодеками заключается в том, что дают четкие кадры без артефактов и предсказательной логики. Любой момент можно четко рассмотреть. Нет зависимости от ключевых кадров.
Преимущества межкадровых – меньший размер кадра, соответственно уменьшение необходимой пропускной способности канала.
MJPEG и JPEG2000
Недостатками MJPEG являются более низкий коэффициент сжатия по сравнению с кодеками выполняющими сжатие последовательности изображений (H.264, MPEG4, Motion Wavelet, MxPEG) и блочная структура данных (дробление изображения на квадраты 8х8 пикселей ).
Преимуществом, относительно (H.264, MPEG4) является, то, что даёт качественные стоп-кадры, позволяющие с большей вероятностью, например выяснить номер проехавшего автомобиля.
Преимущества JPEG2000 перед MJPEG:
1. Изображения, при высоких степенях сжатия не содержат артефактов в виде “решётки” из блоков размером 8х8 пикселей.
2. Обеспечивает как сжатие с потерями, так и сжатие без потерь в кодек. Сжатие без потерь обеспечивается путем использования обратимого (целочисленного) вейвлет-преобразования;
3. Обеспечивает эффективную организацию кодового потока, которая позволяет просматривать файл с меньшей разрешающей способностью или с меньшим качеством.
Размер кадра в MJPEG и JPEG2000
Размера кадра взят из программы из on-line калькуляторов от Avigilon (максимально качество) и Axis (минимальное сжатие, камера AXIS Q6035-E, сцена Stairway (максимальный размер кадра))
В калькуляторе Axis есть возможность посмотреть пример получаемого изображения.
MxPEG
По мнению производителя (Mobotix) данный кодек, позволяет получить изображение с качеством характерным для покадровых кодеков и размером кадра (при малой интенсивности движения) в кадре близким к межкадровым.
Алгоритм проще чем у H.264, соответственно ресурсов требуется меньше. Проще тем, что не пытается предсказывать содержимое опорных кадров (видно на рис.1)
Размер кадра в MxPEG
Таблица 1. Все настройки по максимуму (качество – 90%, заполненность изображения – высокая, процент движения – очень высокий)
Таблица 2. Все настройки по максимуму, кроме заполненности изображения движения (качество – 90%, заполненность изображения – средняя, процент движения – очень высокий)
Размер кадра взяты из калькулятора от Mobotix.
Из таблиц можно сделать вывод, что данный кодек надо применять с осторожностью, если вы знаете, что часть кадра будет занимать неподвижная стена вдоль которой движение будет отсутствовать или большую часть времени изменений в кадре не предвидится, то тогда на размере архива можно сэкономить, главное не забывать про изменяющийся объем передаваемых данных и с учетом этого рассчитывать канал передачи данных.
H.264 и MPEG4
За счет мощных математических вычислений, требует больших объемов вычислений, чем другие кодеки. Как следствие устройства, обрабатывающие потоки H.264 должны обладать высокой производительностью.
Второй нюанс, аналогичен MxPEG – сложное прогнозирование потока H.264. Благодаря таким особенностям кодирования, как сохранение в последующем кадре только изменений предыдущего, объем передаваемых данных зависит от снимаемого изображения и может меняться.
Размер кадра в H.264
Размера кадра взят из программы IP Video System Design Tool (все настройки максимальные).
Видим, что степень сжатия на много превышает таковую в MxPEG. При необходимости получения архива большой глубины за меньшие средства, данный кодек является оптимальным вариантом.
Недостаток заключается в том, что за счет использования предсказательной логики, собственно и позволяющей так уменьшить средний размер кадра, не все кадры могут быть пригодными, например для индетификации.
Motion Wavelet
Данный кодек с 2005 года использует компания “ITV” в программном обеспечении “Интеллект”.
Размер кадра (разрешение 704х576) в максимальном качестве при максимальная интенсивности – 73 кБайт, высокой – 27, средней – 19. Степень сжатия соответственно – 16,2; 44; 62,5.
Расчет архива
Расчет сводится к определению размер кадра изображения, темпа записи на каждую камеру (количество кадров в секунду), необходимое количество часов записи в сутки, количество видеокамер устанавливаемых на объекте и необходимое количество суток записи.
Ориентировочный размер кадра в лучшем качестве для приведенных кодеков для любого разрешения определяем путем определения размера несжатого кадра в необходимом разрешении, после чего делим полученное изображение на степень сжатия для данного кодека.
Зная приведенные выше параметры можем рассчитать необходимую емкость жестких дисков.
Итак, по порядку:
- Определяем требуемое место на жестком диске для записи одной видеокамеры в течении 1 часа (строка 5, см таблицу ), для этого перемножаем объем 1 кадра изображения (строка 1) на количество кадров в час (строка 4);
- Определяем требуемый объем для записи одной видеокамеры в течении 1 суток (7 строка) для этого нам необходимо знать — требуемое место на жестком диске для записи одной видеокамеры в течении 1 часа (5 строка), количество часов записи в сутки (6 строка, есть смысл записывать информацию с камеры видеонаблюдения установленной, например, в магазине в рабочее время постоянно, ночью только в случае тревоги, соответственно в расчет емкости жесткого диска нет смысла вставлять 24 часа);
- Определяем требуемый объем жестких дисков для записи всех видеокамер в течении необходимого количества суток, умножаем количество суток (строка 10) на требуемый объем для записи всех видеокамер в течении 1 суток (строка 9);
- Для удобства восприятия переводим КБайт в МБайт (строка 12), ГБайт (строка 13), ТБайт (строка 14).
Таблица — Расчет емкости жестких дисков
* синим выделены формулы в соответствии с которыми выполняется расчет, (1) – ссылка на номер строки со значением вставляемым в формулу
Нюанс:
В 12-14 строке значения делятся на 1024, т.е. в одном Гигабайте 1024 мегабайта и т.д., если будете считать объем жесткого диска в калькуляторе программы IP Video System Design Tool, то заметите, что там значения делятся на 1000.
Обосновано, тем, что производители накопителей жестких дисков (HDD) считают килобайт равным 1000 байт, а не 1024, как положено.
В комментариях можно задать вопрос по теме и вам обязательно ответят, а также можно высказать свое мнение или описать свой опыт.
Хочу дополнить Ваше пояснение:
Обосновано, тем, что производители накопителей жестких дисков (HDD) считают килобайт равным 1000 байт, а не 1024, как положено.
В соответствии с международным стандартом МЭК 60027-2 единицы «бит» и «байт» применяют с приставками СИ.
Исторически сложилась такая ситуация, что с наименованием «байт» некорректно (вместо 1000 = 10 в 3-й степени принято 1024 = 2 в 10-й степени) использовали (и используют) приставки СИ: 1 Кбайт = 1024 байт, 1 Мбайт = 1024 Кбайт, 1 Гбайт = 1024 Мбайт и т.д. При этом обозначение Кбайт начинают с прописной буквы в отличие от строчной буквы «к» для обозначения множителя 10 в 3-й степени.
На сайте одного из американских производителей жестких дисков выложено следующая информация:
При указании емкости средств хранения данных 1 мегабайт (МБ) = 1 миллион байтов, 1 гигабайт (ГБ) = 1 миллиард байтов, а 1 терабайт (ТБ) = 1 триллион байтов. Общая полезная емкость накопителя зависит от используемой операционной системы. При указании емкости кэш-памяти 1 мегабайт (МБ) = 1048576 байтов. При указании скорости передачи данных 1 мегабайт в секунду (МБ/с) = 1 миллион байтов в секунду, 1 мегабит в секунду (Мб/с) = 1 миллион битов в секунду, а 1 гигабит в секунду (Гб/с) = 1 миллиард битов в секунду.
Таким образом, данный производитель считает, что при определении емкости HDD, 1 Кбайт=1000 байт, при определении скорости передачи данных 1 Мб/сек=1 000 000 бит в секунду, при определении емкости кэш-памяти 1 Мб=1024х1024=1048576 байт.
Наверное многие пользователи видели, при покупке ноутбука или ПК, что задекларирована например емкость HDD 2Тб, а сама Windows оперирует «двоичными» (в виде степени числа «2») гигабайтами: 1 Гб = 1024 Мб =1048576 Кб. Таким образом, HDD с номиналом по емкости 2Тб, будет восприниматься в операционной системе как ~1,8Тб. Когда речь едет о терабайтах реальная емкость будет меньше задекларированной производителем на 10%.
Полезное дополнение, черт побери. Вечно задумываюсь как правильно писать приставку с заглавной или строчной буквы. Таким образом, 1 Кбайт = 1024 байт (в отличие от 1 кбайт = 1000 байт).
Думаю, логично и правильно загнать в Ваш шаблон 1000 вместо 1024, т.к. жеские диски мы выбираем по номиналам, которые указывает производитель. Либо ввести в расчет повышающий коэффициент конечного результата. В данном случае: (1024*1024*1024)/(1000*1000*1000)=1,07.
Предлагаю дополнить тему: разделом «Количество кадров в секунду на жесткий диск«.
Так как размер информации, передоваемой с IP камер, может быть достаточно большим и превысить скорость записи жесткого диска, необходимо обратить внимание на общий объем данных с IP камер.
Если не брать в расчет Raid и то что данные кэшируются, то чтобы «перегрузить» HDD по пропускной способности надо порядка 86 камер
Данные для расчета
допустим худшее значение записи 30 MB/с (в реальности больше)
Объем 1 кадра изображения в разрешении – 704х576 — 43,6 КБайт
Скорость записи с камеры — 8 кадров/сек
Поток с одной камеры 43,6 КБ*8=348,8 КБ
Количество камер , которые перегрузят HDD =30 *10^6/348.8^3=86
Или я где то не прав?
В шаблоне разрабатываемого калькулятора заменю 1024 на 1000. Раздел — количество кадров в секунду на жесткий диск добавлю.
Согласен с тем, что для IP систем он может оказаться узким местом.
Посмотрел тройку калькуляторов,первая тройка выдачи из яндекса. Их всех объединяет методика подсчета, оно и понятно несжатый кадр коэффициенты и бла бла бла.
Но все они отличаются размерам несжатого кадра, видимо из за разного предполагаемого кол-ва цветов, и как результат разброс идет ого го. В статье указано что все камеры (цветные) вещают в 24 битах (8 на канал) а так ли это? И где бы это прочитать достоверно.
«Для кодирования черно-белого изображения используется 1 бит (2^1 = 2 цвета)» это не совсем корректно. 1 бит это значит что будет 2 цвета. а в изображении есть еще и оттенки серого.
В некоторых интернет-расчетах вообще участвует 12 битный цвет (4 на канал)
Полное цветное 704х576- размер кадра 594 Кб
Со словами «Горшочек вари!» двинулся на викпедию….. запупутался окончательно : )
Зашел на самсунг тех вин, посмотрел паспорта и инструкции на видеокамеры, регистраторы, сетевые видеокодеры — есть все о разрешении, но о цветности ни слова.
Сам себя запутал? )) Или не добрался до истины. Есть еще вариант, написать в саппорт и спросить.Ваши мысли?)
Калькуляторы производители, как правило, пишут под свое оборудование. Влияет не только цветность камеры, но и программное обеспечение. Отсюда и отличия.
Например, платы видеозахвата от ITV и софт «Интеллект» изображение с видеокамер обрабатывает в 16 битном цвете. Про один бит согласен, в изображении будет только два цвета, в видеонаблюдении такое не используется.
Про камеры уточню у поставщиков, если в инете не найду точной информации.
Цитата:
Так как для 16 цветов — 4 бит, то 704 х 576 х 4 / 8 / 1024 = 198 кбайт. Я прав?
Да прав, 8 бит это уже 256 цветов. У меня ошибка. Поправил.
Павел Романовский:
Вот я тоже хотел узнать, сколько же бит нужно для кодирования ч/б изображения с видеокамер, а если точнее, то изображения в градациях серого? Оказывается необходимо 8 бит (256 цветов). Взял с ru.wikipedia.org.
Да, черно-белое изображение в видеонаблюдении условно так называется. На самом деле 8 бит и градации серого.
Не знаю кому верить… Ты используешь разрешение PAL 704х576, в других местах указывается 720×576 (D1 или 4CIF). Кто прав? В Википедии говорится о разбиение изображения на 625 строк, из которых активные — 576. Может ответ в этом?
Разрешение использую то в котором изображение сохраняет ПО. В калькулятор добавил разрешение 720х576.
Денис, спасибо что идешь на встречу. Добавь еще пожалуйста 720х288 и 360х288.
Не за что Максим. Указанные разрешения добавлю в течении дня.
Добавил в калькулятор следующие разрешения: 720х288, 360х288.
Благодарю 🙂
здравствуйте! мне по учебе необходимо рассчитать размер сжатого кадра, в интернете натыкаюсь только на программки, вы не можете предоставить хоть какой-нибудь алгоритм расчета, формулы. спасибо заранее
Здравствуйте Наталья. Если вас интересует размер сжатого кадра видео, то в статье расписано, что и откуда берется. Если, что-то конкретно непонятно, то спрашивайте.
Здравствуйте! Хочу поблагодарить Вас за ваши уроки. Спасибо огромное, это неоценимая помощь для студентов (да и не только для нас). Мне лично ваши разработки помогли в написании дипломного проекта. Спасибо еще раз =)
Приятно, что информация была полезной. Удачной Вам защиты диплома Мария.
«…Современные видеокамеры отображают изображение с глубиной 24 бита.
Таким образом, получаем следующий размер несжатого изображения 405 504 х 24 = 9 732 096 бита.
…
В итоге получаем, что наше изображение в разрешении 704х576 пикселей в несжатом виде весит 1 216 512 / 1024 = 1 188 (тысяча сто восемьдесят восемь) кбайт…»
Неверные рассуждения. На стороне аналоговой камеры мы не имеем «пикселей при 24-битном цвете», лишь НЧ видеосигнал по ГОСТ, в котором вообще нет пикселей.
Пиксели появляются при оцифровке, однако ни о каких 24 битах цвета на пиксель речь не идёт — как правило это 8-10 (для чипов BT) или 12 (на чипах от Phillips), максимум это 14 бит цвета на пиксель (для малораспространённых, используемых в специализированных приложениях).
Хорош проектировщик — вдвое ошибься, ппц!
Спасибо за замечание, в статью внес изменение (удалил упоминание аналоговой видеокамеры).
Добрый день!
Много полезного в статье, спасибо Вам!
МНе для дипломной работы необходимо рассчитать нагрузку на полосу пропускания. Правильно ли я понял из вашей статьи:
1. Выбираем разрешение, например VGA 256 цветов=8 бит, 640х480
2. 307200*8/8 байт = 30700/1024 = 300 Кбайт
3. Далее умножаем на кол-во кадров, которое подерживает моя камера при таком разрешении: 300*30 = 9000 Кбайт в секунду.
4. Пропускная способность канала Ethernet = 100Mbit/c, а значит 9000 Кбайт = 72Mbit/c
А как дальше посчитать компрессию из того, что я имею? Поделить на степень сжатия H.264 — 74.9??
Условия у меня такие, что с IP-камеры вся информация уходит на облачный сервер ivideon, а от туда я уже просматриваю онлайн трансляцию и архивные записи. Никак не могу разобраться.
Заранее спасибо за помощь!
Здравствуйте, расчеты не проверял, но если все по методике приведенной в статье, то правильно.
Коэффициент сжатия используемый у Ivideon может отличаться от приведенного мной. Реальный можно определить только экспериментально. Скоро это, собираюсь сделать (как только придет IP камера из Китая).
Для диплома думаю пойдет не реальный, а расчетный коэффициент сжатия.
Т.е. коэффициент сжатия для H.264 — 74.9 вполне подходит для расчётов??
Вот тоже очень интересует данный вопрос 🙂
Порылся данное значение негде не нашёл, можете получше объяснить, как вы его получили?)
Все данные выдернуты из калькулятора входящего в состав программы для проектирования систем видеонаблюдения IP Video System Design Tool.
Коэффициент сжатия у любого производителя может быть свой, ориентируетесь на средний размер кадра.
Может я дурак, а может я чего не понимаю 🙁
Я не понимаю совсем, как определяется степень сжатия данного формата.
В идеале берете видеокамеру конкретного производителя, снимаете фрагмент видеозаписи, высчитываете размер одного кадра. Отсюда можете посчитать коэффициент сжатия для конкретной видеокамеры, конкретный условий, выбранного кодека.
Проще — берете онлайн калькулятор предлагаемый производителем и из его данных высчитываете размер кадра и дальше эту цифру используете в работе.
У меня не в идеале, у меня проект университетский, если можно объясните как высчитать этот коэффициент и от чего он зависит.
P.s. Высчитал размер 1-го кадра.
Спрашивайте то чего нет в статье, о том как считается размер сжатого кадра написано.
Добрый день, Денис!
Добавьте пожалуйста разрешение 976×582
Заранее спасибо!
Добрый День Валерий, добавил себе в задачу пунктик. Как сделаю здесь отпишусь.
Добавил разрешение 976х572. Можно пользоваться.
как снимать с Н.264 информацию на флешку для дальнейших просмотров и пересмотров?
H.264 это кодек. Если используется программа для работы с видеокамерами, то архив просматривать можно через нее. Если браузер, то в настройках смотри путь для сохранения файлов.
Если у меня к видеорегистратору SAF-04CH04A Н.264 будет подключено 3 камеры 800TVL (SAF-200C — 2шт, SAF-310C — 1шт). Сколько Гб память ЖД мне понадобится на сутки записи? Заранее благодарю!
В паспорте на видеорегистратор посмотрите, поймите в голове характеристики сжатия, для каждой модели не держу. Для ориентировочного расчета воспользуйтесь калькулятором.
купили 8 камер и регистратор не тянет пропадает одна или две камеры,мне сказали что поток информации слишком большой можете показать таблицу для потока записи информации
Смотрите характеристики вашего регистратора.
Здравствуйте! В вашем расчете есть такая характеристика — «сложность» с возможностью выбрать значение то 1 до 4, что это такое и как ее нужно учитывать?
Влияет на размер кадра. Подробнее чем расписано в статье уже ничего и не скажу.
Может у меня глаз «замылился» но в статье слова «сложность» не встречается, и по смыслу где идет об этом речь не вижу
Два года назад статью писал. От значения сложности зависит размер кадра. Калькулятор и его данные взяты из платного калькулятора входящего в IP Video System Design Tool.
Здравствуйте! По учебе нужно оценить объем жесткого диска в регистраторе при необходимости записи изображе-ний от 16 камер с частотой 4 кадра/с в течении 7 суток. Посчитала по вашей статье, у меня получилось 1,57ТБайта. Но я сомневаюсь в правильности. Проверьте пожалуйста!
Не все исходные данные даете, в конце статьи ссылка на онлайн калькулятор с помощью которого можете самостоятельно проверить свой расчет.
А что означает число в скобках после названия кодека в вашем калькуляторе?
Чем меньше цифра тем лучше качество.
А % движения как прикинуть на глаз? разбежка порядочная получается.
Брать по максимуму или прописывать в задании на проектирование системы видеонаблюдения процент движения.
он динамический и зависит от движений объектов перед объективом? типа если много движений , то пусть будет 60% , а пустующий склад — 20%?
При использовании кодека H.264 с переменным битрейтом именно так.
Во многих современных IP камерах, при CBR (Constant Bit Rate, постоянный битрейт), выставляется битрейт, далее в расчете архива надо «плясать» от этой цифры выставленной на всех камерах. Т.е. сумма этих значений и будет кол-вом бит/сек., делим на 8 и получаем байт/сек. При VBR (Variable bitrate, переменный битрейт) все сложнее, да и честно расчет исходя из VBR нельзя делать или для расчета использовать макс. битрейт для VBR .
Поддерживаю, лучше всего переменный битрейт использовать. При этом можно и саму максимальную цифру битрейта поднять и качество картинки поднимется и архив будет меньшего объёма.
Читайте методику расчета тут — https://markevich.by/obuchenie-proektirovaniyu/metodika-rascheta-emkosti-zhestkix-diskov-razmer-videokadra.html
В этой статье вообще нет слова «сложность», может как-то по-другому называется термин в ней?
Там весь смысл расчета отражен. Смысл параметра — увеличение битрейта, чем сцена сложнее тем битрейт выше. Каждый производитель рекомендует оптимальный битрейт для своих камер — //markevich.by/ip-videonablyudenie/bitrejt-ip-videokamer-hikvision.html
О, теперь понял, «сложность» это сложность сцены, а не сложность сжатия или ещё чего-то там. Т.е. чем больше мелких и движущихся объектов тем больше сложность получается, понятно теперь.
По поводу битрейта — если в камере задается битрейт, тогда сложный калькулятор не нужен, т.к. камера уже сама его будет поддерживать — нужно просто биты умножить на время.
Калькулятор как раз нужен чтобы прикинуть объем видео при записи не по битрейту, а по другим параметрам.
Прикинуть можно, упрощенно — надо знать битрейт который устраивает для нужной сцены. Подключаем камеру и тестируем.
Поясните, откуда взялся такой объем 1 кадра изображения в табл. для расчета емкости жестких дисков? Это из какой-то программы или расчетным методом получено? А то я считаю и никак понять не могу — цифры другие получаются
Вся методика описана в статье, повторяться не буду.
Значит у вас ошибка в таблице
Нет, скорее вы не поняли суть расчёта.
Ура! Нашла таки ответ на свой вопрос! https://markevich.by/obuchenie-proektirovaniyu/metodika-rascheta-emkosti-zhestkix-diskov-razmer-videokadra.html в комментариях.