Оборудование для организации видеонаблюдения видеокамеры, видеорегистраторы

Видео-версия этой статьи

Зачем нам кодеки и почему есть разное качество кодирования

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

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

• Уменьшение цветов (более грубые градиенты)
• Усреднение соседних областей (потеря детализации и чёткости)
• Ухудшение качества движущихся объектов (разрывы на объектах, артефакты, нарушения границ объектов, смешение объектов с фоном)

Однако распространённые сейчас кодеки способны в очень малый объём данных скомпрессировать видео практически без потерь, но достигается это значительным увеличением требований к производимым расчётам. Иными словами — сжатие происходит очень долго.

Для сжатия видео, когда оно производится заранее, то есть не в масштабах реального времени воспроизведения — эта проблема не так велика. Ведь если не важно передавать сжатый поток в реальном времени, то можно и поток сделать более широким, то есть выделить для сжатия больший битрейт видео, либо сжимать видео настолько долго, насколько это возможно. И в том и в другом случае получая высокое качество, правда с разной компрессией данных.

Однако такой сценарий доступен не всегда. Если требуется передавать поток в режиме реального времени, то скорость кодирования должна быть равна или выше, чем скорость воспроизведения видео. В таком случае гипотетически можно увеличить битрейт и тем самым использовать упрощённые методы сжатия, теряя меньше деталей при компрессии. И это было бы так, если бы современные стриминговые площадки не ограничивали доступный битрейт для видеопотока.

Иными словами — для того чтобы терять меньше качества при стриминге видео неизбежно надо применять более реусурсозатратные алгоритмы сжатия данных.

Какие есть пресеты настроек

И для кодека x.264 и для более современного кодека x.265 есть масса параметров которые влияют на качество кодирования. Десятки опций имеющих возможность переключения множества параметров, которые образуют десятки тысяч комбинаций настроек. И чтобы пользователю не приходилось тратить своё время на подбор оптимальных конфигураций были введены готовые пресеты настроек. И для кодека x.264 и для кодека x.265 этих пресетов 10.

• Ultra Fast
• Super Fast
• Very Fast
• Faster
• Fast
• Medium
• Slow
• Slower
• Very Slow
• Placebo

Названия пресетов передают их суть. А если точнее характеризуют скорость кодирования видео. То есть пресет «Ultra Fast» позволяет кодировать видео ультрабыстро, «Slow» — кодировать медленно, а самый «прожорливый» — «Placebo» и вовсе придуман был просто «чтобы было» и чтобы показать, что такое качество тоже возможно, но возможность его реального применения — это скорее самовнушение, чем действительность.

С пресетами разобрались. Теперь надо разбираться с методикой тестирования и критериями и оценками качества.

Методика тестирования

И это сейчас самое важное. В целом — тестов пресетов кодеков и так много, но есть проблемы с методикой, а вернее с тем, что обычные методики не предполагают контроля того насколько сложная сцена. А именно сложность сцены влияет на качество кодирования.

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

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

Задача не тривиальная и, забегая вперёд, оценки будут субъективными, так как оценки я буду ставить… умозрительно, на основе визуальных дефектов. Тем не менее — даже чтобы глазами посмотреть на разницу эту разницу надо как-то сгенерировать и выбрать точные метрики для отслеживания качества.

Оценивать предлагаю по вот этому тестовому кадру:

В нём есть довольно много интересных мест, которые будут меняться при сжатии.

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

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

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

Видео состоит из 11 градаций изменений сложности кодирования от 0-ой, самой простой сложности, до 10-ой, самой сложной. При переходе на каждую следующую градацию в картинку добавляется 100 дополнительных фигур, таким образом на 0-ой сложности число фигур — 0, а на 10 сложности число фигур — 1000.

Однако говорить о строгой линейности прироста сложности я бы не стал. Фигуры пересекаются друг с другом и трудно судить — становится сложнее кодировать из-за этого или проще при увеличении числа фигур. Тем не менее — приращение энтропии близко к линейному.

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

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

Итого у нас выходит 20 пресетов кодирования, по 10 на x.264 и x.265, и в каждом из 20 пресетов по 11 результатов тестирования по одному для каждого уровня сложности. То есть в сумме — 220 изображений. Ссылки на оригиналы находится в конце статьи.

Чтобы сжать видео первоначально было получено несжатое видео (55 секунд объёмом примерно в 20 ГБ) в Vegas Pro 15. Само видео я передать не могу в силу его размера, но проект видео в Vegas Pro можно скачать «тут«.

Далее это несжатое видео было сжато в программе MeGUI (скачать можно тут). Программа выполняет скрипт программы AviSynth, которую можно скачать тут. Самый простой скрипт будет если поместить видео и сам скрипт формата *.avs и программу MeGUI в одну папку и скрипт можно создать текстовым редактором (например блокнотом), вписав:

