Вектор c a b a c: что скрывается за этими пятью буквами — Техника на vc.ru — RC74 — интернет-магазин радиоуправляемых моделей

Содержание

что скрывается за этими пятью буквами — Техника на vc.ru

Статья для специалистов и тех, кто хочет им стать. Разбираемся, что такое контекстно-адаптивное двоичное арифметическое кодирование.

1121 просмотров

Перечислим еще раз основные этапы обработки видеокадра при кодировании стандартом H.265/HEVC (рис.1). На первом этапе (с условным названием «Разбиение на блоки») кадр разбивается на блоки CU (Coding Unit). На следующем этапе изображение внутри каждого блока предсказывается с использованием пространственного (Intra) или временного (Inter) предсказания. При выполнении временного предсказания блок CU может быть разбит на подблоки PU (Prediction Unit), каждый из которых может иметь собственный вектор движения. Значения предсказанных отсчетов вычитаются из значений отсчетов кодируемого изображения. В результате для каждого блока CU формируется разностный двумерный сигнал Residual. На третьем этапе двумерный массив отсчетов разностного сигнала разбивается на блоки TU (Transform Unit), каждый из которых подвергается двумерному дискретному косинус-преобразованию Фурье (исключение здесь составляют блоки TU отсчетов яркости, полученных путем Intra-предсказания, размером 4×4, для которых используется дискретное синус-преобразование Фурье).

Рис 1. Основные этапы кодирования видеокадра в системе стандарта H.265/HEVC

На следующем этапе спектральные Фурье-коэффициенты разностного сигнала квантуются по уровню. Информация о всех произведенных на каждом из четырех этапах действиях, позволяющая восстановить закодированное изображение, поступает на вход энтропийного кодера. Это последний этап. Здесь поступающие данные подвергаются дополнительному сжатию без потерь по алгоритмам контекстно-адаптивного двоичного арифметического кодирования (Context Adaptive Binary Arithmetic Coding, сокращенно CABAC). Попробуем разобраться, что же означает эта последовательность из пяти слов.

Начнем со словосочетания «арифметическое кодирование». Чтобы проиллюстрировать идею арифметического кодирования рассмотрим простой пример. Попробуем сжать информационное сообщение, состоящее из 20 символов. Видов символов у нас будет всего три: символ «a», символ «b» и символ «EOF», который будет индицировать конец сообщения. Само сообщение будет следующим: {b, a, b, b, b, b, b, b, b, b, a, b, b, b, b, b, b, b, b, EOF}. Процедура сжатия будет заключаться в рекурсивном делении текущего интервала. Возьмем в качестве начального интервала [0, 1). Разобьем его на интервалы, длина которых будет пропорциональна частоте появления символов в сообщении. Символ «b» появляется в сообщении в 17 случаях из 20 возможных. Символ «a» — в 2 случаях из 20. Символ «EOF» появляется один раз. После разбиения будем иметь три интервала: [0, 2/20), [2/20, 19/20), [19/20, 1). Первый символ в сообщении — символ «b». В качестве текущего теперь выбираем отрезок, длина которого пропорциональна частоте появления символа «b», т. е. текущим отрезком становится [2/20, 19/20). Повторяем процедуру разбиения текущего интервала, выбирая в качестве нового интервала тот, длина которого соответствует частоте появления в сообщении очередного символа. Процедуру повторяем до конца сообщения. Последовательность действий при нашем кодировании оформим в виде таблицы.

Таблица 1

Результатом рекурсивного деления текущего интервала стал выделенный жирным в таблице интервал, границы которого приведем без округления: [0.142948471255693, 0.142980027967343). В двоичной системе счисления полученный интервал представляется в виде [0.001 001 001 001 100 00100010101100001000011100111000000010, 0.001 001 001 001 101 00101011011010000000110011101010011101). Число 0.001 001 001 001 100 1 (в десятичной системе счисления это число 0.142959594726563), принадлежащее полученному интервалу, является результатом кодирования нашего сообщения. Это число содержит 16 бит. Таким образом, из сообщения длиной 20 символов мы получили 16-ти битовый код. Мы сжали наше сообщение!

142959594726563 принадлежит среднему интервалу [0.1, 0.95). Таким образом, первый декодированный символ — это символ «b» (что отражено в пятом столбце таблицы в первой строке). Текущим интервалом становится [0.1, 0.95). Опять делим его на три части в соответствии с частотами появления символов в сообщении. Результат разбиения показан во второй строке Таблицы 1. Число 0.142959594726563 принадлежит первому из интервалов, полученных при делении, [0.1, 0.185). Этот интервал имеет длину, пропорциональную частоте появления символа «a». Этот символ и является результатом декодирования на второй итерации. Из сказанного выше очевидно, что весь процесс декодирования уже отображен в Таблице 1. Итеративное деление текущего интервала при декодировании будет продолжаться до тех пор, пока не будет декодирован символ «EOF», сигнализирующий о конце сообщения.

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

Отметим здесь несколько достаточно очевидных моментов, касающихся процедуры кодирования. Совершенно очевидно, что в том случае, когда текущий интервал полностью лежит в области от 0 до ½, текущий бит результата кодирования будет нулевым. Аналогично, в том случае, когда текущий интервал полностью лежит в области от ½ до 1, текущий бит результата кодирования будет единичным. В том же случае, когда левый конец текущего интервала меньше ½, а правый больше, но оба не отстоят от ½ более чем на ¼, значение текущего бита результата неизвестно. Однако, можно уверенно утверждать, что следующий бит результата будет иметь противоположное к текущему значение. После выдачи каждого текущего бита результата кодирования длину интервала можно удвоить. Все это позволило ввести процедуру удвоения длины текущего интервала, которая позволяет обойти оба указанных выше недостатка арифметического кодирования.

5), [0.25, 0.75), [0.5, 1). Если текущий интервал не лежит полностью ни в одном из этих трех интервалов, то итерации прекращаются. В противном случае, когда текущий интервал лежит в одном из этих трех, выполняется один из трех наборов действий. Таким образом, каждый набор соответствует своему интервалу.

Если текущий интервал полностью принадлежит интервалу [0, 0.5), то выдается бит результата 0 и после него столько битов 1, сколько было накоплено на предыдущих символах. (Количество единиц, выдаваемых в результирующий битовый поток равно значению счетчика, называемого в стандарте bitsOutstanding. После вывода единичных битов счетчик сбрасывается в 0). Значения границ текущего интервала удваивается. В результате, естественно удваивается и длина интервала. Для краткости назовем это удвоение «расширением интервала вправо».

Если текущий интервал полностью лежит внутри интервала [0.5, 1), то выдается бит результата 1 и после него столько битов 0, сколько было накоплено на предыдущих символах (количество битов 0 опять равно значению счетчика bitsOutstanding, счетчик сбрасывается в 0). Границы интервала смещаются влево так, чтобы расстояние от них до 1 удвоилось. Назовем это удвоение «расширением интервала влево».

Если текущий интервал полностью лежит внутри интервала [0.25, 0.75), то этот факт необходимо запомнить для последующей выдачи битов результата (увеличить на 1 значение счетчика bitsOutstanding). Левая граница текущего интервала смещается влево так, чтобы расстояние от нее до точки 0.5 удвоилось. Правая граница смещается вправо также с удвоением расстояния от нее до точки 0.5. Назовем удвоение длины интервала в этом случае «расширением интервала в обе стороны».

Кроме того, формализуем процедуру выбора последних двух бит закодированного сообщения, конкретизирующих выбор двоичного числа из полученного итеративным делением интервала. Эта процедура очень проста. Если левая граница полученного интервала меньше 0.25, то последними битами сообщения будет последовательность {0, 1}. В противном случае — это последовательность {1, 0}.

Проиллюстрируем работу процедуры ренормализации на примере кодирования того же 20-ти символьного сообщения {b, a, b, b, b, b, b, b, b, b, a, b, b, b, b, b, b, b, b, EOF}

Таблица 2

В результате кодирования получили 001 001 001 001 100 1, т. е. те же 16 бит, которые мы получали и без использования процедуры ренормализации.

Отметим еще один момент. Процедуру итеративного деления текущего интервала на части, длины которых пропорциональны частотам появления символов в сообщении, легко формализовать. Действительно, если обозначить fi за относительную частоту i-го символа (в нашем примере у первого символа «a» эта частота равна 0.1), за

то границы текущего интервала на каждой итерации могут быть рассчитаны как:

R = Hc — Lc

L = Lc + P1 ∙ R ,

H = Lc + P2 ∙ R ,

где Lc – левая граница текущего интервала, L – новое значение левой границы текущего интервала после деления, Hc– правая граница текущего интервала, H – новое значение правой границы текущего интервала после деления.

Олег Пономарев — специалист в области распространения радиоволн, статистической радиофизики, доцент кафедры радиофизики НИ ТГУ, кандидат физико-математических наук. 16 лет занимается вопросами видео кодирования и цифровой обработки сигналов. Руководитель исследовательской лаборатории Elecard.

CABAC кодирование — Русские Блоги

H. Стандарт 264 / AVC принимает много новых технологий и новых методов, что значительно повышает эффективность кодирования видео, из которых CABAC является H. Один из новых методов энтропийного кодирования, принятый 264 / AVC. CABAC использует идею эффективного арифметического кодирования, полностью учитывая соответствующие статистические характеристики видеопотока, что значительно повышает эффективность кодирования. Подводя итог, CABAC имеет три важных характеристики:
(1)Моделирование контекста обеспечивает оценку условного распределения вероятности кодированных символов, Используя соответствующую контекстную модель, при кодировании текущего символа в соответствии со статистикой вероятности кодированных соседних символов переключаются между различными вероятностными моделями, тем самым устраняя избыточность между символами.
(2)Арифметическое кодирование может назначать нецелые биты каждой букве символаТаким образом, символ может быть закодирован с близкой к нему скоростью энтропии. Пара вероятностей больше, чем О. Символ 5 очень эффективен. Если выбрана эффективная модель вероятности, вероятность символа часто больше, чем O. 5. В настоящее время дробные биты намного эффективнее, чем целочисленные биты UVLC (не менее 1 бита).
(3)Адаптивное арифметическое кодирование позволяет энтропийному кодеру адаптироваться к статистике вероятности динамических символов, В общем, статистика вероятности векторов движения может сильно различаться в зависимости от разницы в пространстве и времени или последовательности и кода. Следовательно, поскольку адаптивная модель полностью использует статистику вероятности кодированных символов, арифметическое кодирование может лучше адаптироваться к вероятности текущего символа, тем самым повышая эффективность кодирования.

CABAC состоит из трех частей: бинаризация, контекстное моделирование и двоичное арифметическое кодирование

Каждая часть подробно описана ниже:
(1) бинаризация
CABAC — двоичное арифметическое кодирование, верноОстаточные данные недвоичных символы, такие как вектор движения, тип макроблока, номер опорного кадра, и квантование преобразованияНужно заранеепреобразованное к двоичному, В Х. В стандарте 264 / AVC схема бинаризации CABAC состоит из базовой схемы и последовательной схемы. Базовая схема имеет четыре типа: унарная бинаризация (U), укороченная унарная бинаризация (TU), экспоненциальная бинаризация Голомба K-го порядка (UEGK) и код фиксированной длины (Fixed. 1-я бинаризация, FL). Схема конкатенации формируется путем конкатенации базовых схем. Различные схемы бинаризации подходят для различных типов синтаксических элементов.Для остаточных данных с большим диапазоном изменения значений (таких как остаточные данные MVD между вектором движения и значением предсказания вектора движения) используйте код UEGK，Для простых символов элементы пометки представлены кодами FL, Ниже приведены методы кодирования четырех основных схем:

U двоичное кодирование:Этот метод кодирует целое число без знака X в X «1» и добавляет суффикс «0». Например, целое число 3 преобразуется в «l110».

Двоичное кодирование TU: Этот метод использует разные методы преобразования в соответствии с параметром cMax. Если целое число без знака x <cMax, используйте для преобразования метод унарной бинаризации, если x = cMax, X преобразуется в X «1».

UEGK двоичное кодирование:Кодовое слово, преобразованное этим методом, состоит из двух частей: префикс и суффикс. Префиксная часть конвертируется с помощью унарной бинаризацииполучить。

Двоичное кодирование FL:Этот метод устанавливает фиксированную длину для элементов синтаксиса. Если 0≤X <cMax, его длина L =

CABAC преобразует элементы синтаксиса для кодирования вДвоичный поток битов представлен только «0» и «l»Вызывается поток битов (строка bin), затемКодировать строку бина различными вероятностными моделями, Полностью учитывая корреляцию видеопотока, он может адаптироваться к изменению статистических характеристик сигнала и легко достигать прогрессивной производительности. В процессе кодирования исходный символ строки бина делится наСимвол наибольшей вероятности (MPS) и символ наименьшей вероятности (LPS), Если MPS равен 0, LPS равен 1. И наоборот, если NIPS равен «1», то LPS равен «0». Но когдаРазница между вероятностью возникновения MPS и LPS относительно великаВ соответствии с принципом информационной энтропии, значение энтропии строки бина относительно мало,Эффект сжатия лучше, Если вероятность появления MPS и LPS равна или равна, значение энтропии строки бина относительно велико, и эффект сжатия неочевиден.

(2) Контекстное моделирование
Кодовый символ имеетКонтекстная актуальность, Используя закодированные символыПредоставлена контекстная информацияВыберите подходящую вероятностную модель для символа кодирования, это моделирование контекста. Он предназначен для кодирования синтаксических элементов, связанных с движением, шаблонами и структурной информацией. Благодаря построению контекстной модели модель вероятности копирования может адаптироваться к статистическим характеристикам, которые изменяются с видеоизображением, уменьшать избыточность между символами и значительно снижать вычислительные затраты.
CABACЖизненный цикл крупного рогатого скота как арифметический кодХ. Стандарт 264 / AVC преобразует данные, которые могут появиться на чипеРазделен на 399 контекстных моделейКаждая модель имеет свой собственный номер контекста (Ctxldx),Каждый отдельный символ индексирует свою собственную таблицу поиска вероятности в соответствии с соответствующей контекстной моделью, После получения символов,Сначала индексируйте символ Ctxldx, чтобы найти таблицу вероятностного поиска (TransldxLPS).Разделение этих моделей с точностью до битов, и почти все биты и их соседи находятся в разных контекстных моделях. Есть два шага, чтобы найти контекстную модель, соответствующую каждому биту:
Первый шаг:Определить синтаксический элемент, к которому принадлежит бит, CABAC назначает интервал контекстной модели каждому синтаксическому элементу, подробности см. В таблице 9.11.
Второй шаг:В соответствии с определенным правилом найдите соответствующий Ctxldx для текущего бита в интервале, полученном на предыдущем шаге, Правило отличается для разных синтаксических элементов и обычно выражается в таблицах. Эти 399 моделей контекстной модели делятся на 4 типа: Первый типПредсказать текущий элемент синтаксиса на основе левого и верхнего элементов синтаксиса, Второй тип предназначен только дляТип макроблока и тип предварительно макроблока, Тип n-го бита должен относиться к типу, принятому ранее закодированным n-1 битом. Третий и четвертый типы используются только для остатков. Третий типНе зависит от предыдущих закодированных данных, но от местоположения пути сканирования, Четвертый типСюда также входит подсчет количества накопленных кодов.В CABAC «репрезентативное значение вероятности используется для представления вероятности LPS. Эти 64 значения вероятности рассчитываются по формулам (3.1) и (3.2):

Значение может быть представлено 7 битами.

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

(3) двоичное арифметическое кодирование
Оценка вероятности и кодер составляют адаптивный двоичный арифметический кодер. Оценка вероятности — это оценка вероятности, обновленная после предыдущего этапа моделирования контекста, После кодирования каждого двоичного значения,Значение этой вероятностной оценки должно быть скорректировано в соответствии с только что закодированным двоичным символом, Бинарное арифметическое кодирование является частным случаем арифметического кодирования, и его принцип такой же, как и общее арифметическое кодирование. Разница заключается в том, что в двоичном арифметическом кодировании последовательность кодирования имеет только два символа: «0» и «l,Вовлеченные вероятности — только P (0) и P (1).Интервал вероятности делится на две части, одна — это интервал кодирования MPS, а другая — интервал кодирования LPS. Длина интервала определяется вероятностью каждого исходного символа,Интервал кодирования LPS всегда должен быть меньше, чем у MPS, Если вероятность LPS записывается как Q, вероятность MPS записывается как P = I-Q. В процессе кодирования, если имеется непрерывный вход LPS, может случиться, что Q> P. В это время исходные символы, представленные MPS и LPS, должны быть заменены наУбедитесь, что вероятность исходного символа, представленного MPS, всегда больше, чем вероятность исходного символа, представленного LPS, В начале каждого среза CABAC инициализирует и устанавливает таблицу состояний вероятности. При выполнении двоичного арифметического кодирования значение состояния вероятности каждого бита получается путем проверки таблицы состояний вероятности. иПосле кодирования одного бита значение состояния в таблице состояний вероятности должно быть обновлено, Обновление значения состояния вероятности осуществляется следующим образом:Бит (двоичный код) кода равен NIPS, и значение состояния вероятности a увеличивается на 1, что означает, что значение R уменьшается, а значение (1.R) увеличиваетсяЭто фактически означает, что вероятность следующего появления MPS увеличивается, а вероятность появления LPS уменьшается. Если a = 62, это означает, что (1.n) достиг максимума, в это время a не изменится, пока не появится LPS. Если кодированный бит biIlvm равен LPS, а a = 0, это означает, что вероятности MPS и LPS равны, а значения MPS и LPS взаимозаменяемы. Справочная формула обновления значения конкретной вероятности (3.3)

Чтобы облегчить наблюдение, мы даем приблизительную оценку и обновляем диаграмму модели CABAC (как показано на рисунке 3.2). При работе с binval обновление вероятности имеет два направления:Если binval — LPS, вероятность LPS становится больше, и он смотрит налево вдоль пунктирной линии на рисунке ниже, если binval — MPS, вероятность LPS становится меньше, и он смотрит вправо вдоль сплошной линии на рисунке., Мы можем видеть, что обновленное значение при появлении MPS просто указывает на следующий бит текущего значения, то есть a + l. То естьКогда текущий обрабатываемый символ является MPS, интервал прогрессирует только потому, что длина интервала изменилась, но L, который влияет на фактическое выходное значение, не изменился, Это явление означаетЕсли большое количество MPS постоянно появляется во входном потоке, или вероятность MPS относительно LPS относительно высока, может быть достигнут очень высокий эффект сжатия, Скорость кодирования кодированного выхода также ближе к скорости энтропии.

что скрывается за этими пятью буквами

Рис 1. Основные этапы кодирования видеокадра в системе стандарта H.265/HEVC

На следующем этапе спектральные Фурье-коэффициенты разностного сигнала квантуются по уровню. Информация о всех произведенных на каждом из четырех этапах действиях, позволяющая восстановить закодированное изображение, поступает на вход энтропийного кодера. Это последний этап. Здесь поступающие данные подвергаются дополнительному сжатию без потерь по алгоритмам контекстно-адаптивного двоичного арифметического кодирования (mzepgsHAXLQ Adaptive Binary Arithmetic Coding, сокращенно CABAC). Попробуем разобраться, что же означает эта последовательность из пяти слов.

Таблица 1

Результатом рекурсивного деления текущего интервала стал выделенный жирным в таблице интервал, границы которого приведем без округления: [0. 142948471255693, 0.142980027967343). В двоичной системе счисления полученный интервал представляется в виде [0.001 001 001 001 100 00100010101100001000011100111000000010, 0.001 001 001 001 101 00101011011010000000110011101010011101). Число 0.001 001 001 001 100 1 (в десятичной системе счисления это число 0.142959594726563), принадлежащее полученному интервалу, является результатом кодирования нашего сообщения. Это число содержит 16 бит. Таким образом, из сообщения длиной 20 символов мы получили 16-ти битовый код. Мы сжали наше сообщение!

Попробуем теперь его декодировать. Для этого опять возьмем исходный интервал [0, 1). Разделим его в соответствии с частотами появления символов в сообщении. Результат этого разбиения, очевидно, представлен в Таблице 1 в строке с номером итерации 1. Полученное число 0.142959594726563 принадлежит среднему интервалу [0.1, 0.95). Таким образом, первый декодированный символ — это символ «b» (что отражено в пятом столбце таблицы в первой строке). Текущим интервалом становится [0. 1, 0.95). Опять делим его на три части в соответствии с частотами появления символов в сообщении. Результат разбиения показан во второй строке Таблицы 1. Число 0.142959594726563 принадлежит первому из интервалов, полученных при делении, [0.1, 0.185). Этот интервал имеет длину, пропорциональную частоте появления символа «a». Этот символ и является результатом декодирования на второй итерации. Из сказанного выше очевидно, что весь процесс декодирования уже отображен в Таблице 1. Итеративное деление текущего интервала при декодировании будет продолжаться до тех пор, пока не будет декодирован символ «EOF», сигнализирующий о конце сообщения.

