Что такое videofx decoder

Что такое VideoFx.exe? Это безопасно или вирус? Как удалить или исправить это

Что такое VideoFx.exe?

VideoFx.exe это исполняемый файл, который является частью VideoCap Pro ActiveX Control Программа, разработанная Viscom Software, Программное обеспечение обычно о 11.21 MB по размеру.

VideoFx.exe безопасно, или это вирус или вредоносная программа?

Первое, что поможет вам определить, является ли тот или иной файл законным процессом Windows или вирусом, это местоположение самого исполняемого файла. Например, такой процесс, как VideoFx.exe должен запускаться, а не в другом месте.

Если статус процесса «Проверенная подписывающая сторона» указан как «Невозможно проверить», вам следует взглянуть на процесс. Не все хорошие процессы Windows имеют метку проверенной подписи, но ни один из плохих.

Самые важные факты о VideoFx.exe:

Если у вас возникли какие-либо трудности с этим исполняемым файлом, перед удалением VideoFx.exe вам следует определить, заслуживает ли он доверия. Для этого найдите этот процесс в диспетчере задач.

Найдите его местоположение (оно должно быть в C: \ Program Files \ VideoCap Pro ActiveX Control \) и сравните размер и т. Д. С приведенными выше фактами.

Если вы подозреваете, что можете быть заражены вирусом, вы должны немедленно попытаться это исправить. Чтобы удалить вирус VideoFx.exe, вам необходимо Загрузите и установите приложение полной безопасности, например Malwarebytes., Обратите внимание, что не все инструменты могут обнаружить все типы вредоносных программ, поэтому вам может потребоваться попробовать несколько вариантов, прежде чем вы добьетесь успеха.

Могу ли я удалить или удалить VideoFx.exe?

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

Однако, если это не вирус и вам необходимо удалить VideoFx.exe, вы можете удалить VideoCap Pro ActiveX Control со своего компьютера с помощью программы удаления, которая должна находиться по адресу: «C: \ Program Files \ VideoCap Pro ActiveX Control \» unins000.exe «. Если вы не можете найти его деинсталлятор, вам может потребоваться удалить VideoCap Pro ActiveX Control, чтобы полностью удалить VideoFx.exe. Вы можете использовать функцию «Добавить / удалить программу» в Панели управления Windows.

Распространенные сообщения об ошибках в VideoFx.exe

Наиболее распространенные ошибки VideoFx.exe, которые могут возникнуть:

• «Ошибка приложения VideoFx.exe.»
• «Ошибка VideoFx.exe».
• «VideoFx.exe столкнулся с проблемой и будет закрыт. Приносим извинения за неудобства.»
• «VideoFx.exe не является допустимым приложением Win32».
• «VideoFx.exe не запущен».
• «VideoFx.exe не найден».
• «Не удается найти VideoFx.exe».
• «Ошибка запуска программы: VideoFx.exe.»
• «Неверный путь к приложению: VideoFx.exe».

Как исправить VideoFx.exe

Если у вас возникла более серьезная проблема, постарайтесь запомнить последнее, что вы сделали, или последнее, что вы установили перед проблемой. Использовать resmon Команда для определения процессов, вызывающих вашу проблему. Даже в случае серьезных проблем вместо переустановки Windows вы должны попытаться восстановить вашу установку или, в случае Windows 8, выполнив команду DISM.exe / Online / Очистка-изображение / Восстановить здоровье, Это позволяет восстановить операционную систему без потери данных.

Чтобы помочь вам проанализировать процесс VideoFx.exe на вашем компьютере, вам могут пригодиться следующие программы: Менеджер задач безопасности отображает все запущенные задачи Windows, включая встроенные скрытые процессы, такие как мониторинг клавиатуры и браузера или записи автозапуска. Единый рейтинг риска безопасности указывает на вероятность того, что это шпионское ПО, вредоносное ПО или потенциальный троянский конь. Это антивирус обнаруживает и удаляет со своего жесткого диска шпионское и рекламное ПО, трояны, кейлоггеры, вредоносное ПО и трекеры.

Обновлен декабрь 2021:

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

Загрузите или переустановите VideoFx.exe

