Gop потока больше рекомендуемого securos как исправить - Исправление ошибок и поиск оптимальных решений проблем

Назад к основам: что такое «группа изображений» (GOP)?

Оригинал статьи: ссылка (Bryan Samis, Sr. Specialized Solutions Architect, AWS Elemental Media Services)

Иногда, в своей повседневной жизни, специалисты по работе с видео забывают, что не все понимают абракадабру из трехбуквенных абревиатур, которые используются в нашей индустрии. В серии публикаций “Назад к основам” мы рассмотрим основные фундаментальные понятия и принципы, используемые при кодировании или сжатии видео для его дальнейшего распространения. Попытаемся объяснить их доступным и лёгким для понимания языком.

В этой статье мы рассмотрим такое понятие, как “Group of Pictures (GOP)” – группа изображений или группа кадров, которое используется в современных алгоритмах кодирования видео, включая такие алгоритмы межкадрового кодирования, как MPEG-2, H.264 и H.265.

Ну, что же, давайте начнём.

Зачем нам в принципе нужно сжимать видео?

Несжатое или некомпрессированное видео, которое передается по таким интерфейсам, как “High Definition Multimedia Interface” (HDMI), “Serial Digital interface” (SDI) или Ethernet требуют большой пропускной способности. Таблица, приведённая ниже, показывает примерные значения битрейтов, которые требуются для работы с несжатым цифровым видео сигналом для различных разрешений (размеров изображения) и частотах кадровой развертки (количеству передаваемых изображений/кадров в секунду времени):

Разрешение	Битрейт
1280×720 (720 50/60p)/1920×1080 (1080 25/30i)	~ 1.5 Гигабита в секунду
1920×1080 (1080 50/60p)	~ 3 Гигабита в секунду
3180 x 2160 (2160 50/60p or 4K)	~ 12 Гигабит в секунду

Хотя работа с видеосигналами со скоростью в несколько Гигабит в секунду возможна в рамках профессионального студийного комплекса, совершенно очевидно, что транслировать 1,5 Гбит/с в дома большинства зрителей или на их мобильные устройства невозможно. Для большей части пользователей домашние интернет-провайдеры даже не способны предоставить такую скорость подключения, не говоря уже о скорости скачивания. Таким образом, чтобы доставлять видео через Интернет или другую среду с фиксированной пропускной способностью (например, через спутник, эфир или кабель), необходимо кодировать или сжимать видео до меньших объемов (битрейтов) или иначе говоря, компрессировать (обычно в диапазоне от 1 до 20 Мбит/с).

Как работает видео компрессия?

Сколько времени вы готовы потратить на погружение в эту область? Для глубокого понимания специфики алгоритмов кодирования видео потребуются годы обучения. Обычно это является предметом исследованиий аспирантов в области компьютерных наук или математики. В этой публикации мы лишь поверхностно коснемся основ, объясняющих общие принципы кодирования видео.

На фундаментальном уровне, процессы кодирования видео основаны на поиске и устранении избыточной информации в изображении или последовательности изображений. Изображение в этом случае называется кадром, последовательность изображений – последовательностью кадров.

Если мы рассмотрим немного более детально абсолютно обычное видео, которое вы можете посмотреть онлайн или по телевизору – например, выпуск новостей, то каждый кадр новостного видеоряда, где диктор читает новости, обычно очень похож на те, которые предшествуют и следуют за ним. Губы диктора могут шевелиться во время разговора, бегущая строка может меняться в нижней части экрана, но большая часть изображения либо одинакова, либо очень похожа от кадра к кадру.

На примере трёх последовательных кадров из мультфильма “Big Buck Bunny” видно, что большая часть содержимого от кадра к кадру остается неизменной, лишь слегка меняются положение крыльев бабочки.

Эта наблюдения берутся за основу и являются ключевыми для алгоритмов межкадрового кодирования, т.к. в большинстве случаев сжатие видео достигается путём отправки полной информации только для определенных кадров, которые называются ключевыми или опорными кадрами, а для всех остальных кадров передается только информация о разнице между ключевым кадром и последующими кадрами. Приемное устройство или декодер может использовать ключевой кадр, плюс эти различия, для воссоздания нужного кадра с разумной точностью. Этот метод сжатия известен, как временное сжатие, потому что он использует тот факт, что информация в видео изменяется медленно с течением времени.

Второй тип сжатия, известный как пространственное сжатие, также используется для сжатия ключевых кадров путём поиска и устранения избыточности в самом изображении или кадре. Давайте ещё раз вернёмся к примеру новостей и представим единичный снимок изображения, где диктор читает новости. В большинстве случаев пиксели (пиксель – это наименьший логический элемент двумерного цифрового изображения) в этом изображении похожи на пиксели, которые их окружают, поэтому мы можем применить тот же метод, что и ранее, отправив только различия между одной группой пикселей и последующей группой. Это тот же метод используется для сжатия обычных изображений (картинок, фотографий, и т.п.), когда мы сохраняем их в формате JPEG (широко известный и распространенный формат сжатия одиночных изображений, разработанный одноименной группой разработчиков Joint Photographic Experts Group).

На примере кадра, извлечённого из того же мультфильма “Big Buck Bunny” видно, что пиксели обычно окружены другими пикселями аналогичного цвета — например, в небе синие пиксели окружены другими синими пикселями, а белые пиксели окружены другими белыми пикселями в облаке. При кодировании используется этот факт, который позволяет существенно сжимать (уменьшать объем данных) изображения с применением алгоритмов пространственного сжатия без видимой или существенной потери качества.