В стандарте эта процедура назвается ренормализацией. В процессе ренормализации при кодировании сразу выдаются биты результата кодирования, а длина текущего интервала удваивается. Ренормализация выполняется итеративно после выбора каждого текущего интервала. Итерации продолжаются до тех пор, пока текущий интервал попадает полностью в один из трех интервалов: [0, 0.5), [0.25, 0.75), [0.5, 1). Если текущий интервал не лежит полностью ни в одном из этих трех интервалов, то итерации прекращаются. В противном случае, когда текущий интервал лежит в одном из этих трех, выполняется один из трех наборов действий. Таким образом, каждый набор соответствует своему интервалу.

Таблица 2

то границы текущего интервала на каждой итерации могут быть рассчитаны как:

R = Hc — Lc

L = Lc + P1 ∙ R ,

H = Lc + P2 ∙ R ,

Данный материал является частной записью члена сообщества Club.CNews.
Редакция CNews не несет ответственности за его содержание.

2 года назад | категории: SMB: Телеком Телеком: Беспроводная связь Телеком: Инфраструктура Математика: ПО и алгоритмы Технологии: Связь Фото, видеотехника: DVD и медиапроигрыватели Фото, видеотехника: Видеокамеры Мультимедиа: Видео Мультимедиа: Кодеки Мультимедиа: Конвертеры Разра

Стандарты сжатия видео AVC и H.

264

AVC/H.264

Стандарт сжатия видео AVC (Advanced Video Coding) был предложен группой экспертов JVT (Joint Video Team) в мае 2003 года. В то время он представлял собой революционный прорыв в технологиях сжатия видео. Новый стандарт полностью превзошел повсеместно использовавшиеся тогда стандарты MPEG-2 и MPEG-4 Part 2 (SP, ASP). По некоторым оценкам для хранения видео, сжатого по стандарту AVC, требуется в 2 раза меньший объем памяти, чем для видео, сжатого по стандарту MPEG-2 при одинаковом качестве.

Новый стандарт позволил получить видео стандартной четкости вещательного качества при потоке в 1,5 Мбит/с. Такая степень сжатия позволяет передать примерно 12 сжатых телевизионных каналов в полосе частот, прежде занятой одним аналоговым ТВ-каналом. Также, внедрение AVC позволило телеоператорам предоставлять новые услуги для видео в местах, где они до этого были не доступны и открыло возможность “упаковывать” большее количество каналов видео в узкий и дорогостоящий диапазон частот при передаче. Преимущества в эффективности кодирования, такие как хорошее качество видео при низких битрэйтах, сделали AVC безусловным лидером в системах интернет телевидения, и вывели эту индустрию на качественно новый уровень. Также AVC позволил существенно увеличить качество цифрового телевидения и сделал широкодоступным телевидение высокой четкости HDTV.

Низкая плата за лицензию от MPEG-LA также способствовала стремительному внедрению стандарта, и, к настоящему времени, H.264/AVC успешно закрепился на рынке. В 2010 году количество решений на базе AVC превзошло количество аналогичных решений на базе устаревшего стандарта MPEG-2 и увеличивалось с каждым годом вплоть до принятия следующего стандарта сжатия видео H.265/HEVC.

Основные характеристики стандарта H.264/AVC

Стандарт H.264 обеспечивает усовершенствованную технологию кодирования по методам, схожим с технологией кодирования предыдущих стандартов MPEG и ITU-T. Более высокая производительность и качество обеспечиваются новыми инструментальными средствами, которые включают в себя следующие.

Улучшенная оценка движения

Оценка движения позволяет искать субмакроблоки различного размера от 16×16 до 4×4 пикселов. Векторы движения теперь допускают точность до 1/4 пиксела для сигнала яркости, и до 1/8 пиксела для сигнала цветности. Кроме этого, существенно улучшено кодирование векторов движения; используется их предсказание.

Пространственное предсказание

H.264 выполняет внутрикадровое предсказание для intra-кодированных блоков, позволяя применить до 9 различных способов такого предсказания в зависимости от направления.

Оптимизация параметров кодирования

Классический метод кодирования предполагает принятие локально оптимальных решений на каждом этапе. Очевидно, что в таком случае результирующее решение может не оказаться оптимальным. Стандарт AVC предлагает новый алгоритм оптимизации параметров кодирования RDO (Rate distortion optimization), суть которого состоит в выборе таких параметров, использование которых наилучшим образом отразится на результате.

Модифицированное ДКП

Для преобразования остаточной информации, используется модифицированное целое дискретное косинусное преобразование (МДКП), которое предотвращает ошибки округления. Важным отличием от предыдущих стандартов являются размеры блоков для ДКП. AVC позволяет осуществлять преобразования над блоками размера 8×8 и 4×4 пиксела.

Фильтрация границ блоков

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

Улучшение кодирования при плавных движениях

В AVC добавлен ряд новых условий для кодирования макроблоков в режиме «skip». Фактически, в этом случае, макроблок не кодируется, а используется другой макроблок в той же позиции, но с другого кадра. Таким образом, достигается существенный выигрыш на малых битрейтах или при плавных движениях камеры, когда вся картинка движется одинаково.

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

Стандарт обеспечивает два более производительных процесса энтропийного кодирования. Context-adaptive variable length coding (CAVLC — контекстно-адаптированное кодирование с различной длиной кодового слова) — энтропийный кодер, принцип действия которого близок к алгоритму сжатия Хаффмана. CAVLC позволяет быстро сжимать информацию, при этом обеспечивает приемлемую степень сжатия.

Context-adaptive binary arithmetic coding (CABAC — контекстно-адаптированное двоичное арифметическое кодирование) представляет собой арифметический кодер. Использование CABACа позволяет добиться эффективности сжатия близкой к максимально возможной, однако он требует существенно больше ресурсов, чем CAVLC.

5 июля 2018

Контекстно-адаптивное двоичное арифметическое кодирование — Context-adaptive binary arithmetic coding

Контекстно-адаптивное двоичное арифметическое кодирование ( CABAC ) — это форма энтропийного кодирования, используемая в стандартах H. 264 / MPEG-4 AVC и высокоэффективного видеокодирования (HEVC). Это метод сжатия без потерь, хотя стандарты кодирования видео, в которых он используется, обычно предназначены для приложений сжатия с потерями . CABAC примечателен тем, что обеспечивает гораздо лучшее сжатие, чем большинство других алгоритмов энтропийного кодирования, используемых при кодировании видео, и является одним из ключевых элементов, обеспечивающих схему кодирования H.264 / AVC лучшей способностью сжатия, чем ее предшественники.

В H.264 / MPEG-4 AVC CABAC поддерживается только в основном и более высоких профилях (но не в расширенном профиле) стандарта, поскольку для его декодирования требуется больший объем обработки, чем в более простой схеме, известной как контекстно-адаптивная. кодирование переменной длины (CAVLC), которое используется в базовом профиле стандарта. CABAC также сложно распараллеливать и векторизовать, поэтому другие формы параллелизма (например, параллелизм пространственных областей) могут быть связаны с его использованием. В HEVC CABAC используется во всех профилях стандарта.

СОДЕРЖАНИЕ

1 Алгоритм
2 Пример
3 Механизм арифметического декодирования
4 История
5 См. Также
6 Ссылки

Алгоритм

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

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

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

Метод CABAC энтропийного кодирования, используемый в стандарте сжатия видео h364 на английском языке

Контекстное моделирование обеспечивает оценки условных вероятностей кодирующих символов. Используя подходящие контекстные модели, можно использовать данную межсимвольную избыточность, переключаясь между различными вероятностными моделями в соответствии с уже закодированными символами в окрестности текущего символа для кодирования. Контекстное моделирование обеспечивает примерно 10% -ную экономию CABAC в скорости передачи данных по сравнению с методом энтропийного кодирования CAVLC .

Кодирование символа данных включает следующие этапы.

Бинаризация: CABAC использует двоичное арифметическое кодирование, что означает, что кодируются только двоичные решения (1 или 0). Недвоичный символ (например, коэффициент преобразования или вектор движения) «бинаризуется» или преобразуется в двоичный код перед арифметическим кодированием. Этот процесс аналогичен процессу преобразования символа данных в код переменной длины, но двоичный код дополнительно кодируется (арифметическим кодером) перед передачей.
Этапы повторяются для каждого бита (или «бина») двоичного символа.
Выбор контекстной модели: «Контекстная модель» — это вероятностная модель для одного или нескольких бинов бинаризованного символа. Эта модель может быть выбрана из набора доступных моделей в зависимости от статистики недавно закодированных символов данных. Контекстная модель хранит вероятность того, что каждая ячейка будет равна «1» или «0».
Арифметическое кодирование: арифметический кодер кодирует каждый интервал согласно выбранной вероятностной модели. Обратите внимание, что для каждого бина есть только два поддиапазона (соответствующие «0» и «1»).
Обновление вероятности: выбранная контекстная модель обновляется на основе фактического кодированного значения (например, если значение интервала было «1», счетчик частоты «1» увеличивается).

Пример

1. Бинаризуйте значение MVDx, разность векторов движения в направлении x .

МВД _х	Бинаризация
0	0
1	10
2	110
3	1110
4	11110
5	111110
6	1111110
7	11111110
8	111111110

Первый бит двоичного кодового слова — это ячейка 1; второй бит — это ячейка 2; и так далее.

2. Выберите контекстную модель для каждой корзины. Для бина 1 выбирается одна из 3 моделей на основе ранее закодированных значений MVD. Рассчитывается норма L1 двух ранее закодированных значений, e _k :

e _k	Контекстная модель для корзины 1
0 ≤ е _к <3	Модель 0
3 ≤ е _к <33	Модель 1
33 ≤ e _k	Модель 2

Если e _k мала, то высока вероятность того, что текущая MVD будет иметь небольшую величину; и наоборот, если e _k велико, то более вероятно, что текущий MVD будет иметь большую величину. Соответственно выбираем таблицу вероятностей (контекстную модель). Остальные ячейки кодируются с использованием одной из 4 дополнительных контекстных моделей:

Корзина	Контекстная модель
1	0, 1 или 2 в зависимости от e _k
2	3
3	4
4	5
5 и выше	6

3. Закодируйте каждую ячейку. Выбранная контекстная модель предоставляет две оценки вероятности: вероятность того, что ячейка содержит «1», и вероятность того, что ячейка содержит «0». Эти оценки определяют два поддиапазона, которые арифметический кодер использует для кодирования бина.

4. Обновите контекстные модели. Например, если контекстная модель 2 была выбрана для ячейки 1 и значение ячейки 1 было «0», счетчик частоты «0» увеличивается. Это означает, что в следующий раз, когда будет выбрана эта модель, вероятность получения «0» будет немного выше. Когда общее количество вхождений модели превышает пороговое значение, счетчики частоты для «0» и «1» будут уменьшены, что фактически дает более высокий приоритет последним наблюдениям.

Механизм арифметического декодирования

Арифметический декодер более подробно описан в Стандарте. Он имеет три различных свойства:

Оценка вероятности выполняется посредством процесса перехода между 64 отдельными состояниями вероятности для «наименьшего вероятного символа» (LPS, наименее вероятное из двух двоичных решений «0» или «1»).
Диапазон R, представляющий текущее состояние арифметического кодера, квантуется до небольшого диапазона предварительно установленных значений перед вычислением нового диапазона на каждом шаге, что позволяет вычислить новый диапазон с помощью справочной таблицы (т. Е. Без умножения ).
Упрощенный процесс кодирования и декодирования определяется для символов данных с почти однородным распределением вероятностей.

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

История

В 1986 году исследователи IBM Коттапурам М.А. Мохиуддин и Йорма Йоханнен Риссанен подали патент на алгоритм двоичного арифметического кодирования без умножения. В 1988 г. исследовательская группа IBM, в которую входили Р. Б. Арпс, Т. К. Чыонг, Д. Лу, В. Б. Пеннебейкер, Л. Митчелл и Г. Г. Лэнгдон, представила алгоритм адаптивного двоичного арифметического кодирования (ABAC) под названием Q-Coder.

Вышеупомянутые патенты и исследовательские работы, а также несколько других от IBM и Mitsubishi Electric, были позже процитированы CCITT и Joint Photographic Experts Group в качестве основы для алгоритма адаптивного двоичного арифметического кодирования формата сжатия изображений JPEG в 1992 году. Однако кодеры и декодеры формат файла JPEG, который имеет параметры как для кодирования Хаффмана, так и для арифметического кодирования, обычно поддерживает только вариант кодирования Хаффмана, который изначально был связан с патентными проблемами, хотя патенты на арифметическое кодирование JPEG с тех пор истекли из-за возраста стандарта JPEG.

В 1999 году Ёнджун Ю ( Texas Instruments ), Янг Гэп Квон и Антонио Ортега ( Университет Южной Калифорнии ) представили контекстно-адаптивную форму двоичного арифметического кодирования. Современный алгоритм контекстно-адаптивного двоичного арифметического кодирования (CABAC) был коммерчески представлен с форматом H.264 / MPEG-4 AVC в 2003 году. Большинство патентов на формат AVC принадлежат Panasonic, Godo Kaisha IP Bridge и LG Electronics .

Смотрите также

Арифметическое кодирование
Сжатие данных
Сжатие без потерь
Контекстно-адаптивное кодирование переменной длины (CAVLC)

использованная литература

Handbrake | Русскоязычная документация по Ubuntu

Содержание

Handbrake
- Установка
- Основное окно
- Вкладка Summary
- Вкладка Video
- Вкладка Audio
- Вкладка Subtitles
- Вкладка Advanced
  - Encoding Features (особенности кодирования)
  - Reference Frames
  - Maximum B-Frames
  - Piramidal B-Frames
  - Weighted P-Frames
  - 8×8 Transform
  - CABAC Entropy Encoding
  - Analysis (анализ)
  - Motion Est. Method
  - Subpel ME & Mode
  - Motion Est. Range
  - Adaptive Direct Mode
  - Adaptive B-Frames
  - Partitions
  - Trellis
  - Psychovisual (восприятие)
  - Adaptive Quantization Strength
  - Psychovisual Rate Distortion
  - Psychovisual Trellis
  - Debloking
  - No DCT Decimate
- Вкладка Chapters
- Вкладка Tags
- Настройки изображения
- Пресеты
- Ссылки

Handbrake — кроссплатформенный DVD riper и видео-конвертер с расширенными настройками для энкодера H.264(x264), с встроенными фильтрами, с автокропингом и настройками для анаморфного кодирования.

Handbrake может открыть множество форматов видео которые поддерживаются libav, в том числе DVD диски, DVD-образы, DVD видео из каталога, Blu-ray диски (не защищеные).
Сохраняет видео в контейнеры mp4, m4v, mkv.
Использует для конвертирования:

видео кодеки: H.264(x264), MPEG-4(ffmpeg), MPEG-2(ffmpeg), VP3(Theora)
аудио кодеки: AAC, AC3, MP3, Vorbis, Flac, а также может копировать оригинальные аудио дорожки.

В программе доступны пресеты для iPod, iPhone, iPad и других устройств, можно создать свои.

Интерфейс не русифицирован.

Установка

Для установки Handbrake выполните в терминале следующие команды:

sudo apt-add-repository ppa:stebbins/handbrake-releases
sudo apt-get update
sudo apt-get install handbrake-gtk

Основное окно

Панель кнопок:
«Выбрать видео файл» «Начать кодирование» «Приостановить кодирование» «Добавить в очередь» «Показать очередь» «Настройки изображения» «Показать лог файл»

Source (источник)
Title — выбор заголовков для конвертирования (в DVD бывает несколько)
Chapters — выбор глав для конвертирования
Seconds — выбор секунд для ковертирования
Frames — выбор кадров для конвертирования

Destination (результат)
File — название нового файла
Каталог для сохранения
Format — формат файла

Параметры для mp4:
Web optimized — веб оптимизация для быстрой перемотки при просмотре по сети
iPod 5G Support — поддержка iPod 5G, опция для некоторых старых моделей айподов
Large file (>4GB) — вместить в mp4 больше 4 гигабайт (не все устройства поддерживают такие файлы)

Вкладка Summary

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

Вкладка Video

Видео параметры.

Video encoder — кодировщик видео
Framerate — частота кадров, по умолчанию выбран «Same as source» — как в исходном файле.
Constant Framerate — постоянная частота кадров (если в исходном файле была переменная частота кадров, то создаст копии некоторых кадоров)
Variable Framerate — переменная частота кадров (лучше качество видео и меньше размер файла)

Constant Quality — выбор уровней качества видео (вместо указания битрейта)
RF — уровень качества, чем меньше цифра — тем качество ближе к исходному, чем больше — тем сильнее сжимается видео, для конвертирования DVD видео рекомендуется значение 20, а для HD видео (720p,1080p, Blu-ray) использовать значение 22.
Это предпочтительный метод для создания DVD rip, так как не требует расчета оптимального битрейта для выбранного файла.
Если у вас исходный файл уже сильно сжат, например mp4(h364,aac) или AVI(Xvid,mp3), тогда лучше переключиться на настройку битрейта.

Bitrate — указание битрейта (вместо уровней качества), предварительно посмотрите битрейт исходного файла через mediainfo или плеер
Чтобы подобрать оптимальный битрейт для вашего файла, сконвертируйте кусок в 15 секунд с одним битрейтом, потом с другим, и сравните качество изображения в плеере.
2-Pass Encoding — кодирование в два прохода, это улучшит качество полученного видео
Turbo First Pass — быстрое выполнение первого прохода, почти не влияет на качество видео, зато уменьшается время кодирования

Use Advaced Options — активирует вкладку с расширенными настройками для энкодера H.264(x264)
Большинству пользователей хватит основных настроек, расширенные пригодятся для уменьшения искажений при очень низких битрейтах.

x264 Preset — предустановки для энкодера H.264(x264) разделены по скорости кодирования, чем быстрее кодирование тем хуже качество, рекомендуется использовать medium.

x264 Tune — улучшения для разных типов видео, оставьте значение по умолчанию, то есть выберите none

H. 264 Profile — профили, ориентированные на конкретные классы приложений (описание профилей), выберите auto

H.264 Level — уровни ограничений для аппаратных декодеров (описание уровней, для старых устройств будет 3, а для HD — 4), выберите auto если собираетесь смотреть видео на компьютере

Fast Decode — дополнительные настройки кодирования, для уменьшения нагрузки на процессор при воспроизведении полученного файла, например если кодируете видео для просмотра его на смартфоне, если планируете смотреть видео на компьютере — не выбирайте

More Settings — окно команд, перед настройкой очистите его

Вкладка Audio

Аудио параметры.

Passthru — означает копировать аудиопоток без перекодирования.

Вкладка Subtitles

Субтитры.

Вкладка Advanced

Расширенные настройки для видео энкодера H.264(x264).

Для активации вкладки Advanced необходимо на вкладке Video Выбрать пункт Use Advaced Options.

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

Encoding Features (особенности кодирования)

Reference Frames

Параметр задает количество используемых рефернсных кадров. Определяет, сколько предыдущих кадров может быть связано (заимствование макроблоков) с P- или B-кадрами.

Рекомендации: Приблизительно 4-6. Большие значения могут быть полезны для анимации, аниме, скринкастов и другого «статичного» видео. Примечание: При 5-ти и более референсных кадрах, качество, обычно, повышается незначительно.
Кроме того, 4 — максимальное значение для 1080p, а 9 — максимальное для 720p, придерживаясь спецификации Level 4.1. Это самый высокий уровень, поддерживаемый в большинстве бытовой электроники, которая поддерживают воспроизведение H.264, включая также Xbox 360 и Playstation 3.
Чем больше референсных кадров, тем медленнее кодирование.
Диапазон: 0..16
В MediaInfo: ref=<integer>
Значение по умолчанию: 3

Maximum B-Frames

Количество последовательных B-кадров между I- и P- кадрами. B-кадры – это кадры, в которых закодированы изменения не только от предыдущих кадров, но и от последующих. Имеют еще большую степень сжатия, чем P-кадры, но также и наихудшее качество. B-кадры подобны P-кадрам, кроме того, они могут использовать предсказание движения от будущих кадров также. Это может привести к значительному улучшению степени сжатия.

Рекомендации: Оптимальные значения: 2..6.
Если Вы используете –b-adapt 2, то можно смело задавать –bframes 16. Это самый простой способ, так как выбор оптимального значения падает на енкодер.
Оптимальное значение для конкретного видео можно получить путем чтения статистики первого прохода.
Примечание: При высоких значениях, больших чем необходимо, кодирование может быть значительно замедленно, без выйграша в качестве. Также большое количество В-кадров затрудняет декодирование.
Диапазон: 1..16
В MediaInfo: bframes=<integer>
Значение по умолчанию: 3

Piramidal B-Frames

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

Типы:

none — запрещает использовать В-кадры как референсные.
strict — разрешают по 1-му референсному В-кадру на каждый minigop (соблюдает ограничения стандарта Blu-ray).
normal — разрешает множественное использование референсных В-каров на каждый minigop.

Примечание: Без этого параметра, В-кадры могут ссылаться только на I- или P-кадры. Хотя I/P-кадры и более ценны, из-за их более высокого качества, B-кадры также могут быть полезными.
Необходимо значение –bframes выше 2-х. Немного замедляет кодирование. При кодировании для Blu-ray не используйте normal.
В MediaInfo: b_pyramid=<integer>
Значение по умолчанию: normal

