Цифровое видео

         

Ниже приводится мнение Александра Чемериса


Ниже приводится мнение Александра Чемериса на первый комментарий.
Сначала процитирую Григория Байцура:
У меня есть сильное сомнение, что код вычислений для видео эффектов уж такой
длинный. Там ведь одни циклы должны быть, и параметрические зависимости
считаться. Данных много, а код, скорее всего очень компактный. На битовом
уровне эффекты может, и программируют, но такой код становится плохо
переносимым между платформами, и писать его придется для каждой. А это
дорого, особенно если он длинный. Проще сделать все на более высоком уровне
и иметь аргумент для повышения производительности систем. MMX скорее
исключение из правила.
Теперь выскажу свое мнение:
Данное рассуждение справедливо для работы с простыми эффектами типа шторки.
Сложные эффекты с использованием преобразования Гаусса и 3D эффекты сильно нагружают ЦП, не


оптимизированный под векторные преобразования. Более того, алгоритм просчета
эффектов сильно зависит от "интеллектуальности" ПО.
Простой пример. Необходимо обработать 2 эффекта на 1 кадре. Первый эффект - обработка кадра
(например - поворот кадра в плоскости, псевдо 3D эффект), второй - наложение титров по ключу.
Выполнить эту обработку ЦП может несколькими способами:
Первый - последовательное выполнение
эффектов. Вначале ЦП (вернее алгоритм ПО) рассчитывает новые координаты точек кадра, а затем
происходит просчет наложения 2-го изображения поверх первого. При этом необходимо загрузить и
выполнить две последовательности команд ЦП. Если ПО достаточно "интеллектуально", то оно
проанализирует возможности загрузки обоих последовательностей в КЭШ. Иначе просто будет выполнено
два цикла обращения к ОЗУ.
Второй вариант. Анализируются оба изображения на область точек перекрытия. Просчитывается
возможность распараллеливания вычислений. Понятно, что область закрытая вторым изображением может
не просчитываться на эффект поворота, а сразу рассчитываться по алгоритму замещения точек
изображения. При этом имеется возможность одновременной загрузки, как целочисленного АЛУ, так и


АЛУ для чисел с плавающей точкой, при условии возможности их одновременной работы. Выигрыш в
скорости очевиден. Следует заметить, что при наличии векторного ЦП с размерностью 2048х2048
векторов, расчет данного эффекта теоретически мог занять один цикл такого ЦП.
Теперь что касается переносимости кода. При всей разнообразности платформ ЦП, основной набор
команд достаточно стандартный и при наличии хороших компиляторов, не составит большой проблемы.
Проблемы могут возникнуть как раз при переносе кода, например, на векторные ЦП. Что касается
использования более высокого уровня команд, то в принципе так оно и есть. Большое количество
эффектов сторонних разработчиков используют именно этот способ для дополнения к существующему ПО.
Правда такой подход ограничивает количество ПО, на котором доступны эти эффекты.
Следует заметить и еще такой фактор. Быстро растущие мощности ЦП, при снижении стоимости и
необходимость удержания на рынке, заставляют разработчиков ПО идти по интенсивному пути развития.

Александр Чемерис ()

Содержание раздела