h264 amd vce что это

If your graphics card supports AMD App Acceleration, you will be able to enhance the recording ability of Bandicam by using the GPU of the graphics card. Bandicam 1.9.2 or a higher version supports the AMD VCE/VCN H.264 encoder, so Bandicam users can record the target with high speed, high compression ratio, and excellent quality.

HEVC (H.265) is better at compression than H.264 (The video quality of HEVC is better than H.264 if the file size is the same. The file size of HEVC is smaller than H.264 if the video quality is the same).

However, some media players don’t support HEVC and HEVC uses more CPU usage than H.264.
Users have to choose the proper codec to meet their needs.

The table below shows the file sizes, video quality and codec speed.

Codec	Size	Quality	Speed	Description
HEVC	33.5 MB	Better	Fast	Better than H.264 at compression
H264	34.2 MB	Better	Fast	Best codec for most users

(Recording time: one minute, Video resolution: 1920×1080, FPS: 30, Quality: 80) » Comparison of video codecs

To use the AMD VCE/VCN encoder, please follow the steps below:

Download/install the latest AMD video card driver

Choose the «H.264 (AMD VCE/VCN)» option from Bandicam

If you cannot see the «H.264 (AMD VCE/VCN)» option from Bandicam, please try the solutions below:

Try the latest version of Bandicam from https://www.bandicam.com/downloads/.

«H.264 (AMD VCE/VCN)» is available on Windows Vista/7/8/10/11.

Uninstall graphics card driver and reinstall the latest AMD video card driver.

Identify the model of your AMD graphics card.

If your graphics card supports «VIDEO CODEC ENGINE (VCE/VCN)«, you can use the AMD VCE H.264 encoder.
Please visit https://www.amd.com/ to check if your graphics card supports «VIDEO CODEC ENGINE (VCE)«.

Uncheck «Run this program in compatibility mode for:»

If you still can’t see the «H.264 (AMD VCE/VCN)» option,

Error message: «Your system does not support ‘H.264 (AMD VCE/VCN)’, so the default codec will be used.»

If you see the error message above when you use the ‘H.264 (AMD VCE/VCN)’ codec, go to your Windows Desktop, right-click, select Display settings, choose another display («No. 1» or «No.2») which is being used by AMD, check the Make this my main display option, and try it again.

Источник

Магия H.264

H.264 — стандарт сжатия видео. И он вездесущ, его используют для сжатия видео в интернете, на Blu-ray, телефонах, камерах наблюдения, дронах, везде. Все сейчас используют H.264.

Нельзя не отметить технологичность H.264. Он появился в результате 30-ти с лишним лет работы с одной единственной целью: уменьшение необходимой пропускной способности канала для передачи качественного видео.

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

Видео в несжатом виде это последовательность двумерных массивов, содержащих информацию о пикселях каждого кадра. Таким образом это трёхмерный (2 пространственных измерения и 1 временной) массив байтов. Каждый пиксель кодируется тремя байтами — один для каждого из трёх основных цветов (красный, зелёный и синий).

1080p @ 60 Hz = 1920x1080x60x3 =>

Этим практически невозможно было бы пользоваться. Blu-ray диск на 50Гб мог бы вмещать всего около 2 мин. видео. С копированием так же будет не легко. Даже у SSD возникнут проблемы с записью из памяти на диск.

Поэтому да, сжатие необходимо.

Обязательно отвечу на этот вопрос. Но сперва я покажу кое-что. Взгляните на главную страницу Apple:

Я сохранил изображение и приведу в пример 2 файла:

Эмм… что? Размеры файлов кажется перепутали.

Нет, с размерами всё в порядке. Видео H.264 с 300 кадрами весит 175 Кб. Один единственный кадр из видео в PNG — 1015 Кб.

Кажется, мы храним в 300 раз больше данных в видео, но получаем файл весом в 5 раз меньше. Получается H.264 эффективнее PNG в 1500 раз.

Как такое возможно, в чём заключается приём?

А приёмов очень много! H.264 использует все приёмы о которых вы догадываетесь (и уйму о которых нет). Давайте пройдёмся по основным.

Избавляемся от лишнего веса.

Представьте, что вы готовите машину к гонкам и вам нужно её ускорить. Что вы сделаете в первую очередь? Вы избавитесь от лишнего веса. Допустим, машина весит одну тонну. Вы начинаете выбрасывать ненужные детали… Заднее кресло? Пфф… выбрасываем. Сабвуфер? Обойдёмся и без музыки. Кондиционер? Не нужен. Коробка передач? В мусо… стойте, она еще пригодится.

