Процесс декодирования восстанавливает последовательность в том же порядке в каком она кодировалась. Определим множество нормализованных кодов (нормализация на целый интервал):

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

Если до этого момента понятно так и не стало, то нас спасет только пример.

Следуя примеру из предыдущей заметки, входная последовательность символов: a2a1a0a0a1a3. Распределение вероятностей: p = [0.2, 0.5, 0.2, 0.1]. Код: 0.74267578125.

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

Вспомнил я о индукции не просто так, а в продолжении темы арифметического кодирования. В прошлый раз мы остановились на том, что определили рекурсивный метод нахождения конечного интервала из которого, в результате, получили код входной последовательности символов. Вот он в двоичной системе счисления: 0.10111110001(2)

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

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

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

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

Вот такая вот ода математике.

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

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

Существенное отличие арифметического кодирования от других подходов энтропийного сжатия состоит в том, что метод не пытается построить взаимнооднозначное соответствие между символом или группой символов и кодовым словом, подобно тому, как это делают алгоритмы семейства variable length coding. Арифметическое кодирование кодирует всю информацию целиком. Символ за символом метод формирует конечное битовое представление, действительное число в интервале [0, 1). Чтобы понять, нужно разобраться в природе кода.

Код последовательности есть действительное число с дробной частью, которая равна этой последовательность. То есть переход от последовательности к коду есть ничто иное как добавление в начало «0.». В качестве примера, возьмем последовательность выходных бит 01010010110, которые порождает арифметическое кодирование, тогда 01010010110 – есть ничто иное как закодированная последовательность, 0.01010010110 = 0.6898797800010 – кодовое значение, действительное число.

Подобная конструкция создает удобную связь между бесконечной последовательностью символов из D-символьного (в нашем примере 2х или 10-ти) алфавита и реальными числами в полуинтервале [0, 1), где любая последовательность может быть представлена в виде действительного числа и наоборот.

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

Где S – входная последовательность, а α и β действительные числа, такие что:

Для упрощения принято представлять интервалы в иной форме:

Тогда интервалы представляют следующим множеством рекурсивных выражений:

Процесс кодирования необходимо проиллюстрировать примером. Рассмотрим алфавит из 4 элементов со следующим распределением вероятностей p = [0.2, 0.5, 0.2, 0.1]. Входная последовательность: a2a1a0a0a1a3. Разберем шаги алгоритма арифметического кодирования:

1. Сперва задается «текущий интервал» [0,1).
2. Далее повторяем следующие действия до последнего входного элемента: делим текущий интервал на части пропорционально вероятностям каждого символа, выбираем подынтервал, соответствующий текущему входному символу, и назначаем его новым текущим интервалом.
3. Результатом будет любая точка внутри конечного интервала.

Графическая иллюстрация:

Обработав последний входной символ (понять, что он последний можно по специальному маркеру или дополнительно передав информацию о размере входного потока), мы получили интервал [0.7426, 0.7428] внутри которого содержится бесконечное множество действительных чисел. Осталось выбрать одно, тем самым сделав финальный шаг всего процесса. Кодовое значение не может быть передано в форме действительного числа, его необходимо представить в форме выбранной системы счисления. Так как число из интервала может быть абсолютно любым, то естестевенно выбрать наиболее удобный вариант для представления, то есть наиболее короткий. В нашем примере, в случае десятичной системы наиболее короткое число 0.7426, в двоичной 0.10111110001 = 0.74267578125.

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

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

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

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

Важность этих требований обусловлена огромным количеством путей внутри такой программы, как кодек. И выбор пути определяется не только набором входных параметров, коих великое множество сочетаний, но и поступающим на кодировку видео. В зависимости от характера движения на видео, кодек может вести себя по-разному. Например, наиболее важными и часто применяемыеми для тестирования кодека видео-последовательностями являются мультики. Как вы догадываетесь, это не имеет ничего общего с нашей любовью к данному жанру, точнее, не всегда имеет, но связано с характерными свойствами подобного контента. Мультики, как правило, содержат очень много «однотонных» областей, большие области высокой корелляции пикселей. Вторым примером служит видео с постоянным движением камеры, например, слева направо. Очень полезно посмотреть, как на таком примере ведет себя оценка движения. Принимает ли она объективные решения, находит ли лучшие совпадения и какой ценой, насколько длинны вектора движения.