Надеюсь пока все понятно! Ну так что же все же это — GOP?

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

Произвольный доступ: отправка первого кадра в качестве ключевого кадра и последующих в виде различий между текущим и ключевым кадром могла бы работать, если бы каждый зритель начинал бы просмотр видео с первого кадра и смотрел только вперед от начала до конца. Но на самом деле, зрители смотрят видео контент по-разному. Если мы говорим про просмотр лйнейных ТВ каналов, зрители обычно подключаются к их просмотру случайным образом – когда им удобно или у них есть свободное время. Чтобы подстроиться под такое поведение зрителя, необходимо разместить больше ключевых кадров по всему видео, чтобы зрители могли начать просмотр не сначала, а с этих точек, где будут передаваться ключевые кадры. Они называются точками произвольного доступа.
Устойчивость к ошибкам. Другая проблема, связанная передачей только одного ключевого кадра и затем только с различий между кадрами, заключается в том, что для большинства случаев среда доставки или распространения видео является неидеальной. Какая то часть информации может потеряться во время доставки, данные/биты (бит – это минимальная единица измерения информации в двоичной системе счисления) могут доставляться с разной скоростью/задержкой, что может привести к тому, что часть их может поменяться местами, и есть еще множество других факторов, которые существуют в реальном мире и могут приводить к появлению всевозможных ошибок. Если вы отправляете только отличия от того, что было раньше, и при этом вначале возникает ошибка или потеря данных, то эта ошибка будет продолжать повторяться для всей остальной части видеопотока, пока он не закончится. Добавление дополнительных ключевых кадров по всему видео обеспечит устойчивость к ошибкам, возвращая декодер к «заведомо исправному» кадру и очищая предыдущие ошибки, которые могли бы продолжаться без них. Вы, наверняка, видели, как это происходит при просмотре видео, когда появляется какая-то ошибка, и экран становится блочным, или на нем появляются фигуры с зеленым оттенком. И потом, внезапно, изображение возвращается к норме.

Изменение сцены: передача только различий между кадрами работает очень хорошо, когда различия между кадрами относительно небольшие. Но во время изменения контента или перехода между сценами почти все изображение может быть заполнено новой информацией абсолютно отличающейся от предыдущей последовательности кадров. Когда это происходит, обычно нет смысла продолжать передавать только различия. Устройство кодирования видео (видеокодер) способно отслеживать это и автоматически вставлять новый ключевой кадр в пограничную точку – в момент смены сцены. Это называется обнаружением смены сцены.

Итак, теперь, когда вы понимаете, почему так важно регулярно вставлять ключевые кадры в видеопотоке, мы можем поговорить о группе изображений или группе кадров (GOP). Проще говоря, GOP — это расстояние между двумя ключевыми кадрами, измеряемое количеством кадров или промежутком времени между ключевыми кадрами. Например, если ключевой кадр вставляется в видео каждую секунду со скоростью 25 кадров в секунду, длина GOP составляет 25 кадров или 1 секунду. Хотя реальная длина GOP зависит от выбранной реализации и конкретного применения, обычно она находится в диапазоне 0.5–2 секунды.

«Ключевые кадры»? «Кадры, несущие разницу между текущим и ключевым кадром»? Нет ли для них других более официальных названий?

Конечно есть! В стандартах кодирования MPEG-2 и выше ключевые кадры обычно известны, как кадры с внутренним кодированием или сокращенно I-кадры («intra-coded frame»). Они названы так потому, что кадры сжимаются с использованием пространственного сжатия, и, таким образом, вся информация, необходимая для декодирования этого типа кадра, есть в нем самом. Декодеру не нужно каких-либо других кадров для воссоздания изображения.

Важно заметить, что начиная со стандарта H.264 и выше был введен еще один специальный тип кадра, называемый “ Instantaneous Decoder Refresh ” (или IDR-кадр), который представляет из себя ключевой I-кадр, содержащий дополнительно специальную команду для декодирующего устройства для очищения референсного буфера. IDR кадр указывает, что ни один кадр после кадра IDR не может ссылаться на какой-либо кадр перед ним. Данный фукционал широко используется для адаптивного стримминга – вещания через интернет, где один и тот же контент вещается небольшими частями/кусками с разными разрешениями и битрейтами, и приемное устройство, в зависимости от доступной на данный момент времени для него полосы, может запросить копию с меньшим или больщим видео битрейтом, обеспечив тем самым беспрерывное декодирование видео, хотя и с потерей качества в моменты падения скорости доступа в интернет).

Хотя между кадрами I и IDR есть тонкие различия, для понимания GOP мы можем рассматривать их так, как если бы они были одинаковыми.

Вы можете думать об I-кадре, как о простом статичном изображении в формате JPEG. Обычно I-кадры используют наибольшее количество битов в видеопотоке (имеют больший размер), потому что они используют только пространственное сжатие, и совсем не используют временное.