С соответствующими настройками кодирования с постоянным ограниченным битрейтом в 10 Мбит/с.

Результаты

Далее нам надо оценить результаты. И я хочу остановится на сложностях 6 и 10. Сложность 6 отражает довольно высокую нагрузку, реально достижимую в видео. Сложность 10 просто самая большая.

Нам необходимо заполнить таблицу:

Учитывая методику тестирования появляется одна проблема, связанная с объёмом видеофайла более 20 ГБ. С быстрыми кодированиями производительность ограничивалась скоростью чтения с SSD накопителя, а не Intel Core i9 9900k в стоке, на котором проводилось кодирование, поэтому говоря про скорость кодирования, она на «быстрых» пресетах идентичная и время заполнено в таблице ниже:

В виде графика эти данные выглядят так:

Видно, что время требующееся на сжатие — стремительно увеличивается с изменением пресета качества, по вертикали измерения в секундах.

Далее я дал субъективные оценки качества изображения для сложности 6 и сложности 10.

Приоритеты при оценке были следующими:

1. Сохранение форм и чёткости
2. Сохранение цветов, полутонов, градиентов
3. Отсутствие артефактов

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

Я дал оценки от 1 (наихудший результат) до 10 (неотличимый от оригинала) с градациями в 0,5 балла. Баллы выше 1 я ставил за удовлетворительный результат, оценку 1 я ставил за неудовлетворительный результат. То есть 1 балл — это не оценка качества, а отсутствие оценки (в сортах …. пиксельной каши не разбираюсь).

Оценки проводились для сложности 6 и 10.

Сложность сцены 6

Для сложности 6 результаты занесены в таблицу:

Эти же данные в виде графиков представлены ниже:

Стоит отметить, что пресеты для x.264 очень нелинейно прирощают качество. Между качествами Slower и Very Slow кодека x.264 находятся все результаты для x.265 кроме Ultra Fast. При этом до пресета Fast в x.264 я результаты счёл неудовлетворительными. В то время как пресеты Very Slow и Placebo на x.264 оказались лучшими по качеству, чем Very Slow и Placebo на x.265.

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

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

С точки зрения математики, при анализе субъективных оценок качества, наиболее выгодным является пресет настроек Medium кодека x.265. То есть пресет позволяет получить приемлемое качество с приемлемыми затратами производительности.

Также видно для x.265, что дальнейший рост времени кодирования плохо компенсирует возрастающее качество.

Для x.264 ситуация иная. Качество приростает примерно с той же «скоростью», что и затрачиваемое на кодирование время (за исключением Placebo).

Сложность сцены 10

Далее оценим аналогичные параметры для максимальной сложности видео.

На максимальной сложности нелинейность качества на x.264 становится ещё выше, и расслоение качества на x.265 так же становится больше. При этом стоит отметить, что для placebo x.265 я поставил оценку 7,5, что ниже, чем Very Slow для x.264.

Полученные изменения привели к тому, что при увеличении сложности самого видео ситуация с x.264 становится лучше, и пресет Slower позволяет добиться хорошего соотношения качества/производительности, но этот пресет всё равно не обходит по этому показателю Medium x.265.

Выводы

В тесте не затронут вопрос производительности в реальном времени, а именно этот параметр важен для стрима, где и применяется софтверное кодирование. В настоящее время для старших процессоров intel на сокете 1151 v.2 с одновременной игрой в саму игру — достижим пресет medium для кодека x.264. Для старших процессоров AMD на сокете AM4 достижим пресет Slow для кодека x.264. В реальных задачах (уровень сложности 6) разница между пресетами есть, и достаточно ли она велика для того чтобы на основе неё делать выбор для стримменогового компьютера — решать только вам. Также стоит сказать, что существенно более высокое качество видео способен обеспечить пресет Slower, но для работы с ним в 1080p 60 FPS в реальном времени процессоров пока нет.

Ещё стоит отметить существенно большую чёткость изображения на средних пресетах x.265 в сравнении с x.264. Изображение полученное с пресетом x.265 Ultra Fast сопоставимо с изображением с пресетом slow x.264.

x.265 Ultra Fast требует существенно меньших затрат ресурсов, но поддержки кодека x.265 популярными стриминговыми сервисами нет.

Гипотетически достижимый сейчас пресет medium x.265 для кодирования в реальном времени и стриминга обеспечивал бы существенно более качественную картинку, чем технически недостижимый сейчас x.264 Slower.

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

Тем не менее для монтажа видео и его вывода не в масштабах реального времени целесообразно применять аппаратное кодирование.

Для сравнения в архиве с оригиналами сжатых видео находится видео полученное RTX 2070 с динамическим битрейтом и средним битрейтом в 20 Мб/с, с объёмом в 133 МБ, против 93 для Placebo h.264.