Таким образом вы избавитесь от всего, кроме необходимого.

Этот метод отбрасывания ненужных участков называется сжатием данных с потерями. H.264 кодирует с потерями, отбрасывая менее значимые части и сохраняя при этом важные.

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

Важные части? Как алгоритм может определять их важность в кадре?

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

Что же на самом деле делает H.264?

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

Видите как на сжатом изображении исчезли отверстия в решётке динамика у MacBook Pro? Если не приближать, то можно и не заметить. Изображение справа весит всего 7% от исходного и это при том, что сжатия в традиционном смысле не было. Представьте машину весом всего лишь 70 кг!

7%, ого! Как возможно так избавиться от детализации?

Для начала немного математики.

Информационная энтропия

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

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

Предположим, что монета весьма странная — её подбросили 10 раз и каждый раз выпадал орёл. Как бы вы кому нибудь рассказали об этом? Вряд ли как-то вроде ОООООООООО, вы бы сказали «10 бросков, все орлы» — бум! Вы только что сжали информацию! Легко. Я вас спас от многочасовой утомительной лекции. Это, конечно же, огромное упрощение, но вы преобразовали данные в некое короткое представление с той же информативностью. То есть уменьшили избыточность. Информационная энтропия данных не пострадала — вы только преобразовали представление. Такой способ называется энтропийным кодированием, который подходит для кодирования любого вида данных.

Частотное пространство

Теперь, когда мы разобрались с информационной энтропией, перейдем к преобразованию самих данных. Можно представить данные в фундаментальных системах. Например, если использовать двоичный код, будут 0 и 1. Если же использовать шестнадцатеричную систему, то алфавит будет состоять из 16 символов. Между вышеупомянутыми системами существует взаимно однозначная связь, поэтому можно легко преобразовывать одно в другое. Пока всё понятно? Идём дальше.

А представьте, что можно представить данные, которые изменяются в пространстве или времени, в совершенно иной системе координат. Например, яркость изображения, а вместо системы координат с x и y, возьмём частотную систему. Таким образом, на осях будут частоты freqX и freqY, такое представление называется частотным пространством[Frequency domain representation]. И существует теорема, что любые данные можно без потерь представить в такой системе при достаточно высоких freqX и freqY.

Хорошо, но что такое freqX и freqY?

freqX и freqY всего лишь другой базис в системе координат. Так же как можно перейти из двоичной системы в шестнадцатеричную, можно перейти из X-Y в freqX и freqY. Ниже изображён переход из одной системы в другую.

Мелкая решётка MacBook Pro содержит высокочастотную информацию и находится в области с высокими частотами. Таким образом мелкие детали имеют высокую частоту, а плавные изменения, такие как цвет и яркость низкую. Всё, что между, остаётся между.

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

Пока всё понятно, но зачем это нужно?

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

Ниже знакомый нам ноутбук, но теперь уже с, применёнными к ней, круговыми масками.

В процентах указана информационная энтропия относительно исходного изображения. Если не приближать, то разница не заметна и при 2%! — машина теперь весит 20 кг!

Именно таким образом нужно избавляться от веса. Такой процесс сжатия с потерями называется Квантованием.

Это впечатляет, какие еще приёмы существуют?

Цветовая обработка

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

В телевизорах, цвета RGB преобразуются в YCbCr, где Y это компонента яркости (по сути яркость черно-белого изображения), а Cb и Cr компоненты цвета. RGB и YCbCr эквиваленты в плане информационной энтропии.

Зачем же тогда усложнять? RGB разве не достаточно?

Во времена чёрно-белых телевизоров, была только компонента Y. А с началом появления цветных телевизоров у инженеров встала задача о передаче цветного RGB изображения вместе с чёрно-белым. Поэтому вместо двух каналов для передачи, было решено кодировать цвет в компоненты Cb и Cr и передавать их вместе с Y, а цветные телевизоры уже сами будут преобразовывать компоненты цвета и яркости в привычный им RGB.

Но вот в чём хитрость: компонента яркости кодируется в полном разрешении, а компоненты цвета лишь в четверть. И этим можно пренебречь, т.к. глаз/мозг плохо различает оттенки. Таким образом можно уменьшить размер изображения в половину и с минимальными отличиями. В 2 раза! Машина будет весить 10 кг!

Данная технология кодирования изображения со снижением цветового разрешения называется цветовой субдискретизацией. Она используется повсеместно уже давно и относится не только к H.264.

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

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

Компенсация движения

H.264 стандарт, который позволяет компенсировать движения.

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

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