Вход в музей Мадам Тюссо не рекомендуется загружать заменяемые exe-файлы с любых сайтов загрузки, так как они могут содержать вирусы и т. д. Если вам нужно скачать или переустановить VideoFx.exe, мы рекомендуем переустановить основное приложение, связанное с ним. VideoCap Pro ActiveX Control.

Информация об операционной системе

Ошибки VideoFx.exe могут появляться в любых из нижеперечисленных операционных систем Microsoft Windows:

Источник

Библиотеки для декодирования видео. Сравнение на Python и Rust

Многие задаются вопросом — насколько медленный Python в операциях декодирования? Правда ли, что компилируемые языки дают прирост скорости во всем, чего касаются? Что быстрее: OpenCV или ничего? Ответы на эти и другие бесполезные вопросы под катом вы прочитать не сможете. Там обычное скучное исследование производительности в конкретной задаче.
Все заинтересовавшиеся, добро пожаловать!

Основная часть проекта, над которым я работаю, состоит в распознавании людей и их действий на видео в реальном времени. Изначально он был написан на Python+OpenCV. Разумеется, в какой-то момент внезапно потребовалось наращивать масштаб, повышать производительность и всячески оптимизировать. И первым делом я решил осмотреться среди библиотек для работы с видеопотоком. А заодно узнать как сильно язык влияет на производительность этой задачи.

Рассматривал самые популярные (на самом деле, выбор не особо велик):

VLC и Valkka отпали практически сразу. Первый без вызова графического интерфейса так и не заработал. На второй крайне мало документации и еще меньше библиотек для других языков.

А вот о первых трех я расскажу поподробнее и сравню их производительность на Python.

OpenCV

Плюсы

Минусы

После запроса кадра мы сразу получаем готовый numpy.ndarray, да еще и в BGR (к слову операция преобразования в RGB достаточно быстрая). И если для простой программы проблем нет, то для более сложной, когда производительности одного ядра не хватает, начинаются проблемы. А любая попытка распараллелить обработку с помощью библиотеки мультипроцессинга начинает забирать дополнительные ресурсы, так как при передаче между процессами объекты в python должны быть pickable.

Это означает, что библиотека, например, при добавлении в Queue, для передаваемых объектов автоматически выполняет pickle.dumps() и pickle.loads() (к слову в версии Python 3.8 пообещали эту проблему исправить через shared memory). Это довольно накладно для FullHD кадров. В качестве ndarray кадр занимает

6мб оперативной памяти.

То же происходит и при попытке передать эти данные по сети. Полученный numpy.ndarray нужно преобразовать в bytes перед отправкой, на что тратится довольно значительное количество процессорного времени.

FFmpeg

Плюсы

Минусы

GStreamer

Плюсы

Минусы

Примеры кода и производительность

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

Для OpenCV объяснения вряд ли требуются. Статей о начале работы с этой библиотекой — полный хабр.

Для FFmpeg есть несколько библиотек для Python (ffmpeg-python, scikit-video, ffmpy, ffmpeg). Лучшая, на мой взгляд, ffmpeg-python: хорошая документация, удобный синтаксис запросов. Но все эти библиотеки — только обертка поверх консольного вызова через subprocess.Popen и последующей передачей данных через linux pipe в stdout, а код на Python уже слушает stdout и превращает данные в numpy ndarray.

Выглядит это примерно следующим образом:

В приведенном выше коде есть несколько интересных моментов. Например, чтобы прочитать bytearray нужно знать разрешение кадра. Можно, конечно, воспользоваться ffprobe и так же, запустив его в отдельном субпроцессе, получить эти данные перед началом обработки. Но это крайне неудобно, и время запуска удваивается, т. к. ffprobe должен подключиться к rtsp-потоку и взять один кадр.

Второй момент — это цветовое пространство. По умолчанию все видео файлы и видеопотоки используют подмножество YUV, чаще это I420 (YUV420p), кадр которого состоит из полного кадра яркости и двух цветоразностных полукадров. А модели свёрточных нейросетей чаще всего обучены на RGB.

Кстати, декодирование кадра на GPU (например на NVDEC) преобразует кадр в цветовое пространство NV12 которое тоже является подмножеством YUV. В случае с ffmpeg мы можем задать преобразование через него или использовать функции OpenCV. Разницу будет видно в тестах производительности.

C GStreamer все несколько больше кода, но, в целом, не сложнее.