Weighted P-Frames

Взвешенное предсказание яркости для P-кадров, которое улучшает затухания и градиенты цвета (небо и т. п.).

Варианты:

0 — отключено
1 — оценка затуханий
2 — оценка затуханий и поиск референсных дубликатов

В MediaInfo: weightp=<integer>
Значение по умолчанию: 2

8×8 Transform

Умное использование преобразований 8×8 в I-кадре.

Значение по умолчанию: включено

CABAC Entropy Encoding

CABAC (Context-Adaptive Binary Arithmetic Coding / Контекстно-Адаптивное Двоичное Арифметическое Кодирование) — это умная техника сжатия без потерь. При отключении CABAC энкодер начнет использовать CAVLC (Контекстно-Адаптивное Неравномерное Кодирование).

Рекомендации: Для карманных устройств(КПК, КМК и смартфонов) лучше использовать CAVLC. Так как их мощности не хватит что бы справится с CABAC.
Примечание: CABAC дает сжатие, приблизительно, на 10-20% больше, по сравнению с CAVLC.
CABAC использует больше процессорного времени для кодирования и декодирования.

Значение по умолчанию: Включено

Analysis (анализ)

Motion Est. Method

Устанавливаем метод оценки движения полного пикселя.

Методы:

dia (diamond, ромб) — простейший поиск, начиная с одного пикселя одного кадра, начинают просматриваться соседние пиксели на соседнем кадре, на один пиксель выше, правее, ниже и левее. Выбирается наиболее вероятно сдвинувшийся пиксель и процесс повторяется до тех пор, пока не будет найден лучший пиксель или пока не будет достигнут предел диапазона поиска движения
hex (hexagon, шестиугольник) — состоит из подобной стратегии, но использует для поиска 6 окружающих точек, отсюда и название — шестиугольник. Значительно эффективней, чем dia, но немного медленнее. Оптимален для повседневного кодирования.
umh (неравный мультишестиугольник) — значительно медленнее, чем hex, но ищет используя сложную модель мультишестиугольника. Лучше предыдущего, способен найти сложные векторы движения, ценой потери скорости кодирования. В отличие от предыдущих алгоритмов, в этом, и во всех последующих, опция –merange задает не количество итераций, а радиус, в пределах которого будет искаться пиксель.
esa (exhaustive, исчерпывающий) — высокооптимизированный интеллектуальный поиск на всей области поиска векторов движения, в пределах лучшего merange предсказания. Это математически эквивалентно методу поиска перебором, для каждого вектора движения в этой области, но быстрее. Этот метод значительно медленнее чем umh, но не дает значительного повышения качества, поэтому не рекомендован для повседневного кодирования.
tesa (transformed exhausive, преобразовано-исчерпывающий) — алгоритм, который пытается улучшить эффект Hadamard преобразования, сравнивая с каждым вектором движения. Похож на esa, но немного лучше и немного медленнее.

Рекомендации: umh
В MediaInfo: me=<string>
Значение по умолчанию: hex

Subpel ME & Mode

Задаем сложность оценки подпикселя. Уровни 1-5 просто управляют силой обработки подпикселя. Уровень 6 допускает RDO для режима предсказания, и уровень 8 допускает RDO для векторов движения и intra режимов предсказания.

Уровни:

0 — fullpel only (не рекомендуется)
1 — метод предсказания SAD, одна QPel итерация
2 — метод предсказания SADT
3-5 — постепенное увеличение QPel
6 — метод предсказания RD для I-/P- кадров
7 — метод предсказания RD для всех типов кадров
8 — RD обработка для I-/P- кадров
9 — RD обработка для всех типов кадров
10 — QP-RD (требует: –trellis 2 и –aq-mode >0)
11 — Full RD — новая опция, необходимая для будущего –trellis режима

Рекомендации: Стандартное значение или выше
Примечание: Чем выше уровень, тем ниже скорость кодирования.
В MediaInfo: subme=<integer>
Значение по умолчанию: 7

Motion Est. Range

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

Рекомендации: Стандартное значение для SD видео и 24 для HD видео. Падение скорости не стоит выигрыша в качестве, времени кодирования уже после 32.
Желательно использовать значения кратные 4-м.
Примечание: Для umh, esa и tesa, увеличение merange значительно замедлит кодирование.
Для dia и hex диапазон значений: 4..16.
В MediaInfo: me_range=<integer>
Значение по умолчанию: 16

Adaptive Direct Mode

Определяет метод нахождения векторов движения.

Доступные методы:

none — отключает поиск векторов движения.
spatial — использует для поиска соседние блоки одного кадра. Может повысить PSNR.
temporal — использует для поиска блоки соседних кадров. Немного лучше предыдущего.
auto — сам выбирает какие блоки использовать.

Примечание: auto лучше всего подходит для двухпроходного режима, но так же может использоваться и при однопроходном. auto нужно задавать во время обоих проходов, иначе второй проход будет автоматически использовать temporal.
Использовать none крайне не рекомендуется.
Рекомендации: auto – для двухпроходного режима, и spatial — при кодировании с CRF
В MediaInfo: direct=<integer>
Значение по умолчанию: spatial

Adaptive B-Frames

Позволяет x264 адаптивно решать, где будут использоваться B-кадры, уменьшая количество B-кадров там, где это не нужно.

Рекомендации: При высоком значении –bframes лучше задавать значение 2.
Настройки:

0 — полностью отключить
1 — «быстрый» алгоритм. Этот метод позволяет использовать –bframes 16
2 — оптимальный алгоритм, медленнее предыдущего

Примечание: В многопроходном кодировании эта опция необходима только для первого прохода, где типы кадров определены.
В MediaInfo: b_adapt=<integer>
Значение по умолчанию: 1

Partitions

x264 разбивает каждый кадр на части(макроблоки), и кодирует каждую отдельно. Этот параметр позволяет задать дополнительные параметры разбиения для каждого типа кадров.

Доступные partitions: p8x8(включает в себя p16x8/p8x16), p4x4(включает в себя p8x4/p4x8), b8x8(включает в себя b16x8/b8x16), i8x8, i4x4
Вы можете также установить none(отключить все) или all(включить все).
Рекомендации: Значение по умолчанию — оптимально. Для получения максимально качества можно использовать all, но скорее всего будет не лучше чем используя значение по умолчанию.
Примечание: p4x4 вообще то не очень полезен и его применение значительно снижает скорость кодирования при незначительном повышении качества изображения. Для HD видео лучше вообще не использовать.
i8x8 может использоваться только в High Profile
В MediaInfo: analyse=<string>
Значение по умолчанию: p8x8,b8x8,i8x8,i4x4

Trellis

Выполняет треллис квантование для повышения эффективности сжатия. На всех решениях, кроме 0, скорость падает очень сильно.

Варианты:

Рекомендации: 2, но при условии совместной работы с psy-trellis, иначе происходит незначительное замыливание мелких деталей. Требует включенного CABAC.
Примечание: Вариант 1 — хороший компромисс между падением скорости и повышением эффективности.
В MediaInfo: trellis=<integer>
Значение по умолчанию: Отключено

Psychovisual (восприятие)

Adaptive Quantization Strength

Устанавливает силу AQ, для подавления блочности и размытия на «плоских» и текстурированных областях.

Рекомендации: Применяйте в диапазоне от 0.7 (большая детализация изображения, но и больше артефактов) до 1.5 (меньшая детализация, но значительное снижение вероятности появления артефактов). Всё зависти от качества источника изображения.
Примечание: Отрицательные значения не допускаются. Значения вне диапазона 0.0 — 2.0 скорее всего приведут к полному искажению видео.
В MediaInfo: aq=<float>
Значение по умолчанию: 1.0

Psychovisual Rate Distortion

Psy-RDO позволяет экономно, с точки зрения битрейта, закодировать шумы видеоряда и значительно повысить детализацию изображения. Зернистость большинства видеоматериалов создаёт эффект большей детализации изображения, но после воздействия шумоподавляющих фильтров происходит замыливание изображения. Psy-RDO позволяет регулировать силу психовизуальной адаптации высокочастотных деталей изображения по следующему сценарию: вместо кодирования мелких деталей максимально приближенными к исходному материалу, Psy-RDO кодирует их максимально похожими на источник удобным с точки зрения битрейта способом, повышая таким образом детализацию изображения и несколько завышая показатели шума в PSNR. При этом мелкие детали не замыливаються, а заменяются похожими и выгодными кодеку структурами. Этот метод требует дополнительного битрейта в меньших объёмах при значительном повышении детализации изображения.

Рекомендации: оставьте всё по умолчанию, хотя для многих исходных материалов вполне приемлемы значения 1.0:0.15 при условии установки –aq-strength 0.7..1.2 и –trellis 2
Примечание: Психовизуальный метод имеет два параметра настройки:

Первый параметр — сила психовизуальной адаптации PSY-RDO (требует активации, чтобы –subme >-6). При PSY-RDO = 0 кодек отключает специфическую психовизуальную адаптацию вовсе. При этом кодек использует старую ssd метрику, которая стремится к большей точности, но не похожести мелкой детализации. Увеличение параметра PSY-RDO повышает детализацию и зернистость изображения, уменьшение наоборот их снижает. Следите за этим параметром внимательно, не допуская перешарпности изображения и таким образом ещё и экономя битрейт.
Второй параметр — сила Psy-Trellis. Чтобы использовать требуется –trellis >=1. Отметьте, что Psy-Trellis всё еще считают ‘экспериментальной’, и не рекомендуется, чтобы Вы использовали для реального кодирования, хотя кодирует всё же. При этом не повышайте величину Psy-Trellis более 0.5, хотя бы в начале.

В MediaInfo: psy_rd=<float>:<float>
Значение по умолчанию: 1.0:0.0

Psychovisual Trellis

Смотрите предыдущий пункт, это тожеотносится к нему.

Debloking

Использование фильтра подавления блоков с параметрами — alpha (сила подавления блоков):beta (точность определения блоков). При кодировании изображение разбивается на блоки размерами 8х8 пикселей и каждый такой блок кодируется отдельно. При недостаточном битрейте, эти блоки становятся заметными. Включение данной опции поможет решить проблему.

Рекомендации: Параметр «alpha» рекомендуется выбрать от -3 до 3. Большее значение увеличивает силу подавления блоков, но картинка становится немного размытой (используйте при низких битрейтах или при кодировании мультипликации). Меньшее значение уменьшает силу, зато картинка остается достаточно чёткой (используйте при высоких битрейтах). Если не знаете, что выбрать, то оставьте 0 — подходит для большинства случаев.
Параметр «beta» рекомендуется выбирать от -2 до 2. При больших значениях, кодек может распознать некоторые детали за блок и применить к ним фильтр подавления блоков. При меньших значениях, деталей сохранится больше, но некоторые блоки могут быть приняты за деталь (используйте меньшие значения при кодировании мультипликации — в ней четкие контуры, поэтому кодек не ошибется). Желательно чтобы этот параметр отличался не больше, чем на единицу от предыдущего. Если не знаете, что выбрать, то оставьте 0 — подходит для большинства случаев. Сила деблокинга вычисляется для каждого макроблока, исходя из квантизера для него и близлежащих макроблоков. Альфа определяет: является ли приграничный квадрат блочным или же на самом деле это деталь. Это похоже на порог. Бета так же похожа на порог, но используется для того, чтобы убедиться в однородности картинки с обеих приграничных сторон и, тем самым, отделить детали от блочности. Когда определена блочность, альфа решает, какую силу использовать (максимально допустимое изменение пикселя). Бета немного изменяет силу, если блок однородный. Сила деблокинга: Порог деблокинга. Порог деблокинга устанавливает жёсткость отбора блочности фильтром. Сила деблокинга регулирует, как сильно определённые блоки будут смягчены. Значения по умолчанию сочетают аккуратность удаления блочности и сохранение деталей. Значения должны лежать в диапазоне от -3 до 3 (чем ниже значения, тем меньше устраняется блочность. Отрицательные значения не означают, что блочность оставляется).
Примечание: Слишком высокие значения дадут потерю многих деталей и текстур или смазывание. Установка слишком низких значений оставит резкие края и «москитный шум» (mosquito noise). Должна быть положительная взаимосвязь между двумя коэффициентами деблокинга (желательно, чтобы обе цифры были отрицательными или положительными). Если Вы увеличиваете силу, то должны увеличить и порог
Диапазон: -6..6 (для alpha и beta соответственно)
В MediaInfo: deblock=1:<integer>:<integer>
Значение по умолчанию: 0:0

No DCT Decimate

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

Рекомендации: Используйте (то есть отключайте) при кодировании в –crf.
Примечание: Эта опция отключает данную функцию.
В MediaInfo: Не отображается
Значение по умолчанию: Отключено

Вкладка Chapters

Главы.

Вкладка Tags

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

Настройки изображения

Окно предпросмотра
Шкала выбора кадра для предпросмотра
Кнопка плей — запускает конвертирование заданного отрывка времени, начиная с выбранного кадра, и воспроизводит, получается предпросмотр результата
Duration — продолжительность отрывка для предпросмотра, в секундах
Show Crop — показать на изображении границы обрезки
Windowed/Fullscreen — предпросмотр в небольшом окне или наполный экран
Hide Settings — скрыть окно настроек изображения

Dimensions (размер изображения)
Cropping — обрезка изображения слева, справа, сверху, снизу
Auto Crop — автообрезка черных полос
Loose Crop — обрезка, когда нужно округлить число пикселов до кратного значения
Crop Dimensions — размер после обрезки

Рекомендации: оставьте автообрезку

Storage (запоминание размера)
width, height — ширина и высота изображения, когда отключен параметр Optimal for source
Optimal for source — оптимальный для исходного файла
Anamorphic — растягивание видео по ширине, как широкоформатное

Off — отключить
Strict — оставить как в оригинале
Loose — пропорции экрана оставить как в оригинале, изменить кратность и размер сторон
Custom — указать вручную: размер изображения, кратность, пропорции экрана

Alignment — сделать кратным установленному значению

Рекомендации: оставить значения по умолчанию, Loose и Optimal for source

Display (экран)
width, height — ширина, высота не регулируется, когда отключен параметр Keep Aspect
Pixel Aspect — пропорции в пикселах
Keep Aspect — сохранение исходных пропорций
Display Aspect — пропорции экрана, которые получились после изменений

Рекомендации: оставьте как есть.

Фильтры
Grayscale — полутона (делает видео черно-белым)
Deblock — подавление блоков, при очень низком битрейте могут появиться мелкие шестиугольники, их можно размыть с помощью этого фильтра
Denoise — удаление шума (когда видно что изображение состоит из точек), для DVD rip следует выбрать максимальное значение Strong
Detelecine — обратный пересчет кадров
Decomb — устранение гребенки (линий лесенкой) только в тех кадрах, где она обнаружена (более интеллектуальный метод чем Deinterlace)
Deinterlace — устранение гребенки (линий лесенкой), медленные алгоритмы лучше но замедляют кодирование

Пресеты

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

Ссылки

Официальный сайт Handbrake (англ.)
Документация по Hadbrake (англ.)
Краткое описание стандарта сжатия видео H.264
Опции для энкодера x264 (расшиернная настройка)

handbrake

Контекстно-адаптивное двоичное арифметическое кодирование (CABAC) H.264/AVC

1 Введение

Стандарт расширенного видеокодирования H.264 определяет два типа энтропийного кодирования: контекстно-ориентированное адаптивное двоичное арифметическое кодирование (CABAC) и кодирование переменной длины. (ВЛК). Этот документ представляет собой краткое введение в CABAC. Предполагается знакомство с концепцией арифметического кодирования.

2 Адаптивное двоичное арифметическое кодирование на основе контекста (CABAC)

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

Кодирование символа данных включает следующие этапы.

Бинаризация: CABAC использует двоичное арифметическое кодирование, что означает, что кодируются только двоичные решения (1 или 0). Недвоичный символ (например, коэффициент преобразования или вектор движения) «бинаризуется» или преобразуется в двоичный код перед арифметическим кодированием. Этот процесс аналогичен процессу преобразования символа данных в код переменной длины, но двоичный код дополнительно кодируется (арифметическим кодером) перед передачей.

Этапы 2, 3 и 4 повторяются для каждого бита (или «бина») бинаризованного символа.

Выбор контекстной модели: «Контекстная модель» — это вероятностная модель для одного или нескольких элементов бинарного символа. Эта модель может быть выбрана из набора доступных моделей в зависимости от статистики недавно закодированных символов данных. Контекстная модель хранит вероятность того, что каждый бин равен «1» или «0».
Арифметическое кодирование: Арифметический кодер кодирует каждый бин в соответствии с выбранной вероятностной моделью. Обратите внимание, что для каждого бина имеется только два поддиапазона (соответствующих «0» и «1»).
Обновление вероятности: выбранная контекстная модель обновляется на основе фактического закодированного значения (например, если значение бина было «1», частота подсчета «1» увеличивается).

3 Процесс кодирования

Мы проиллюстрируем процесс кодирования на одном примере, MVDx (разность векторов движения в направлении x).

Бинаризовать значение MVDx . Бинаризация выполняется в соответствии со следующей таблицей для |MVDx|<9 (большие значения MVDx преобразуются в бинарную форму с использованием кодового слова Exp-Golomb).

(Обратите внимание, что каждое из этих двоичных кодовых слов однозначно декодируется).

Первый бит бинарного кодового слова — бин 1; второй бит — bin 2; и так далее.

Выберите контекстную модель для каждой корзины. Для бина 1 выбирается одна из 3 моделей на основе ранее закодированных значений MVD. Вычисляется норма L1 двух ранее закодированных значений, ek:

Кодировать каждый бин. Выбранная контекстная модель предоставляет две оценки вероятности: вероятность того, что ячейка содержит «1», и вероятность того, что ячейка содержит «0». Эти оценки определяют два поддиапазона, которые арифметический кодер использует для кодирования бина.
Обновите модели контекста. Например, если контекстная модель 2 была выбрана для бина 1, а значение бина 1 было «0», счетчик частоты «0» увеличивается. Это означает, что при следующем выборе этой модели вероятность «0» будет несколько выше. Когда общее количество вхождений модели превышает пороговое значение, счетчики частоты для «0» и «1» будут уменьшены, что фактически дает более высокий приоритет недавним наблюдениям.

4 Контекстные модели

Контекстные модели и схемы бинаризации для каждого элемента синтаксиса определены в стандарте. Всего существует 267 отдельных моделей контекста, от 0 до 266 (по состоянию на сентябрь 2002 г.) для различных элементов синтаксиса. Некоторые модели имеют различное использование в зависимости от типа среза: например, пропущенные макроблоки не разрешены в I-срезе, поэтому контекстные модели 0–2 используются для кодирования бинов mb_skip или mb_type в зависимости от того, является ли текущий слайс кодированным внутри.

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

5 Механизм арифметического кодирования

Арифметический декодер подробно описан в Стандарте. Он имеет три различных свойства:

Оценка вероятности выполняется в процессе перехода между 64 отдельными состояниями вероятности для «наименее вероятного символа» (LPS, наименее вероятное из двух бинарных решений «0» или «1»).
Диапазон R, представляющий текущее состояние арифметического кодера, квантуется до небольшого диапазона предварительно заданных значений перед вычислением нового диапазона на каждом шаге, что позволяет вычислить новый диапазон с помощью справочной таблицы (т. свободно).
Упрощенный процесс кодирования и декодирования определен для символов данных с почти однородным распределением вероятностей.

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

Дополнительная литература

Iain E Richardson, «The H.264 Advanced Video Compression Standard», John Wiley & Sons, 2010.

Об авторе

Vcodex возглавляет профессор Иэн Ричардсон, всемирно известный эксперт по стандартам сжатия видео MPEG и H.264. Живя в Абердине, Шотландия, он часто путешествует по США и Европе.

Профессор Ричардсон является автором «Расширенного стандарта сжатия видео H.264», широко цитируемой работы в исследовательской литературе. Он написал еще три книги и более 50 статей для журналов и конференций по сжатию изображений и видео. Он регулярно консультирует компании по вопросам технологий видеокодеков, патентов на кодирование видео и слияний/поглощений в индустрии кодирования видео. Профессор Ричардсон возглавляет всемирно известную исследовательскую группу по кодированию изображений и видео, вносит свой вклад в группу по отраслевым стандартам MPEG и пользуется спросом в качестве свидетеля-эксперта и консультанта по судебным разбирательствам.

Быстрая оценка скорости CABAC на основе энтропии для выбора режима в HEVC | SpringerPlus

Исследования
Открытый доступ
Опубликовано: 17 июня 2016 г.

Вэй-Ган Чен ORCID: orcid.org/0000-0002-9332-0972 ¹ и
Сюнь Ван ¹

СпрингерПлюс том 5 , Номер статьи: 756 (2016) Процитировать эту статью

1097 доступов
1 Цитаты
Детали показателей

Abstract