И это именно то, что H.264 делает. H.264 разбивает изображение на макроблоки, обычно 16х16, которые используются для расчёта движения. Один кадр остаётся статичным, обычно его называют I-кадр [Intra frame], и содержит всё. Последующие кадры могут быть либо P-кадры [predicted], либо B-кадры [bi-directionally predicted]. В P-кадрах вектор движения кодируется для каждого макроблока на основе предыдущих кадров, таким образом декодер должен использовать предыдущие кадры, взяв последний из I-кадров видео и постепенно добавляя изменения последующих кадров пока не дойдёт до текущего.

Ещё интереснее обстоят дела с B-кадрами, в которых расчёт производится в обоих направлениях, на основании кадров идущих до и после них. Теперь вы понимаете почему видео в начале статьи весит так мало, это всего лишь 3 I-кадра, в которых мечутся макроблоки.

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

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

Выглядит впечатляюще. Теперь что?

Теперь мы подведём черту, используя традиционное энтропийное кодирование без потерь. Почему нет?

Энтропийное кодирование

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

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

Вот теперь всё! В основе H.264 лежат вышеупомянутые технологии. В этом и заключаются приёмы стандарта.

Отлично! Но меня разбирает любопытство узнать, сколько же весит теперь наша машина.

Исходное видео было снято в нестандартном разрешении 1232×1154. Если посчитать, то получится:

5 сек. @ 60 fps = 1232x1154x60x3x5 => 1.2 Гб
Сжатое видео => 175 Кб

Если соотнести результат с оговорённой массой машины в одну тонну, то получится вес равный 0.14 кг. 140 граммов!

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

Источник

Механизм кодирования видео был представлен 22 декабря 2011 года в серии Radeon HD 7000. VCE занимает значительную часть поверхности кристалла, и его не следует путать с AMD Unified Video Decoder (UVD).

СОДЕРЖАНИЕ

Обзор

VCE 1.0

По состоянию на апрель 2014 года существует две версии VCE. Версия 1.0 поддерживает H.264 YUV420 (I & P-кадры), H.264 SVC Temporal Encode VCE и Display Encode Mode (DEM).

Его можно найти на:

VCE 2.0

По сравнению с первой версией VCE 2.0 добавляет H.264 YUV444 (I-Frames), B-кадры для H.264 YUV420 и улучшения DEM (Display Encode Mode), что приводит к лучшему качеству кодирования.

Его можно найти на:

VCE 3.0

Технология Video Code Engine 3.0 (VCE 3.0) отличается новым высококачественным масштабированием видео и высокоэффективным кодированием видео (HEVC / H.265).

Его вместе с UVD 6.0 можно найти в 3-м поколении Graphics Core Next (GCN3) с аппаратным обеспечением графического контроллера на базе «Tonga», «Fiji», «Iceland» и «Carrizo» (VCE 3.1), которое сейчас используется. AMD Radeon Rx 300 Series (семейство GPU Pirate Islands) и VCE 3.4 от реальных AMD Radeon Rx 400 Series и AMD Radeon 500 Series (оба семейства Polaris GPU).

VCE 4.0

Кодер Video Code Engine 4.0 и декодер UVD 7.0 включены в графические процессоры на базе Vega.

VCE 4.1

Графический процессор AMD Vega20, присутствующий в картах Instinct Mi50, Instinct Mi60 и Radeon VII, включает VCE 4.1 и два экземпляра UVD 7.2.

Обзор возможностей

В следующей таблице представлены черты AMD «s APUs (смотри также: Список AMD Accelerated Processing единиц ).

Графические процессоры

