Альтернативная реализация декодера VP8 обогнала по производительности код Google
25 июля 2010 года
Разработчик проекта x264, ранее опубликовавший критическую статью, в которой был проведен анализ недостатков открытого компанией Google видеокодека VP8, представил (Архивная копия от 30 сентября 2010 на Wayback Machine) обзор текущего состояния альтернативной свободной реализации декодера VP8 - ffvp8, подготовленной в рамках совместной работы участников проектов FFmpeg и x264. Тестирование производительности показало заметное преимущество кода ffvp8, способного выдать на современных процессорах примерно на 30% больше кадров в секунду при показе видео с разрешением 1080p.
Небольшой отрыв в скорости на процессорах Atom объясняется тем, что разработчики ffvp8 еще не приступили к оптимизации производительности для этого вида процессоров. Несмотря на то, что за месяц после выхода первого рабочего прототипа процесс оптимизации ffvp8 существенно продвинулся вперед, разработка еще остается экспериментальной. Благодаря использованию многих типовых функций, используемых в других декодерах пакета FFmpeg и уже неплохо оптимизированных, код декодера ffvp8 получился достаточно компактным (в пять раз меньше строк кода, чем в эталонном декодере libvpx). Загрузить тестовую версию декодера ffvp8 можно из SVN-репозитория проекта FFmpeg.
В статье также подробно описываются возникшие в процессе работы над ffvp8 проблемы, например, обращается внимание на недостаточно качественное оформление спецификаций, в которых не упомянута логика работы некоторых расширенных функций и некоторые заявления расходятся с практикой, т.е. с тем, что на самом деле представлено в коде. Иными словами, в текущем виде спецификации оказалось недостаточно для создания полностью совместимой с Google реализации декодера, разработчикам пришлось провести серьезный анализ кода, прежде чем удалось добиться полного бинарного совпадения на уровне декодированных потоков.
Из оптимизаций, которые помогли добиться высокой производительности, отмечается проведение работы по увеличению попадания данных в кэш процессора (используется метод умной предварительной загрузки данных из ключевых кадров, обращение к которым наиболее вероятно после обработки текущего кадра) и активное использование ассемблерных оптимизаций с задействованием SIMD-расширений современных процессоров (MMX, SSE, 3DNow), особенно в таких сильно нагружающих CPU задачах, как компенсация движения и фильтр деблокирования. В настоящий момент оптимизация проведена пока только для процессоров x86, поддержка архитектуры ARM остается в планах на будущее.
Также была проведена работа по уменьшению числа распаковки цифровых значений с разной степенью точности (8-битовых в 16-битовые переменные). Например, возьмём операцию abs(a-b) (модуль разности), где a и b - это 8-битные без-знаковые целые числа. Результат вычисления "a - b" требует для своего хранения в памяти 9-бит, так как может быть в промежутке от -255 до 255. Т.е. требуется привлечение дополнительного девятого знакового бита, чего можно избежать используя в условиях конструкцию вида (satsub(a,b) | satsub(b,a)), которая требует всего 4 ассемблерных команд вместо минимум 10 при использовании распаковки.
Источники
править- Главная ссылка к новости (http://x264dev.multimedia.cx/?...) (Архивная копия от 30 сентября 2010 на Wayback Machine)
Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.
Комментарии
Если вы хотите сообщить о проблеме в статье (например, фактическая ошибка и т. д.), пожалуйста, используйте обычную страницу обсуждения.
Комментарии на этой странице могут не соответствовать политике нейтральной точки зрения, однако, пожалуйста, придерживайтесь темы и попытайтесь избежать брани, оскорбительных или подстрекательных комментариев. Попробуйте написать такие комментарии, которые заставят задуматься, будут проницательными или спорными. Цивилизованная дискуссия и вежливый спор делают страницу комментариев дружелюбным местом. Пожалуйста, подумайте об этом.
Несколько советов по оформлению реплик:
- Новые темы начинайте, пожалуйста, снизу.
- Используйте символ звёздочки «*» в начале строки для начала новой темы. Далее пишите свой текст.
- Для ответа в начале строки укажите на одну звёздочку больше, чем в предыдущей реплике.
- Пожалуйста, подписывайте все свои сообщения, используя четыре тильды (~~~~). При предварительном просмотре и сохранении они будут автоматически заменены на ваше имя и дату.
Обращаем ваше внимание, что комментарии не предназначены для размещения ссылок на внешние ресурсы не по теме статьи, которые могут быть удалены или скрыты любым участником. Тем не менее, на странице комментариев вы можете сообщить о статьях в СМИ, которые ссылаются на эту заметку, а также о её обсуждении на сторонних ресурсах.