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

Привет всем.

Задали хороший вопрос, отвечаем.

Что такое интервал I-кадра, I-фрейма, GO{P,V}-{size,length} (всё одно и тоже, в принципе)

можно почитать в сети или в самом низу этой страницы

http://avreg.net/manual_applications_multi-stream.html

Итак, первичный параметр это всё же GOP (group of pictures) length в секундах.

Прим.: в каждом GOP один I-frame, считается что он начинает GOP.

С учётом того что:

1) у нас источник видео — «живой» сетевой (rtsp), а не какой-то заранее сделанный локальный видео файл с кинишкой,

2) видео с камер в системах видеонаблюдения, как правило, ещё оперативно наблюдают )) ,

разумный диапазон значений GOP length это [1..5] сек.

Интервал I-frame зависит от GOP length и framerate потока,

а именно: I-frame-interval = framerate * GOP-length-in-seconds

Например, если нужно сделать GOP length = 2 сек. для потока со скоростью кадров 25fps

и на камере задаётся только параметр «Интервал I-кадра», то в его значении нужно поставить 50.

Измените framerate, не забудьте поправить «Интервал I-кадра».

На некоторых камерах бывает др. параметр, типа «повторять I-frame каждые N сек» (как-то так),

это и есть GOP length.

Теперь нюансы:

* если планируете с AVReg-а забирать HLS(264), то выбирайте GOP [1..2] сек.

* если камеры далеко или сеть загружена (постоянно или периодами) — GOP не более 3 сек.

* если основная задача запись и при этом качественные камеры в локалке,

и когда ничего не «жмёт» в плане ресурсов (ни сеть ни комп),

можете выбрать GOV [3..5] сек., вы немного (5-15%) сэкономите на трафике и размерах медиа-файлов,

на реальных сценах, а не статичной черной картинке.

Прим: «революционный» h264+ с I-frame interval 700 (или около того) от HikVision или как там они сейчас называются,

не используйте никогда, это развод ло.ов маркетологами ))

Хорошо что он опциональный у них ))

P.S. у кого что есть добавить/поправить, не стесняйтесь.

Назад к основам: что такое «группа изображений» (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?

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

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

Итак, теперь, когда вы понимаете, почему так важно регулярно вставлять ключевые кадры в видеопотоке, мы можем поговорить о группе изображений или группе кадров (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.

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

Оригинал статьи: ссылка (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?

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

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

Итак, теперь, когда вы понимаете, почему так важно регулярно вставлять ключевые кадры в видеопотоке, мы можем поговорить о группе изображений или группе кадров (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 на рисунке выше. 

Понравилась статья? Поделить с друзьями:
  • Как составить кроссворд на летнюю тему
  • Как найти силу трения бруска по столу
  • Как найти штрих в математике
  • В ворде ошибка источник ссылки не найден как исправить
  • Как найти свою колонку алису