Я надеюсь, что затянувшийся посыл дает понять, что тестирование кодека дело очень непростое и хлопотное в плане ресурсов. Например, еженедельное тестирование Intel Media SDK ведется силами десятков топовых машин и занимает до четырех суток. За это время исполняется порядка 50 тысяч различных тестов, ~95% из которых функциональные, то есть происходит реальное транскодирование, кодирование и декодирование видео. И это только время исполнения тестов, без учета затрат на анализ, баг репортов и общего отчета по валидации.

Но вернемся к разработчикам, именно они на начальном этапе создают и внедряют новые подходы для сжатия. Так как, кодек всегда производит сжатие с потерей информации, то неплохо было бы определить метрику, которая покажет расхождение между оригинальным «сырым» видео и восстановленным после кодирования. Сложно придумать размерность для подобных измерений, но хочется, чтобы ее увеличение говорило о лучшем совпадении. Такую метрику придумали и назвали «пиковое отношение сигнал/шум» - PSNR – «peak signal to noise ratio». Метрика общепринята, используется практически всеми для сравнения качества кодеков и имеет сравнительно невысокую вычислительную сложность.

Формулы для вычисления несложны. Метрика требует вычисления среднеквадратической ошибки (MSE, Mean Square Error). Итак, O – пикселы оригинального изображения, R – восстановленого после кодирования, тогда:

Как уже было отмечено, PSNR величина безразмерная, однако из-за наличия логарифма она масштабируется в децибелах (dB). Отметим, что в наихудшем случае, когда пикселы исходного изображения принимают значение из интервала [0, 255], и знаменатель равен 255 (максимум ошибки), мы имеем значение PSNR равное 0. Обратный случай, когда знаменатель равен 0 (изображения абсолютно совпадают), PSNR устремляется к бесконечности.

Между исходной (первая картинка) и восстановленной картинкой значение PSNR составляет 54.7 dB. Достаточно высокое значение, чтобы разглядеть видимую разницу. Придется напрячься.

Нет никакого смысла в том, чтобы судить о качестве видео по величине PSNR, скажем, равной 40 dB. Метрика не призвана отслеживать расхождения, которые мы можем оценить с помощью органов человеческого зрения. Ее высокое значение показывает только высокую схожесть оригинального и восстановленного изображения, что не значит, что результат «понравится» человеческому глазу. Но метрика полезна для анализа работы кодека и порог ее изменения, скажем, в 0.5 dB, будет заметен человеческому глазу. Ну, а если уж, в результате некоторых изменений в кодеке, значение PSNR скакнуло с 40 до 10 dB, то ждите беды.

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

Существуют более развитые метрики, такие как SSIM, призванные устранить недостатки PSNR. Но это уже совсем другая история...

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

На давно минувшей выставке Consumer Electronics Show’11 некий мужчина в забавном головном уборе позволил себе вопросить у зала, почти дословно: «Как часто, в вашей повседневной жизни, вы занимаетесь транскодированием? Поднимите ваши руки!». На что зал стыдливо потупил глаза. Лишь единицы смело подняли руки, да и то, наверняка, потому, что просто неправильно расслышали вопрос. «Окей», - приободрившись продолжил он. «Теперь поднимите руки те, кто ежедневно загружает видео на YouTube и на свои яблочные девайсы». Зал рук. «Поздравляю! Это и есть транскодирование».

Сложно упрекнуть людей в том, что они не знают, что происходит за кулисами простых манипуляций с файлами. Все благоразумно сопрятано от обывательских глаз. Не все ли им равно, что видео в разрешении 1280p не может проигрываться его медиа устройством. И что оно вообще формата MPEG-2 формата, а устройство способно проигрывать только H.264. Однако пользователю точно будет интересно, почему «простой перенос» файла загружает 90% центрального процессора на довольно продолжительное время. Ему невдомек, что декодирование, предобработка и кодирование (все три стадии транскодирования) видео по сей день остаются одной из самых трудоемких задач.