А как насчет «кадров, несущих разницу между текущим и ключевым кадром»? Есть два типа кадров, которые мы используем для передачи информации о различиях декодеру. Первый называется прогнозируемым или разностным кадром (P-кадр, “Predicted frame”). Он называется прогнозируемым кадром, потому что он содержит информацию о том, что изменилось по сравнению с предыдущими кадрами. P-кадры предоставляют «различия» между текущим кадром и одним (или несколькими) кадрами, которые были перед ним. Например, Р-кадр, который следует сразу за I-кадром, использует неизменную информацию из этого I-кадра и дополняет ее своей межкадровой разностью. Если за этим P-кадром следует еще один Р-кадр, то он в свою очередь берет неизменную информацию из предыдущего P-кадра (который в свою очередь использовал неизменную информацию I-кадра) и дополняет ее своей межкадровой разностью. P-кадры сжимаются гораздо лучше, чем I-кадры, поскольку они используют преимущества, как временного, так и пространственного сжатия и занимают меньше битов в видеопотоке.

Последний тип кадра, которые мы используем для передачи информации о различиях — это кадр с двунаправленным прогнозом или B-кадр (“Bi-predicted frames”). Они также могут называться обратными кадрами.

B-кадры являются двунаправленными, потому что они используют данные из кадров, которые были до и после них, и несут только различия между текущим кадром, прошлым и будущим опорными или прогнозируемыми кадрами. Поскольку они используют временное сжатие, и передают только разницу между текущим кадром, прошлым и будущим I и P кадрами, то их коэфициент сжатия выше чем у остальных типов. B-кадры обеспечивают максимальное сжатие и занимают наименьшее количество бит в видеопотоке.

Те из вас, кто всё еще не потерял нить объяснения, могут спросить, как B-кадр может заглядывать в будущее, чтобы указать различия между ним и будущим кадром. Опять же, детали немного выходят за рамки этой публикации, но происходит то, что устройство кодирования (кодер) буферизует прошлые и будущие кадры перед кодированием промежуточных кадров. Оно отправляет эти кадры в декодер не по порядку, поэтому будущий кадр (I или P) фактически поступает в декодер раньше, чем B-кадры. Затем декодер создает промежуточные кадры и воспроизводит их в правильном порядке, используя информацию о временной синхронизации, добавленную кодером на этапе кодирования в транслируемый сигнал или видеофайл.

На рисунке выше, вы можете посмотреть размеры (в килобайтах) различных типов кадров в одной группе кадров (GOP). Обратите внимание, что I-кадры используют наибольшее количество битов, за ними следуют P-кадры, а B-кадры используют наименьшее количество битов.

I и B, и P – как много всего! Как же это выглядит в реальности?

Типичная структура GOP содержит повторяющийся шаблон кадров B и P, “зажатый” между I кадрами. Примером типичного GOP может быть что-то вроде:

I B B P B B P B B P B B I

Последовательность, подобная приведённой выше, может быть представлена двумя числами: M и N. M представляет собой расстояние между двумя I или P-кадрами, тогда как N представляет собой расстояние между двумя I-кадрами. Вышеупомянутая группа кадров (GOP) описывается, как M = 3, N = 12.

Профессиональные видеоанализаторы могут визуально отображать группы изображений и типы кадров:

Но вы также можете увидеть структуру GOP закодированного видео с помощью бесплатного программного обеспечения, к примеру, такого как ffprobe:

$ ffprobe -i SAMPLE_MOVIE.mp4 -show_frames | grep 'pict_type'
pict_type=I
pict_type=B
pict_type=B
pict_type=P
pict_type=B
pict_type=B
pict_type=P
pict_type=B
pict_type=B
pict_type=P
pict_type=B
pict_type=P
pict_type=I

Из результатов выполнения команды, приведеннй выше, мы видим, что наш образец видео имеет длину GOP 12 кадров.

Как настройки длины GOP влияют на качество кодирования видео?

Чем короче длина GOP, тем меньше кадров B и P существует между I кадрами. Помните, что кадры B и P предлагают нам наиболее эффективное сжатие, поэтому в видео с более низким битрейтом короткая длина GOP приведет к ухудшению качеству видео. Увеличение длинны GOP, в свою очередь, обеспечивает более эффективное сжатие контента, что позволит ожидать более высокого качества видео при более низкой скорости передачи данных, однако это может повлиять на увеличение времени переключения между каналами и на отказоустойчивость.

В качестве примера, два последующих изображения представляют увеличенный фрагмент одного и того же кадра из мультфльма Big Buck Bunny, закодированного со скоростью 2,5 Мбит/с с использованием идентичных настроек кодирования, за исключением длины GOP. Первое изображение сжато с GOP, равным 4 кадрам, а второе — с длиной GOP, равной 90 кадрам.

Кадр того же видео, закодированный со скоростью 2,5 Мбит/с, с GOP, равным 4 кадрам (вверху), и GOP, равным 90 кадрам (внизу), это наглядная иллюстрация того влияния, которое настройки GOP могут иметь на качество видео. Поскольку в верхнем примере меньше кадров B и P, кодер должен более грубо квантовать I-кадры (сжимать их больше), чтобы соответствовать выбранному битрейту, что приводит к блочности, размытости и потере деталей.

Вышесказанное верно для большинства случаев кодирования. Однако при кодировании с очень высокой скоростью передачи данных, где поддержание высокого качества изображения более важно, чем сохранение битов (обычно 50 Мбит / с и выше), можно использовать длину GOP, равную 1 кадру (то есть, когда каждый кадр является I-кадром). Обычно это используется только на этапе производства и для создания архивов. В этом случае требования к качеству превалируют над требованиями к сохранению полосы.

Как настраивать параметры GOP при кодировании?