Название GPU серии	Задаваться вопросом	Мах	3D ярость	Ярость Pro	Ярость 128	R100	R200	R300	R400	R500	R600	RV670	R700	Вечнозеленый	Северные острова	Южные острова	Морские острова	Вулканические острова	Арктические острова / Полярная звезда	Вега	Navi 1X	Navi 2X
Выпущенный	1986 г.	1991 г.	1996 г.	1997 г.	1998 г.	Апрель 2000 г.	Август 2001 г.	Сентябрь 2002	Май 2004 г.	Октябрь 2005 г.	Май 2007 г.	Ноя 2007	Июнь 2008 г.	Сентябрь 2009 г.	Октябрь 2010 г.	Янв 2012	Сентябрь 2013	Июн 2015	Июн 2016	Июн 2017	Июл 2019	Ноя 2020
Маркетинговое название	Задаваться вопросом	Мах	3D ярость	Ярость Pro	Ярость 128	Radeon 7000	Radeon 8000	Radeon 9000	Radeon X700 / X800	Radeon X1000	Radeon HD 2000	Radeon HD 3000	Radeon HD 4000	Radeon HD 5000	Radeon HD 6000	Radeon HD 7000	Radeon Rx 200	Radeon Rx 300	Radeon RX 400/500	Radeon RX Vega / Radeon VII (7-нм)	Radeon RX 5000	Radeon RX 6000
Поддержка AMD
Добрый	2D		3D
Набор инструкций	Неизвестно публично										Набор инструкций TeraScale					Набор инструкций GCN					Набор инструкций RDNA
Микроархитектура											TeraScale 1			TeraScale 2 (VLIW5)	TeraScale 3 (VLIW4)	GCN 1-го поколения	GCN 2-го поколения	GCN 3-го поколения	GCN 4-го поколения	GCN 5-го поколения	РДНА	РДНА 2
Тип	Фиксированный трубопровод						Программируемые пиксельные и вершинные конвейеры				Единая шейдерная модель
Direct3D	N / A		5.0	6.0		7.0	8.1	9,0 11 ( 9_2 )	9.0b 11 ( 9_2 )	9.0c 11 ( 9_3 )	10,0 11 ( 10_0 )	10,1 11 ( 10_1 )		11 ( 11_0 )		11 ( 11_1 ) 12 ( 11_1 )	11 ( 12_0 ) 12 ( 12_0 )			11 ( 12_1 ) 12 ( 12_1 )		11 ( 12_1 ) 12 ( 12_2 )
Шейдерная модель	N / A						1.4	2.0+	2,0b	3.0	4.0	4.1		5.0		5.1	5,1 6,3			6.4		6.5
OpenGL	N / A			1.1	1.2	1.3		2.1			3.3			4.5 (в Linux: 4.5 (Mesa 3D 21.0))		4.6 (в Linux: 4.6 (Mesa 3D 20.0))
Вулкан	N / A															1.0 ( Win 7+ или Mesa 17+ )	1.2 (Adrenalin 20.1, Linux Mesa 3D 20.0)
OpenCL	N / A										Близко к металлу		1.1 (без поддержки Mesa 3D)	1.2 (в Linux : 1.1 (без поддержки изображений) с Mesa 3D)			2.0 (драйвер Adrenalin в Win7 + ) (в Linux : 1.1 (без поддержки изображений) с Mesa 3D, 2.0 с драйверами AMD или AMD ROCm)				2.0	2.1
HSA	N / A																				?
Видео декодирование ASIC	N / A										Авиво / УВД	УВД +	УВД 2	УВД 2.2	УВД 3	УВД 4	УВД 4.2	УВД 5.0 или 6.0	УВД 6.3	УВД 7	VCN 2.0	VCN 3.0
Кодирование видео ASIC	N / A															VCE 1.0	VCE 2.0	VCE 3.0 или 3.1	VCE 3.4	VCE 4.0
ASIC с жидкостным движением
Энергосбережение	?										PowerPlay				PowerTune	PowerTune и ZeroCore Power					?
TrueAudio	N / A																Через выделенный DSP		Через шейдеры			?
FreeSync	N / A																1 2
HDCP	?																1.4		1,4 2,2		1,4 2,2 2,3	?
PlayReady	N / A																		3.0		3.0	?
Поддерживаемые дисплеи	1-2	2							2–6							?
Максимум. разрешающая способность	?													2–6 × 2560 × 1600		2–6 × 4096 × 2160 при 60 Гц			2–6 × 5120 × 2880 при 60 Гц	3 × 7680 × 4320 при 60 Гц	?
/drm/radeon													N / A
/drm/amdgpu	N / A															Экспериментальный

Поддержка операционной системы

Linux

Программное обеспечение MediaShow Espresso Video Transcoding, похоже, максимально полно использует VCE и UVD.

XSplit Broadcaster поддерживает VCE начиная с версии 1.3.

Программное обеспечение Open Broadcaster (OBS Studio) поддерживает VCE для записи и потоковой передачи. Исходное программное обеспечение Open Broadcaster Software (OBS) требует сборки вилки для включения VCE.

Программное обеспечение AMD Radeon поддерживает VCE со встроенным захватом игр («Radeon ReLive») и использует AMD AMF / VCE на APU или видеокарте Radeon, чтобы уменьшить падение FPS при захвате игрового или видеоконтента.

HandBrake добавил поддержку Video Coding Engine в версии 1.2.0 в декабре 2018 года.

Преемник

На смену VCE пришла AMD Video Core Next в серии APU Raven Ridge, выпущенной в октябре 2017 года. VCN сочетает в себе функции кодирования (VCE) и декодирования (UVD).

Источник