Введение
H.265 – новый стандарт передачи видеоданных в видеонаблюдении. С появлением на рынке ONVIF-совместимых камер H.265 производители VMS начали выпускать софт с его поддержкой, но остается много вопросов о том, как клиентам лучше перейти на этот стандарт. По сравнению с H.264, в H.265 сжатие эффективней. Это значит, что нужно меньше места под видеоархив и меньшую ширину канала для видеокамер. По мере того, камеры с разрешением больше двух мегапикселей становятся нормой, преимуществ перехода на H.265 всё больше. Однако для кодирования и декодирования H.265 требуется большая, по сравнению с H.264, мощность и переход H.265 не обойдется без компромиссов.
В этой статье предпринята попытка отделить факты от вымысла, предоставив читателю понимание лежащей в основе технологии, реальных преимуществ, которые она дает, и оценки связанных с этим затрат. Только с помощью такой информации клиенты вместе с интеграторами могут решить, какой путь миграции для лучше.
Чтобы понять как влияет H.265 на развитие систем видеонаблюдения, полезно знать как он работает и чем отличается от предыдущих алгоритмов сжатия. Чтобы объяснить, вернемся к истокам сжатия видео, прародители которых – алгоритмы сжатия фотографий.
Что такое H.265?
Пространственная (покадровая) компрессия
Раньше цифровые изображения определялись по пикселям и были маленькие, но с развитием компьютеров эти изображения сильно выросли в размере. Рост популярности Интернета требовал, чтобы эти изображения передавались по сетям и для этого были разработаны методы сжатия, дающие возможность снизить размер файла изображения. JPEG-сжатие работает путем поиска избыточных частей изображения и определения их как групповых, а не как пиксельных. Представьте, как бы выглядела фотография, если бы была визуализирована в книге-раскраске. Черные контуры охватывают все области одного цвета, что значительно упрощает и ускоряет цветопередачу изображения. Такой тип сжатия называется “пространственным сжатием”, иногда – «покадровым».
Поскольку видео представляет собой серию изображений (кадров), логично выстроить ряд изображений JPEG вместе для создания потока. Этот метод компрессии называется motion-JPEG (M-JPEG.) В M-JPEG каждый отдельный кадр сжимается отдельно. Другими словами, компьютеру не нужна информация о каком-либо другом кадре, чтобы декодировать и отображать то, что там есть.
Временная (межкадровая) компрессия
После M-JPEG появился новый стандарт, названный MPEG. MPEG ищет группы похожих пикселей не только внутри каждого кадра, но и между кадрами. MPEG организует видео в группы кадров, каждый из которых содержит “опорный кадр” (I-кадр), а затем серию последующих “промежуточных кадров” (P-кадров). Каждый опорный кадр определяется с помощью пространственного сжатия (типа JPEG), после чего описываются следующие промежуточные кадры по отношению к предыдущему опорному кадру. Все, что не изменяется, считается избыточным и не нуждается в полном описании. Это называется “временным сжатием” или “межкадровым”. MPEG использует как пространственное (для опорных), так и временное сжатие.
Межкадровая компрессия изредка создает опорные кадры, а все остальное время «описывает» разницу между ними.
H.264 является развитием MPEG. Он ищет закономерности движения пикселей между кадрами. Представьте себе один видеокадр разделен на сетку квадратов, каждый из которых состоит из 16×16 пикселей. Каждый квадрат называется макроблоком. Если некоторые из этих макроблоков меняют положение с одного кадра на другой, то H.264 определяет новое положение этих кусков, но не нужно полностью описывать, как они выглядят, так как I-кадр уже предоставляет эту информацию. Потоковые видеосервисы, например Нетфликс, используют компрессию H.264. Поэтому при перемотке видео нельзя точно остановиться на каждом кадре, а только на I-кадрах. Промежуточные кадры не могут быть реконструированы телевизором, компьютером или мобильным устройством без предварительного построения I-кадра, на котором он построен.
По мере того, как разрешение видео увеличивается, необходимы более эффективные методы сжатия. Это послужило толчком к разработке H.265, который схож с H.264, но с несколькими ключевыми улучшениями. Одно из них то, что H.265 гибче в размерах используемых макроблоков, в том числе и гораздо более крупных. Другое заключается в том, что H.265 точней определяет направление движения объектов, что позволяет им двигаться плавней и с меньшим количеством визуальных артефактов. Это упрощенное объяснение методов сжатия, но его достаточно для понимания вопросов, обсуждаемых в статье.
Маленькие файлы и большие преимущества
При сравнении записанного видео такого же качества, файлы H.265 примерно в два раза легче, чем файлы H.264. Однако, как и в случае с H.264, эффективность H.265 сильно плавает в зависимости от типа сцены. Кроме того, при непосредственном сравнении эффективности сжатия H.265 с H.264, уменьшение размера файла на 50% зависит от разрешения видео и количества движения внутри видео.
Факторы эффективности
H.265 гораздо эффективней на сценах с большим количеством движений в предсказуемых шаблонах, например при наблюдении за эскалатором. Более крупные макроблоки, которые он использует, в сочетании с алгоритмами прогнозирования, которые определяют движение в большем количестве направлений, позволяют ему лучше сжимать видео. Это означает, что стандартное 50-процентное уменьшение размера файла в этих случаях приближается к 60 и более процентам.
Однако, как и H.264, новый кодек наиболее эффективен в ситуациях, когда движения мало. Эти сценарии позволяют кодировщику максимально использовать сходство между кадрами. Камеры в коридоре являются идеальным примером такого сценария использования для камер H.254 и H.265. Стол для рулетки казино, напротив, – кошмар для камер, использующих временную компрессию. Из-за постоянного и случайного движения кодировщику трудно найти способы экономии на размере файла.
На эффективность компрессии также влияет разрешение видео. При сравнении кодирования H.265 с H.264, изображения более высокого разрешения предоставляют больше возможностей для использования крупных макроблоков, используемых в H.265. Поскольку макроблоки в новом кодеке могут быть в 16 раз больше, понятно, как преимущества сжатия увеличат разницу при кодировании 8-мегапиксельного изображения, а не 2-мегапиксельного.
Передача
Почему размер файла важен? Передача и хранение. Давайте начнем с передачи. Кодированное видео идет через сеть на VMS через сеть, соединяющую между собой камеры, серверы и станции просмотра. Каждый канал видео требует полосы пропускания, а у сетей он ограничен. H.265 позволяет сетям поддерживать одновременную передачу большего количества видеопотоков. Например, 2-мегапиксельная камера, передающая 30 кадров в секунду, с помощью H.264 дает битрейт 1,5-2,5 Мб/с. При использовании H.265 скорость снижается до 50% при сохранении эквивалентного качества изображения.
Эффективность зависит от размера системы видеонаблюдения, качества инфраструктуры и топологии. Очевидно, что более крупные системы видеонаблюдения с большим количеством камер принесут больше пользы. Так же, как и объекты, в которых отсутствует современная сетевая инфраструктура для поддержки типа высокоскоростного трафика, генерируемого системами VMS.
Архитектура системы также важна. Те, кому раньше приходилось ужимать качество видео, чтобы не перегрузить сеть, смогут либо повысить качество видео, либо добавить больше камер в систему.
Хранение
Преимущества, связанные с хранением, очевидны. Меньший размер видеопотока означает, что уже существующие системы записи теперь могут либо хранить видео с двух камер вместо одной в течение того же времени, либо видео можно хранить в два раза дольше. А при покупке нового оборудования на хранение нужно меньше денег.
Кодировочная дилемма
В одном кадре современной IP-камеры от двух до восьми миллионов пикселей. Сравнение пикселей внутри и между кадрами в режиме реального времени требует невероятной вычислительной мощности. Оценки показывают, что по сравнению с H.264, новый кодек требует в восемь раз больше вычислительной мощности для кодирования и в два раза больше – для декодирования.
Кодирование против декодирования
Плюсом в том, что кодирование происходит непосредственно на камере, а стоимость новых камер не сильно отличается от стоимости камер H.264, благодаря новому поколению кодировщиков, которые обрабатывают оба формата.
Декодирование, должно происходить в любом месте, где отображается видеопоток. Поток нужно “распаковать” из формата H.265, прежде чем можно будет просмотреть с помощью программного обеспечения, браузера или мобильного приложения. И для этого требуется вдвое больше лошадиных сил, чем для декодирования H.264. Аппаратное обеспечение, используемое сегодня для просмотра видео H.264, может отображать в два раза меньше одновременных видеопотоков в H.265. Например, если станция просмотра сконфигурирована на отображение восьми 2МП-камер и процессор уже работает на полную мощность с использованием H.264, то в H.265 процессор сможет обработать только четыре камеры.
Цена декодирования
В дальнейшем производители СВН, предлагающие сертифицированное на заводе оборудование, должны будут определить спецификации отдельно для H.264 и H.265. Им также придется рассмотреть вопрос о расширении предложений за счет включения в них более производительных, но и более дорогих вариантов аппаратного обеспечения.
Определение того, может ли H.265 привести к чистой экономии для данной установки, потребует баланса между повышенной стоимостью аппаратуры для отображения и снижением затрат на хранение и сетевую инфраструктуру. Для СВН с большим количеством камер или с большой глубиной архива использовать H.265 выгодней, чем H.264. Для небольших СВН, но с круглосуточным мониторингом в режиме реального времени выгодней остаться на H.264. Кроме того, как уже упоминалось, эффективность H.265 (и H.264, если уж на то пошло) сильно зависит от типа сцены, поэтому камеры, которые используются для наблюдения за динамическими сценами, например за оживленными перекрестками, могут оказаться эффективней на других алгоритмах.
Постановка камер на работу
Один из способов, с помощью которого производители СВН могут снизить требования к вычислительной мощности для поддержки H.265, заключается в использовании камер, снижают нагрузку на рабочие станции и устройства отображения, а также на видеоаналитику.
Мультипоток
Камеры, предлагающие тройное кодирование (в M-JPEG, H.264 и H.265), а также многопотоковую передачу (передача 2 или 3 одновременных независимых потоков), позволяют передавать видео высокого разрешения H.265 на записывающее устройство, а видео стандартного разрешения (VGA) в форматах M-JPEG или H.264 отправляется на рабочую станцию в мультиэкран. По требованиям к вычислительной мощности для отображения, два потока H.265 сопоставимы с 16 потоками VGA M-JPEG. Затем, при выведении этой камеры на весь экран, из мульти экрана, VMS переключается на отображение потока высокого разрешения H.265 для этой одной камеры. Таким образом ресурсы рабочей станции используются эффективней.
У такого способа отображения нет недостатков, если используемые камеры поддерживают многопотоковую передачу и рабочая станция может быть сконфигурирована так, как описано выше. Визуальное превосходство видеопотока высокого разрешения есть только при разворачивании изображения на весь экран. При таком подходе нужно поддерживать только один видеопоток H.265 одновременно – на рабочей станции. В то же время, полное видео высокого разрешения со всех камер хранится в архиве в формате H.265 с высокой степенью сжатия. Такой способ передачи мы часто предлагаем на стройплощадках и складах – именно там просят наибольшую глубину архива.
Поиск по видеоархиву
Если видео записывается и хранится в H.265, то какая вычислительная мощность необходима для работы с архивом? Опять же, камеры могут сделать этот процесс менее затратным. У камер есть детектор движения, а также возможность интерпретации информации о движении. Как описано выше, в процессе кодирования камеры определяют группы пикселей, которые движутся вместе, и оценивают векторы движения для описания направления. Многие камеры могут передавать эту информацию на сервер в виде метаданных. В зависимости от характера поиска, программному обеспечению часто требуется искать только по метаданным события, которые соответствуют критериям поиска, и только после этого соответствующее видео декодируется для просмотра и анализа. Типы поиска, которые поддерживаются этим процессом, будут варьироваться в зависимости от моделей VMS и камер. И если стандарт ONVIF сделал совместимыми почти все IP-камерами разными VMS, то между камерами и VMS-решениями одного производителя часто предлагается более тесная интеграция. Гибкий и мощный поиск – это та область, в которой окупаемость комплексных решений максимальна! Без возможности поиска метаданных процессорам придется декодировать видеопотоки перед применением алгоритмов поиска, а для поиска, включающего декодирование и сканирование сотен часов видео, потребуется мощный компьютер.
Видеоаналитика
Простые средства анализа – обнаружение движения, пересечения линий и вторжений, могут быть запущены на самой камере или на VMS. Но более сложная аналитика – распознавание лиц и подсчет людей, обрабатываются программным обеспечением, отделенным от VMS, часто на специальных видеосерверах. Эти решения хорошо работают с многопоточными камерами, которые выдают поток M-JPEG низкого разрешения – CIF или VGA, который легко обрабатывается в режиме реального времени. Многим аналитическим системам не требуется видео высокого разрешения.
Некоторые системы видеоаналитики, определив нужные видеоклипы как релевантные из CIF-потока, запрашивают поток высокого разрешения для дальнейшей обработки. Например система распознавания лиц, обнаружив лицо в потоке низкого разрешения, переключается на поток высокого разрешения для распознавания.
Когда видеоаналитика встроена в программное обеспечение VMS, объем вычислительной мощности, необходимый сервису, будет зависеть от того, как работает интеграция. Если видеоаналитика работает только с HD-видео H.265, то сначала нужно декодировать видео, а затем выполнить повторную выборку в более низком разрешении. Если все это работает на одном сервере, то количество поддерживаемых камер снизится. Если встроенная аналитика работает как описывалось выше, получая небольшой поток видео непосредственно с камеры, то все промежуточные шаги по декодированию исчезают. Аналитика по прежнему будет создавать нагрузку на процессор, но гораздо меньше, чем если бы приходилось перекодировать потоки. Наибольшей популярностью видеоаналитика пользуется при установке видеонаблюдения в магазинах и кафе.
Что с просмотром архива?
Использование потока M-JPEG с низким разрешением на мультиэкране подходит для мониторинга реальном времени, но что произойдет, когда операторы захотят просмотреть видеоархив с нескольких камер одновременно? Ведь в этом случае рабочей станции доступно только видео в высоком разрешении H.265, которое лежит в архиве. А если рабочая станция не тянет несколько потоков H.265-видео в режиме реального времени? Тогда записанное видео можно смотреть в замедленном режиме. В ряде случаев это приемлемо, а в ряде – нет.
Что будет дальше
Растущее использование 4K и ультра-HD видео в индустрии безопасности будет неразрывно связано с адаптацией H.265 в качестве стандарта передачи по умолчанию, точно так же, как H.264 проложил путь для превращения мегапиксельных камер в стандарт de facto. Как только сетевые администраторы почувствуют уверенность в том, что широкомасштабное использование 4K- и сверхвысокоскоростных камер не поставит под угрозу работоспособность сети и не приведет к чрезмерно дорогому хранению данных, инсталляторы систем видеонаблюдения будут чаще применять H.265, а конечные пользователи получат более высокую детализацию изображения.
Это будет важно для криминалистов, где ultra-HD видео может выявить улики, не снятые камерами с более низким разрешением. Кроме того, использование этих камер будет доступно даже клиентам со старой инфраструктурой или с ограниченной пропускной способностью сети.
Низкий битрейт также открывает возможности для разработки облачных решений VMS. До сих пор лишь немногие производители предлагали облачные VMS, так как передавать видео в больших системах было сложно и ненадежно. H.265 может стать спровоцировать появление VMS как услуги.
Это перевод статьи с сайта sourcesecurity.com.
Оригинал здесь.