В AWS Elemental MediaConvert (облачный сервис AWS для кодирования видео файлов) вы можете настроить параметры GOP, выбрав видеодорожку требуемого выхода и прокрутив вниз до дополнительных настроек.

В примере выше примере мы указали длину группы изображений равной 90 кадров с двумя B-кадрами между опорными или прогнозируемым кадрами. Другими словами, приведенная выше конфигурация представляет M = 3, N = 90.

В AWS Elemental MediaLive (облачный AWS сервис для кодирования линейного контента в реальном времени) Вы найдёте настройки GOP, выбрав видеодорожку требуемого выходного потока и прокрутив вниз до раздела «Структура GOP».

В этом примере длина GOP равна 60 кадров с 3 B-кадрами между опорными кадрами. Другими словами, приведенная выше конфигурация представляет схему M = 4, N = 60.

Наконец, если вы осуществляете кодирование с помощью бесплатного программного обеспечения с открытым исходным кодом, такой как например ffmpeg с x264, вы можете указать настройки GOP, включив аргументы keyint = и bframes = в испольняемую команду:

$ ffmpeg -i SAMPLE_MOVIE.mp4 -c:v libx264 -b:v 4M -x264-params keyint=24:bframes=2 OUTPUT.mp4

При данных настройках видео будет кодироваться, используя длину GOP = 24, с двумя B-кадрами между опорными кадрами, или M = 3, N = 24.

Какой тип кадров наиболее важен?

Частый вопрос на собеседовании для специалистов по обработке видео: «какой тип кадра самый важный?». Распространенный (и вполне приемлемый) ответ, что I-кадры являются наиболее важными, потому что без них другим типам кадров было бы не на чем основывать свои различия. Но тонкий нюанс этого вопроса в том, что на него нет однозначного правильного ответа. С таким же правом можно сказать, что B-кадры являются наиболее важными, потому что они обеспечивают наилучшее сжатие. В конце концов, какой смысл в сжатии видео, если оно работает не эффективно? Цель этого вопроса не в том, чтобы получить правильный ответ, а в том, чтобы услышать, как кандидат обосновывает свой ответ, поскольку это дает ключ к пониманию того, насколько хорошо он знаает фундаментальные основы кодирования видео.

Надеюсь, после прочтения этой публикации вы будете понимать различные методы сжатия, используемые в кодировании видео, какие типы кадров при этом бывают, и то, как они объединяются, чтобы сформировать GOP.

И как заключение, хотелось бы чтобы Вы сами попытались ответить на вопрос: «Какой тип кадра, по вашему мнению, наиболее важен?»

Источник

Вся активность

SecurOs 9.1 и UNV IPC2125LR3-PF40M-D

Доброго времени суток.

Имеется SecurOs 9.1 в него заведено 17 камер с разного оборудования и разных вендоров.

Примерно месяц назад сменили 4 камеры RVI-IPC41LS 2.8mm на 4 камеры UNV IPC2125LR3-PF40M-D и начались проблемы.

SecurOS периодически теряет поток видео. Остальные камеры не пропадают. Так же и не пропадали RVI.

Уже было протестировано: Уменьшен битрейт, к/c, и разрешение камер, сменены протоколы onvif, rtsp, unv (заложенный в программе). Не помогло.

Камеры по пингам не пропадают, пробывали заводить тестово на Axxon Next всё исправно работает по onvif и не пропадает.

В чём может быть загвоздка?

Изменено 28 ноября, 2019 пользователем Night511

Вставить ник
Цитата
Ответить с цитированием

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

Скорее всего (бывает такое), когда реализация кодека в самой камере как-то не очень, как его там собрали не известно, но может есть какие либо логи на вашей системе (посмотреть почему отваливается поток), поменять с H264 на H265 или наоборот, выключить не стандартные кодеки на камере. Обновить прошивку камеры, если есть свежее.

Вставить ник
Цитата
Ответить с цитированием

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

2 часа назад, bkdipnet сказал:

Скорее всего (бывает такое), когда реализация кодека в самой камере как-то не очень, как его там собрали не известно, но может есть какие либо логи на вашей системе (посмотреть почему отваливается поток), поменять с H264 на H265 или наоборот, выключить не стандартные кодеки на камере. Обновить прошивку камеры, если есть свежее.

Кодеки тоже пробывал менять. Не помогло.

Ошибка звучит как: Потеря потока с камеры.

Что самое интересное что не потеря камеры, а потеря потока.

Мне кажется если бы проблема была с камерой то она в Axxone бы тоже вытворяла дел. А там всё нормально. Я думаю или сервер тупит, или версия SecurOs 9.1 не оптимизирована под эти камеры.

Но мне всё же интересно мнение со стороны.

Изменено 28 ноября, 2019 пользователем Night511

Вставить ник
Цитата
Ответить с цитированием

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

Так в том и дело, что речи про отвал камеры не идет, а вот проблема с кодированием, мне кажется, очевидна. Конечно может проблема и в сервере, просто не предусмотрели всех возможных глюков в потоке. Как вариант, проиграть поток в VLC к примеру, и сравнить информацию о кодеке, к сожалению других мыслей нет, поищите прошивку на эту камеру. Если камера в одной сети с сервером и ей не нужен инет, а в настройках камеры указан шлюз, через который камера имеет доступ в инет, поменяйте на любой другой, находящийся в этой подсети. Это к тому, что многим китайским камерам лучше не иметь доступа в инет.