У GStreamer отличие в специальном элементе appsink, который вызывает callback-функцию и передает в нее полученный кадр.

Что же с производительностью?

Все варианты тестирования производились на Intel Core i5-6600K, по 10 итераций. Для Python использовалась библиотека timeit. В качестве тестового видео взял стандартное Tractor_500kbps_x264.mp4.

Native

У FFmpeg и GStreamer есть возможность проверить производительность обработки, сбрасывая кадры в /dev/null. Эти цифры мы будем считать за базовые.

OpenCV

Здесь опций мало. Мы можем замерить только получение кадра и конвертацию в два цветовых пространства с эмуляцией через pickle передачи по сети или в соседний процесс. Как видно, на больших объемах данных pickle полностью убивает производительность.

FFmpeg

Здесь опций уже больше. Потому что появляется возможность использовать встроенный преобразователь цветового пространства или использовать встроенный в OpenCV. Также отпадает необходимость сериализовывать кадр через pickle при отправке по сети или в соседний процесс.

Как видно, собственная функция преобразования цветового пространства работает помедленнее, чем в OpenCV. yuv_gray — это яркостная составляющая I420 кадра, а цветоразностную схему просто выбрасываем.

GStreamer

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

Преобразование цветового пространства еще медленнее, чем в FFmpeg. Остальные форматы чуть быстрее из-за нормального способа передачи кадра.

При обработке через Python теряется примерно 30% производительности относительно тестового случая. Однако, как видно будет дальше, GStreamer, на самом деле, сильно оптимизирует вывод, чем выигрывает больше скорости, и реальная цифра находится в пределах от 10% до 20%. Также в начале мне показалось странным, что преобразование в RGB быстрее, чем в GRAY8. Но это подтверждается тестированием без python:

Казалось бы, возможно, это Python слишком медленный, и можно использовать какой-нибудь компилируемый язык, чтобы выжать еще немножко скорости. В качестве нового модного и молодежного языка будет Rust.

OpenCV

GStreamer

В случае с OpenCV прироста вообще не получилось. А вот GStreamer дает

15% прироста производительности. Причем основная производительность опять же теряется на конвертации цветового пространства через OpenCV. Основное предположение, что в случае с Python используется библиотека opencv-python из pypi, в составе которой поставляется OpenCV, собранный с оптимизациями. Здесь же используется системный, из репозиториев Arch Linux.

В итоге получается, что комбинация декодирования через GStreamer и конвертации цветого пространства через OpenCV позволяет добиться хорошей производительности и гибкости при написании параллельного или распределённого по сети кода.

Источник

Что такое Ffdshow? Как скачать программу, установить и настроить?

Программа Ffdshow – это пакет аудио и видео кодеков в совокупности с системой постобработки потокового видео и аудио сигнала. Она работает по принципу DirectShow фильтра, что позволяет программе встраиваться в работу практически любого видеоплеера.

Что это за программа и для чего нужна?

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

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

Отличительная черта данного программного обеспечения — отсутствие встроенного плеера для воспроизведения видео контента. То есть, Ffdshow будет интегрироваться в работу уже установленных плееров на вашем компьютере. Программное обеспечение распространяется по лицензии GNU General Public License version 2.0 (GPLv2). То есть, она передается бесплатно и может быть скачана любым пользователем для личных или коммерческих нужд.

Официальный язык программы — английский. Но при первоначальной установке можно выставить русскую версию. Вообще Ffdshow поддерживает огромное количество языков.

Программа Ffdshow впервые появилась в 2002 году и была альтернативой декодерам DivX 3.11 и DivX 5.02. До 2006 года разработка велась одним программистом Milan Cutka. Позже проект перешел в руки ffdshow-tryouts. Сегодня проектом занимается группа разработчиков, включая компанию Ffmpeg.

Как настраивать Video Decoder?

Условно область настроек можно разбить на две части:

В нижней части программы располагаются кнопки «отмена», «ок» и «подтвердить». Также есть отдельная кнопка под экспорт настроек.

Как скачать и установить эту программу?

Для оптимальной работы потребуется компьютер или ноутбук с минимальными системными требованиями:

Вообще данная программа очень нетребовательна к ресурсам компьютера.

Мощное «железо» может потребоваться именно для обработки видео хорошего качества. Например, в разрешении 720р или 1080р.

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

