x264 или как кодировать видео
Проблема с кодированием видео и его сжатием его из гигабайтов в мегабайты, по-моему, всегда была актуальной. Если более менее профессиональные операторы, монтажники и т.д. уже не одну кошку съели на этой теме, то например любители и те, кто записывают видео с экрана своего монитора, порой долго чешут затылок, прежде чем добиться каких либо серьезных результатов. В итоге куча потерянного времени, никому не нужные гигабайты исходящего трафика для загрузки домашнего видео на ютуб. Конечно, можно использовать в какой-то степени готовые решения в лице одной программы, и сжать видео буквально тремя кликами, но это не наш подход, когда абсолютно все шаги можно контролировать и влиять на них. Покопавшись в поиске, Хабр так и не выдал ничего похожего. Хотя возможно, что просто плохо поискал.
Сразу оговорюсь, что изначально статья не моя. Я наткнулся на неё, лет пять назад, когда встала задача что-то делать с записанными моментами из тогда любимой многими игры Battlefield 2, на популярном отечественном ресурсе мувимейкеров. Постепенно статья допиливалась и публиковалась, то там, то там. Не исключаю, что первоначально статья пришла из-за «бугра» и всего на всего была переведена на наш могучий язык.
Итак, кодек х264 пришел на смену таким монстрам своего времени как DivX и XviD и удачно положил обоих на лопатки. Для того, что бы добиться действительно впечатляющего результата, нам понадобится следующие вещи:
1. MeGUI — этим мы сжимаем само видео. Вернее, сжимает сам кодек, а это только GUI объединивший в себе десятки разных специализированных утилит.
2. Avisynth — фреймсервер. Если вдруг кто не знает, что это такое, то он является посредником между нашим не сжатым видео и кодеком.
3. VLC media player — Тут совсем все просто. Всеядный плеер, умеющий работать с потоковым видео. Достаточно популярный.
4. K-Lite Codec Pack — пакет все возможных кодеков, на все случаи жизни. Нам нужна сборка Mega.
Настоятельно рекомендую обновлять K-Lite Codec Pack, как минимум всегда перед сжатием видео. Это конечно не обязательно, но опыт подсказывает, что если вы столкнетесь с непонятными ошибками/косяками/глюками/etc то в 50%, а то и больше, обновление кодеков избавит вас от лишнего геморроя.
Кстати, MeGUI достаточно быстро и часто обновляется и дополняется. Скриншоты приведенные ниже, могут уже не соответствовать текущей версии, но это не страшно. Как правило, меняется расположение элементов, что то пододвинули вправо, что-то перенесли в другую закладку. Пропажа находится очень быстро, поэтому не пугайтесь.
Поехали. Устанавливаем Avisynth, а затем MeGUI. После того, как MeGUI обновится, идем в папку, где лежит наш опытный образец, и для удобства создаем там файл с расширением *.avs. Открываем блокнотом и пишем заветные строки:
Первая строка, подскажет MeGUI с каким файлом требуется работать. Вторая строка, указывает на используемую систему цветов.
Существует несколько различных способов представление цвета. Например: цветовое пространство YUV и RGB. В YUV цветовом пространстве есть один компонент, который представляет яркость (сигнал яркости) и два других компонента, которые представляют цвет (сигнал цветности). В то время как яркость передается со всеми деталями, некоторые детали в компонентах сигнала цветности могут быть удалены путем понижения разрешения отсчетов (фильтрация или усреднение), что может быть сделано несколькими способами (т.е. есть много форматов для сохранения изображения в цветовом пространстве YUV). YV12 — один из таких форматов (тут сигнал цветности общий для каждого блока пиксел 2×2), который поддерживается AviSynth.
У нас получился скрипт. Идем дальше. Открываем MeGUI и указываем месторасположение скрипта. Если скрипт AviSynth находится в той же папке где и ваше видео, то вторая строка заполнится автоматически.
Открываем настройки кодека, нажатием на кнопку Config, справа от Encoder settings. Ставим галочку, подтверждая, что нам действительно нужны расширенные настройки. Дальше нам остается поставить галочки в соответствии со скриншотами.
Нажимаем на кнопку queue и идем спать, пить кофе и т.д. в зависимости от предпочтений и мощностей ПК.
Хочу оговориться, что данный конфиг подходит для исходного видео 720p. Для 1080p нужно немного под редактировать конфиг:
Так же можно указать, сколько кодеру можно использовать ядер:
Что мы получаем в итоге. Я имел в наличии следующий видео-ролик:
Format: RGB
Codec ID: 0x00000000
Codec ID/Info: Basic Windows bitmap format. 1, 4 and 8 bpp versions are palettised. 16, 24 and 32bpp contain raw RGB samples
Duration: 3mn 42s
Bit rate: 663 Mbps
Width: 1 280 pixels
Height: 720 pixels
Display aspect ratio: 16:9
Frame rate: 29.970 fps
Bit depth: 8 bits
Bits/(Pixel*Frame): 24.000
Stream size: 17.2 GiB (100%)
После ожидания около 15-16 минут, я получил на выходе 184 Мб.
Если Хабру интересны подобные статьи на тематику сжатия видео, то я продолжу и поделюсь своим опытом. Если хотите меня поправить и указать на ошибку, то с радостью отвечу на всю критику и замечания.
Влияние пресетов кодирования x.264 и x.265 на качество видео
Видео-версия этой статьи
Зачем нам кодеки и почему есть разное качество кодирования
Современные реалии, а именно широкое распространение видео в интернете, требуют быстро и качественно производить компрессию данных, и желательно, с минимальными требованиями к железной части как во время кодирования, так и во время декодирования уже на клиентском устройстве.
Для реализации этой идеи внедряются специальные алгоритмы (программы), называемые кодеками, которыми и совершается компрессия данных. Но, к сожалению, компрессия происходит с потерей информации, то есть после декомпрессии видео оно становится менее качественным, появляются разнообразные проблемы среди которых:
Однако распространённые сейчас кодеки способны в очень малый объём данных скомпрессировать видео практически без потерь, но достигается это значительным увеличением требований к производимым расчётам. Иными словами — сжатие происходит очень долго.
Для сжатия видео, когда оно производится заранее, то есть не в масштабах реального времени воспроизведения — эта проблема не так велика. Ведь если не важно передавать сжатый поток в реальном времени, то можно и поток сделать более широким, то есть выделить для сжатия больший битрейт видео, либо сжимать видео настолько долго, насколько это возможно. И в том и в другом случае получая высокое качество, правда с разной компрессией данных.
Однако такой сценарий доступен не всегда. Если требуется передавать поток в режиме реального времени, то скорость кодирования должна быть равна или выше, чем скорость воспроизведения видео. В таком случае гипотетически можно увеличить битрейт и тем самым использовать упрощённые методы сжатия, теряя меньше деталей при компрессии. И это было бы так, если бы современные стриминговые площадки не ограничивали доступный битрейт для видеопотока.
Иными словами — для того чтобы терять меньше качества при стриминге видео неизбежно надо применять более реусурсозатратные алгоритмы сжатия данных.
Какие есть пресеты настроек
И для кодека x.264 и для более современного кодека x.265 есть масса параметров которые влияют на качество кодирования. Десятки опций имеющих возможность переключения множества параметров, которые образуют десятки тысяч комбинаций настроек. И чтобы пользователю не приходилось тратить своё время на подбор оптимальных конфигураций были введены готовые пресеты настроек. И для кодека x.264 и для кодека x.265 этих пресетов 10.
Названия пресетов передают их суть. А если точнее характеризуют скорость кодирования видео. То есть пресет «Ultra Fast» позволяет кодировать видео ультрабыстро, «Slow» — кодировать медленно, а самый «прожорливый» — «Placebo» и вовсе придуман был просто «чтобы было» и чтобы показать, что такое качество тоже возможно, но возможность его реального применения — это скорее самовнушение, чем действительность.
С пресетами разобрались. Теперь надо разбираться с методикой тестирования и критериями и оценками качества.
Методика тестирования
И это сейчас самое важное. В целом — тестов пресетов кодеков и так много, но есть проблемы с методикой, а вернее с тем, что обычные методики не предполагают контроля того насколько сложная сцена. А именно сложность сцены влияет на качество кодирования.
Суть сжатия заключается в выборе опорного кадра и анализе изменений в последующих или соседних кадрах, и если этих изменений мало, то и описание изменений будет занимать мало места, а значит эти описания изменений могут поместится и в малый битрейт без значительного ухудшения качества. А если изменений в соседних кадрах будет много и они будут сложные как по цветам, так и по геометрии, то описать такие изменения будет либо сложно с точки зрения алгоритмов, либо сложно с точки зрения требований по объёму этих записей. Напомню, что мы рассматриваем случай когда в объёме мы ограничены.
В итоге для каждой из сложности кодирования нужно составить своего рода зависимость качества кодирования от сложности сцены для кодирования при неизменном битрейте.
Задача не тривиальная и, забегая вперёд, оценки будут субъективными, так как оценки я буду ставить… умозрительно, на основе визуальных дефектов. Тем не менее — даже чтобы глазами посмотреть на разницу эту разницу надо как-то сгенерировать и выбрать точные метрики для отслеживания качества.
Оценивать предлагаю по вот этому тестовому кадру:
Нажмите для увеличения
В нём есть довольно много интересных мест, которые будут меняться при сжатии.
Для наглядности вот GIF анимация нескольких этапов ухудшения качества. Естественно и сама GIF анимация использует сжатие, так что она не всецело отражает разницу, но все исходники будут размещены в самом низу статьи, и с ними может ознакомится любой желающий.
Нажмите на изображение чтобы открыть анимацию (2,6 МБ)
Основные отличия можно рассмотреть в чёткости сеток, в чёткости сложной спиральной формы скруглённой сетки, в равномерности и плавности градиентов цветов и цветовых переходов, в качестве градиентов серого цвета, в пиксилезации и замылинности текстур высокой контрастности и текстур низкой контрастности, в чёткости отображения текста.
Показанные выше изображения — это стоп кадры видео. Вы уже можете увидеть, что кроме тестовой сцены присутствую ещё разнообразные геометрические фигуры. Для видео они изменяются каждый кадр, именно они и создают разницу между кадрами, которую, меняя число фигур, можно регулировать. То есть чем больше фигур, тем выше сложность кодирования и тем хуже удаётся кодеку воспроизвести оригинал при ограниченном битрейте.
Видео состоит из 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 (наихудший результат) до 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).
Соотношение качество/производительность. Зелёный треугольник — результат RTX 2070 в сравнении с i9 9900k
Для 10-ой сложности качество при аппаратном кодировании RTX 2070 примерно соответствует x.265 Very Slow.
Соотношение качества/производительность. Зелёный треугольник — результат RTX 2070.
При этом производительность в кодировании/декодировании видео у видеокарт RTX 20** и GTX 16** (за исключением GTX 1650 не Super) — идентичная.
Вышеуказанная разница, естественно, получена с различным битрейтом, исходя из различных задач. Для расчётов процессором исходя из требований битрейта для стримов видеопотока, а для расчётов аппаратным кодированием видеокартой исходя из достаточности качества, то есть для получения качества сравнимого с обычными не стрим видео на Youtube. Пример тестового видео сжатого в VP9 после загрузки видео на Youtube имеется в архиве с видео.
Ссылки для скачивания исходных файлов:
Проект для Vegas Pro для создания не сжатого видео: тут (12 МБ)
Стоп кадры из тестовых видео: тут (502 МБ) (упаковано в архив 7-zip)
Видео зарендеренные с разными пресетами кодеков: тут (1,76 ГБ) (упаковано в архив 7-zip)
Видео на YouTube канале «Этот компьютер»
Сжатие видео на пальцах: как работают современные кодеки?
Затраты на хранение данных зачастую становятся основным пунктом расходов при создании системы видеонаблюдения. Впрочем, они были бы несравнимо больше, если бы в мире не существовало алгоритмов, способных сжимать видеосигнал. О том, насколько эффективны современные кодеки, и какие принципы лежат в основе их работы, мы и поговорим в сегодняшнем материале.
Для большей наглядности начнем с цифр. Пускай видеозапись будет вестись непрерывно, в разрешении Full HD (сейчас это уже необходимый минимум, во всяком случае, если вы хотите полноценно использовать функции видеоаналитики) и в режиме реального времени (то есть, с фреймрейтом 25 кадров в секунду). Предположим также, что выбранное нами оборудование поддерживает аппаратное кодирование H.265. В этом случае при разных настройках качества изображения (высоком, среднем и низком) мы получим примерно следующие результаты.
Кодек
Интенсивность движения в кадре
Использование дискового пространства за сутки, ГБ
H.265 (Высокое качество)
H.265 (Высокое качество)
H.265 (Высокое качество)
H.265 (Среднее качество)
H.265 (Среднее качество)
H.265 (Среднее качество)
H.265 (Низкое качество)
H.265 (Низкое качество)
H.265 (Низкое качество)
Но если бы сжатия видео не существовало в принципе, мы бы увидели совсем иные цифры. Попробуем разобраться, почему. Видеопоток представляет собой не что иное, как последовательность статичных картинок (кадров) в определенном разрешении. Технически каждый кадр является двумерным массивом, содержащим информацию об элементарных единицах (пикселях), формирующих изображение. В системе TrueColor для кодирования каждого пикселя требуется 3 байта. Таким образом, в приведенном примере мы бы получили битрейт:
Учитывая, что в сутках 86400 секунд, цифры выходят поистине астрономические:
Итак, если бы мы записывали видео без сжатия в максимальном качестве при заданных условиях, то для хранения данных, полученных с одной единственной видеокамеры в течение суток нам бы потребовалось 12 терабайт дискового пространства. Но даже система безопасности квартиры или малого офиса предполагает наличие, как минимум, двух устройств видеофиксации, тогда как сам архив необходимо сохранять в течение нескольких недель или даже месяцев, если того требует законодательство. То есть, для обслуживания любого объекта, даже весьма скромных размеров, потребовался бы целый дата-центр!
К счастью, современные алгоритмы сжатия видео помогают существенно экономить дисковое пространство: так, использование кодека H.265 позволяет сократить объем видео в 90 (!) раз. Добиться столь впечатляющих результатов удалось благодаря целому стеку разнообразных технологий, которые давно и успешно применяются не только в сфере видеонаблюдения, но и в «гражданском» секторе: в системах аналогового и цифрового телевидения, в любительской и профессиональной съемке, и многих других ситуациях.
Наиболее простой и наглядный пример — цветовая субдискретизация. Так называют способ кодирования видео, при котором намеренно снижается цветовое разрешение кадров и частота выборки цветоразностных сигналов становится меньше частоты выборки яркостного сигнала. Такой метод сжатия видеоданных полностью оправдан как с позиции физиологии человека, так и с точки зрения практического применения в области видеофиксации. Наши глаза хорошо замечают разницу в яркости, однако гораздо менее чувствительны к перепадам цвета, именно поэтому выборкой цветоразностных сигналов можно пожертвовать, ведь большинство людей этого попросту не заметит. В то же время, сложно представить, как в розыск объявляют машину цвета «паука, замышляющего преступление»: в ориентировке будет написано «темно-серый», и это правильно, ведь иначе прочитавший описание авто даже не поймет, о каком оттенке идет речь.
А вот со снижением детализации все оказывается уже совсем не так однозначно. Технически квантование (то есть, разбиение диапазона сигнала на некоторое число уровней с последующим их приведением к заданным значениям) работает великолепно: используя данный метод, размер видео можно многократно уменьшить. Но так мы можем упустить важные детали (например, номер проезжающего вдалеке автомобиля или черты лица злоумышленника): они окажутся смазаны и такая запись будет для нас бесполезной. Как же поступить в этой ситуации? Ответ прост, как и все гениальное: стоит взять за точку отсчета динамические объекты, как все тут же становится на свои места. Этот принцип успешно используется со времен появления кодека H.264 и отлично себя зарекомендовал, открыв ряд дополнительных возможностей для сжатия данных.
Это было предсказуемо: разбираемся, как H.264 сжимает видео
Вернемся к таблице, с которой мы начали. Как видите, помимо таких параметров, как разрешение, фреймрейт и качество картинки решающим фактором, определяющим конечный размер видео, оказывается уровень динамичности снимаемой сцены. Это объясняется особенностями работы современных видеокодеков вообще, и H.264 в частности: используемый в нем механизм предсказания кадров позволяет дополнительно сжимать видео, при этом практически не жертвуя качеством картинки. Давайте посмотрим, как это работает.
Кодек H.264 использует несколько типов кадров:
Поскольку в процессе вычитания возможны ошибки, приводящие к появлению графических артефактов, то через какое-то количество кадров схема повторяется: вновь формируется опорный кадр, а вслед за ним — серия кадров с изменениями.
Полное изображение формируется путем «наложения» P-кадров на опорный кадр. При этом появляется возможность независимой обработки фона и движущиеся объектов, что позволяет дополнительно сэкономить дисковое пространство без риска упустить важные детали (черты лиц, автомобильные номера и т. д.). В случае же с объектами, совершающими однообразные движения (например, вращающимися колесами машин) можно многократно использовать одни и те же разностные кадры.
Независимая обработка статических и динамических объектов позволяет сэкономить дисковое пространство
Данный механизм носит название межкадрового сжатия. Предсказанные кадры формируются на основе анализа широкой выборки зафиксированных состояний сцены: алгоритм предвидит, куда будет двигаться тот или иной объект в поле зрения камеры, что позволяет существенно снизить объем записываемых данных при наблюдении за, например, проезжей частью.
Кодек формирует кадры, предсказывая, куда будет двигаться объект
В свою очередь, использование двунаправленных предсказанных кадров позволяет в несколько раз сократить время доступа к каждому кадру в потоке, поскольку для его получения будет достаточно распаковать только три кадра: B, содержащий ссылки, а также I и P, на которые он ссылается. В данном случае цепочку кадров можно изобразить следующим образом.
Такой подход позволяет существенно повысить скорость быстрой перемотки с показом и упростить работу с видеоархивом.
В чем разница между H.264 и H.265?
В H.265 используются все те же принципы сжатия, что и в H.264: фоновое изображение сохраняется единожды, а затем фиксируются лишь изменения, источником которых являются движущиеся объекты, что позволяет значительно снизить требования не только к объему хранилища, но и к пропускной способности сети. Однако в H.265 многие алгоритмы и методы прогнозирования движения претерпели значительные качественные изменения.
Так, обновленная версия кодека стала использовать макроблоки дерева кодирования (Coding Tree Unit, CTU) переменного размера с разрешением до 64×64 пикселей, тогда как ранее максимальный размер такого блока составлял лишь 16×16 пикселей. Это позволило существенно повысить точность выделения динамических блоков, а также эффективность обработки кадров в разрешении 4K и выше.
Кроме того, H.265 обзавелся улучшенным deblocking filter — фильтром, отвечающим за сглаживание границ блоков, необходимым для устранения артефактов по линии их стыковки. Наконец, улучшенный алгоритм прогнозирования вектора движения (Motion Vector Predictor, MVP) помог заметно снизить объем видео за счет радикального повышения точности предсказаний при кодировании движущихся объектов, чего удалось достичь за счет увеличения количества отслеживаемых направлений: если ранее учитывалось лишь 8 векторов, то теперь — 36.
Помимо всего перечисленного выше, в H.265 была улучшена поддержка многопоточных вычислений: квадратные области, на которые разбивается каждый кадр при кодировании, теперь могут обрабатываться независимо одна от другой. Появилась и поддержка волновой параллельной обработки данных (Wavefront Parallelel Processing, WPP), что также способствует повышению производительности сжатия. При активации режима WPP обработка CTU осуществляется построчно, слева направо, однако кодирование каждой последующей строки может начаться еще до завершения предыдущей в том случае, если данных, полученных из ранее обработанных CTU, для этого достаточно. Кодирование различных строк CTU с временной задержкой со сдвигом, наряду с поддержкой расширенного набора инструкций AVX/AVX2 позволяет дополнительно повысить скорость обработки видеопотока в многоядерных и многопроцессорных системах.
Флэш-карты для видеонаблюдения: когда значение имеет не только размер
И вновь вернемся к табличке, с которой мы начали сегодняшний разговор. Давайте подсчитаем, сколько дискового пространства нам понадобится в том случае, если мы хотим хранить видеоархив за последние 30 дней при максимальном качестве видеозаписи:
По нынешним меркам 4 терабайта для винчестера индустриального класса — практически ничто: современные жесткие диски для видеонаблюдения имеют емкость до 14 терабайт и могут похвастаться рабочим ресурсом до 360 ТБ в год при MTBF до 1.5 миллионов часов. Что же касается карт памяти, то здесь все оказывается не так однозначно.
В IP-камерах флэш-карты играют роль резервных хранилищ: данные на них постоянно перезаписываются, чтобы в случае потери связи с видеосервером недостающий фрагмент видеозаписи можно было восстановить из локальной копии. Такой подход позволяет существенно повысить отказоустойчивость всей системы безопасности, однако при этом сами карты памяти испытывают колоссальные нагрузки.
Как видно из нашей таблицы, даже при низком качестве изображения и при условии минимальной активности в кадре, всего за сутки будет записано около 24 ГБ видео. А это значит, что 128-гигабайтная карточка будет полностью перезаписана менее чем за неделю. Если же нам требуется получать максимально качественную картинку, то все данные на таком носителе будут полностью обновляться раз в сутки! И это лишь при разрешении Full HD. А если нам понадобится картинка в 4K? В этом случае нагрузка вырастет практически в два раза (в заданных условиях видео в максимальном качестве потребует уже 250 ГБ).
При бытовом использовании подобное попросту невозможно, поэтому даже самая бюджетная карта памяти способна прослужить вам несколько лет к ряду без единого сбоя. А все благодаря алгоритмам выравнивания износа (wear leveling). Схематично их работу можно описать следующим образом. Пусть в нашем распоряжении есть новенькая флеш-карта, только что из магазина. Мы записали на нее несколько видеороликов, использовав 7 из 16 гигабайт. Через некоторое время мы удалили часть ненужных видео, освободив 3 гигабайта, и записали новые, объем которых составил 2 ГБ. Казалось бы, можно задействовать только что освободившееся место, однако механизм выравнивания износа выделит под новые данные ту часть памяти, которая ранее никогда не использовалась. Хотя современные контроллеры «тасуют» биты и байты куда более изощренно, общий принцип остается неизменным.
Напомним, что кодирование битов информации происходит путем изменения заряда в ячейках памяти за счет квантового туннелирования электронов сквозь слой диэлектрика, что вызывает постепенный износ диэлектрических слоев с последующей утечкой заряда. И чем чаще меняется заряд в конкретной ячейке, тем раньше она выйдет из строя. Выравнивание износа как раз направлено на то, чтобы каждая из доступных ячеек перезаписывалась примерно одинаковое количество раз и, таким образом, способствует увеличению срока службы карты памяти.
Нетрудно догадаться, что wear leveling перестает играть хоть сколько-нибудь значимую роль в том случае, если флэш-карта постоянно перезаписывается целиком: здесь на первый план уже выходит выносливость самих чипов. Наиболее объективным критерием оценки последней является максимальное количество циклов программирования/стирания (program/erase cycle), или, сокращенно, циклов P/E, которое способно выдержать флеш-память. Также достаточно точным и в данном случае наглядным (так как мы можем заранее рассчитать объемы перезаписи) показателем является коэффициент TBW (Terabytes Written). Если в технических характеристиках указан лишь один из перечисленных показателей, то вычислить другой не составит особого труда. Достаточно воспользоваться следующей формулой:
TBW = (Емкость × Количество циклов P/E)/1000
Так, например, TBW флеш-карты емкостью 128 гигабайт, ресурс которой составляет 200 P/E, будет равен: (128 × 200)/1000 = 25,6 TBW.
Давайте считать дальше. Выносливость карт памяти потребительского уровня составляет 100–300 P/E, и 300 — это в самом лучшем случае. Опираясь на эти цифры, мы можем с достаточно высокой точностью оценить срок их службы. Воспользуемся формулой и заполним новую таблицу для карты памяти емкостью 128 ГБ. Возьмем за ориентир максимальное качество картинки в Full HD, то есть в сутки камера будет записывать 138 ГБ видео, как мы выяснили ранее.
Ресурс карты памяти, циклов P/E