Вставить ник
Цитата
Ответить с цитированием

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

Join the conversation

You can post now and register later.

If you have an account, sign in now to post with your account.

Источник

Компания Dahua в своих регистраторах использует кроме стандартных параметров настройки кодирования H.264 ещё и расширенные, обозначенный как режим SMART.

Smart H.264 не является новой технологией, это оптимизированная реализация технологии кодирования H.264. Smart H.264 представляет собой набор интеллектуальных алгоритмов кодирования, разработанных компанией Dahua на основе кодека H.264. Чтобы соответствовать особенностям записи при видеонаблюдении, Smart264 использует некоторые ключевые методы кодирования видео. Smart H.264 кодек может повысить эффективность кодирования видео в соответствии с особенностями различных мест наблюдения, кроме того, он может значительно снизить объем записи и потока для передачи данных по сети.

Технология Smart H.264 представляет собой набор интеллектуальных алгоритмов кодирования.

Разработанный компанией Dahua технология Smart H.264, включает в себя следующие три ключевых аспекта:

— Алгоритм расширенного управления скоростью передачи битов потока;

— Видеокодирование на основе аналитического контента видео (включая динамический ROI, динамический GOP(Интервал между опорными кадрами), гибкую структуру опорных кадров);

— Технология подавления шума.

I-кадры(Intra-coded frames) — Опорный (ключевой) кадр. Кодируются независимо от других кадров, так как обрабатываются с использованием собственной информации конкретного кадра. I-кадры имеет большой размер.

Р-кадры (Predicted-Frames) — кадры с предсказанием, с компенсацией движения. Кодирование осуществляется с учетом ближайших предшествующих I или P-кадров, используется «разностная» схема сжатия, при которой сохраняются только отличия от предшествующего кадра. В P-кадрах, если сравнивать их с I-кадрами, значительно выше достижимая степень сжатия видеоданных.

Структура записи видеопотока при фиксированном интервале I-кадров

Типичные настройки видеорегистратора реализует фиксированную структуру GOP (Интервал между опорными кадрами, I-кадр), что означает, что интервал между двумя I-кадрами постоянен и, как правило, установлен 2 секунды.

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

В видеонаблюдении, в большинстве случаев, видео статично, а движущийся объект или общее движение появляются в определенные периоды, таким образом, мы можем увеличить интервал GOP, чтобы уменьшить количество I-кадров за период времени. I-кадр имеет гораздо больший объём в видеопотоке по сравнению с P-кадром. Уменьшение кол-ва I-кадров позволит уменьшить размер видеопотока, либо увеличить размер P-кадров, тем самым увеличить качество картинки при записи.

В CVI видеорегистраторах Dahua при выборе режима Smart H.264 реализуется гибкая структура опорных кадров, использующая технологию двух-кадровой ссылки и технологию виртуального опорного I-кадра.

Технология двух-кадровой ссылки.

Для обычного кодирования видеопотока в системах видеонаблюдения использует только один кадр (опорный I-кадр или предыдущий кадр) в качестве эталонного кадра,на который ссылается следующий кадр. Для двухкадровой режима (режим Reframes=2) для ссылки будут взяты два контрольных кадра, один – это предыдущий кадр, другой — это 0-й кадр (I-кадр). На рисунке 2-й P-кадр ссылается как на 0-й кадр, так и на первый P-кадр. В сцене движения, структура с двухкадровой ссылкой может найти лучшие блоки для определения фоновой зоны относительно движущегося объекта. Это может увеличить точность оценки движения и повысить эффективность сжатия.

Технология виртуального I кадра.

Как правило, только через I-кадр можно реализовать функцию обрезки/вставки видеопотока. Реализация виртуальной технологии I-кадра гарантирует, что определённый P-кадр может назначить I-кадр как ближайший опорный кадр, не учитывая с 1-го по 4-й P-кадр (на рисунке 5-й P-кадр ссылается только на 0-й I-кадр), таким образом, он становиться, как бы, 1-м кадром для следующих за ним P-кадрами. Эта технология уменьшает время доступа к случайному кадру в видеопотоке, поскольку для получения нужного кадра нет необходимости полностью распаковать всю цепочку P-кадров от ближайшего опорного I-кадра.

Настройки видеорегистратора при выборе режима Smart H.264+ , можно заметить что нет выбора интервала между опорными кадрами (I-кадр).

Протестируем различные настройки кодирования на видеорегистраторе XVR5104HE-S2 с прошивкой вер. 3.218.0000002.1. Видеопоток с разрешением 1920х1080 и частотой кадров 15 кадров в секунду. Сравним обычный режим и режим Smart H.264.

Сначала используем базовые настройки с фиксированным интервалом I-кадров в 2 секунды,с переменным битрейтом VBR, с максимальным потоком 4096 кБит и настройками Качество 4,5,6. Записывать будем уличную картинку с минимальным движением в кадре. Значение среднего битрейта при разном параметре Качество занесём в таблицу.

Таблица битрейта при разном качестве. Интервал опорного кадра I=2 cек. Максимальный битрейт= 4096 кБит/сек.

Качество	4	5	6
Средний битрейт видеопотока	1320 кБит/сек.	2080 кБит/сек.	3700 кБит/сек.

Оптимальные настройки для записи это параметр Качество=4 или =5. Значение =6 даёт слишком высокий битрейт для почти статичной картинки. Структура получившейся записи при значении параметра Качество=4 представлена на картинке ниже.