Источник

Аппаратное декодирование

Для поддержки технологии аппаратной поддержки воспроизведения, DirectX Video Acceleration (DXVA), требуются специальные декодеры (например, NVIDIA PureVideo Decoder, CyberLink MPEG2 и H.264 video decoder), и проигрыватели с поддержкой DXVA. На данный момент существуют DXVA-декодеры для аппаратного ускорения MPEG2, WMV, VC-1 и H.264

У разных видеочипов уровень поддержки аппаратного ускорения декодирования видео разный, он зависит от модели карты и установленного чипа. Ранее, некоторые low-end решения были ограничены в поддержке декодирования видео высоких разрешений, но складывается обратная ситуация — что у AMD, что у NVIDIA. Верхние чипы линеек, GeForce и RADEON, не поддерживают всех возможностей, которыми обладают решения среднего и низшего ценовых диапазонов.

Аппаратное ускорение работает не всегда идеально, не со всеми декодерами и типами видеоданных. Так, изначально сразу несколько производителей плееров и декодеров H.264 объявили о поддержке ускорения в решениях. На деле это были, скорее, рекламные заявления, и ускорение H.264 или не работало вовсе или работало кое-как. Например, в своё время на рынке появилась версия PowerDVD 7.0 с поддержкой декодирования H.264, но не работающим аппаратным ускорением, версия того декодера была 1.6.0.1528. При использовании этого декодера ускорение включается, но на деле не работает.

Кроме того, на разных моделях видеокарт одной и той же компании ускорение может работать, а может не работать. Особенно это относится к low-end и mid-end решениям прошлых поколений, таких как GeForce 6600 и RADEON X1300. Бывали случаи, когда при выполнении одинаковой последовательности действий, ускорение включалось на одной карте, но не включалось на другой. Это ещё не все проблемы аппаратного декодирования, так, H.264 декодер CyberLink в DXVA ускоренном режиме всегда отключает деблокинг (удаление артефактов блочности изображения), что хорошо заметно на плавных цветовых переходах. и стоит отметить, что некоторые версии декодеров могли работать в аппаратно ускоренном режиме на видеокартах одного производителя, и не работать на видеокартах другого, в зависимости от версий драйверов.

Источник

Как работает видеокодек. Часть 2. Что, для чего, как

Первая часть: Основы работы с видео и изображениями

Что? Видеокодек — это часть программного/аппаратного обеспечения, сжимающая и/или распаковывающая цифровое видео.

Для чего? Невзирая на определённые ограничения как по пропускной способности так
и по количеству места для хранения данных, рынок требует всё более качественного видео. Припоминаете, как в прошлом посте мы подсчитали необходимый минимум для 30 кадров в секунду, 24 бита на пиксель, с разрешение 480×240? Получили 82,944 Мбит/с без сжатия. Сжатие — это пока единственный способ вообще передавать HD/FullHD/4K на телевизионные экраны и в Интернет. Как это достигается? Сейчас кратко рассмотрим основные методы.

Перевод сделан при поддержке компании EDISON Software.

Кодек vs Контейнер

Распространенная ошибка новичков — путать кодек цифрового видео и контейнер цифрового видео. Контейнер это некий формат. Обёртка, содержащая метаданные видео (и, возможно, аудио). Сжатое видео можно рассматривать как полезную нагрузку контейнера.

Обычно расширение видеофайла указывает на разновидность контейнера. Например, файл video.mp4, вероятно всего, является контейнером MPEG-4 Part 14, а файл с именем video.mkv — это, скорее всего, матрёшка. Чтобы быть полностью уверенным в кодеке и формате контейнера, можно воспользоваться FFmpeg или MediaInfo.

Немного истории

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

Видеокодек H.261 появился в 1990 году (технически — в 1988) и был создан для работы со скоростью передачи данных 64 Кбит/с. В нём уже использовались такие идеи, как цветовая субдискретизация, макроблоки и т.п. В 1995 году был опубликован стандарт видеокодека H.263, который развивался до 2001 года.

В 2003 году была завершена первая версия H.264/AVC. В том же году компания «TrueMotion» выпустила свой бесплатный видеокодек, сжимающий видео с потерями под названием VP3. В 2008 году Google купил эту компанию, выпустив VP8 в том же году. В декабре 2012 года Google выпустил VP9, ​​и он поддерживается примерно на ¾ рынка браузеров (включая мобильные устройства).

