Чем только этот суппортс будет обеспечен? Ну.. мало ли чем. Скидывайте RAW в оперативку. А дальше, кодек вам зачем поставили?
Пользуйтесь! А там глядишь, может кодек уже и с VGA потоком справится!
Остаётся одно, тестировать

Вот только непонятно, зачем принимать сжатые данные, что бы потом "дохленькое" ядрышко, с никакой памятью, загрузить под 100% ...... Но наше дело
supports, а ваше дело разбираться..
Предположу, что реальное применение кодеку - только если на входе JPG, и ничего нельзя с этим поделать. Например, изображение из интернета.
Жаль, что на 216 МГц так и остановились

p.s.
Ковыряюсь сейчас с AM3358, работающим на частоте 1 ГГц. То же не всё гладко.. Что бы код выполнялся на такой частоте в одноцикловом режиме, он должен загрузиться в L1. Наблюдаю как это работает в реальной жизни? Механизм очень похож на следующий: что бы участок кода попал в L1, он должен быть хотя бы один раз выполнен процессором. И тогда он начинает работать на максимуме. Действительно, некоторые инструкции начинают выполняться по 2 штуки за цикл.
Так вот,
хотя бы один раз пройден, вот этот самый первый раз выполняется на скорости от 5 до 15(!) раз медленней! Скорость зависит от того, где размещается исполняемый код - в L3 или в DDR. Способ подгрузить код в L1 как-то вручную, я пока не обнаружил..
Результаты измерений. Есть некий участок кода, подпрограмма. При размещении её в DDRIII, первый вызов выполняется за ~500 циклов, из L3 уже за ~200 циклов. Все последующие вызовы этой подпрограммы стабильно требуют всего 44 (сорок четыре) цикла на её выполнение. Хотя реально в этом коде 48 строк. Остаётся только понять, надолго ли этот фрагмент задержится в L1?
Но похоже я начинаю догадываться, почему интеловские процессора иногда вдруг дико подтормаживают.. Возможно одновременно начинают выполняться разбросанные участки кода, которые отсутствуют в кеше первого уровня...
Время выполнения измерял встроенным в ядро счётчиком машинных циклов, типа
DWT.