Как видно при анализе катринке, опорный I-кадр имеет размер 129 кБайт и интервал каждые 30 кадров (2 секунды) , а P-кадры имеют в среднем от 4 кБайт до 8 кБайт. Структура потока соответствует представленной схеме на рисунке выше.

Далее используем режима Smart H.264,с переменным битрейтом VBR, с максимальным потоком 4096 кБит и настройками Качество 4,5,6. Записывать будем уличную картинку с минимальным движением в кадре. Значение среднего битрейта при разном параметре Качество занесём в таблицу.

Таблица битрейта при разном качестве в режиме SMART H.264. Максимальный битрейт= 4096 кБит/сек.

Качество	4	5	6
Средний битрейт видеопотока	910 кБит/сек.	1820 кБит/сек.	3480 кБит/сек.

Общий битрейт видеопотока уменьшился при включении режима Smart H.264. В целом картина зависимости размера видеопотока от параметра Качество не изменилась по сравнению с базовыми настройками. Так же оптимальные значения для записи — параметр Качество=4 или =5. Значение =6 всё так же даёт слишком высокий битрейт для статичной картинки. Посмотрим на структуру получившейся записи при значении параметра Качество=4 на картинке ниже.

Как видно при анализе катринке, при включении режима кодирования SMART H.264 интервал опорного I-кадра становиться равным 10 секундам (кажные 150 кадров), его размер 125 кБайт. Также хорошо видно что каждые 15 кадров P-кадры имеют рамер в среднем 20 кБайт, что в четыре раза больше чем остальные P-кадры ( в среднем 5 кБайт). Каждый P-кадр, имеющий рамер 20 кБайт, – это кадры полученные непосредственно от 0-го I-кадра (Технология виртуального I-кадра). Структура потока соответствует представленной схеме для режима Smart H.264 на рисунке выше.

Источник

Домашнее видеонаблюдение и удалённый просмотр через Интернет

Время прочтения
8 мин

Просмотры 57K

Недавно на Geektimes была опубликована статья про домашнее видеонаблюдение — «Домашнее видеонаблюдение». Автор её так и не смог настроить просмотр камер через web-интерфейс. Решил поделиться своим опытом в этом деле. Далее собственно статья с картинками о том, как это легко и быстро настроить у себя. Также вспомнил, что у меня были вопросы по ходу настройки, в связи с этим решил более подробно расписать весь процесс настройки. Внимание, много картинок.

Чтобы свою систему не ломать переустановкой, сделал всё на виртуалке, с самого начала.

Что нужно:

— Компьютер с Win7 или выше;
— Софт – упомянутый в предыдущей статье Securos Lite (скачивается на сайте производителя) и модуль WebView. И если первое легко скачивает на сайте производителя, то вот ссылку на второе я уже и не помню как искал;
— Камера. Здесь, конечно, каждый сам должен выбирать исходя из качества изображения/цены/целей и т.д. Общие рекомендации: если на камере есть наклейка Onvif, скорее всего она заведется в любом софте. Если в описании камеры на сайте, в документации, либо на форуме написано, как завести её в VLC, то видео с такой камеры с вероятностью 99% так же сможете получить, по крайней мере в Секуросе есть механизм получения видеоизображения с любой камеры, которые показываются в VLC. Разница в HDReady и FullHD прилично влияет на архив, но если пару десятков гигов есть свободных, то лучше брать FullHD.

Настраиваем камеру

Заходим на веб-интерфейс камеры, задаем сетевые настройки (если у вас дома роутер), логин/пароль, проверяем, что она показывает в этом самом интерфейсе.

Ставим софт

Ничего сложного тут нет. Сперва запускаем первый инсталлятор. Несколько раз прощёлкиваем «Далее» и всё, программа установлена. В установке и удалении программ так же появился Postgres. Запускаем второй инсталлятор (вроде можно и потом его доставить), опять пару раз «Далее», видно, как ставится Java и сервер TomCat. Установку Томката также прощелкиваем.

Первый запуск

Первое что меня смутило, это сообщение об ошибке:

Можно было бы и написать в сообщении, что же делать. Но мы то знаем, что надо запускать из-под администратора. Чтобы каждый раз не щелкать «запустить из-под Администратора», включаем эту опцию в настройках программы:

Замечу, что тех. поддержка заявила, что это уже поправлено в готовящейся к выпуску следующей версии 8.7. Там вручную ничего делать не надо будет, даже если включён UAC.

После запуска появляется Мастер первоначальной настройки:

В принципе, тоже его быстро прощёлкиваем. Самое главное там – это выбрать диск куда будет архив писаться, главное на SSD не указать его. Там же есть страница, где можно вручную добавить камеры, но в ней нет автопоиска, да и потом можно будет вызвать более удобный инструмент добавления камер. Так что пропустим его. Ещё одна особенность: можно сразу добавить удаленный клиент, например, свой рабочий комп. Про это я подробнее ниже напишу, сейчас это можно пропустить. В общем прощёлкиваем до конца, жмем Завершить, и появляется пустой (так как мы не добавляли камер) Монитор.

Здесь сразу сделаю отступление: как я понял, в Секуроса есть 2 встроенных средств работы с камерами. Они называются Монитор и МедиаКлиент. Как я понимаю, старый и новый. Старый функциональнее (кнопок там ненужных нам больше), второй красивее, удобнее, и с рабочего компьютера, почему-то в несколько раз меньше CPU есть (2% вместо 8%). В общем, рекомендую сразу заменить созданный по умолчанию Монитор на МедиаКлиент. Для этого вызовем дерево с объектами (правый клик по иконке в трее, показать панель, на ней нажимаем шестеренку).