AV1 — это новый бесплатный видеокодек с открытым исходным кодом, разработанный Альянсом за открытые медиа (AOMedia), в состав которого входят известнейшие компании, как-то: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel и Cisco. Первая версия кодека 0.1.0 была опубликована 7 апреля 2016 года.

Рождение AV1

В начале 2015 года Google работал над VP10, Xiph (который принадлежит Mozilla) работал над Daala, а Cisco сделала свой бесплатный видеокодек под названием Thor.

Затем MPEG LA сначала объявила годовые лимиты для HEVC (H.265) и плату, в 8 раз выше, чем за H.264, но вскоре они снова изменили правила:

без годового лимита,
плата за контент (0,5% от выручки) и
плата за единицу продукции примерно в 10 раз выше, чем за H.264.

Альянс за открытые медиа был создан компаниями из разных сфер: производителями оборудования (Intel, AMD, ARM, Nvidia, Cisco), поставщиками контента (Google, Netflix, Amazon), создателями браузеров (Google, Mozilla) и другими.

У компаний была общая цель — видеокодек без лицензионных отчислений. Затем появляется AV1 с гораздо более простой патентной лицензией. Тимоти Б. Терриберри сделал сногсшибательную презентацию, ставшей источником текущей концепции AV1 и её модели лицензии.

Вы будете удивлены, узнав, что можно анализировать кодек AV1 через браузер (заинтересовавшиеся могут перейти по адресу aomanalyzer.org).

Универсальный кодек

Разберём основные механизмы, лежащие в основе универсального видеокодека. Большинство из этих концепций полезны и используются в современных кодеках, таких как VP9, AV1 и HEVC. Предупреждаю, что многие объясняемые вещи будут упрощены. Иногда будут использоваться реальные примеры (как в случае с H.264) для демонстрации технологий.

1-й шаг — разбиение изображения

Первым шагом является разделение кадра на несколько разделов, подразделов и далее.

Для чего? Есть множество причин. Когда дробим картинку, можно точнее прогнозировать вектор движения, используя небольшие разделы для маленьких движущихся частей. В то время как для статического фона можно ограничиться и более крупными разделами.

Обычно кодеки организуют эти разделы в секции (или фрагменты), макроблоки (или блоки дерева кодирования) и множество подразделов. Максимальный размер этих разделов варьируется, HEVC устанавливает 64×64, в то время как AVC использует 16×16, а подразделы могут дробиться до размеров 4×4.

Припоминаете разновидности кадров из прошлой статьи?! Это же можно применить и к блокам, так что, у нас могут быть I-фрагмент, B-блок, P-макроблок и т.п.

Для желающих попрактиковаться — посмотрите как изображение разобъётся на разделы и подразделы. Для этого можно воспользоваться уже упоминаемой в прошлой статье Intel Video Pro Analyzer (тот, что платный, но с бесплатный пробной версией, имеющей ограничение на первые 10 кадров). Здесь проанализированы разделы VP9:

2-й шаг — прогнозирование

Как только у нас появились разделы, мы можем составлять астрологические прогнозы по ним. Для INTER-прогнозирования необходимо передать векторы движения и остаток, а для INTRA-прогнозирования передаётся направление прогноза и остаток.

3-й шаг — преобразование

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

Хотя есть и другие методы, рассмотрим более подробно дискретное косинусное преобразование (DCT — от discrete cosine transform). Основные функции DCT:

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

Давайте возьмем такой блок пикселей 8×8:

Этот блок рендерится в следующее изображение 8 на 8 пискелей:

Применим DCT к этому блоку пикселей и получаем блок коэффициентов размером 8×8:

И если отрендерим этот блок коэффициентов, получим такое изображение:

Как видим, это не похоже на исходное изображение. Можно заметить, что первый коэффициент сильно отличается от всех остальных. Этот первый коэффициент известен как DC-коэффициент, представляющий все выборки во входном массиве, нечто похожее на среднее значение.

У этого блока коэффициентов есть интересное свойство: он отделяет высокочастотные компоненты от низкочастотных.

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

Частота означает, насколько быстро меняется сигнал.

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

Сначала конвертируем его в частотную область.