Кодирование видео заняло около 24 секунд и для 6-ой сложности получено качество ~8 баллов (примерно как x.265 medium и существенно лучше x.264 Slower).

Для 10-ой сложности качество при аппаратном кодировании RTX 2070 примерно соответствует x.265 Very Slow.

При этом производительность в кодировании/декодировании видео у видеокарт RTX 20** и GTX 16** (за исключением GTX 1650 не Super) — идентичная.

Вышеуказанная разница, естественно, получена с различным битрейтом, исходя из различных задач. Для расчётов процессором исходя из требований битрейта для стримов видеопотока, а для расчётов аппаратным кодированием видеокартой исходя из достаточности качества, то есть для получения качества сравнимого с обычными не стрим видео на Youtube. Пример тестового видео сжатого в VP9 после загрузки видео на Youtube имеется в архиве с видео.

Ссылки для скачивания исходных файлов:

Проект для Vegas Pro для создания не сжатого видео: тут (12 МБ)

Стоп кадры из тестовых видео: тут (502 МБ) (упаковано в архив 7-zip)

Видео зарендеренные с разными пресетами кодеков: тут (1,76 ГБ) (упаковано в архив 7-zip)

Видео на YouTube канале «Этот компьютер»

Сравнение магазинов комплектующих (2020)Как правильно наносить термопасту? Как пасту размазывает кулер и практические тесты.Элементы Пельтье для охлаждения компьютера (часть 1 | замеры эффективности и теория)InfoCAST #029 | Компьютерные новости февраля 2020Как изменялись самые выгодные (цена/производительность) видеокарты разных годов (тесты) (2016-2020)Как оплачиваются пошлины при покупке в иностранных интернет магазинахСтоит ли покупать самые бюджетные GTX 1650 Super?InfoCAST #028 | Необычные устройства на CES 2020 и др. новости январяУстаревание видеокарт NVIDIA vs AMD RadeonAMD RADEON | Драйвера 2016 vs 2020 | RX 470Intel, AMD и Nvidia на CES 2020Уточнение к видео про VRM (про работу даблеров)

Кодек H264. Где взять? Отдельно или в наборе?

Недавно задался вопросом — «Где взять кодек H264 ? «

Зачем он и почему у меня не оказалось его в установленной операционной системе, это второстепенно.

Обычно я ставлю все необходимые программы и в том числе кодеки, при установке системы.

Вот что написано о кодеке в википедии:

Ко́дек(англ. codec, от coder/decoder — шифратор/дешифратор — кодировщик/декодировщик или compressor/decompressor) — устройство или программа, способная выполнять преобразование данных или сигнала. Для хранения, передачи или шифрования потока данных или сигнала его кодируют с помощью кодека, а для просмотра или изменения — декодируют. Кодеки часто используются при цифровой обработке видео и звука.

Что конкретно представляет из себя кодек H264 можно почитать в википедии тут.

Где взять сам кодек ?

Тут два варианта решения данной проблемы:

1. Вам нужен только H264
2. Вам нужен весь стандартный набор кодеков, включая H264.

Если вам нужен только кодек H264.

То поступаем как вы догадались очень просто. Скачиваем его с официального сайта DivX тут.

Скачивайте только с проверенных сайтов  — сайтов производителей.

Если вам нужны все стандартные кодеки часто используемые.

В интернете предлагается множество наборов кодеков. Вам необходимо только определиться с выбором.  Скачав, один из наборов и установив его, вы получаете полный набор включая кодек H264.

Выбор зависит от вас. Я использую набор кодеков K-Lite Codec Pack.

Данный пакет предлагается в нескольких вариантах: Basic, Standard, Full, Mega, Update, Beta.

О каждом пакете вы можете почитать на официальном сайте в разделе скачать.

Как правило обычному пользователю хватает пакета Standart. В описании этого пакета так и написано

«Это рекомендуемый вариант для обычного пользователя. Используйте это, если вы не знаете, что вам нужно.»

Скачать вы можете его с официального сайта www.codecguide.com.

На этом сегодня все.

Всем Удачи!

Каталог

Видеокамеры AHD</li></ul>

Новости

Статьи о видеонаблюдении

Выбираете между аналоговыми и IP камерами? С помощью новых гибридных видеорегистраторов TBTEC можно использовать эти 2 технологии на одном объекте. Видеорегистраторы TBTEC серии TBR-H позволяют подключать одновременно аналоговые камеры с разрешением 960H и IP камеры Full HD. Благодаря HDMI выходу, картинку с регистраторов можно выводить на огромную ЖК панель с разрешением 1920*1080. Видеорегистраторы TBTEC поддерживают «облачную» Cloud технологию для удаленного просмотра и администрирования через Интернет без использования выделенного IP адреса. Все видеорегистраторы TBTEC имеют удобный русскоязычный интерфейс, графический поиск, мультипросмотр, поддержку всех современных мобильных устройств и WEB браузеров, а так же поставляются в комплекте с программой CMS, позволяющей объединить на 1 компьютере до 64 камер. …подробнее »