В нем удаляем «Монитор», встаём на «Рабочий стол», нажимает создать, выбираем «Медиа Клиент».

Заводим камеру

На панели находим и нажимаем кнопку «Менеджер IP-устройств». Появляется окно этого менеджера. В нижней половине есть кнопка искать. Мой Beward он нашел сам. Единственное, я сразу вручную исправил модель с default на BDSeries. Если камера не нашлась, то можно вручную попытаться настроить, на скриншоте вот я выбрал ONVIF (половина камер сейчас его поддерживает, даже если на коробке с камерой нет такого слова, то в первую очередь рекомендую попробовать настроить как ONVIF). Нажимаем «Добавить», в верхней части водим логин/пароль, нажимаем «Применить», закрываем менеджер. Камера сразу показывается в медиаклиенте.

Включаем запись архива

Здесь сразу лучше проверить, что она пишет архив (поставить на запись в медиаклиенте, снять через несколько минут, зайти в архив). Если на кнопке «Запись» появился тревожный треугольник, то всё плохо, архив не пишется. По личному опыту знаю, что обычно такая проблема возникает, когда на диске мало места. Как в итоге оказалось, у меня проблема возникла по тому, что под архив я выделил диск всего на 20 гигов. А так как ставим мы всё-таки бесплатную версию коммерческого продукта, то видимо и настройки по умолчанию там для серьёзных систем. Поиск по инету, поиск настроек в реестре и даже небольшой разговор с тех. поддержкой дал найти нужные настройки. В 32-битной винде это ветка HKEY_LOCAL_MACHINESOFTWAREISSXpressNiss400Video (на 64-х битной системе: HKEY_LOCAL_MACHINESOFTWAREWow6432NodeISSXpressNiss400Video). Я выставил параметры так: MinDelMB – 1700, FreeMB – 1350.

Далее для экономии места на диске (чтобы больше была история хранилась) лучше запись сразу отключить и подумать, как вообще будет удобнее ставить камеру на «охрану» (режим, когда архив пишется только при наличии движения на изображении). Я сперва настроил временную зону (под объектом SecurOS Lite) и две Макрокоманды, которые автоматически ставили камеру на охрану утром, и снимали с охраны вечером. Ниже пример настройки одной из макрокоманд.

Но в итоге, так как я ухожу/прихожу из дома в разное время, мне удобнее оказалось управлять записью вручную с работы, т.е. приехал на работу, поставил на «охрану», приехал домой – «снял с охраны».

Настройка Веб-Сервиса

Подошли к самому интересному. В дереве объектов создаём объект WebView Сервер, у него в настройках добавляем нашу камеру. Далее под ним создаём объект WebView Монитор. В его настройках выбираем нашу камеру (Просто нажать кнопку «Все»).

В принципе, это всё. Далее предполагается уже смотреть в браузере. Если Томкат ставили по умолчанию, то заходим на http://localhost:8080/webview. Здесь хочу сразу заявить о 2-х проблемах, которые мне пришлось обойти, чтобы видео появились. Пишу, чтобы если у кого они тоже будут, то он знал, что делать. У меня на порту 8080 оказался TFS сервер. При этом netstat показывал этот порт как незанятый. Томкат тупо не стартовал. Это выявил сразу, так как открывалась страница где было упомянуто TFS. Решил путём захода в настройки Томката и смены порта на незанятый 8070. Далее была весёлая ошибка 500. Тех поддержка подсказала, что надо проверить версию Явы. Должна быть < 1.8. (пообещали, что в последующих версиях уже запланирован апдейт Томката и Явы на последние версии, что такого больше никогда не возникало). В общем, в меню Пуск, находим ярлык Configure Tomcat, переходим на вкладку Java и меняем путь к яве (у меня был C:Program FilesJavajre1.8.0_25binclientjvm.dll) на C:Program FilesJavajre7binclientjvm.dll и перезапускаем службу Apache Tomcat 6. После этого опять открываем страницу в браузере. Должно получиться что-то типа:

Последние шаги

Для авторизации через веб-интерфейс нельзя использовать аккаунт супер-пользователя Секуроса (написано из-за небезопасности передачи пароля). Поэтому чтобы работать дальше надо вручную создать пользователя. Опять открываем дерево объектов, выделяем объект SecurOS Lite, нажимаем Создать, выбираем в меню Отдел. Под ним тут же создаём пользователя. Название лучше сразу написать что-то адекватное, я, например, задал webview. Далее переходим в дереве на Права пользователей -> Права опытных пользователей, и в окне настройки в блоке пользователи выбираем нашего пользователя, и задаём ему пароль.