Далее отбрасываем часть (67%) коэффициентов, в основном нижнюю правую часть.

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

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

Каждый коэффициент формируется с использованием всех пикселей

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

Вы также можете попытаться визуализировать DCT, взглянув на простое формирование изображения на его основе. Например, вот символ A, формируемый с использованием каждого веса коэффициента:

4-й шаг — квантование

После того как на предыдущем шаге выбрасываем некоторые коэффициенты, на последнем шаге (преобразование), производим особую форму квантования. На этом этапе допустимо терять информацию. Или, проще говоря, будем квантовать коэффициенты для достижения сжатия.

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

Можем ли обратить этот блок коэффициентов? Да, можем, умножив на то же значение, на которые делили.

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

5 шаг — энтропийное кодирование

После того, как мы квантовали данные (блоки изображений, фрагменты, кадры), все еще можем сжимать их без потерь. Существует много алгоритмических способов сжатия данных. Мы собираемся кратко познакомиться с некоторыми из них, для более глубокого понимания вы можете прочитать книгу «Разбираемся со сжатием: сжатие данных для современных разработчиков» («Understanding Compression: Data Compression for Modern Developers»).

Кодирование видео с помощью VLC

Сжимаем поток, предполагая, что в итоге потратим 8 бит на каждый символ. Без сжатия на символ понадобилось бы 24 бита. Если каждый символ заменять на его код, то получается экономия!

Первый шаг заключается в кодировании символа e, который равен 10, а второй символ — это a, который добавляется (не математическим способом): [10] [0], и, наконец, третий символ t, который делает наш финальный сжатый битовый поток равным [10] [0] [1110] или же 1001110, для чего требуется всего 7 бит (в 3,4 раза меньше места, чем в оригинале).

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

И кодер, и декодер должны иметь доступ к таблице символов со своими бинарными кодами. Поэтому также необходимо отправить во входных данных и таблицу.

Арифметическое кодирование

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

Теперь давайте закодируем поток из трёх символов: eat.

Сначала выбираем первый символ e, который находится в поддиапазоне от 0,3 до 0,6 (не включая). Берём этот поддиапазон и снова делим его в тех же пропорциях, что и ранее, но уже для этого нового диапазона.

Давайте продолжим кодировать наш поток eat. Теперь берём второй символ a, который находится в новом поддиапазоне от 0,3 до 0,39, а затем берём наш последний символ t и, повторяя тот же процесс снова, получаем последний поддиапазон от 0,354 до 0,372.

Нам просто нужно выбрать число в последнем поддиапазоне от 0,354 до 0,372. Давайте выберем 0,36 (но можно выбрать и любое другое число в этом поддиапазоне). Только с этим числом сможем восстановить наш оригинальный поток. Это как если бы мы рисовали линию в пределах диапазонов для кодирования нашего потока.

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

С первым диапазоном замечаем, что наше число соответствует срезу, следовательно, это наш первый символ. Теперь снова разделяем этот поддиапазон, выполняя тот же процесс, что и раньше. Тут можно заметить, что 0,36 соответствует символу a, и после повторения процесса мы пришли к последнему символу t (формируя наш исходный кодированный поток eat).

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

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

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

6 шаг — формат битового потока

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

Мы поверхностно ознакомимся с битовым потоком H.264. Нашим первым шагом является создание минимального битового потока H.264 (FFmpeg по умолчанию добавляет все параметры кодирования, такие как SEI NAL — чуть дальше узнаем, что это такое). Можем сделать это, используя наш собственный репозиторий и FFmpeg.

Данная команда сгенерирует необработанный битовый поток H.264 с одним кадром, разрешением 64×64, с цветовым пространством YUV420. При этом используется в качестве кадра следующее изображение.

Битовый поток H.264

Стандарт AVC (H.264) определяет, что информация будет отправляться в макрокадрах (в понимании сети), называемых NAL (это такой уровень абстракции сети). Основной целью NAL является предоставление «дружественного к сети» представления видео. Этот стандарт должен работать на телевизорах (на основе потоков), в Интернете (на основе пакетов).

Существует маркер синхронизации для определения границ элементов NAL. Каждый маркер синхронизации содержит значение за исключением самого первого, который равен Если запустим hexdump для сгенерированного битового потока H.264, то идентифицируем по крайней мере три паттерна NAL в начале файла.