Так вот, того самого человека зовут Мули Иден и представлял он тогда еще новую линейку процессоров Sandy Bridge. И подобные вопросы он задавал отнюдь не для того, чтобы самоутвердиться за счёт зрителей, а чтобы представить новую технологию аппаратно-акселерированной обработки видео под названием Intel(R) Quick Sync Video. Впервые, в рамках майнстрим процессоров, Intel анонсировала технологию позволяющую перенести задачу транскодирования видео с плеч процессора на узкоспециализированные графические юниты, тем самым освобождая процессор от тонны вычислений и экономя ватты батерейки ноутбука.

Уже много лет практически все графические чипы, как интегрированные, так и дискретные, несут на борту обособленную логику аппаратного декодирования популярных форматов видео, таких как: MPEG2, H264 и VC1. Качество видео улучшалось с каждым годом, что естественным образом сказывалось на увеличение нагрузок на процессор и батарейку при декодировании. Появлялись все новые и новые медиа устройства, где подобные чипы уже стоят дефакто. Все ради того, чтобы разгрузить центральный процессор и уменьшить энергопотребление ноутбука или планшета. Даже сегодня маркетологи с гордостью выставляют на передний план этикетку с надписью «HD playback». Признаем, что с декодированием разобрались быстро и эффективно.

А где же кодирование? Уже некоторое продолжительно время монструозные дискретные графические карты предоставляют возможность кодирования с использованием GPU. Однако, соотношение скорость/качество и сложность разработки нивелировали все преимущества такого подхода. Технология Intel(R) Quick Sync Video показала, что оптимальное соотношение существует, а сложность разработки несравнимо ниже, чем у конкурентных решений.

И, наконец, центральный вопрос: а как часто Вы занимаетесь транскодированием? Говорят, что для здоровья процедуру надо повторять 5-6 раз в неделю

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

Пара центов про архитектуру библиотеки. Картинка ниже иллюстрирует основную концепцию. Дело в том, что приложение, использующее нашу библиотеку, ничего не знает о деталях ее реализации. Оно лишь оперирует примитивами: инициализация, уничтожение, запрос результата. Это позволяет нам скрыть детали внутри библиотеки. Библиотека реализует специальный объект HANDLE, с которым приложение общается через интерфейсные примитивы. HANDLE – ядро библиотеки и отвечает за ресурсы, алгоритмы, реализует схему параллелизации и синхронизации. Мощная такая штука.

Главная особенность в том, что HANDL'ов может быть несколько. Каждый под свою железку. Например, библиотека может предоставлять объект-ядро для софтовой реализации алгоритмов и для железо-специфичной Nvidia и ATI. Понятно, что для каждого объекта механизмы инициализации, синхронизации и управления памятью будут особенными.

После небольшого экскурса в архитектуру рассмотрим основные интерфейсные функции доступные приложению. Благо их немного.

Начинаем с инициализации

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

// the main hardware me structure
hw_me_handle_t hwhandle = new _HW_ME_HANDLE;

// parameters of hardware me
HW_ME_PARAMETERS hwPar;

// auxiliary variables
Ipp32u sts, numMb, imageStep, imageSize;

// initialize hardware me parameters
hwPar.codecStandard = HW_ME_H264;
hwPar.meType = HW_ME_WHOLE_PIXEL;
hwPar.algType = HW_ME_RESIDUAL;
hwPar.strictWithinFrame = ippFalse;
hwPar.minSubblockSize = HW_ME_DIV_16X16;
hwPar.imageSize.width = width;
hwPar.imageSize.height = height;

pMeInfo.pMbInfo = NULL;

// number of reference frames for motion estimation
hwPar.maxNumRef = 2;

// initialize me handle by me parameters
InitializeHWME(&hwPar, &hwhandle);

Довольно просто, не так ли? Так вот внутренность интерфейсной функции не намного сложнее.