Переходим обратно в браузер, вводим webview/password, жмем Continue. Появляется страница выбора мониторов. У нас он один, выбираем его. Если браузер InternetExplorer, то предложится ActiveX поставиться. Лучше поставить, после его установки, резко снижается нагрузка на сеть (как я понимаю, гонится по сетке поток H.264). В общем сейчас можно зайти на этот web-интерфейс с любого браузера, (в том числе с мобильного) и смотреть видео, смотреть архив, который по детектору движения пишется. Чтобы ставить камеры на охрану/снимать с охраны я использовал выше упомянутые макросы. Единственный недостаток – если использовать мобильный трафик, то большой расход получится, в первом отпуске, помню, смотрел камеру только в отеле через WiFi. Кстати, этот сервер тоже умеет отдать сжатое видео (которое мало трафика потребляет, как через ActiveX в IE) по rtsp. Если кто по-продвинутей и знает, как в VLC добавлять rtsp ссылки, то всё будет работать, в том числе на смартфонах. Но это, конечно вариант только для просмотра живого видео, без архива, и без управления камерой.

Что-же получилось в итоге

Написано много, но в первый раз я запустил всё быстрее, когда ставил на реальную систему (у меня не возникло проблем с записью из-за виртуалки, да и других не было), помню осталось только приятное воспоминание, как быстро всё заработало.

И теперь опишу как это у меня сейчас работает. Мне для работы со всем этим гораздо удобнее оказался использовать клиент для виндоуз. Сделал я следующее:

— дома настроил доступ на работу через OpenVPN (на самом деле он у меня уже был). Для тех, у кого в компании нет такого, можно использовать VPN через TeamViewer. Также уверен, что можно легко и через интернет настроить, но там уже небольшие хаки нужны (либо статический ip, либо no-ip использовать ). Если будут проблемы обращайтесь в личку, постараюсь помочь;
— дома в Секуросе создал ещё один компьютер типа «Рабочее место оператора». Под ним создал Медиа Клиент. Пробовал и старый Монитор, но разница очень большая между ними. Медиа Клиент на порядок меньше грузит процессор, приятнее и удобнее;
— на работе поставил Секурос, в режиме «рабочее место оператора». Из того-же дистрибутива, только сейчас уже не прощёлкиваем быстро страницы, а находим страницу, где он спрашивает тип установки, в комбо-боксе выбираем, что это Рабочее место оператора;
— далее запускаем Секурос, вводим IP или имя (если это имя резолвится), нажимаем подсоединиться. Логин можно всё тот-же: webview. Возникает окно Медиа Клиента. Единственное, что плохо, настроить его можно только с домашнего компьютера. Т.е. я его сначала на весь экран сделал, было неудобно. Пришлось подключаться на домашний комп по TeamViewer’у и настраивать, где и как должен Медиа Клиент показываться.

Алгоритм работы у меня сейчас такой. Прихожу на работу, в Медиа Клиенте нажимаю кнопку «поставить на охрану», перед уходом с работы (или уже дома) нажимаю снять с охраны. Быстренько на 4x/8x/16x просматриваю, не было ли чего подозрительного.

В дополнение настроил себе «место оператора» так же на ноутбуке (в отпуске проверял всё ли дома хорошо, и как там цветочки поливаются). Это удобнее, чем пытаться на смарте глядеть камеру. Тут и позумить можно, и покрутить её. Опять-таки для отпуска в итоге настроил посылку нотификаций на email о обнаружении движения в камере (хотел ещё старый телефон для смс прикрутить, но потом понял, что для меня сейчас без разницы СМС пришло или письмо на Gmail, все равно Push-сообщение появляется). Документация есть, F1 есть, разобраться во всём можно. Я даже для интереса разобрался как простенькие программы писать, но это мне не пригодилось. Сейчас хочу ещё камеру добавить, чтобы покрытие расширить, но кухня у меня очень маленькая, вот потихоньку присматриваюсь к чуду с объективом «рыбий глаз», работа с ними в софте уже есть.

Как итог

Настроить веб-интерфейс можно, это не сложно, если пол вечера не жалко, то всё получится. Если что-то не получится самому, то тех. поддержка помогает, что на самом деле удивительно для бесплатного продукта, видимо забота о бренде. Из приятного уже сейчас множество дополнительных плюшек (в том числе и нотификации, слежение за работоспособностью, работа со звуком (надо к камере подключить микрофон, и тогда при выборе камеры в Медиа Клиенте с неё ещё и звук идёт) и множество того, что я не использую, ибо даже не представляю зачем они мне нужны (это как с Фотошопом – использую только 5-10 процентов его функционала). Радует, что тех. поддержка обещает появления множества новых плюшек, которые могут лично мне понадобиться: всё-таки нативный клиент под Андроид (так как иногда всё-таки хочется поглядеть на телефоне, сейчас через мобильный браузер не самый удобный вариант), переработанный веб-интерфейс, управление потоком, который в сеть отдавать (как я понял, с камеры будут браться 2 картинки, одна будет писаться в архив, а второй с меньшим разрешением транслироваться через веб-сервер (это как я понял уже и сейчас можно сделать и с Монитором и с Медиа Клиентом).

Updated: Разобрался в новой версией софта с таким понятием как «мульти-поточность».

Мульти-поточность

Мульти-поточность — это возможность забирать одновременно 2 и более картинки с камеры, разного разрешения и/или уровня сжатия, и потом возможность управлять что с этими потоками делать. Т.е. для записи в архив можно сохранять картинку в хорошем качестве (например, FullHD), а через сеть можно посылать видео, скажем среднего разрешения.

Пришлось камеру понастраивать и софт немного. Зато теперь ещё быстрее стало видео, на 3g — без тормозов и лагов. Если кому интересно, и не получилось настроить самому, пишите в личку, постараюсь всё подробно объяснить в скриншотах, какие настройки надо делать на самой камере через веб-интрерфейс, и какие в софте.

Источник