Как говорилось, декодер должен знать не только данные изображения, но также и детали видео, кадра, цвета, используемые параметры и многое другое. Первый байт каждого NAL определяет его категорию и тип.

Обычно первым NAL битового потока является SPS. Этот тип NAL отвечает за информирование об общих переменных кодирования, таких как профиль, уровень, разрешение и прочее.

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

Например, первый байт после маркера синхронизации равен 01100111, где первый бит (0) находится в поле forbidden_zero_bit. Следующие 2 бита (11) сообщает нам поле nal_ref_idc, которое указывает, является ли этот NAL ссылочным полем или нет. И остальные 5 бит (00111) сообщает нам поле nal_unit_type, в данном случае это блок SPS (7) NAL.

Второй байт (binary=01100100, hex=0x64, dec=100) в SPS NAL — это поле profile_idc, которое показывает профиль, который использовал кодер. В данном случае использовался ограниченный высокий профиль (т.е. высокий профиль без поддержки двунаправленного B-сегмента).

Если ознакомиться со спецификацией битового потока H.264 для SPS NAL, то обнаружим много значений для имени параметра, категории и описания. Например, давайте посмотрим на поля pic_width_in_mbs_minus_1 и pic_height_in_map_units_minus_1.

Если продолжить проверку нашего созданного видео в двоичном виде (например: ), то можно перейти к последнему NAL, который является самим кадром.

Здесь видим его первые 6 байтовых значений: 01100101 10001000 10000100 00000000 00100001 11111111. Поскольку известно, что первый байт указывает на тип NAL, в данном случае (00101) это IDR фрагмент (5), и тогда получится дополнительно исследовать его:

Используя информацию спецификации, получится декодировать тип фрагмента (slice_type) и номер кадра (frame_num) среди других важных полей.

Чтобы получить значения некоторых полей (ue(v), me(v), se(v) или te(v)), нам нужно декодировать фрагмент, используя специальный декодер, основанный на экспоненциальном коде Голомба. Этот метод очень эффективен для кодирования значений переменных, особенно, когда если есть много значений по умолчанию.

Значения slice_type и frame_num этого видео равны 7 (I-фрагмент) и 0 (первый кадр).

Битовый поток можно рассматривать как протокол. Если желаете узнать больше о битовом потоке, стоит обратиться к спецификации ITU H.264. Вот макросхема, показывающая, где находятся данные изображения (YUV в сжатом виде).

Можно исследовать и другие битовые потоки, такие как VP9, H.265 (HEVC) или даже наш новый лучший битовый поток AV1. Все ли они похожи? Нет, но разобравшись хотя бы с одним — гораздо проще понять остальные.

Хотите попрактиковаться? Исследуйте поток битов H.264

Можно сгенерировать однокадровое видео и использовать MediaInfo для исследования потока битов H.264. Фактически, ничто не мешает даже поглядеть исходный код, который анализирует поток битов H.264 (AVC).

Для практики можно использовать Intel Video Pro Analyzer (я уже вроде говорил, что программа платная, но есть бесплатная пробная версия, с ограничением на 10 кадров?).

Обзор

Отметим, что многие современные кодеки используют ту же самую модель, которую только что изучили. Вот, давайте взглянем на блок-схему видеокодека Thor. Она содержит все шаги, нами пройденные. Весь смысл этой заметки в том, чтобы вы, по крайней мере, лучше понимали инновации и документацию из этой области.

Ранее рассчитали, что потребуется 139 Гб дискового пространства для хранения видеофайла длительностью один час при качестве 720p и 30 fps. Если использовать методы, которые разобрали в этой статье (межкадровые и внутренние прогнозы, преобразование, квантование, энтропийное кодирование и т.п.), то можно достичь (исходя из того, что тратим 0,031 бит на пиксель), видео вполне удовлетворительного качества, занимающее всего 367,82 Мб, а не 139 Гб памяти.

Как H.265 достигает лучшей степени сжатия, чем H.264?

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

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

HEVC имеет больше вариантов разделов (и подразделов), чем AVC, больше направлений внутреннего прогнозирования, улучшенное энтропийное кодирование и многое другое. Все эти улучшения сделали H.265 способным сжимать на 50% больше, чем H.264.

Источник