IppStatus InitializeHWME(const HW_ME_PARAMETERS *pHWMEParams, hw_me_handle_t *pHandle)
{
    hw_me_handle_t handle;

    // release the existing object
    if (*pHandle)
    {
        ReleaseHWME(*pHandle);
        *pHandle = NULL;
    }

    // create new handle object
    handle = new _HW_ME_HANDLE();

    if (NULL == handle)
    {
        return ippStsMemAllocErr;
    }

    // initialize handle
    handle->Init(pHWMEParams);

    switch (pHWMEParams->meType)
    {
    case HW_ME_QUARTER_PIXEL:

        switch (pHWMEParams->codecStandard)
        {
            case HW_ME_H264:
                handle->pEst = new H264EstimatorQuarter;
                break;
            case HW_ME_VC1:
                break;
            case HW_ME_MPEG2:
                break;
            default: // MPEG4 standard
                break;
        }
        break;

    case HW_ME_HALF_PIXEL:

        switch (pHWMEParams->codecStandard)
        {
            case HW_ME_H264:
                handle->pEst = new H264EstimatorHalf;
                break;
            case HW_ME_VC1:
                break;
            case HW_ME_MPEG2:
                break;
            default: // MPEG4 standard
                break;
        }
        break;

    default:

        handle->pEst = new CEstimatorWhole;
        break;
    }

    handle->pEst->Initialize(pHWMEParams);

    *pHandle = handle;

    return ippStsNoErr;

} // IppStatus InitializeHWME(HW_ME_PARAMETERS *pHWMEParams, hw_me_handle_t *pHandle)

Функция принимает на вход параметры оценки движения и указатель на объект-ядро, осуществляет проверку на повторную инициализацию, создает определенный объект оценки движения (тут приведено только для h264 стандарта) и возвращает готовый к употреблению объект-ядро. Вуаля.

Загрузка данных в объект-ядро

Выделенную память следует заполнить данными, а данные прикрепить к объекту оценки движения. Приложение делает:

// YUV reader
CYUVReader reader;

// initialize YUV reader
sts = reader.Init(filename, width, height);
CHECK_STS(sts);

// read the first frame
sts = reader.ReadYUVData();
CHECK_STS(sts);

// copy data from yuv reader to source image memory
IppiSize iSize;
iSize.height = height;
iSize.width = width;

CopyPlane(reader.m_pYUVData[0], width, hwSrcImage.pPlanes[0], imageStep, iSize);

iSize.width = iSize.width / 2;
iSize.height = iSize.height / 2;

CopyPlane(reader.m_pYUVData[1], width / 2, hwSrcImage.pPlanes[1], imageStep / 2, iSize);
CopyPlane(reader.m_pYUVData[2], width / 2, hwSrcImage.pPlanes[2], imageStep / 2, iSize);

sts = CopyHWMESource(hwhandle, &hwSrcImage);
CHECK_STS(sts);

// start preparing of reference frames
for (Ipp32u i = 0; i < hwPar.maxNumRef; i += 1)
{
    // read the next frame
    reader.ReadYUVData();

    // copy data from YUV reader to reference image memory

    iSize.height = height;
    iSize.width = width;

    CopyPlane(reader.m_pYUVData[0], width, hwRefImage.pPlanes[0], imageStep, iSize);

    iSize.width = iSize.width / 2;
    iSize.height = iSize.height / 2;

    CopyPlane(reader.m_pYUVData[1], width / 2, hwRefImage.pPlanes[1], imageStep / 2, iSize);
    CopyPlane(reader.m_pYUVData[2], width / 2, hwRefImage.pPlanes[2], imageStep / 2, iSize);

    // add reference image to the handle
    sts = CopyHWMEReference(hwhandle, i, &hwRefImage);
    CHECK_STS(sts);
}

А внутри все просто - копирование данных во внутренние структуры объекта-ядра.