Бывают случаи, когда необходимо сделать резервную запись с камер видеонаблюдения на удаленный сервер, который расположен на значительном удалении от основного видеорегистратора или вообще находится на другом объекте. Это позволяет сохранить архив видеозаписи в случае выхода из строя жесткого диска, преднамеренной порчи или кражи видеорегистратора. Можно использовать платные облачные видеосервисы для записи информации, например Ivideon, либо осуществлять резервную запись на свое персональное «облако». Платные сервисы не всегда подходят,  во-первых, нужно будет платить каждый месяц абонентскую плату, во-вторых, качество будет не оригинальным из-за ограничения битрейта, в-третьих, не всех устраивает, что запись хранится на стороннем ресурсе.  Если рассматривать резервную запись на свое персональное «облако», то единственный минус — это разовая …подробнее »

В продаже присутствуют новые скоростные видеокамеры TBTEC с графическим меню на русском языке. Все видеокамеры имеют 22-кратный оптический зум, матрицу Sony 960H с процессором Effio-E, а так же интеллектуальную ИК-подсветку, которая вместе с двойным механическим ИК-фильтром позволяет видеть в полной темноте на расстоянии до 120 метров. Видеокамеры изготовлены из высококачественных деталей: «процессор», управляющий движениями видеокамеры, и содержащий её память — микроконтроллер ARM STM32, контроллер моторов – Toshiba TB62212FNG, автофокус управляется ARM STM8. Благодаря графическому меню на русском языке, можно удобно выставить все необходимые параметры, в том числе порог включения встроенного вентилятора, обогрева, отображение температуры камеры, туры патрулирования и все возможные электронные функции (BLC, ATR …подробнее »

Себестоимость проекта можно снизить правильной настройкой компрессии и шумоподавления. Снижается количество используемых жёстких дисков и требования к сетевой и воспроизводящей аппаратуре.   1)Шумоподавление   Наличие шумов матрицы, хаотично разбросанных по изображению пикселей, совершенно не вписывается в концепцию работы кодеков семейства MPEG (в том числе и H264): это и наличие движения в кадре, и ВЧ составляющая в блоках после косинусного преобразования, и внесение помех в матрицу квантования, что ухудшает качество восстановленного изображения. Из-за вышеописанных факторов, скорость видеопотока значительно возрастает, в несколько раз. То есть, при одном и том же качестве изображения битрейт видеопотока с настроенным шумоподавлением будет 3500 кбит/с, а видеопотока с ненастроенным шумоподавлением — 11400 кбит/с. Кроме этого, при заш…подробнее »

Сетевые IP камеры и видеорегистраторы TBTEC (TBR-H и TBR-N)  позволют подключаться к ним удаленно с мобильного устройства на базе IOS (IPhone, iPad), Mac или Android. Ниже описана процедура подключения в зависимости от используемого устройства. IOS: Для соединения видеокамеры (регистраторов TBR-H, TBR-N) с мобильным устройством на базе IOS (IPhone, iPad) необходимо установить из AppStore одну из программ: XMEye (для подключения либо по IP-адресу, либо через облачный сервер по серийному номеру камеры/регистратора), vMEyeSuper (для подключения по IP-адресу), vMEyeCloud (для подключения через облачный сервер по серийному номеру камеры), либо vMEyeIPC (эта программа позволяет подключаться как по IP адресу, так и через серийный номер). Для устройств Apple Mac в AppStore доступны к скачив…подробнее »

Наибольшей популярностью в современных сетевых IP камерах видеонаблюдения пользуются видеопроцессоры (DSP) HiSilicon двух серий: Hi3518 и Hi3516. Базовые модели видео процессоров данных серий были разработаны более 5 лет назад и постоянно модернизируются до сих пор. Параметры процессоров  существенно различаются в зависимости от буквы в наименование и версия (v) исполнения. Более бюджетными и менее производительными являются процессоры серии Hi3518. Параметры процессора этой серии позволяют использовать его в видеокамерах с разрешением до 1,3 Мп (960p). В линейке видеокамер TBTEC с процессором Hi3518 и матрицей на 1,3 Мп присутствуют следующие модели сетевых IP видеокамер: уличные — TBC-i1312IR и TBC-i1313IR, купольная — TBC-i3313IR и миниатюрная — TBC-i4312IR. При разрешении более 1,3 Мп скорость обработки процессора становится гораздо ниже …подробнее »

</ul>Используемые источники:

• https://pc-01.tech/x-264-x-265/
• https://propk.ru/kodek-h264/
• http://tbtec.ru/article.php