Высокоэффективное кодирование видео (HEVC) ищет наилучшую конфигурацию кодового дерева, наилучшее деление блока прогнозирования и режим прогнозирования путем оценки функционала «скорость-искажение» рекурсивным способом и с использованием принципа «попробовать все и выбрать лучшее». стратегия. Кроме того, HEVC поддерживает только контекстно-адаптивное двоичное арифметическое кодирование (CABAC), недостатком которого является высокая последовательность и сильная зависимость данных в качестве энтропийного кодера. Таким образом, разработка быстрого алгоритма оценки скорости для кодирования на основе CABAC имеет большое практическое значение для определения режима в HEVC. В процессе кодирования CABAC есть три элементарных шага: бинаризация, контекстное моделирование и двоичное арифметическое кодирование. Типичные подходы к быстрой оценке скорости CABAC упрощают или исключают последние два шага, но оставляют этап бинаризации без изменений. Чтобы максимально снизить вычислительную сложность, в этой статье мы предлагаем быструю оценку скорости CABAC на основе энтропии. Это устраняет не только этапы моделирования и кодирования, но и этап бинаризации. Экспериментальные результаты показывают, что предложенный оценщик способен снизить вычислительную сложность решения о режиме в HEVC на 9–23 % с незначительной потерей PSNR и приращением скорости BD, и, следовательно, демонстрирует применимость к практической реализации кодировщика HEVC.

Общие сведения

Высокоэффективное кодирование видео (HEVC), недавно разработанный стандарт кодирования видео, следует так называемой блочной гибридной архитектуре кодирования (Салливан и др., 2012). HEVC направлен на обеспечение более высокой эффективности кодирования и улучшение распараллеливания кодека по сравнению с предыдущими стандартами. Эталонное программное обеспечение HM (https://hevc.hhi.fraunhofer.de/svn/svn-HEVCSoftware) достигло ожидаемой производительности, но за счет некоторых высокопроизводительных инструментов кодирования, включая блок кодирования на основе дерева квадрантов (CU), большие и блок асимметричного предсказания (PU), блок преобразования на основе остаточного дерева квадрантов (TU) (Ом и др., 2012; Боссен и др., 2012; Ким и др., 2012; Корреа и др., 2012; Пан и др., 2014).

Выбор режима, который управляет тем, как кодируется единица дерева кодирования (CTU) с помощью CU с переменными размерами блоков и режимами прогнозирования, является важным процессом в HEVC. Для достижения наилучшей производительности HEVC ищет наилучшую конфигурацию дерева кодирования, наилучшее разделение PU, режим прогнозирования и т. д. путем оценки функционала «скорость-искажение» (R-D), где член искажения взвешивается по отношению к члену скорости с использованием «попробовать». все и выбрать лучшую» стратегию (Pan et al. 2014).

Член скорости в функционале R-D представляет оценку количества закодированных битов, произведенных энтропийным кодером. В отличие от H.264/AVC, контекстно-адаптивное кодирование переменной длины (CAVLC) не поддерживается в HEVC. Он определяет только контекстно-адаптивное двоичное арифметическое кодирование (CABAC), которое включает три элементарных шага: бинаризацию, контекстное моделирование и двоичное арифметическое кодирование (Марпе и др., 2003) в качестве энтропийного кодера. На этапе бинаризации недвоичные элементы синтаксиса (SE), которые будут представлены в битовом потоке и описывают, как видеопоследовательность может быть восстановлена в декодере, сопоставляются с двоичными символами. Этот шаг продлит конвейеры кодирования, поскольку он обычно отображает один элемент в строку бина. На этапе моделирования бинарным символам присваивается модельное распределение вероятностей, которое было обновлено с использованием статистики уже закодированных соседних символов. На этапе арифметического кодирования фактический механизм кодирования управляется вероятностной моделью. На основе рекурсивного интервального деления и выбора процедура кодирования генерирует последовательность битов для представления SE.

Преимущество CABAC заключается в высокой эффективности кодирования. Однако эти три шага очень последовательны и вызывают сильную зависимость данных (Sze and Budagavi 2012). Таким образом, сложно использовать параллелизм и конвейерную обработку, что делает CABAC известным узким местом в пропускной способности при реализации видеокодека (Sze and Budagavi 2012; Sole et al. 2012). Типичные подходы к быстрой оценке скорости CABAC для принятия решения о режиме упрощают или устраняют этапы моделирования и кодирования, но оставляют без изменений этап бинаризации. Оценщик скорости CABAC для H.264/AVC, представленный в Hahm and Kyung (2010), упростил часть контекстного моделирования и заменил расчет арифметического кодирования схемой поиска по таблице. Он разработал несколько таблиц поиска. Записи в таблице были проиндексированы индексами состояния вероятности, которые были целыми числами от 0 до 62, и между записями и набором предопределенных репрезентативных значений вероятности наименее вероятного символа (LPS) имелось однозначное соответствие. За счет упрощения этапов моделирования и кодирования средство оценки скорости позволило снизить вычислительную сложность оценки RD для H.264/AVC примерно на 30 % (Hahm and Kyung 2010). Быстрая оценка скорости CABAC в Won et al. (2012) также был разработан для H.264/AVC и упростил этап кодирования за счет использования схемы таблицы поиска. Он разработал только одну таблицу, которая зависела от двух значений, одно из которых было индексом вероятности LPS, а другое было указанием на то, равны ли наиболее вероятный символ (MPS) и текущий кодируемый двоичный код. В Hahm et al. (2009 г.), была предложена оценка скорости, которая аппроксимирует контекстное моделирование в CABAC. Сообщалось, что оценщик снизил примерно на 20 % вычислительную сложность оптимизации R-D.

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

Оставшаяся часть статьи организована следующим образом. В разделе «Оценка скорости CABAC на основе энтропии» мы сначала представляем обзор оценки скорости для оптимизации R-D в HEVC. Затем оценивается корреляция между энтропией и скоростью CABAC CU, и предлагается основанная на энтропии оценка скорости CABAC. В разделе «Экспериментальные результаты» показаны некоторые экспериментальные результаты. Наконец, статья завершается разделом «Заключение».

Оценка скорости CABAC на основе энтропии

Оценка скорости для оптимизации скорости и искажения в HEVC

Конструкция HEVC следует классическому блочному гибридному подходу к кодированию видео. Изображение разбивается на последовательность CTU, аналогичную макроблокам в предыдущих стандартах. CTU может содержать только одну CU или может быть разделена на четыре CU одинакового размера. Рекурсивным образом CU имеет размер $2N \times 2N$ ($N = 8, 16, 32$) и может быть далее разделен на четыре более мелкие единицы одинакового размера. Структура блочного раздела CTU подобна дереву квадрантов. CU, являющийся конечным узлом дерева квадрантов, указывает область, совместно использующую один и тот же режим прогнозирования, то есть внутренний или внутренний. CU состоит из блока кодирования яркости (CB) и соответствующих CB цветности и связанных элементов синтаксиса. Кроме того, CU можно разделить на одну, две или четыре PU, и PU определяет область, совместно использующую одну и ту же информацию прогнозирования. Для CU с внутренним кодированием поддерживаются два возможных типа разделения PU. Для интеркодированных CU определены восемь типов разделения. А для пропущенных CU допускается только один тип разделения PU (то есть того же размера, что и CU) (Ким и др., 2012). После прогнозирования и компенсации вложенное дерево квадрантов разделяет остаток CU на единицы преобразования, каждая из которых определяет область, использующую одно и то же преобразование.

Как определить конфигурацию кодового дерева, определить разделение PU и выбрать режимы прогнозирования для всех CU в CTU — это критическая проблема для повышения эффективности кодирования. HEVC рассматривает эту проблему как так называемую оптимизацию искажения скорости (Салливан и Виганд, 1998), то есть

$$\begin{aligned} \min \left\{ D \right\} ,\quad \quad \mathrm {{s. t.}}\quad R \le R_c \end{aligned}$$

(1)

, где R и D представляют скорость и искажение для CU соответственно. $R_c$ — ограничение скорости. Задача оптимизации с ограничениями в (1) решается с помощью лагранжевой оптимизации, где член искажения взвешивается по отношению к члену скорости (Салливан и Виганд 19).*&= \mathop {\arg \min}\limits _{P \in M} \left\{ {J_p} \right\} \nonumber \\ J&= D + \lambda R \end{aligned}$$

(2)

, где M обозначает весь возможный набор параметров кодирования (т. е. настройку размера CU, деления PU, режима прогнозирования и т. д.), J — лагранжев функционал искажения скорости, а $ \lambda$ — множитель Лагранжа, который обычно определяется экспериментально или параметром квантования (QP) (Салливан и Виганд 1998). Например, принимая решение о глубине CU, стоимость R-D $CU_i$ (CU в глубине i ), закодированная без разделения, будет сравниваться со стоимостью при разделении. Проблема конфигурации дерева кодирования может быть решена путем принятия решения о том, следует ли разбивать CU каждого размера рекурсивным способом (Xiong et al. 2014).

Член скорости R в (2) может существенно повлиять на процесс оптимизации. Пусть r обозначает отношение между $\lambda R$ и J закодированной CU, т. е. $r = \frac{{\lambda R}}{J}$. Как правило, большее значение r означает, что гораздо больше битов было закодировано для представления SE для CU, и более высокая вычислительная нагрузка возлагалась на средство оценки скорости CABAC. Мы вычислили среднее значение r для нескольких тестовых последовательностей и изобразили результаты в таблице 1. Можно заметить, что среднее соотношение составляет от 8,2 до 37,5 % (как правило, чем меньше размер CU, тем больше значение отношения). Перед фактическим энтропийным кодированием следует выполнить процесс оптимизации в (2) для всех возможных CU, PU и TU, чтобы получить оптимальные настройки кодирования для CTU. Таким образом, вычислительная нагрузка для оценки члена скорости очень высока, и необходимо разработать быстрый оценщик скорости CABAC с достаточной точностью для процесса оптимизации скорости-искажения. 9{L — 1} {\Pr (k) \log _2 \Pr (k) } \end{aligned}$$

(3)

, где L обозначает количество возможных различных сообщений. Согласно теореме Шеннона о бесшумном кодировании (Jain, 1988), можно закодировать без искажения источник энтропии H бит, используя в среднем $H + \varepsilon$ бит на сообщение, где $\varepsilon$ равно сколь угодно малое количество.

В качестве источника рассматриваем СЭ ТС. Используя энтропию H SE, используемых для представления информации CU, мы можем оценить нижнюю границу количества битов, необходимых для кодирования вывода CU, то есть

$$\begin{align} R_{\min } = H\sum \limits _k {N\left( {z_k } \right) } \end{aligned}$$

(4)

где $ {N\left( {z_k } \right) }$ — частота появления элементов со значением $z_k$.

Пусть $x_i$ и $y_i$ обозначают предполагаемую нижнюю границу с использованием (4) и фактический результат кодирования CABAC в HM 13.0 (Ким и др. 2013) для $CU_i$ соответственно. 2 } } }} \end{align}$$

(5)

где $\bar{x}$ и $\bar{y}$ — средние значения x и y соответственно. Результаты для нескольких тестовых последовательностей представлены в таблице 2.

Рис. 1

Иллюстрация распределения выборочных данных $\left\{ {\left( {x_i , y_i } \right) } \right\} $, которые были получены из первых 25 кадров последовательности BasketballDrill , где $x_i$ — предполагаемая нижняя граница, а $y_i$ — количество фактических выходных битов кодера CABAC для CU

Изображение в натуральную величину

Рис. 2

Среднее значение сокращения затрат времени на оценку R-D (в процентах) для последовательностей в табл. 4, a – d QP = 22, 27, 32, и 37

Полноразмерное изображение

Таблица 1 Соотношение r (в процентах) для CU разных размеров для нескольких последовательностей с QP = 27

Полноразмерная таблица

Таблица 2 Иллюстрация коэффициента корреляции для последовательностей с различным QP

Полноразмерная таблица

Предлагаемый оценщик скорости CABAC и реализация

В CABAC бинаризация отображает данный SE в уникальную двоичную строку, и разные элементы приводят к разным бинам с разным количеством битов «0» и «1». Для обычного режима кодирования будет выбрана конкретная модель контекста, и одно из двух двоичных значений (0 или 1) будет идентифицировано как MPS, а другое — как LPS (Sole et al. 2012). Кроме того, LPS больше уменьшает диапазон интервалов и имеет более высокую вероятность генерирования выходного бита, чем MPS. Принимая во внимание влияние этих двух шагов, $R_{\min}$ в (4) не принимается напрямую в качестве оценки количества закодированных битов для CU. Вместо этого мы вводим вектор $\mathbf {w}$, содержащий веса, соответствующие различным значениям SE, чтобы учесть эффект бинаризации и контекстного моделирования. Оценщик сформулирован как модель линейной регрессии ниже 9T \mathbf{{u}} = w_0 u_0 + w_1 u_1 + \cdots + w_n u_n \end{aligned}$$

(6)

, где $\mathbf {w}$ и $\mathbf { u}$ являются L -мерными векторами-столбцами, а

$$\begin{aligned} u_k = \left\{ {\begin{array}{*{20}c} { — N\left( {z_k } \right) \log _2 {h\left( {z_k } \right) } } &{} \quad {h\left( {z_k } \right) \ne 0} \\ 0 &{} \quad {\ mathrm{{иначе}}} \\ \end{массив}} \right. {L — 1} {N\left( {z_i} \right) } }} \end{aligned}$$

(8)

Формулировка использует $\mathbf {u}$ в качестве входного вектора регрессора. Теперь осталось определить подходящий вектор параметров $\mathbf {w}$, который может предсказать скорость CABAC с приемлемой точностью. Мы рассматриваем оценку в (6) как нестационарную систему, параметры которой изменяются во времени. Поскольку существует высокая корреляция между нижней границей и количеством фактически закодированных битов кодера CABAC, разумно предположить, что изменения параметров происходят медленно. Мы обращаемся к вектору параметров как к состоянию линейной динамической системы с дискретным временем. 9T \mathbf{{u}}_k + e_2 \end{aligned}$$

(10)

где $R_k$ — количество фактически закодированных битов для $CU_k$. $e_1$ и $e_2$ представляют шум процесса и измерения соответственно. Предполагается, что они белые и имеют нормальное распределение вероятностей, то есть:

$$\begin{aligned}&p\left( {e_1 } \right) \sim N\left( {0,\;\mathbf {Q} } \right) \end{align}$$

(11)

$$\begin{aligned}&p\left( {e_2 } \right) \sim N\left( {0,\;\sigma _e^ 2 } \right) \end{aligned}$$ 9- \end{aligned}$$

(17)

, где $\mathbf {I}$ обозначает единичную матрицу.

Наконец, мы хотели бы сделать несколько замечаний по поводу предложенного здесь оценщика скорости CABAC. Во-первых, для CU обновление вектора весов выполняется только один раз, в то время как оценка в (6) оценивалась десятки раз для определения режима предсказания, разбиения PU. Хотя обновление в (14)–(17) несколько сложно с точки зрения вычислений, оно не приведет к еще большему снижению вычислительной эффективности оценщика. Во-вторых, HEVC имеет много разных SE. Для SE, который был представлен как флаг включения/выключения (например, merge_flag, cu_split_flag), мы просто добавили один бит к расчетной скорости для каждого флага, в то время как уравнение. (6) применялась в наших экспериментах для других СЭ.

Таблица 3 Условия тестирования

Полноразмерная таблица

Таблица 4 Тестовые последовательности

Полноразмерная таблица

Экспериментальные результаты

Для оценки производительности быстрой энтропийной оценки скорости CABAC предложенный алгоритм был реализован на HEVC эталонное программное обеспечение HM 13. 0 (Ким и др., 2013 г.) с общими условиями тестирования HEVC (Боссен, 2012 г.), которые приведены в таблице 3. Мы закодировали три последовательности класса B с пространственным разрешением $1920 x 1080$ и три последовательности класса E. последовательности с разрешением \(1280 х 720). Тестовые последовательности и их порядковые номера приведены в таблице 4. Моделирование проводилось на персональном компьютере с процессором Intel Core i5-4430 и 4 ГБ ОЗУ. В качестве операционной системы использовалась 64-разрядная версия Microsoft Windows 7 Enterprise.

Экономия времени

Мы записали время, затрачиваемое на определение режима для всех CU (то есть время, затрачиваемое xCompressCU (), который является модулем анализа CU в ПО HM), и аккумулировали их. Снижение вычислительной сложности было рассчитано следующим образом (Xiong et al. 2014):

$$\begin{aligned} \Delta T = \frac{{T_{test} — T_{ref} }}{{T_{ref} }} \times 100\,\% \end{aligned}$$

(18)

где $T_{ref}$ обозначает накопленное время, затрачиваемое исходным кодировщиком HM 13. 0, а $T_{test }$ обозначает время, затраченное на то, когда быстрые оценщики скорости CABAC были приняты для оценки затрат на НИОКР.

Для сравнения, алгоритм Won et al. (2012), который был разработан для быстрой оценки скорости для выбора режима H.264/AVC, также был реализован на HM. Среднее значение $\Delta T$ для протестированных последовательностей в таблице 4 суммировано на рис. 2. Он показывает, что предложенный алгоритм экономит вычисление оценки скорости от 9,2 до 22,3 % и 14,5 % в среднем. Результаты также показывают, что предложенный оценщик вычислительно более эффективен, чем предыдущий алгоритм. В частности, улучшение производительности было выше, когда QP был небольшим. Причина этого заключается в том, что значение QP влияет на общее время кодирования, а меньший QP подразумевает более высокую остаточную энергию, и на блок оценки скорости CABAC будет возложена более высокая вычислительная нагрузка. В этих обстоятельствах наша схема имеет то преимущество, что устраняет все три этапа кодирования CABAC, в то время как метод Won et al. (2012) оставляет шаг бинаризации без изменений.

Эффективность сжатия

Мы сравнили эффективность кодирования предложенного алгоритма с эталонным программным обеспечением с точки зрения дельта скорости Бьонтегора (BD-Rate), дельта Бьонтегора PSNR (BD-PSNR) (Bjøntegaard 2001). Экспериментальные результаты были сведены в Таблицу 5. Мы заметили, что предложенная оценка немного увеличила скорость BD. Для яркостной составляющей прирост составляет от 1,81 до 2,43 %, в среднем около 2,21 %. Приращение компонентов цветности (Cb и Cr) от 0,19до 2,29 % и 1,19 % в среднем. Тем не менее, снижение сложности и производительность за счет лучшего распараллеливания стоили увеличения скорости. Из результатов также видно, что потери BD-PSNR незначительны. Кроме того, мы оценили производительность оценщика скорости CABAC по ошибке оценки, используя критерий ниже

$$\begin{aligned} \Delta R = \frac{{\left| {R_t — R_r } \право| }}{{R_t + R_r}} \times 100\,\% \end{align}$$

(19)

, где $R_t$ — расчетная скорость нашего оценщика, а $R_r$ — скорость программы HM. Мы рассчитали среднее значение $\Delta R$ для всех CU и изобразили результат в таблице 5. Производительность кодирования предложенного алгоритма также сравнивалась с оценкой в Won et al. (2012) с точки зрения $\Delta T$, BD-Rate и BD-PSNR, а результаты представлены в таблице 6.

Таблица 5 Среднее значение ${\Delta R}$, $ {\Delta T}$, приращение скорости BD и потеря BD-PSNR по сравнению с эталонным программным обеспечением HEVC

Полноразмерная таблица

Таблица 6 Характеристики кодирования (среднее значение $\Delta T$, BD-Rate и BD-PSNR) предложенного метода в сравнении с методом Won et al. (2012)

Полноразмерная таблица

Заключение

В этой статье предлагается быстрый алгоритм оценки скорости CABAC на основе энтропии, который применим для оптимизации соотношения скорости и искажения в HEVC. Синтаксические элементы CU рассматриваются как источник, содержащий дискретный набор независимых сообщений. Исследуется неявная связь между энтропией источника и количеством закодированных битов (т. е. выход кодера CABAC) для CU. Используя корреляцию между этими двумя значениями, предлагаемый подход оценивает скорость CABAC как взвешенную сумму информации, генерируемой источником. Весовой вектор, который используется для компенсации эффекта шагов бинаризации и контекстного моделирования, рассматривается как состояние линейной динамической системы с дискретным временем. Веса адаптивно обновляются в процессе фактического кодирования CABAC, который активируется для кодирования всех SE в битовый поток после определения наилучшего режима текущей CU с использованием фильтрации Калмана.

Ссылки

Bjøntegaard G (2001) Расчет средних различий psnr между rd-кривыми. В: документ VCEG VCEG-M33, ITU-T SG16/Q6, Остин. ITU-T, стр. 1–5
Боссен Ф., Бросс Б., Зюринг К., Флинн Д. (2012) Сложность HEVC и анализ реализации. IEEE Trans Circuits Syst Video Technol 22(12):1685–1696
Статья Google ученый
Боссен Ф. (2012 г.) Общие условия тестирования и эталонные конфигурации программного обеспечения. См.: документ JCT-VC JCTVC-J1100, 10-е собрание, Стокгольм, 11–20 июля 2012 г. JCT-VC, стр. 1–3
Катлин Д.Э. (1988) Оценка, управление и дискретный фильтр Калмана. Спрингер, Нью-Йорк
Google ученый
Corrêa G, Assuncão P, Agostini L, Cruz LAS (2012) Оценка производительности и вычислительной сложности высокоэффективных видеокодеров. IEEE Trans Circuits Syst Video Technol 22(12):1899–1909
Статья Google ученый
Hahm J, Kyung C-M (2010) Эффективная оценка скорости CABAC для выбора режима H.264/AVC. IEEE Trans Circuits Syst Video Technol 20(2):310–316
Статья Google ученый
Hahm J, Kim J, Kyung CM (2009) Быстрая оценка скорости CABAC для выбора режима H.264/AVC. В: Труды международной конференции IEEE по акустике, речи и обработке сигналов, Тайбэй, 19–24 апреля 2009 г. IEEE Computer Society, стр. 929–932
Программное обеспечение HM. https://hevc.hhi.fraunhofer.de/svn/svn-HEVCSoftware
Джайн А.К. (1988) Основы цифровой обработки изображений. Prentice Hall, Englewood Cliffs
Google ученый
Kim IK, Min J, Lee T, Han WJ, Park JH (2012) Структура разделения блоков в стандарте HEVC. IEEE Trans Circuits Syst Video Technol 22(12):1697–1706
Статья Google ученый
Ким И.К., Макканн К., Сугимото К., Бросс Б., Хан В.Дж., Салливан Г. (2013) Высокоэффективное кодирование видео (hevc), тестовая модель 13 (hm 13), описание кодировщика. В: Документ JCT-VC JCTVC-O1002, 15-е собрание, Женева, 23 октября – ноябрь. 1 2013. JCT-VC, стр. 1–39
Марпе Д., Шварц Х., Виганд Т. (2003) Адаптивное двоичное арифметическое кодирование на основе контекста в стандарте сжатия видео H. 264/AVC. IEEE Trans Circuits Syst Video Technol 13(7):620–636
Статья Google ученый
Ом Дж.-Р., Салливан Г.Дж., Шварц Х., Тан Т.К., Виганд Т. (2012) Сравнение эффективности кодирования стандартов кодирования видео, включая высокоэффективное кодирование видео (HEVC). IEEE Trans Circuits Syst Video Technol 22(12):1669–1684
Статья Google ученый
Pan Z, Kwong S, Sun MT, Lei J (2014) Раннее решение о режиме слияния на основе оценки движения и иерархической корреляции глубины для HEVC. IEEE Trans Broadcast 60 (2): 405–412
Артикул Google ученый
Соле Дж., Джоши Р., Нгуен Н., Джи Т., Карчевиц М., Клэр Г., Генри Ф., Дуэньяс А. (2012) Кодирование коэффициента преобразования в HEVC. IEEE Trans Circuits Syst Video Technol 22(12):1765–1777
Статья Google ученый
Салливан Г. Дж., Ом Дж.Р., Хан В.Дж., Виганд Т. (2012) Обзор стандарта высокоэффективного кодирования видео (HEVC). IEEE Trans Circuits Syst Video Technol 22 (12): 1649–1668
Артикул Google ученый
Салливан Г.Дж., Виганд Т. (1998) Оптимизация соотношения скорости и искажения для сжатия видео. IEEE Signal Process Mag 15(6):74–90
Статья Google ученый
Сзе В., Будагави М. (2012) Высокопроизводительное энтропийное кодирование CABAC в HEVC. IEEE Trans Circuits Syst Video Technol 22(12):1778–1791
Статья Google ученый
Вон К., Ян Дж., Чон Б. (2012) Оценка скорости Fast CABAC для выбора режима H.264/AVC. Eletron Lett 48(19):1201–1202
Статья Google ученый
Xiong J, Li H, Wu Q, Meng F (2014) Метод быстрого выбора hevc inter cu, основанный на дивергенции движения пирамиды. IEEE Trans Multimed 16(2):559–564
Статья Google ученый

Скачать ссылки

Вклад авторов

WG провела исследования по оценке скорости CABAC, отредактировала статью и подготовила рукопись. Все авторы прочитали и одобрили окончательный вариант рукописи.

Благодарности

Эта работа была частично поддержана Фондом естественных наук провинции Чжэцзян (№ LY14F020001), Фондом естественных наук Китая (№ 61379075), Национальной программой поддержки ключевых технологий (№ 2014BAK14B00) и провинцией Чжэцзян. Проект научно-технического плана (грант № 2014C33070). Авторы хотели бы поблагодарить анонимных рецензентов за их полезные комментарии.

Конкурирующие интересы

Авторы заявляют, что у них нет конкурирующих интересов.

Author information

Authors and Affiliations

School of Computer and Information Engineering, Zhejiang Gongshang University, Hangzhou, 310018, China
Wei-Gang Chen & Xun Wang

Authors

Wei-Gang Chen
Посмотреть публикации автора
Вы также можете искать этого автора в PubMed Google Академия
Xun Wang
Посмотреть публикации автора
Вы также можете искать этого автора в PubMed Google Scholar

Автор, ответственный за корреспонденцию

Вэй-Ганг Чен.

Права и разрешения

Открытый доступ Эта статья распространяется в соответствии с условиями международной лицензии Creative Commons Attribution 4.0 (http://creativecommons.org/licenses/by/4.0/), которая разрешает неограниченное использование, распространение и воспроизведение на любом носителе при условии вы должным образом указываете автора (авторов) и источник, предоставляете ссылку на лицензию Creative Commons и указываете, были ли внесены изменения.

Перепечатки и разрешения

Об этой статье

Быстрая оценка скорости CABAC на основе энтропии для выбора режима в HEVC

Список журналов
Спрингерплюс
PMC48

Спрингерплюс. 2016; 5(1): 756,

Опубликовано в сети 17 июня 2016 г. doi: 10.1186/s40064-016-2377-0

^и

Информация об авторе Примечания к статье Информация об авторских правах и лицензии Отказ от ответственности

Видео с высокой эффективностью конфигурация дерева, разделение на наилучшие единицы прогнозирования и режим прогнозирования путем оценки функционала «скорость-искажение» рекурсивным способом и с использованием стратегии «попробовать все и выбрать лучшее». Кроме того, HEVC поддерживает только контекстно-адаптивное двоичное арифметическое кодирование (CABAC), недостатком которого является высокая последовательность и сильная зависимость данных в качестве энтропийного кодера. Таким образом, разработка быстрого алгоритма оценки скорости для кодирования на основе CABAC имеет большое практическое значение для определения режима в HEVC. В процессе кодирования CABAC есть три элементарных шага: бинаризация, контекстное моделирование и двоичное арифметическое кодирование. Типичные подходы к быстрой оценке скорости CABAC упрощают или исключают последние два шага, но оставляют этап бинаризации без изменений. Чтобы максимально снизить вычислительную сложность, в этой статье мы предлагаем быструю оценку скорости CABAC на основе энтропии. Это устраняет не только этапы моделирования и кодирования, но и этап бинаризации. Экспериментальные результаты показывают, что предложенный оценщик способен снизить вычислительную сложность решения о режиме в HEVC на 9–23 % с незначительной потерей PSNR и приращением скорости BD, и, следовательно, демонстрирует применимость к практической реализации кодировщика HEVC.

Ключевые слова: Высокоэффективное кодирование видео, выбор режима, оптимизация искажения скорости, контекстно-адаптивное двоичное арифметическое кодирование, оценка скорости

Высокоэффективное кодирование видео (HEVC), которое является недавно разработанным стандартом кодирования видео, так называемая блочная гибридная архитектура кодирования (Салливан и др. , 2012). HEVC направлен на обеспечение более высокой эффективности кодирования и улучшение распараллеливания кодека по сравнению с предыдущими стандартами. Эталонное программное обеспечение HM (https://hevc.hhi.fraunhofer.de/svn/svn-HEVCSoftware) достигло ожидаемой производительности, но за счет некоторых высокопроизводительных инструментов кодирования, включая блок кодирования на основе дерева квадрантов (CU), большие и блок асимметричного предсказания (PU), блок преобразования на основе остаточного дерева квадрантов (TU) (Ом и др., 2012; Боссен и др., 2012; Ким и др., 2012; Корреа и др., 2012; Пан и др., 2014).

Оценка скорости для оптимизации скорости и искажения в HEVC

Конструкция HEVC следует классическому блочному гибридному подходу к кодированию видео. Изображение разбивается на последовательность CTU, аналогичную макроблокам в предыдущих стандартах. CTU может содержать только одну CU или может быть разделена на четыре CU одинакового размера. Рекурсивным образом CU имеет размер 2 90 594 N 90 595 × 2 90 594 N 90 595 ( 90 594 N 90 595 = 8, 16, 32) и может быть дополнительно разделена на четыре меньшие единицы одинакового размера. Структура блочного раздела CTU подобна дереву квадрантов. CU, являющийся конечным узлом дерева квадрантов, указывает область, совместно использующую один и тот же режим прогнозирования, то есть внутренний или внутренний. CU состоит из блока кодирования яркости (CB) и соответствующих CB цветности и связанных элементов синтаксиса. Кроме того, CU можно разделить на одну, две или четыре PU, и PU определяет область, совместно использующую одну и ту же информацию прогнозирования. Для CU с внутренним кодированием поддерживаются два возможных типа разделения PU. Для интеркодированных CU определены восемь типов разделения. А для пропущенных CU допускается только один тип разделения PU (то есть того же размера, что и CU) (Ким и др., 2012). После прогнозирования и компенсации вложенное дерево квадрантов разделяет остаток CU на единицы преобразования, каждая из которых определяет область, использующую одно и то же преобразование.

Как определить конфигурацию кодового дерева, определить разделение PU и выбрать режимы прогнозирования для всех CU в CTU — это критическая проблема для повышения эффективности кодирования. HEVC рассматривает эту проблему как так называемую оптимизацию скорости искажения (Салливан и Виганд, 1998), то есть

мин { D }, с.т. R ≤ R _c

где R и D представляют скорость и искажение для CU соответственно. R _c — ограничение скорости. Задача оптимизации с ограничениями в (1) решается с использованием лагранжевой оптимизации, где член искажения взвешивается по отношению к члену скорости (Салливан и Виганд, 1998),

P*=argminP∈MJpJ=D+λR

, где M обозначает весь возможный набор параметров кодирования (т. е. настройку размера CU, деления PU, режима прогнозирования и т. д.), J — лагранжев функционал искажения скорости, а λ — это множитель Лагранжа, который обычно определяется экспериментально или параметром квантования (QP) (Салливан и Виганд, 1998). Например, принимая решение о глубине CU, стоимость R-D C U _i (CU в глубине i ), закодированная неразделенным способом, будет сравниваться со стоимостью разделенного способа. Проблема конфигурации дерева кодирования может быть решена путем принятия решения о том, следует ли разбивать CU каждого размера рекурсивным способом (Xiong et al. 2014).

Член скорости R в (2) может существенно повлиять на процесс оптимизации. Пусть r обозначает отношение между λ R и J закодированной CU, т. е. r=λRJ. Как правило, большее значение r означает, что гораздо больше битов было закодировано для представления SE для CU, и более высокая вычислительная нагрузка возлагалась на средство оценки скорости CABAC. Мы вычислили среднее значение r для нескольких тестовых последовательностей и представили результаты в таблице. Можно заметить, что средний коэффициент составляет от 8,2 до 37,5 % (как правило, чем меньше размер ТС, тем больше значение коэффициента). Перед фактическим энтропийным кодированием следует выполнить процесс оптимизации в (2) для всех возможных CU, PU и TU, чтобы получить оптимальные настройки кодирования для CTU. Таким образом, вычислительная нагрузка для оценки члена скорости очень высока, и необходимо разработать быстрый оценщик скорости CABAC с достаточной точностью для процесса оптимизации скорости-искажения.

Таблица 1

Соотношение r (в процентах) для CU разных размеров для нескольких последовательностей с QP = 27

Последовательность	32 × 32	16 × 16	8 × 8
BasketballDrive_1920×1080	10. 1	17.2	26.5
BQTerrace_1920×1080	15.1	24.5	36.1
Parkjoy_1920×1080	8.2	24.4	37.5
Vidyo1_1280×720	8.9	18.1	28.4
Video4_1280×720	10.2	18. 69	27.9
FourPeople_1280× 720	9.2	17.3	29.2

Открыть в отдельном окне

Корреляция между энтропией и скоростью CABAC есть независимый источник, содержащий дискретный набор сообщений

z _k с вероятностями Pr( k ). Энтропия, которая измеряет среднюю информацию, генерируемую всеми сообщениями в источнике, определяется как возможные разные сообщения. Согласно теореме Шеннона о бесшумном кодировании (Jain, 1988), можно закодировать без искажения источник энтропии 90 594 H 90 595 бит, используя в среднем 90 594 H + ε бит на сообщение, где ε — произвольно малое количество.

Rmin=H∑kNzk

где N ( z _k ) — частота появления элементов со значением з _к .

Пусть x _i и y _i обозначают расчетную нижнюю границу с использованием (4) и фактический выход кодировщика CABAC в CABAC 13.0 для HM 13.0. U _и соответственно. Мы представляем их как парные данные ( x _i, y _i). Набор образцов {( x 9На рис. Мы заметили, что может наблюдаться разница между предполагаемой нижней границей и фактическими битами CU на выходе. Однако эксперименты также показали наличие высокой корреляции между переменными x и y . Для подтверждения этой гипотезы корреляция между ними количественно измеряется в виде коэффициента корреляции ниже:

c=∑ixi-x¯yi-y¯∑ixi-x¯2∑iyi-y¯2

где x¯ и y¯ — средние значения x и y соответственно. Результаты для нескольких тестовых последовательностей представлены в таблице.

Открыть в отдельном окне

Иллюстрация распределения выборочных данных {( x _i , y _i )} 2 , полученных из 4 первых 5 кадров последовательности БаскетболДрель , где x _i — расчетная нижняя граница, а y _i — число фактических выходных битов CABAC-кодировщика для CU

7 коэффициента корреляции. Для последовательностей с различными QP

Последовательность	QP = 22	QP = 37
Баскетболдрив_1
баскетбальдрив_1
. 0.9711
BQTerrace_1920×1080	0.9764	0.9761
Vidyo1_1280×720	0.9730	0.9769
Video4_1280×720	0.9661	0.9771
FourPeople_1280×720	0.9761	0,9766
KristenAndSara_1280×720	0,9774	0,9774

5 9 Открыть в отдельном окне0005

Предлагаемый оценщик скорости CABAC и реализация

where w and u are L -dimensional column vectors, and

uk=-Nzklog2hzkhzk≠00otherwise

and

hzk= Nzk∑i=0L-1Nzi

Формула использует u в качестве входного вектора регрессора. Теперь осталось определить подходящий вектор параметров w , который может предсказать скорость CABAC с приемлемой точностью. Мы рассматриваем оценку в (6) как нестационарную систему, параметры которой изменяются во времени. Поскольку существует высокая корреляция между нижней границей и количеством фактически закодированных битов кодера CABAC, разумно предположить, что изменения параметров происходят медленно. Мы обращаемся к вектору параметров как к состоянию линейной динамической системы с дискретным временем.

W _K = W _{K -1} + E ₁

Activeer Parmeter Parameter, Fabreting Factore, Fabreting Factore, Fabreting Factore, We Actiperater. все SE в битовый поток после определения оптимальной структуры CTU и наилучшего режима текущей CU. Связь между наблюдаемым измерением и вектором состояния:

Rk=wkTuk+e2

, где R _k — количество фактически закодированных битов для C U _k . e ₁ и e ₂ представляют шум процесса и измерения соответственно. Предполагается, что они белые и имеют нормальное распределение вероятностей, то есть: с очень маленькими диагональными входами. Это означает, что параметры состояния независимы друг от друга и дисперсия состояния мала. Дисперсия σe2 в (12) меняется при каждом измерении и определяется выражением 9k+1-

А ковариация апостериорной ошибки равна:

Pk+1=I-gk+1uk+1TPk+1-

, где I обозначают единичную матрицу.

Чтобы оценить производительность быстрой оценки скорости CABAC на основе энтропии, предложенный алгоритм был реализован в эталонном программном обеспечении HEVC HM 13. 0 (Ким и др., 2013 г.) с общими условиями тестирования HEVC (Боссен, 2012 г.), которые приведены в таблице. . Мы закодировали три последовательности класса B с пространственным разрешением 1920 × 1080 и три последовательности класса E с разрешением 1280 × 720. Тестовые последовательности и их порядковые номера приведены в таблице. Моделирование выполнялось на персональном компьютере с процессором Intel Core i5-4430 и 4 ГБ оперативной памяти. В качестве операционной системы использовалась 64-разрядная версия Microsoft Windows 7 Enterprise.

Таблица 3

Условия испытаний

9 Открыть в отдельном окне

Таблица 4

Тестовые последовательности

Энкодер	HM 13,0
Макс. и мин. 90 типоразмеров 9CU 64 × 64 и 8 × 8
Макс. и мин. размеры ТУ	32 × 32 и 4 × 4
Fast ME	Включено, диапазон поиска 64
QPs	22, 27, 32, 37

Класс	Номер последовательности	Name	Number of coded frames
B (1920 × 1080))	1	BasketballDrive	500
	2	BQTerrace	500
	3	Parkjoy	500
E (1280 × 720)	4	Vidyo1	300
	5	Vidyo4	300
	6	FourPeople	600

Open in a separate window

Time saving

We recorded the time consumption for mode decision для всех CU (то есть время, затрачиваемое xCompressCU (), который является модулем анализа CU в ПО HM), и их накопление. Снижение вычислительной сложности было рассчитано следующим образом (Xiong et al. 2014):

ΔT = TTEST-Treftref × 100%

, где T _{R E F} Обозначает наклоненное время Ecoder , и 9065 905 905 905 905 905 905. . e s t обозначает время, затраченное на применение быстрых оценщиков скорости CABAC для оценки стоимости R-D.

Для сравнения, алгоритм Won et al. (2012), который был разработан для быстрой оценки скорости для выбора режима H.264/AVC, также был реализован на HM. Среднее значение Δ T для протестированных последовательностей в таблице суммированы на фиг. Это показывает, что предложенный алгоритм экономит расчет оценки скорости от 9,2 до 22,3 % и в среднем 14,5 %. Результаты также показывают, что предложенный оценщик вычислительно более эффективен, чем предыдущий алгоритм. В частности, улучшение производительности было выше, когда QP был небольшим. Причина этого заключается в том, что значение QP влияет на общее время кодирования, а меньший QP подразумевает более высокую остаточную энергию, и на блок оценки скорости CABAC будет возложена более высокая вычислительная нагрузка. В этих обстоятельствах наша схема имеет то преимущество, что устраняет все три этапа кодирования CABAC, в то время как метод Won et al. (2012) оставляет шаг бинаризации без изменений.

Открыть в отдельном окне

Среднее значение сокращения затрат времени на оценку R-D (в процентах) для последовательностей в таблице , a – d QP = 22, 27, 32 и 37

Эффективность сжатия

Мы сравнили производительность кодирования предложенного алгоритма с эталонным программным обеспечением с точки зрения дельта скорости Бьонтегора (BD-Rate), дельта Бьонтегора PSNR (BD-PSNR) (Bjøntegaard 2001). Результаты эксперимента были сведены в табл. Мы замечаем, что предложенная оценка немного увеличила BD-скорость. Для яркостной составляющей прирост составляет от 1,81 до 2,43 %, в среднем около 2,21 %. Приращение компонентов цветности (Cb и Cr) от 0,19до 2,29 % и 1,19 % в среднем. Тем не менее, снижение сложности и производительность за счет лучшего распараллеливания стоили увеличения скорости. Из результатов также видно, что потери BD-PSNR незначительны. Кроме того, мы оценили производительность оценщика скорости CABAC по ошибке оценки, используя критерий ниже наш оценщик, и R _r относится к программному обеспечению HM. Мы рассчитали среднее значение Δ R для всех CU и представили результат в таблице. Производительность кодирования предложенного алгоритма также сравнивалась с оценкой Won et al. (2012) в терминах Δ T , BD-Rate и BD-PSNR, и результаты представлены в таблице.

Таблица 5

Среднее значение Δ R , Δ T , прирост скорости BD и потеря BD-PSNR по сравнению с эталонным программным обеспечением HEVC

Класс	Послед. нет.	Δ R (%)	Δ T (%)	BD-Rate (%)			BD-PSNR (dB)
Класс	Послед. нет.	Δ R (%)	Δ T (%)	Y	Cb	Cr	Y	Cb	Cr
B	1	7.67	15.07	2.43	1.79	1.85	−0. 09	−0.03	−0.06
	2	5.11	15.98	2.28	1.63	0.70	−0.08	−0.03	−0.02
	3	6.62	16.17	2.36	2.29	2.15	−0.11	−0. 09	−0.07
E	4	4.14	12.09	2.18	0.81	1.01	−0.11	−0.03	−0.03
	5	5.88	12.81	1.81	0.89	1.15	−0.09	−0. 03	−0.05
	6	3.91	13.75	2.14	1.22	0.19	−0.12	−0.04	−0.01

Open in a separate window

Table 6

Coding performance (mean value of Δ T , BD-Rate и BD-PSNR) предлагаемого метода сравнивают с методом Won et al. (2012)

Класс	Послед. нет.	Δ T (%)	BD-Rate (%)			BD-PSNR (dB)
Класс	Послед. нет.	Δ T (%)	Y	Cb	Cr	Y	Cb	Cr
B	1	2,83	0,43	0,31	0,28	−0. 03	0.01	−0.02
	2	2.07	0.38	0.20	−0.08	−0.02	−0.00	0.01
	3	2.91	0.36	0.21	0.19	−0.02	−0.00	0. 01
E	4	1.03	0.28	−0.09	0.09	−0.01	−0.01	−0.01
	5	1.06	0.31	0.06	0.15	−0.02	0.01	−0.02
	6	1. 43	0.14	− 0,11	−0,07	−0,22	0,01	0,01

Open On Epplication Apply-Speciation Apply-Speciation Apply-Speciation Appalt Appalt Appalt Appalt Appalt Appalt Apply-Spatemport Apply-Spatmization. предложено в этой статье. Синтаксические элементы CU рассматриваются как источник, содержащий дискретный набор независимых сообщений. Исследуется неявная связь между энтропией источника и количеством закодированных битов (т. е. выход кодера CABAC) для CU. Используя корреляцию между этими двумя значениями, предлагаемый подход оценивает скорость CABAC как взвешенную сумму информации, генерируемой источником. Весовой вектор, который используется для компенсации эффекта шагов бинаризации и контекстного моделирования, рассматривается как состояние линейной динамической системы с дискретным временем. Веса адаптивно обновляются в процессе фактического кодирования CABAC, который активируется для кодирования всех SE в битовый поток после определения наилучшего режима текущей CU с использованием фильтрации Калмана.

Благодарности

Конкурирующие интересы

Авторы заявляют, что у них нет конкурирующих интересов.

Вэй-Ган Чен, электронная почта: nc.ude.usgjz.liam@usg_nehcgw.

Сюнь Ван, электронная почта: nc. ude.usgjz.liam@xw.

Bjøntegaard G (2001) Расчет средней разницы psnr между rd-кривыми. В: документ VCEG VCEG-M33, ITU-T SG16/Q6, Остин. ITU-T, стр. 1–5
Боссен Ф., Бросс Б., Зюринг К., Флинн Д. Сложность HEVC и анализ реализации. IEEE Trans Circuits Syst Video Technol. 2012; 22(12):1685–169.6. doi: 10.1109/TCSVT.2012.2221255. [CrossRef] [Google Scholar]
Bossen F (2012) Общие условия тестирования и эталонные конфигурации программного обеспечения. В: документ JCT-VC JCTVC-J1100, 10-е собрание, Стокгольм, 11–20 июля 2012 г. JCT-VC, стр. 1–3
Catlin DE. Оценка, управление и дискретный фильтр Калмана. Нью-Йорк: Спрингер; 1988. [Google Scholar]
Corrêa G, Assuncão P, Agostini L, Cruz LAS. Оценка производительности и вычислительной сложности высокоэффективных видеокодеров. IEEE Trans Circuits Syst Video Technol. 2012;22(12):1899–1909. doi: 10.1109/TCSVT.2012.2223411. [CrossRef] [Google Scholar]
Hahm J, Kyung C-M. Эффективная оценка скорости CABAC для выбора режима H. 264/AVC. IEEE Trans Circuits Syst Video Technol. 2010;20(2):310–316. doi: 10.1109/TCSVT.2009.2031378. [CrossRef] [Google Scholar]
Hahm J, Kim J, Kyung C-M (2009) Быстрая оценка скорости CABAC для выбора режима H.264/AVC. В: Материалы международной конференции IEEE по акустике, речи и обработке сигналов, Тайбэй, 19–24 апреля 2009 г.. IEEE Computer Society, стр. 929–932
HM Software. https://hevc.hhi.fraunhofer.de/svn/svn-HEVCSoftware
Джейн А.К. Основы цифровой обработки изображений. Энглвудские скалы: Прентис-холл; 1988. [Google Scholar]
Ким И. К., Мин Дж., Ли Т., Хан В. Дж., Пак Дж. Х. Блочная структура разделения в стандарте HEVC. IEEE Trans Circuits Syst Video Technol. 2012;22(12):1697–1706. doi: 10.1109/TCSVT.2012.2223011. [CrossRef] [Google Scholar]
Kim I-K, McCann K, Sugimoto K, Bross B, Han WJ, Sullivan G (2013) Высокоэффективное кодирование видео (hevc), тестовая модель 13 (hm 13), описание кодировщика. В: Документ JCT-VC JCTVC-O1002, 15-е собрание, Женева, 23 октября – ноябрь. 1 2013. JCT-VC, стр. 1–39.
Марпе Д., Шварц Х., Виганд Т. Адаптивное двоичное арифметическое кодирование на основе контекста в стандарте сжатия видео H.264/AVC. IEEE Trans Circuits Syst Video Technol. 2003;13(7):620–636. doi: 10.1109/TCSVT.2003.815173. [CrossRef] [Google Scholar]
Ohm J-R, Sullivan GJ, Schwarz H, Tan TK, Wiegand T. Сравнение эффективности кодирования стандартов кодирования видео, включая высокоэффективное кодирование видео (HEVC) IEEE Trans Circuits Syst Video Technol. 2012;22(12):1669–1684. дои: 10.1109/ТЦСВТ.2012.2221192. [CrossRef] [Google Scholar]
Pan Z, Kwong S, Sun M-T, Lei J. Раннее решение о режиме слияния на основе оценки движения и иерархической корреляции глубины для HEVC. Транстрансляция IEEE. 2014;60(2):405–412. doi: 10.1109/TBC.2014.2321682. [CrossRef] [Google Scholar]
Sole J, Joshi R, Nguyen N, Ji T, Karczewicz M, Clare G, Henry F, Dueñas A. Кодирование коэффициентов преобразования в HEVC. IEEE Trans Circuits Syst Video Technol. 2012;22(12):1765–1777. doi: 10.1109/TCSVT.2012.2223055. [Перекрестная ссылка] [Академия Google]
Салливан Г.Дж., Ом Дж.Р., Хан В.Дж., Виганд Т. Обзор стандарта высокоэффективного кодирования видео (HEVC). IEEE Trans Circuits Syst Video Technol. 2012;22(12):1649–1668. doi: 10.1109/TCSVT.2012.2221191. [CrossRef] [Google Scholar]
Салливан Г. Дж., Виганд Т. Оптимизация скорости искажения для сжатия видео. IEEE Signal Process Mag. 1998;15(6):74–90. дои: 10.1109/79.733497. [CrossRef] [Google Scholar]
Sze V, Budagavi M. Высокопроизводительное энтропийное кодирование CABAC в HEVC. IEEE Trans Circuits Syst Video Technol. 2012; 22(12):1778–179.1. doi: 10.1109/TCSVT.2012.2221526. [CrossRef] [Google Scholar]
Вон К., Ян Дж., Чон Б. Быстрая оценка скорости CABAC для выбора режима H.264/AVC. Элетрон Летт. 2012;48(19):1201–1202. doi: 10.1049/el.2012.1581. [CrossRef] [Google Scholar]
Xiong J, Li H, Wu Q, Meng F. Быстрый метод выбора hevc inter cu, основанный на дивергенции движения пирамиды. IEEE Транс Мультимед. 2014;16(2):559–564. doi: 10.1109/TMM.2013.22
. [CrossRef] [Google Scholar]

Статьи из SpringerPlus предоставлены здесь с разрешения Springer-Verlag

Заявка на патент США для КОНТЕКСТНО-ОСНОВАННОГО АДАПТИВНОГО ДВОИЧНОГО АРИФМЕТИЧЕСКОГО КОДИРОВАНИЯ (CABAC) СООТВЕТСТВИЯ ВИДЕОПОТОКУ Патентная заявка (заявка № 20110135143, выданная 9 июня 2011 г.) Предварительная патентная заявка № 61/189,372, поданная 19 августа 2008 г. и озаглавленная «CABAC STREAM COMPLIANCE». Предварительная заявка прямо включена в настоящий документ посредством ссылки во всей ее полноте для всех целей.

ОБЛАСТЬ ИЗОБРЕТЕНИЯ

Настоящее изобретение относится к внедрению водяных знаков в видеопотоки контекстно-ориентированного адаптивного двоичного арифметического кодирования (CABAC).

ПРЕДПОСЫЛКИ ИЗОБРЕТЕНИЯ

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

Способ предоставления CABAC-совместимых изменений, таких как водяные знаки, включает доступ к закодированным данным, таким как видеоданные, которые содержат по меньшей мере два блока; создание или доступ к списку изменений закодированных данных, которые включают прямое изменение блока; определение дифференциалов характера движения или векторов движения несмежных блоков, причем несмежные блоки являются смежными с непосредственным блоком, которые являются непосредственно смежными с блоком; определение изменения в непосредственном блоке на основе исходного характера движения блока и непрямого блока и характера движения блока, которое будет результатом применения изменения; сохранение изменения в списке, если изменение не приводит к изменению непосредственного блока; и оценивают другие потенциальные изменения, если другие потенциальные изменения доступны, при этом другие потенциальные изменения подвергаются тем же этапам процесса, что и прямое изменение. Блоки могут иметь любой размер или количество элементов коллекции или пикселей, непосредственные блоки могут быть блоками, которые имеют некоторую конечную границу с блоком, а непрямые блоки могут быть блоками, которые имеют некоторую конечную границу с непосредственными блоками, но не с блоком. блокировать. Способ может включать в себя декодирование закодированных данных и кодирование закодированных данных, которые могут включать в себя использование изменений, которые были сохранены в списке. Способ может включать определение контекста для закодированных данных по меньшей мере для одного из блоков и/или определение индекса контекста для закодированных данных, при этом индекс контекста (ctxIdx) представляет собой сумму начального значения (ctxIdxOffset) и приращения. (ctxIdxInc). Способ может дополнительно включать в себя вычисление или вычисление исходного приращения для непосредственного блока и нового приращения для непосредственного блока, связанного с непосредственным изменением блока; и использование исходного и нового приращений в качестве критерия для определения различия на этапе сохранения, при этом дифференциал вектора движения непрямого блока и первоначальный и новый дифференциалы вектора движения для блока могут использоваться в качестве критерия для определения разница в шаге хранения. Если исходное приращение для непосредственного блока и новое приращение для непосредственного блока отличаются для изменения, изменение может быть удалено из списка на этапе сохранения. Способ может дополнительно включать этап вычисления исходного приращения для другого непосредственного блока и нового приращения для другого непосредственного блока, связанного с прямым изменением блока, если исходное и непосредственное приращения не отличаются для непосредственного блока; и использование исходного и нового приращений для другого непосредственного блока в качестве дополнительного критерия для определения разницы на этапе сохранения. Дифференциал вектора движения для другого непрямого блока, который является смежным с другим непосредственным блоком, и первоначальный и новый дифференциалы вектора движения для блока могут использоваться в качестве дополнительного критерия для определения различия на этапе сохранения. Кроме того, изменение может быть добавлено в список на этапе сохранения, если исходное и новое приращения для другого непосредственного блока не отличаются.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

РИС. 1 представлена блок-схема CABAC-кодирования.

РИС. 2 представлена более подробная блок-схема кодирования CABAC.

РИС. 3 иллюстрирует дифференциалы векторов движения для блоков, затронутых изменением.

РИС. 4 иллюстрирует другой набор разностей векторов движения для блоков, затронутых изменением.

РИС. 5 иллюстрирует блок-схему первого решения для предотвращения ошибок при кодировании.

РИС. 6 иллюстрирует блок-схему второго решения и третьего решения для предотвращения ошибок при кодировании.

РИС. 7 иллюстрирует блок-схему четвертого решения для предотвращения ошибок при кодировании.

ОПИСАНИЕ ИЗОБРЕТЕНИЯ

Внедрение водяного знака здесь выполняется путем изменения байтов данных в закодированном видеопотоке, таком как кодированный видеопоток CABAC (адаптивное двоичное арифметическое кодирование на основе контекста). Важно отметить, что CABAC-кодирование в контексте видеокодеров H.264/AVC упоминается повсюду, чтобы подчеркнуть, что раскрытое изобретение будет в целом применимо к таким CABAC-кодированным видеопотокам. Однако объем изобретения обычно применим к другим потокам закодированных данных и другим типам кодеров.

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

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

Контекст изобретения применим к работе алгоритмов кодирования H.264/AVC CABAC, в которых для улучшения энтропийного кодирования используется система арифметического кодирования. CABAC обеспечивает хорошую производительность сжатия за счет (а) выбора вероятностных моделей для каждого элемента синтаксиса в соответствии с контекстом элемента; (b) адаптация оценок вероятностей на основе местной статистики; и (c) с использованием арифметического кодирования.

РИС. 1 показана общая блок-схема для кодирования одного синтаксического элемента 9.0576 100 в CABAC. Процесс кодирования состоит из трех элементарных шагов: 1) оценка бинаризации 101 ; 2) контекстное моделирование 102 ; и 3) двоичное арифметическое кодирование 103 .

Более подробный вид представлен на фиг. 2. Элемент синтаксиса предоставляется в блоке 200 , за которым следует оценка элемента синтаксиса в блоке принятия решения 201 , где недвоичный элемент переходит к этапу 204 . Компонент недвоичного элемента однозначно отображается на двоичную последовательность в так называемую строку бина в блоке 9.0576 204 . Отображенная последовательность и элемент синтаксиса, которые первоначально были двоичными значениями в блоке принятия решения 201 , перейдут к блоку принятия решения 205 . В блоке принятия решения , 205, каждый элемент строки бина или каждый элемент с двоичным значением будет обрабатываться в обычном режиме кодирования или в обходном режиме кодирования.

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

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

Последним этапом сжатия H.264/AVC может быть энтропийное кодирование, при этом по крайней мере одним из методов энтропийного кодирования, поддерживаемых этим стандартом, является CABAC. CABAC — это метод двоичного арифметического кодирования, в котором кодирование конкретного элемента синтаксиса AVC выполняется относительно конкретной вероятностной модели, которая определяется набором переменных, вместе называемых контекстом. Кодер CABAC поддерживает множество контекстов и выбирает один для кодирования каждого синтаксического элемента или даже для кодирования каждого бита в разных битовых позициях одного и того же синтаксического элемента. Во многих случаях процесс кодирования приводит к модификации переменных контекста. Каждый контекст поддерживает набор контекстных переменных. Процесс кодирования может изменить переменные внутри этого контекста.

Первым этапом декомпрессии H.264/AVC является энтропийное декодирование. Когда поток закодирован CABAC, декодирование является декодированием CABAC. Декодер CABAC поддерживает множество контекстов и использует разные контексты для декодирования различных элементов синтаксиса или даже битов в разных битовых позициях одного и того же элемента синтаксиса. Каждый контекст поддерживает набор контекстных переменных. Во многих случаях процесс декодирования приводит к модификации контекстных переменных соответствующего контекста. Различные контексты идентифицируются индексом контекста. Важно, чтобы данные были закодированы таким образом, чтобы декодер и кодировщик оставались синхронизированными. Декодер должен использовать соответствующий контекст для любого конкретного элемента (т. е. какой контекст использовался для кодирования этого элемента). Переменные этого контекста или состояние этого контекста должны быть предсказаны в кодировщике.

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

Теперь бинаризация дифференциала вектора движения (MVD) может состоять из префикса, а если MVD больше 9, из суффикса, при этом бинаризованная MVD может обозначаться или определяться как MVDBIN. Контекст CABAC, используемый для декодирования префикса MVDBIN блока с межкадровым предсказанием, определяется индексом контекста «ctxIdx», как указано в стандарте H.264/AVC. Этот индекс рассчитывается из суммы двух переменных, ctxIdxOffset и ctxIdxInc, начального значения индекса и приращения соответственно, как показано в следующем уравнении:

ctxIdx=ctxIdx Offset+ ctxIdxInc

Значение ctxIdxOffset указано в стандарте. В частности, ctxIdxOffset равен 40 для горизонтального компонента MVDBIN и 47 для вертикального компонента MVDBIN. ctxIdxInc отличается для разных битовых позиций префикса MVDBIN. Для битов, отличных от первого бита, ctxIdxInc определяется битовой позицией. В частности, ctxIdxInc равен 3, 4, 5, 6, 6, 6 в битовых позициях 1, 2, 3, 4, 5, 6 (или больше) соответственно. Для первого бита (позиция бита 0) префикса MVD кодер и декодер CABAC определяют значение приращения, ctxIdxInc, путем проверки абсолютных значений MVD (всего MVD) соседних блоков, в частности, соседнего блока. слева (А) и сосед сверху (В), как показано на фиг. 3, где текущий блок помечен как «Cur». Позиция бита определяет ctxIdxInc для битов, отличных от первого префикса MVDBIN. Блоки А и В на фиг. 3 можно назвать непосредственными блоками, поскольку они имеют общую границу с текущим блоком.

Для кодирования/декодирования первого бита префикса MVDBIN блока с внутренним предсказанием можно использовать три возможных контекста, как описано ниже. Первый контекст индексируется ctxIdxOffset, второй — ctxIdxOffset+1, а третий — ctxIdxOffset+2. Таким образом, переменная ctxIdxInc может принимать значения 0, 1 или 2, и эта переменная используется для выбора из трех доступных контекстов. Первый из этих контекстов используется для случаев, когда ожидается, что текущий MVD будет небольшим, второй используется, когда ожидается, что значение текущего MVD будет умеренным, а третий используется, когда ожидается, что текущий MVD будет большой. Ожидание основано на соседних значениях MVD следующим образом:

Если (absMvd_A+absMvd_B) меньше 3, ctxIdxInc устанавливается равным 0.

Если (absMvd_A+absMvd_B) находится в диапазоне от 3 до 32 включительно, ctxIdxInc устанавливается равным 1.

Если ( absMvd_A+absMvd_B) больше 32, ctxIdxInc устанавливается равным 2.

Короче говоря, (absMvd_A+absMvd_B) может попасть в три области: [0, 3), [3, 32] и (32, +∞ ). (Обозначения являются обозначениями теории порядка: правый открытый интервал, закрытый интервал и открытый интервал, соответственно.)

Один или несколько вариантов осуществления в приложенной заявке могут привести к модификации MVD некоторых блоков, при этом следует соблюдать осторожность, чтобы не вызвать контекстные состояния для изменения. Однако, если MVD блока A или блока B изменяются или изменяются оба из-за модификаций в таком варианте осуществления, новое значение (absMvd_A+absMvd_B) может попасть в область, отличную от исходной. В этом случае ctxIdxInc будет изменен, и для декодирования префикса MVDBIN текущего блока будет использоваться неправильный контекст. Таким образом, декодер CABAC будет вести себя по-разному при декодировании MVD блока Cur, что может привести к ошибкам декодирования. Можно сделать первое решение для этих ошибок декодирования, относящихся к потенциальным модификациям, которое не вызывает никаких изменений в состояниях контекста и проиллюстрировано на фиг. 5. Каждая из этих потенциальных модификаций может быть оценена по ряду критериев, включая ее способность представлять данные, ее влияние на точность декодированных изображений, устойчивость результирующих изменений пикселей и т. д. Из списка выявленных потенциальных модификаций, только те, которые соответствуют конкретным критериям, зависящим от приложения, обычно выбираются для использования в процессе нанесения водяных знаков, а остальные обычно отбрасываются.

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

Для потенциальной модификации в блоке A, которая повлияет на MVD блока A, могут быть затронуты MVD двух его соседних блоков, R (правый) и D (нижний), как показано на фиг. 4. Здесь блоки R и D являются непосредственными блоками, а M и N не являются непосредственными блоками, потому что они не имеют общей границы с текущим блоком A, но имеют общую границу с непосредственными блоками.

Чтобы проверить, вызовет ли модификация ошибку декодирования, это решение проверяет, вызовет ли эта модификация MVD в блоке A изменение ctxIdxInc префикса MVD в блоке R или префикса в блоке D. Это приводит алгоритму, описанному на фиг. 5. Здесь, на этапе 505 , определяются альтернативные MVD в блоке A. Для потенциальной модификации, которая влияет на MVD блока A, ctxIdxInc в блоках R и D проверяются или определяются. В каждом из этих двух случаев вычисляется старый ctxIdxInc, который использовался бы, если бы изменение в блоке A не было сделано. Кроме того, новый ctxIdxInc, который был бы использован, если бы изменение в блоке A было сделано на шаге 9.0576 515 для R-блока и на этапе 525 для D-блока вычисляется, при этом эти примерные блоки, смежные с текущим A-блоком, показаны на фиг. 5. В любом случае, для блока R в блоке принятия решения 520 и для блока D в блоке принятия решения 535 , по крайней мере в одном варианте осуществления, если старый ctxIdxInc и новый ctxIdxInc отличаются, то возможная модификация отбрасывается. на шаге 545 , потому что это потенциально может вызвать ошибку декодирования, описанную выше. Если старый и новый ctxIdxInc совпадают, то альтернативный MVD в блоке A сохраняется на шаге 9.0576 540 .

Обратите внимание, что ctxIdxInc для блока R зависит не только от MVD блока A, но и от MVD блока M, который непосредственно примыкает к блоку R. ctxIdxInc для блока R определяется диапазоном, в котором (absMvd_A+absMvd_M) падает. Точно так же ctxIdxInc блока D зависит как от MVD блока A, так и от MVD блока N, соседнего блока с D, поскольку он определяется диапазоном, в который попадает (absMvd_A+absMvd_N).

Алгоритм на фиг. 5 можно считать «блоком А». Здесь рассматривается потенциальное изменение в блоке А и оценивается воздействие ниже по течению.

Существует случай, когда алгоритм, описанный выше и показанный на фиг. 5, может не обнаруживать или идентифицировать все ошибки декодирования. Ссылаясь на фиг. 3, процесс оценки по фиг. 5 не обязательно будет полностью учитывать случай, когда ДВД как блока А, так и блока В изменены. Для рассмотрения этого случая предлагается другое решение.

Второе решение и третье решение показаны на фиг. 6, на котором показаны расширенные версии показанного на фиг. 5. Второе и третье решения отличаются тем, что во втором решении используется шаг 640 вариант , а в третьем решении используется вариант step 640 b .

Что касается второго решения, по существу, для каждого альтернативного MVD в блоке A влияние на ctxIdxInc блоков D и R на фиг. 4 считаются или обрабатываются. Отличие этого решения состоит в том, что в случаях, когда сами МВД блоков М и N рассматриваются альтернативные значения. Здесь желательно сохранить альтернативные MVD блока A, которые не изменят ctxIdxInc блоков D или R, независимо от того, какие альтернативы могут быть выбраны для блоков M или N.

РИС. 6 показан один алгоритм для этого. Для каждого альтернативного MVD для блока A сначала рассматриваются или обрабатываются все возможные MVD для блока M. Каждая комбинация может быть оценена, чтобы определить, изменит ли какая-либо комбинация ctxIdxInc блока R. Если какая-либо комбинация изменяет ctxIdxInc блока R, этот альтернативный MVD для блока A может быть отброшен. Если ни одна из комбинаций (для данной альтернативной МВД блока А) не изменяет ctxIdxInc блока R, то можно рассмотреть все возможные МВД блока N. Каждая комбинация может быть оценена, чтобы определить, изменит ли какая-либо комбинация ctxIdxInc блока D. Если какая-либо комбинация изменяет ctxIdxInc блока D, этот альтернативный MVD для блока A отбрасывается. Если ни одна из комбинаций не изменяет ctxIdxInc блока D, этот альтернативный MVD для блока A сохраняется.

В частности, на фиг. 6 начинается с вычисления исходного ctxIdxInc блоков R и D на основе исходных пар MVD блоков A и M и блоков A и N на этапе 605 . На этапе 610 проверяется каждый альтернативный MVD в блоке A, после чего на этапе 615 проверяется каждый MVD в блоке M. На этапе 620 выполняется вычисление с модифицированным ctxdxInc для R на основе альтернативного MVD для M и альтернативного MVD для M и альтернативного MVD для A. За этим следует этап принятия решения 9.0576 625 , где, если измененный ctxIdxInc блока R равен исходному ctxIdxInc, то на этапе 630 проверяются дополнительные альтернативные MVD блока M, и если измененный ctxIdxInc блока R не равен исходному ctxIdxInc, то альтернативный MVD в блоке A отбрасывается на этапе 640 a . После этапа отбрасывания 640 a следует еще один этап принятия решения 645 , на котором рассматриваются дополнительные альтернативные MVD блока A. Если других альтернативных МВД блока А нет, то второе решение завершено, что представлено шагом 9.0576 680 . С другой стороны, если имеются дополнительные альтернативные MVD блока A, решение переходит к этапу 650 , на котором осуществляется доступ к следующему альтернативному MVD в блоке A, после чего следует цикл до этапа 610 и к шагам, следующим за шагом 610 , как указано выше.

С дополнительной ссылкой на фиг. 6, когда модифицированный ctxIdxInc блока R равен исходному ctxIdxInc на шаге 625 и на шаге 9 принятия решения имеются дополнительные альтернативные MVD блока M.0576 630 , затем процесс переходит к оценке следующей доступной альтернативы MVD в блоке M на этапе 635 , после чего выполняется возврат к этапу 615 и к этапам, следующим за этапом 615 , как указано выше.

Дополнительно со ссылкой на фиг. 6, когда модифицированный ctxIdxInc блока R равен исходному ctxIdxInc на этапе 625 и отсутствуют дополнительные альтернативные MVD блока M на этапе принятия решения 630 , тогда процесс переходит к доступу к каждому альтернативному MVD в блоке N на этапе 9.0576 655 , а затем к расчету модифицированного ctxdxInc для D на основе альтернативного MVD для N и альтернативного MVD для A на шаге 660 . После этапа 660 , если измененный ctxIdxInc блока D равен исходному ctxIdxInc, то на этапе 665 принятия решения процесс переходит к этапу принятия решения 670 , в котором осуществляется доступ к дополнительному блоку N альтернативных MVD. Если есть дополнительный блок N альтернативных MVD, выполняется переход к блоку 675 , в котором осуществляется доступ к следующему MVD в блоке N с последующим циклическим возвратом к шагу 9. 0576 655 и к шагам, которые следовали за шагом 655 , как указано выше. Если модифицированный ctxIdxInc блока D не равен исходному ctxIdxInc, то в блоке принятия решения 665 процесс переходит к этапу 640 a и продвигается в соответствии с этапами, упомянутыми выше по отношению к этапу 640 a.

Если на шаге принятия решения 670 нет дополнительного блока N альтернативных MVD, решение переходит к шагу 685 , в котором сохраняются альтернативные MVD или MVD в блоке A с последующим переходом к этапу принятия решения 645 , в котором осуществляется доступ к дополнительному блоку A альтернативных MVD. Если альтернативных МВД блока А больше нет, то второе решение завершено, что представлено этапом 680 . С другой стороны, если есть дополнительные альтернативные MVD блока A, решение переходит к этапу 650 , на котором осуществляется доступ к следующей альтернативной MVD в блоке A, после чего следует цикл до шага 9. 0576 610 и к шагам, которые следовали за шагом 610 , как указано выше.

Это решение отбрасывает любой альтернативный MVD для блока A, который имеет комбинацию с любым из альтернативных MVD для блоков M или N, так что комбинация вызывает изменение ctxIdxInc блоков D или R.

В некоторых случаях удаление альтернативного MVD для блока A может оказаться нежелательным или его следует избегать. Таким образом, третье решение проиллюстрировано на фиг. 6, в котором шаг 640 вариант b используется вместо шага 640 вариант . Третье решение удаляет другой альтернативный MVD, такой как тот, который связан с блоком M или N, а не альтернативу для блока A. Эта модификация второго решения делает его таким, что потенциально вредные комбинации записываются в список отбрасывания. Список отбрасывания может быть позже обработан, чтобы решить, какие альтернативы следует удалить.

Существует множество способов обработки списка сброса. Вот некоторые из них:

- 1. Один из подходов заключается в рассмотрении любой комбинации в списке исключений, для которой один из альтернативных MVD является исходным MVD. Эта комбинация удаляется из списка путем удаления другого альтернативного MVD комбинации.
- 2. Другой подход заключается в том, чтобы минимизировать количество удаленных альтернативных MVD, сначала построив гистограмму, и для каждого альтернативного MVD в списке исключенных подсчитайте, сколько раз он появляется. Затем следует удаление наиболее часто встречающегося альтернативного MVD, тем самым удаляя из списка отбрасывания любые комбинации, содержащие этот альтернативный MVD. Кроме того, альтернативные MVD можно постоянно удалять до тех пор, пока список исключений не станет пустым, от наиболее часто появляющихся до наименее часто появляющихся,
- 3. В третьем подходе можно построить гистограмму для каждого альтернативного MVD в списке отбрасывания и подсчитать количество его появления. Затем модель достоверности и/или модель устойчивости могут назначить стоимость каждому альтернативному MVD. Эту стоимость можно использовать вместе с гистограммой частоты появления в качестве основы для удаления альтернативных MVD до тех пор, пока список исключений не станет пустым.

В отличие от первых трех решений, четвертое решение может считаться «ориентированным на блок C» или «ориентированным на блок Cur», поскольку оценивается потенциальное изменение в блоке Cur, а блок A или блок B проверяются для определения если в блоке A или B есть изменения, которые могут повлиять на ctxIdxInc блока Cur. Это четвертое решение проиллюстрировано на фиг. 7. По меньшей мере в одной реализации процесс по фиг. 7 выполняется для каждого среза, который имеет альтернативные MVD в последовательности изображений.

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

Затем, на этапе 710 , для данного блока с межкадровым предсказанием рассматриваются все возможные MVD. Все интерпрогнозированные блоки будут иметь как минимум один MVD; однако для некоторых были выявлены потенциальные изменения. Каждое потенциальное изменение приведет к другому MVD для текущего блока, блока C, где MVD упоминается как MVDc. Для текущего блока, блока С, есть два представляющих интерес соседа: блок А слева и блок В выше, как показано на фиг. 3. В каждом из этих блоков будет МВД; однако для некоторых соседей были выявлены потенциальные изменения. Каждое потенциальное изменение приведет к другому MVD для этого соседнего блока, блока A или блока B. Для MVDc в блоке C рассматриваются или собираются все возможные комбинации или альтернативные значения MVDa и MVDb на шаге 9. 0576 715 и альтернативные МВД блоков А и В соответственно, включая исходные МВД этих блоков. На этапе 720 все возможные комбинации альтернатив накапливаются и направляются на этап 725 . Здесь на этапе 725 для каждой комбинации вычисляется ctxIdxInc для блока C. На этапе принятия решения 730 , если какая-либо комбинация вызывает изменение ctxIdxInc по сравнению со значением, сгенерированным с использованием исходных MVD блоков A и B, один из альтернативный МВДа или альтернативный МВДб исключается из списка на шаге 735 и следующая возможная комбинация начинает рассматриваться на шаге 720 . Если новый ctxIdxInc не отличается от исходного для блока C, то изменение удаляется из списка на шаге 720 . Можно использовать подходы, аналогичные предложенным для обработки списка отбраковки в Решении 3.

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

Некоторые реализации и функции, описанные в этой заявке, можно использовать в контексте стандарта H.264/MPEG-4 AVC (AVC). Однако эти реализации и функции можно использовать в контексте другого стандарта (существующего или будущего) или в контексте, не связанном со стандартом. Таким образом, в настоящем документе предусмотрена одна или более реализаций, имеющих определенные признаки и аспекты. Однако признаки и аспекты описанных реализаций также могут быть адаптированы для других реализаций.

Реализации, описанные в данном документе, могут быть реализованы, например, в способе или процессе, устройстве, программе программного обеспечения, потоке данных или сигнале. Даже если они обсуждаются только в контексте одной формы реализации, такой как упомянутые только как способ, обсуждаемая реализация или признаки также могут быть реализованы в других формах, таких как устройство или программа. Устройство может быть реализовано, например, в соответствующих аппаратных средствах, программном обеспечении и программно-аппаратных средствах. Способы могут быть реализованы, например, в устройстве, таком как, например, компьютер или другое устройство обработки. Кроме того, способы могут быть реализованы с помощью инструкций, выполняемых устройством обработки или другим устройством, и такие инструкции могут быть сохранены на машиночитаемом носителе, таком как компакт-диск, или другом машиночитаемом запоминающем устройстве, или интегральной схеме. Кроме того, машиночитаемый носитель может хранить значения данных, созданные реализацией.

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

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

x264 Руководство по параметрам FFmpeg — кодировка Linux

Обратите внимание: Это руководство останется здесь для исторических целей, но FFmpeg и libav теперь используют внутренние параметры libx264 -preset, -profile и -tune. См. `avconv -h | меньше` или ` ffmpeg -h | less` и прокрутите вниз до « libx264 AVOptions: ».

Это руководство сопоставляет большинство опций x264 с опциями FFmpeg вместе с подробным описанием разработчика x264 Dark_Shikari.

Варианты рамы:

(x264)
-g (FFmpeg)
Интервал ключевого кадра, также известный как длина GOP. Это определяет максимальное расстояние между I-кадрами. Очень большие длины GOP приведут к более эффективному сжатию, но несколько усложнят поиск в видео. Рекомендуемое значение по умолчанию: 250

-keyint_min <целое число>

(x264)
-sc_threshold (FFmpeg)
Настраивает чувствительность обнаружения кадров x264. Редко нуждается в корректировке. Рекомендуемое значение по умолчанию: 40

нет

(x264)
-bf (FFmpeg)
B-кадры являются основным элементом H.264 и более эффективны в H.264, чем любой предыдущий стандарт. Некоторые конкретные цели, такие как HD-DVD и Blu-Ray, имеют ограничения на количество последовательных B-кадров. Однако большинство из них этого не делает; в результате установка этого параметра на максимум (16) редко имеет какой-либо отрицательный эффект, поскольку x264, если используется B-adapt, в любом случае автоматически выберет наилучшее количество B-кадров. Этот параметр просто служит для ограничения максимального количества B-кадров. Обратите внимание, что базовый профиль, например, используемый iPod, не поддерживает B-кадры. Рекомендуемое значение по умолчанию: 16

(x264)
-b_strategy (FFmpeg)
x264, по умолчанию, адаптивно определяет наилучшее количество B-кадров с помощью предпросмотра с низким разрешением.

Эту адаптивность можно отключить; это не рекомендуется. Рекомендуемое значение по умолчанию: 1

0: Очень быстро, но не рекомендуется. Не работает с pre-scenecut (scenecut должен быть выключен, чтобы принудительно отключить b-adapt).

1: Быстрый, режим по умолчанию в x264. Хороший баланс между скоростью и качеством.

2: гораздо более медленный, но более точный режим принятия решения B-кадра, который правильно определяет фейды и обычно дает значительно лучшее качество. Его скорость становится значительно медленнее при высоких значениях bframes, поэтому при использовании этой опции рекомендуется поддерживать относительно низкие bframes (возможно, около 3). Это также может замедлить первый проход x264 в многопоточном режиме.

-bframebias 0

-flags2 +bpyramid

-coder 0

(x264)
-refs (FFmpeg)
Одной из наиболее полезных функций H.264 является возможность ссылаться на кадры, отличные от кадров, непосредственно предшествующих текущему кадру. Этот параметр позволяет указать, сколько ссылок может быть использовано, максимум до 16. Увеличение количества ссылок увеличивает требование DPB (декодированного буфера изображения), что означает, что аппаратные устройства воспроизведения часто будут иметь строгие ограничения на количество ссылок, которые они могут использовать. справиться. В источниках с живыми актерами большее количество ссылок имеет ограниченное использование за пределами 4-8, но в источниках мультфильмов часто полезно максимальное значение до 16. Большее количество эталонных кадров требует большей вычислительной мощности, поскольку поиск движения выполняется в каждом кадре (за исключением случаев, когда принимается решение о раннем пропуске).

Замедление особенно заметно при более медленных методах оценки движения. Рекомендуемое значение по умолчанию: -refs 6

-flags -loop

(x264)
-deblockalpha (FFmpeg)
-deblockbeta (FFmpeg)
проблема блокировки артефактов, нарушающих оценку движения. Это требует небольшого количества процессора для декодирования, но значительно повышает качество почти во всех случаях. Его сила может быть увеличена или уменьшена, чтобы избежать большего количества артефактов или сохранить больше деталей, соответственно. Деблокировка имеет два параметра: альфа (сила) и бета (порог). Рекомендуемые значения по умолчанию: -deblockalpha 0 -deblockbeta 0 (Должен иметь ‘-flags + loop’)

нет

Контроль скорости:

-cqp <целое число>

(x264)
-b (FFmpeg)
Включает режим целевого битрейта. Попытки достичь определенного битрейта. По возможности следует использовать в двухпроходном режиме; 1-проходный режим битрейта, как правило, является худшим режимом управления скоростью, который есть у x264.

(x264)
-crf (FFmpeg)
Режим постоянного качества (также известный как постоянный коэффициент скорости). Битрейт примерно соответствует постоянному квантователю, но дает лучшее качество в целом при небольших затратах скорости.

Лучший однопроходный вариант в x264.

(x264)
-maxrate (FFmpeg)
Указывает максимальный битрейт в любой точке видео. Требуется установить размер буфера VBV. Этот параметр обычно используется при кодировании для аппаратного обеспечения с ограничениями по битрейту.

(x264)
-bufsize (FFmpeg)
Зависит от уровня профиля кодируемого видео. Установите, только если вы кодируете для аппаратного устройства.

(x264)
-rc_init_occupancy (FFmpeg)
Начальное заполнение буфера VBV. Примечание: не связывайтесь с этим.

-qmin <целое число>

-qmax <целое число>

-qdiff <целое число>

(x264)
-bt (FFmpeg)
Допустимое отклонение среднего битрейта

(x264)
-i_qfactor (FFmpeg)
Разница Qscale между I-кадрами и P-кадрами. Примечание: -i_qfactor обрабатывается немного иначе, чем —ipratio. Рекомендуется: -i_qfactor 0,71

(x264)
-b_qfactor (FFmpeg)
Разница Qscale между P- и B-кадрами.

(x264)
-chromaoffset (FFmpeg)
Разница QP между цветностью и яркостью.

(x264)
нет (FFmpeg)
Регулирует силу адаптивного квантования.

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

-pass <1,2,3>

нет

(x264)
-qcomp (FFmpeg)
Сжатие кривой QP: 0.0 => CBR, 1.0 => CQP. Рекомендуемое значение по умолчанию: -qcomp 0,60.

(x264)
-complexityblur (FFmpeg)
Уменьшить колебания QP (до сжатия кривой) [20.

(x264)
-qblur (FFmpeg)
Уменьшить колебания QP (после сжатия кривой) [0,5]

/ (x264)
нет (FFmpeg)
Позволяет установить определенный квантователь для определенной области видео.

нет

Анализ:

-partitions

p8x8 (x264) / +partp8x8 (FFmpeg)

p4x4 (x264) / +partp4x4 (FFmpeg)

b8x8 (x264) / +partb8x8 (FFmpeg)

i8x8 (x264) / +parti8x8 (FFmpeg)

i4x4 (x264) / +parti4x4 (FFmpeg)

(x264)
-directpred (FFmpeg)
B-кадры в H.264 могут выбирать между режимами пространственного и временного прогнозирования. Auto позволяет x264 выбрать лучшее из них; используемая эвристика зависит от того, какой режим позволяет пропускать больше макроблоков.

Обычно следует использовать Auto.

-flags2 +wpred

(x264)
-me_method (FFmpeg)

dia (x264) / epzs (FFmpeg) — самый простой поиск, состоящий из начать с лучшего предиктора, проверить векторы движения на один пиксель вверх, влево, вниз и вправо, выбрать лучший и повторять процесс до тех пор, пока он больше не найдет лучшего вектора движения.

hex (x264) / hex (FFmpeg) состоит из аналогичной стратегии, за исключением того, что он использует поиск в диапазоне 2 по 6 окружающим точкам, отсюда и название. Он значительно более эффективен, чем DIA, и почти не медленнее, и поэтому является хорошим выбором для кодирования общего назначения.

umh (x264) / umh (FFmpeg) значительно медленнее, чем HEX, но ищет сложный шаблон с несколькими шестиугольниками, чтобы не пропустить трудно найти векторы движения. В отличие от HEX и DIA, параметр merange напрямую управляет радиусом поиска UMH, позволяя увеличивать или уменьшать размер широкого поиска.

esa (x264) / full (FFmpeg) — высокооптимизированный интеллектуальный поиск по всему пространству поиска движения в пределах некоторого диапазона лучшего предиктора. Это математически эквивалентно методу грубой силы поиска каждого вектора движения в этой области, хотя и быстрее. Тем не менее, он все еще значительно медленнее, чем UMH, с не слишком большим преимуществом, поэтому он не особенно полезен для повседневного кодирования.

Одна из самых важных настроек для x264, как по скорости, так и по качеству.

-me_range <целое число>

нет

-subq 6

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

2-5: Постепенно лучше и медленнее, 5 служит хорошей средой для более высокоскоростного кодирования.

6-7: 6 — значение по умолчанию. Активирует оптимизацию скорости искажения для решения о разделе. Это может значительно повысить эффективность, хотя и требует заметной скорости. 6 активирует его в кадрах I/P, а subme7 активирует его в кадрах B.

8-9: активирует уточнение скорости-искажения, которое использует RDO для уточнения как векторов движения, так и режимов внутреннего предсказания. Медленнее, чем subme 6, но опять же эффективнее.

: (x264)
нет (FFmpeg)
Первое значение представляет величину смещения x264 в пользу сохранения деталей вместо максимального PSNR при выборе режима. Требуется subme >= 6. Второе значение — psy-trellis, экспериментальный алгоритм, который пытается улучшить резкость и сохранение деталей за счет большего количества артефактов. Рекомендуемые начальные значения 0,1-0,2. Требуется решетка >= 1. Рекомендуемое значение по умолчанию: 1,0:0,0.

-flags2 +mixed_refs

none

-flags2 +dct8x8

-trellis <0,1,2>

0: отключено

1: включено только при окончательном кодировании MB

2: включено для всех решений режима

-flags2 -fastpskip

нет

h364 CABAC (Мейнард Хэндли; Терье Матисен)

h364 CABAC (Мейнард Хэндли; Терье Матисен) Индекс Дом О Блог

От: Мейнард Хэндли 
Группы новостей: comp.arch
Тема: Re: Причины большой смены парадигмы
Идентификатор сообщения: 
Дата: вторник, 21 ноября 2006 г., 06:47:44 по Гринвичу
В статье ,
 Терье Матисен  написал:
> ЖЖ писал:
> > Опять эта проклятая Стена Памяти, новые процессоры, кажется, становятся быстрее только для
> > проблемы, которые имеют высокую локальность ссылки, скажем, видеокодеки
>
> Видеокодеки???
>
> Вы смотрели на h364 (HD-DVD/Blueray) с кодировкой CABAC?
>
> 1) Векторы движения могут идти практически куда угодно, к любому ранее декодированному
> image: Это означает огромные буферы памяти! (Недавнее объявление NVidia сказало
> что вам нужен двухъядерный процессор и 1 ГБ оперативной памяти только для декодирования HD-DVD, даже
> с предположительно настолько мощной аппаратной помощью, насколько они могли получить от графического процессора. )
>
> 2) Фактическое побитовое декодирование ужасно, с крайней зависимостью
> цепочки, разветвление которых по замыслу почти невозможно предсказать
> (иначе надо было лучше сжимать, верно?).
 Оба верны --- хотя правда в том, что, как и следовало ожидать, некоторые
пространственная локальность в предсказании, хотя теоретически это может быть
где-нибудь в любом из дюжины или около того более ранних кадров. Проблема, из
Конечно, вы предусмотрели наихудший возможный случай или
вы готовитесь к ожидаемому случаю и просто смиритесь с тем, что пропускаете
кадры и все остальное, что необходимо, чтобы попытаться не отставать, когда дела пойдут
Плохо?
Что особенно трагично, так это то, что арифметическое кодирование не должно было
быть таким отсталым. Арифметическое кодирование в JPEG2000 (относительно) очень
Дружественный к процессору. Но ребята из h364 внесли небольшие изменения, которые имеют серьезные последствия.
влияет на то, как это может быть реализовано. Стандартная трагедия отказа
верить, что кто-то другой мог бы сделать что-то лучше, чем вы
может и так надо хотя бы посмотреть на их идеи. 
> Дело в том, что этот _очень_ важный видеокодек
> Создан специально для того, чтобы его было чрезвычайно сложно обрабатывать на современном процессоре. :-(
>
> Терье

Дата: Вс, 19 ноября 2006 г. 21:29:16 +0100
От кого: Терье Матисен 
Группы новостей: comp.arch
Тема: Декодирование HD-DVD (было: Re: Причины большой смены парадигмы)
Идентификатор сообщения: 
Бернд Пайсан писал:
> Терье Матисен писал:
>
>> ЖЖ писал:
>>> Опять эта проклятая Стена Памяти, новые процессоры, кажется, становятся быстрее только для
>>> Проблемы, которые имеют высокую локальность ссылок, скажем, видеокодеки
>> Видеокодеки???
>>
>> Вы смотрели на h364 (HD-DVD/Blueray) с кодировкой CABAC?
>>
>> 1) Векторы движения могут идти практически куда угодно, к любому ранее декодированному
>> изображение: Это означает огромные буферы памяти! (Недавнее объявление NVidia сказало
>> что вам нужен двухъядерный процессор и 1 ГБ оперативной памяти только для декодирования HD-DVD, даже
>> с предположительно такой мощной аппаратной помощью, которую они могли бы получить от графического процессора. )
>
> Сильно сомневаюсь, что кто-то будет делать HD-DVD или BR диск с этими
> требования. Ведь у автономных плееров не будет и гигабайта памяти
> (более 256 МБ, как у PS3).
Игроку HW никогда не придется прибегать к многоядерному декодированию, где
каждое ядро процессора начинается с отдельного ключевого кадра. Делать это
очевидный/простой способ обработки видео в худшем случае в SW, но это
немедленно удваивает размер буфера кадра.
В MPEG-2 любой данный кадр никогда не может ссылаться более чем на два эталона.
кадры, и они были четко обозначены в видеопотоке, так что
декодер знал, что он должен их буферизовать. h364 может относиться к более или менее
что-либо ранее декодированное, включая подблоки, ранее декодированные в
сам текущий кадр. т.е. нет (простого) способа запустить два ядра на двух
половины кадра, за исключением Blueray, который разбивает каждое изображение на
отдельно закодированные подкадры.
> Я могу расшифровать 19Трейлеры 20x1080 h364 почти в реальном времени с самыми последними
> MPlayer на моем Athlon64 с тактовой частотой 2 ГГц (чип 754, видеокарта AGP) и, насколько мне известно,
> передача по AGP занимает значительное время. 
Как заметил Чжи-Чунг, реальная проблема — потоки с высоким битрейтом,
особенно если у вас также относительно низкое разрешение: это означает
_lot_ многобитных токенов, использующих однобитовое декодирование, с квадратичным законом или
хуже прибавка в работе по декодированию. Я видел график, показывающий CABAC
только декодирование составляет 60-80% всей работы. :-(
Для видеопотоков, где векторы движения могут обрабатывать почти все
кодирования, требуется (или доступно!) очень мало остаточных битов для
исправить ошибочные пиксели, но чем выше битрейт, тем
спускается довольно быстро.
>> 2) Фактическое побитовое декодирование ужасно, с крайней зависимостью
>> цепочки, разветвление которых по замыслу почти невозможно предсказать
>> (иначе вы должны были сжать лучше, верно?).
>
> Да, но я не уверен, действительно ли вам нужно ветвление для его декодирования. Штат
> таблицу стоит попробовать, зависимые загрузки выполняются значительно быстрее, чем
> зависимые ветви.
Это действительно возможно, но довольно сложно сделать в 32-битном режиме: Зарегистрируйтесь
давление становится ужасным. 
>> Дело в том, что этот _очень_ важный видеокодек
>> Сделано так, чтобы с ним было чрезвычайно сложно работать на современном процессоре. :-(
>
> Судя по всему.
Да, это своего рода противоположность AES, у которого были эффективные реализации программного обеспечения.
как требование.
Терье
--
- 
"почти всё программирование можно рассматривать как упражнение в кэшировании"

Дата: Вт, 21 ноября 2006 г. 13:57:05 +0100
От кого: Терье Матисен 
Группы новостей: comp.arch
Тема: Re: Причины большой смены парадигмы
Идентификатор сообщения: <[email protected]>
Бернд Пайсан писал:
> Чжи-Чунг Чанг писал:
>> (Я зарабатываю на жизнь программными x86-проигрывателями HD-DVD/Blu-Ray/H.264)
>>
>> Я думаю, вы обнаружите, что требования довольно распространены среди программного обеспечения для ПК.
>> игроки. Причина в том, что для пользователей, которые сейчас могут позволить себе HD/BD-диски, 1 ГБ
>> ОЗУ не слишком дорого (и ОЗУ можно использовать для других приложений). 
>
> Ну это конечно правда ;-). Но если предположить, что изготовление PS3 BD
> диск стоит около 80 долларов, разве вы не ожидаете, что в ближайшем будущем диски BD для ПК подешевеют?
> Будущее (когда будет решена проблема доступности голубого лазера)?
>
>> Автономные проигрыватели нуждаются в большей оптимизации для памяти, потому что это напрямую
>> влияет на их составную стоимость.
>>
>> Другая причина заключается в том, что программные декодеры не имеют гарантированного времени декодирования.
>> для каждого кадра, поэтому для сглаживания джиттера используются большие буферы.
>
> Получите операционную систему реального времени ;-). Честно: интересно, почему майор
> разработчики операционных систем (будь то Билл Гейтс и его орда или Линус
> Торвальдс) немного не разбираются в реальном времени, хотя их
> в качестве медиаплеера используются операционные системы, что довольно сложно
> Требования реального времени.
Я согласен. Были хорошие новости о получении вещей от
RT-Linux в основном деле ядра. 
>>> Я могу расшифровать 19Трейлеры 20x1080 h364 почти в реальном времени с самыми последними
>>> MPlayer на моем Athlon64 2 ГГц (чип 754, видеокарта AGP) и, насколько мне известно,
>>> передача по AGP занимает значительное время.
>> 1920х1080 без проблем. Проблема в высоком битрейте. Попробуйте что-нибудь
>> со скоростью 20 Мбит/с или более (максимальная скорость для Blu-Ray — 40 Мбит/с).
BR разбивает каждый кадр на (на самом деле) 4 части, что означает, что это легко
иметь до четырех ядер, работающих параллельно, HD-DVD @ 30 Мбит
вероятно, самый худший случай, когда у вас есть несколько ядер.
> Трейлеры доступны, например, на Сайт Apple обычно не превышает
> 10 Мбит/с.
>
>> Да, это можно сделать без ветки. ffmpeg имеет ветку
>> версия CABAC, использующая cmov. Это быстрее на большинстве x86, но все же
>> занимает много времени.
>
> Я думаю о чем-то другом, чем об использовании cmovs, больше в линии
> быстрый декодер Хаффмана. Если у вас есть статическое дерево для декодирования, вы можете создать
> таблица, которая индексируется по состоянию, следующим x битам входного потока и
> там вы найдете следующее состояние и битовую строку для вставки в вывод
> поток.  Нет (условного) ветвления, нет ограничений на декодирование нескольких токенов в
> один раз. Ограничивающим по времени фактором является зависимая нагрузка, поскольку следующая
> адрес зависит от состояния, загруженного при предыдущем переходе. Вы можете захотеть
> помещается таблица в кэш L1.
Вот тут ты ошибаешься :-(
CA в декодере CABAC расшифровывается как Context-Adaptive, что в данном случае
регистр означает, что пока вы полностью не декодируете бит и, возможно,
(обычно!) берется ветка, которая зависит от ее значения, попадете ли вы в
выяснить, какой контекст использовать для следующего шага однобитового декодирования.
Ой!
Есть места, спец. при работе с большими многобитными значениями,
где индекс контекста (который указывает на 7-битное значение) остается постоянным для
какое-то время, но даже в этом случае минимальное состояние, которое вы должны носить с собой, состоит
из 9+9=18 бит, что составляет довольно большую таблицу поиска.
При обходе логики обновления CABAC, что делается для
длинные токены, вам также нужен дополнительный входной бит, прежде чем вы сможете понять
значение следующего бита для возврата. 
Терье
--
- 
"почти всё программирование можно рассматривать как упражнение в кэшировании"

От: Мейнард Хэндли 
Группы новостей: comp.arch
Тема: Re: Причины большой смены парадигмы
Идентификатор сообщения: 
Дата: вторник, 21 ноября 2006 г., 19:40:20 по Гринвичу
В статье <[email protected]>,
 Терье Матисен  написал:
> Мейнард Хэндли писал:
> > Что особенно трагично, так это то, что арифметическое кодирование не пришлось
> > быть таким отсталым. Арифметическое кодирование в JPEG2000 (относительно) очень
> > Дружественный к процессору. Но ребята из h364 внесли небольшие изменения, которые имеют серьезные последствия.
> > влияет на то, как это может быть реализовано. Стандартная трагедия отказа
> > верить, что кто-то другой мог бы сделать что-то лучше, чем ты
> > Может и так надо хотя бы посмотреть на их идеи.
>
> Что они сделали по-другому?
>
> Судя по тому, что я стукнулся головой о h364, я бы предположил, что блокировка вместе
> токены с таким же контекстом могут стать большим выигрышем?
>
> Расскажите пожалуйста!
>
> Терье
Прошло три года с тех пор, как я имел дело с этим материалом.  Если вы заинтересованы в
подробности, я бы порекомендовал посмотреть главу о механике того, как
расшифровать арифметическое кодирование в большой книге JPEG2000.
У меня было больше одной жалобы, но та, которую я сейчас вспоминаю, должна была
с вычурными деталями ветки. В основном то, как вещи были определены в
JPEG2000, вы могли бы выполнить тест (что бы определить направление
ветви), затем выполните все остальные различные вычисления, чтобы обновить
государственная машина, то возьмите ветку. ветвление x86 повсюду
место в эти дни, но на ппц это соответствовало условию-регистр
архитектура очень красивая. В CABAC это же направление ветки было
определяется как требующий результатов обновленного конечного автомата, прежде чем вы
знал направление, тем самым предотвращая такого рода низшую лигу
параллелизм.
Как я уже сказал, были и другие проблемы (в том числе откровенный баг в DS
что я поймал), но все они затерялись в тумане времени.

Дата: 22 ноября 2006 г., 10:34:59 +0100
От кого: Терье Матисен  [email protected]>
Группы новостей: comp.arch
Тема: Re: Причины большой смены парадигмы
Идентификатор сообщения: 
Мейнард Хэндли писал:
> Уже три года, как я этим делом не занимался. Если вы заинтересованы в
> подробности, я бы порекомендовал посмотреть главу о механике того, как
> расшифровать арифметическое кодирование в большой книге JPEG2000.
> У меня было больше одной жалобы, но та, которую я сейчас припоминаю, должна была
> с вычурными деталями ветки. В основном то, как вещи были определены в
> JPEG2000, можно было бы провести тест (что бы определить направление
> ветки), затем выполните все остальные различные вычисления для обновления
> Государственная машина, тогда бери ветку. ветвление x86 повсюду
> место в эти дни, но на ппц это соответствовало условию-зарегистрируйтесь
> Архитектура очень красивая.
Даже в x86 это работает хорошо: с любым процессором после Pentium ядро OoO будет
быть в состоянии оценить направление ветвления на ранней стадии, непосредственно уменьшая
задержка каждой оценки.  Чтобы получить это преимущество, вам нужно всего лишь встроить
основной шаг декодирования CABAC (что-то, что вы, вероятно, сделаете
в любом случае), так как в противном случае принудительная ветвь RET может остановить процессор на несколько
циклы позже в любом случае.
Кажется, я выяснил, что минимальная задержка однобитового CABAC
декодирование занимает порядка 10 циклов в 32-битном режиме x86:
Это время, когда вы знаете, с каким контекстом работать (с каким
неизвестно, пока вы не расшифруете предыдущий бит), пока вы не
определил, каким будет текущий бит, и использовал его в
способ обновления зависимых переменных.
> В CABAC это же направление ветки было
> определяется как требующий результатов обновленного конечного автомата, прежде чем вы
> знал направление, тем самым предотвращая такого рода низшую лигу
> параллелизм.
Да, это отстой. :-(
Терье
PS. Я уже несколько лет выступаю за перестановку Altivec в x86,
кажется, что присоединение Apple наконец-то привело к тому, что PSHUFB
определяется как не совсем хорошая альтернатива. 
--
- 
"почти всё программирование можно рассматривать как упражнение в кэшировании"

Дата: Чт, 22 Окт 2009 08:26:02 +0200
От кого: Терье Матисен 
Группы новостей: comp.arch
Тема: Re: Не пора ли прекратить исследования в области компьютерной архитектуры?
Идентификатор сообщения: 
Энди «Крейзи» Глю написал:
>В этом и вся суть: вы хотите получить как можно больше кэш-промахов
> насколько это возможно. МЛП. Параллелизм на уровне памяти.
>
> Если вы сериализуете промахи в кеше, например. в линейном связанном списке
>
> а) перейти к фрагменту кода, которого нет. Например. если ты указатель
> гоняясь за внутренним циклом, переходим к следующей итерации внешнего
> петля. Или к следующей функции.
Энди, ты действительно обязан внимательно посмотреть на h364 и
CABAC: Примерно в то же время, когда DES был заменен на AES,
с заявленным требованием легкости быстрого/эффективного
PentiumPro, рабочие группы MPEG решили, что "Контекстно-адаптивное
Двоичный арифметический кодер» был лучшим выбором для видеокодека. 
CABAC требует 3 или 4 ветвей для каждого декодированного _bit_, а
последняя из этих ветвей зависит от значения этого декодированного бита.
Пока вы не сделали эту ветку, вы даже не знаете, какой контекст применить
при декодировании следующего бита!
(Я нашел обходные пути (либо код без ответвлений, либо создание их
предсказуемый) для большинства встроенных ветвей в битовом декодере, но
эта последняя ветвь контекста неизбежна.)
Единственный возможный пропуск вперед — очень большой: вы должны найти
следующий ключевой кадр и запустить другое ядро/поток, но этот подход
крайне ограниченное значение, если вы находитесь в ситуации реального времени, т.е. видео
конференц-связь.
Терье
--
- <Терье.Матисен на tmsw.no>
"почти всё программирование можно рассматривать как упражнение в кэшировании"

Дата: Пт, 23 Окт 2009 08:28:10 +0200
От кого: Терье Матисен 
Группы новостей: comp.arch
Тема: Re: Не пора ли прекратить исследования в области компьютерной архитектуры?
Идентификатор сообщения:  net>
Энди «Крейзи» Глю написал:
> Терье Матисен писал:
>> Энди «Крейзи» Глю написал:
>
>> Энди, ты действительно обязан внимательно посмотреть на h364 и
>> CABAC: примерно в то же время, когда DES был заменен на
>> AES с заявленным требованием простоты и эффективности на
>> процессор PentiumPro, рабочие группы MPEG решили, что "Context
>> Adaptive Binary Arithmetic Coder» был лучшим выбором для видеокодека.
>>
>> CABAC требует 3 или 4 ветвей для каждого декодированного _bit_, а
>> Последняя из этих ветвей зависит от значения этого декодированного бита.
>>
>> Пока вы не сделали эту ветку, вы даже не знаете, в каком контексте
>> применять при декодировании следующего бита!
>>
>> (Я нашел обходные пути (либо код без ответвлений, либо создание их
>> предсказуемо) для большинства встроенных ветвей в битовом декодере, но
>> эта последняя ветвь контекста неизбежна.)
>>
>> Единственный возможный пропуск вперед — очень большой: вам нужно найти
>> следующий ключевой кадр и запустить другое ядро/поток, но этот подход
>> крайне ограниченную ценность, если вы находитесь в ситуации реального времени, т. е.
>> видеоконференцсвязь.
>>
>> Терье
>
>
> Я посмотрел CABAC, и вы правы, это вроде бы ветка
> эквивалент погони за цепочкой хэшей.
>
> Это также эквивалент хорошего онлайн-сжатия (ну, да) и
> шифрование, где каждый бит зависит от всех предыдущих битов (и, возможно,
> некоторые или все будущие биты.
>
> И если вы не можете перейти к следующему самостоятельному куску работы - если есть
> Нет самостоятельной работы, которую можно перескочить - тебе пиздец. Вы должны сделать
> зависимые вещи работают быстрее. Или вообще ничего не делать. Вы делаете
> зависимые вещи выполняются быстрее благодаря архитектуре, которая делает последовательный код
> работать быстрее - имея более быстрые АЛУ или, если это достаточно важно,
> наличие специального оборудования. Достаточно ли важен CABAC?
Почти наверняка достаточно важно, чтобы что-либо дистанционно
чувствительным к мощности потребуется выделенное аппаратное обеспечение для обработки хотя бы части CABAC.
> Напр. Терье, известно, что ты фанат Ларраби.  Можете ли вы векторизовать CABAC?
Совсем нет, афаик.
> Я не против того, чтобы последовательно зависимые вещи работали быстрее. Я
> Просто заметив, что если ограничения устройства мешают, есть
> множество рабочих нагрузок, которые не являются доминирующими или последовательно зависимыми
> мелочь (на мелкозернистость).
>
> Что касается CABAC, то должен признать, что у меня есть надежда на алгоритмический
> методы, подобные тем, которые вы недавно обсуждали для
> Параллельное шифрование.
>
> Например: разделить изображение на подблоки и запустить CABAC на каждом
> подблок параллельно. Чтобы получить аналогичные коэффициенты сжатия, вы должны
Это единственная серебряная подкладка: возможно, из-за того, что они были
работая в то время над PS3, Sony уточнила, что все кадры Bluray
разделены на 4 независимых квадранта, что означает, что они могли
тривиально разделить работу на четыре из 7 или 8 ядер ячеек.
Это также уменьшило размер каждого подкадра в 1080i до 256 К пикселей. :-)
> должны иметь ключевые кадры реже.  Возможны всплески на ключевых кадрах
> можно было бы избежать, перекосив их.
>
> Более того, я остаюсь поклонником кодирования на основе моделей. Хотя это требует
> значительно больше вычислений, это параллельно.
ХОРОШО.
Терье
--
- <Терье.Матисен на tmsw.no>
"почти всё программирование можно рассматривать как упражнение в кэшировании"

 От кого: Терье Матисен  Группы новостей: comp.arch
Тема: Re: Не пора ли прекратить исследования в области компьютерной архитектуры?
Дата: пятница, 23 октября 2009 г., 23:59:59 -07:00 (PDT)
Идентификатор сообщения: <591da682-3d9f-4d9b-b598-8581c04a499d@l34g2000vba.googlegroups.com> 23 октября, 13:45, Майан Модгилл  написала:
> Энди «Крейзи» Глю написал:
> > Напр. Терье, известно, что ты фанат Ларраби. Можете ли вы векторизовать CABAC?
>
> Не шанс.
>
> > Например: разделить изображение на подблоки и выполнить CABAC для каждого
> > подблок параллельно.
>
> Проблема со стандартом. H.264 указывает, что кадр CABAC
> закодировано.