static
IppStatus CopyPlane(const Ipp8u* pSrc, Ipp32s srcStep, Ipp8u* pDst, Ipp32s dstStep, IppiSize roiSize)
{
    Ipp32s y;

    for (y = 0; y < roiSize.height; y++)
    {
        memcpy(pDst, pSrc, roiSize.width);
        pSrc += srcStep;
        pDst += dstStep;
    }

    return ippStsNoErr;

} // IppStatus CopyPlane(const Ipp8u* pSrc, Ipp32s srcStep, Ipp8u* pDst, Ipp32s dstStep, IppiSize roiSize)

IppStatus CopyHWMESource(hw_me_handle_t handle,const HW_ME_IMAGE *pImage)
{

    if (NULL == handle || NULL == pImage)
    {
        return ippStsNullPtrErr;
    }

    HW_ME_IMAGE* sImage = handle->pSource;

    sImage->imageStructure = pImage->imageStructure;

    // copy 3 planes by line
    CopyPlane(pImage->pPlanes[0], pImage->imageStep, sImage->pPlanes[0], sImage->imageStep, iSize);

    iSize.width = iSize.width / 2;
    iSize.height = iSize.height / 2;

    CopyPlane(pImage->pPlanes[1], pImage->imageStep / 2, sImage->pPlanes[1], sImage->imageStep / 2, iSize);
    CopyPlane(pImage->pPlanes[2], pImage->imageStep / 2, sImage->pPlanes[2], sImage->imageStep / 2, iSize);

    return ippStsNoErr;

} // IppStatus CopyHWMESource(hw_me_handle_t handle, const HW_ME_IMAGE *pImage)

IppStatus CopyHWMEReference(hw_me_handle_t handle, const Ipp32u refIdx, const HW_ME_IMAGE *pImage)
{

    if (NULL == handle || NULL == pImage)
    {
        return ippStsNullPtrErr;
    }

    if (handle->params.maxNumRef pReferences + refIdx;

    IppiSize iSize = handle->params.imageSize;

    sImage->imageStructure = pImage->imageStructure;

    // copy 3 planes by line
    CopyPlane(pImage->pPlanes[0], pImage->imageStep, sImage->pPlanes[0], sImage->imageStep, iSize);

    iSize.width = iSize.width / 2;
    iSize.height = iSize.height / 2;

    CopyPlane(pImage->pPlanes[1], pImage->imageStep / 2, sImage->pPlanes[1], sImage->imageStep / 2, iSize);
    CopyPlane(pImage->pPlanes[2], pImage->imageStep / 2, sImage->pPlanes[2], sImage->imageStep / 2, iSize);

    handle->m_numRef++;

    return ippStsNoErr;

} // IppStatus CopyHWMEReference(hw_me_handle_t handle, Ipp32u refIdx, const HW_ME_IMAGE *pImage)

Нажимаем красную кнопку

Запуск процесса оценки движения мы осуществляли следующим образом:

// results storage of me
HW_ME_INFO pMeInfo;

pMeInfo.numFrameRefs[1] = hwPar.maxNumRef;

// calculate the number of macro blocks
numMb = (width * height) / (16 * 16);

// allocate mb info
pMeInfo.pMbInfo = new HW_ME_MB_INFO [numMb];
pMeInfo.numFrameRefs[1] = hwPar.maxNumRef;

sts = DoHWME(hwhandle, &pMeInfo);
CHECK_STS(sts);

Соответствующая интерфейсная функция обращается к объекту эстиматора.

IppStatus DoHWME(hw_me_handle_t handle, HW_ME_INFO *pMeInfo, void **ppEvent)
{
    IppStatus sts;
    Ipp32u width;
    Ipp32u height;

    HW_ME_IMAGE *pRefImages, *pSrcImage;

    // touch unreferenced parameters
    ppEvent = ppEvent;

    // check error(s)
    if (NULL == handle || NULL == pImage || NULL == pMeInfo)
    {
        return ippStsNullPtrErr;
    }

    // set initial parameters
    width =  handle->params.imageSize.width;
    height =  handle->params.imageSize.height;

    pRefImages = handle->pReferences;
    pSrcImage = handle->pSource;

    sts = handle->pEst->EstimateByFrames(pRefImages, NULL, pSrcImage, pMeInfo);

    return sts;

} // IppStatus DoHWME(hw_me_handle_t handle, HW_ME_INFO *pMeInfo, void **ppEvent)

Все!

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

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

Все началось с моего давнего хорошего друга, Клода Шеннона, который в 1948 году заложил фундамент нового, в то время неизвестного, научного направления – теории информации. Для многих страждущих сей факт послужил предметом многих и долгих споров. Ведь как же так? Человечество привыкло воспринимать информацию лишь качественно, но никак не количественно. Как часто это бывало, сама мысль о теории информации настигла Шеннона во время работы над правительственным проектом в области криптографии. Во времена Второй Мировой Войны. Война - извечный двигатель прогресса.

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

Полагаю, что некоторым знакомо понятие энтропии, определенного в рамках химии и термодинамики. Так вот, у нас энтропия информационная и определяется она, конечно, иначе.

Информационная энтропия — мера неопределённости информации. Например, у вас есть источник, который генерирует поток символов некоторого алфавита. Алфавит состоит из 5 элементов и известно, что один из символов в рамках данного алфавита имеет гораздо большую вероятность появления, допустим 0.5, а другие делят между собой 0.1 и 0.2. Тогда неопределенность появления символа с большей вероятностью мала, но велика для других символов. То есть появление первым символа с вероятностью 0.1 станет большей неожиданностью.

Математически двоичная энтропия символа a с вероятностью появления p(a) определяется не иначе как

Оперируя понятием энтропии теория информации предсказывает среднее количество бит для оптимального сжатия символа алфавита. Строка s = a1a1a1a2a3a4a4a5 состоящая из 8 элементов рассмотренного выше алфавита будет иметь следующую энтропию:

Значение энтропии показывает среднее минимальное количество бит требуемых для шифрования или оптимального сжатия строки без потери информации. В нашем примере она равна 27 битам. Размерность энтропии (бит) вытекает из основания логарифма равного 2.

Для наглядной иллюстрации возьмем алфавит из двух символов. Вероятности символов определяют энтропию алфавита. Равновероятные символы порождают максимальную энтропию и минимальное количество бит необходимое для кодирования символа алфавита равно 1. Во втором случае энтропия минимальна, так как известно, что символ a1 почти всегда будет выходом с источника. Количество требуемых бит для кодирования символа составляет 0.08 бита. Третий случай подобен первому и имеет очень высокий показатель энтропии.

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

Ну, и наконец, что же за процесс такой – «энтропийное кодирование»? Известная теорема Шеннона гласит, что «существует предел сжатия без потерь, зависящий от энтропии источника». То есть чем более предсказуема получаемая информация, тем лучше её можно сжать. Таким образом, энтропийное кодирование есть процесс максимизации энтропии символов исходного сигнала путем усреднения вероятностей их появления с источника.

Гений.

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

На этом этапе впору говорить о кодировании информации в отрыве от видео. Методов предостаточно, однако наиболее широко используются коды переменной длины (variable length coding, VLC) и арифметическое кодирование (arithmetic coding, AC).

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

VLC и CAVLC

Смысл VLC – отображение входных символов в кодовые слова, имеющие переменную длину. Если те или иные входные символы встречаются чаще, то их кодовые слова более короткие. Реже – кодовые слова более длинные. Наиболее известный пример – это код Хаффмана, который предварительно вычисляет вероятность вхождения каждого символа и, согласно построенной вероятностной модели, присвает каждому символу код VLC. Метод требует предварительного анализа всей входной последовательности, что приводит к значительной задерже на стороне приемника сигнала. Также динамическое построения таблицы вероятностей на уровне энкодера требует ее передачи в рамках битового потока для последующего декодирования сигнала, что сокращает степень сжатия. Так как оба этих недостатка связанны с динамическим построением таблицы вероятностей, то разработчики стандартов видеокодирования предложили подход предварительного построения таблицы на основе обобщенных видеоматериалов. То есть каждый стандарт использующий схему VLC, будь то код Хаффмана или его модификации, определяет статическую таблицу кодов, построенную на основе предварительного анализа специально подобранного видеоматериала. Замечу, впрочем, что адаптивный Хаффман решает обозначенные выше проблемы.

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

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

AC и СABAC

Побороть эту проблему призвано арифметическое кодирование (arithmetic coding, AC), которое позволяет наиболее плотно приблизиться к теоретическим оценкам сжатия. Однако за эффективность приходиться платить более высокой вычислительной сложностью.

Context-adaptive binary arithmetic coding (CABAC), подобно тому как CAVLC расширяет собой VLC, представляет собой расширение для AC. Расширение использует стандартную схему AC, но при этом:

• работает только с двоичными символами. Все символы имеющие недвоичные значения (коэффиценты, координаты векторов) приводятся в двоичный вид;
• вводит сбор локальной статистики на основе которой выбирается вероятностная модель для кодирования последующих бит информации.

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

Все вышеописанное даст лишь крайне общие представления о существующих схемах энтропийного кодирования. Далее мы отдельно остановимся на VLC и AC, а также их расширениях. А пока просто знайте.

До сих пор я искренне старался донести «на пальцах» (их уже почти не осталось) краеугольные принципы методов видео-кодирования. Затронул основы устранения временной и пространственной избыточности. Напоследок я предлагаю ознакомиться с 3D-DCT преобразованием, которое так удачно, в смысле идеи, объединяет в себе оба пройденных понятия.
С места в карьер, преобразование математически описывается так:

Тем, кто читал заметку о преобразованиях - перечитайте еще раз! И вы поймете, что _в основном_, преобразования работают в 2D простанстве. Прямоугольные блоки размером 8x8, в частности.

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

Но что, если мы увеличим размерность до трех? То есть, кроме вертикальной и горизонтальной размерности, введем временную? Вспомним, как математики смешно описывают 2D-DCT:

Сравнив формулы можно заметить, что в случае 3D мы добавляем еще один цикл суммы, нормирующий множитель и косинус под суммой. Точка имеет 3 координаты, а это означает, что введя еще одну размерность, - временную, мы образуем уже не квадрат значений, но куб. Представьте себе коробку с восемью 3.5’’ дискетами, где каждая дискета есть блок 8x8, но все вместе они образуют куб – наш новый атомарный элемент. В одной такой коробочке содержится 8 блоков размером 8x8 c одинаковым расположением в рамках 8 кадров.

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

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

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

Применив на данной последовательности кадров алгоритм 3D-DCT, получим следующую картину (только компонента яркости):

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

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

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

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

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

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

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

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

И как же связано дискретно-косинусное преобразование с задачей декорреляции?

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

Посмотрим, что из себя представляют базисные вектора дискретно-косинусного преобразования Фурье. Вот они, косинусы :

Ничего не напоминает? Характер каждого базисного вектора повторяет характер векторов нашего простого преобразования. Первый вектор положительная константа. Остальные периодично варьируют свой знак. Осталось только определить восемь точек на каждом векторе и построить по их значения искомую матрицу размером 8x8.

Определяем абсциссы для данных синусоид:

Идем по волнам и считаем значения:

Примечание.
Почему значения абсцисс выбранны такие? Ответ связан с одним из требований к природе преобразования.

Маленький пример для понимания. Рассмотрим одномерное преобразование на следующем исходном векторе значений сэмплов яркости:

56, 57, 56, 53, 60, 53, 56, 58

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

449.0, 2.36396103, 4.0, -10.36396103, 7.0, -10.36396103, 4.0, 2.36396103

Сильно квантуем его, тем самым невосполнимо потеряв часть информации:

449, 0, 0, -10, 7, -10, 0, 0

Применим обратное преобразование:

54.5, 57.01776695, 57.0, 53.48223305, 59.5, 53.48223305, 57.0, 57.01776695

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

Говорят, что пост без картинок не пост . Вот так выглядит картинка до и после преобразования:

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

Немного формул

Математически, для блока n x n с элементами S^ij, прямое DCT преобразование задается следующими формулами:

Обратное преобразование:

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

Где S – это матрица сэмплов исходного блока, S'- матрица коэффицентов, а A – матрица преобразования элементы, которой заданы: