Нам даже чужие исходники скомпилить не удалось.
Не совсем так. Разобраться можно, но на это уйдёт куча времени при не ясном результате. Проще написать свой код с нуля, чем разбираться в чужом коде. Еще одна проблема c2play и ge2dplay - используют функции из других софтин. Сильно патченное ядро со специфичными модулями и библиотеками, софт типа ffmpeg со своими изменениями, настройки системы и т.д.. В результате, даже если собрать плеер, не факт, что он будет работать, как на целевой платформе C2. Это хорошо видно на примере ge2dplay, вроде всё собрал, но в моём ядре нет "чего-то" , что есть в исходном от C2 и всё, ни чего не работает.
Главная проблема - отсутствие хоть какой то документации по базовым библиотекам (функциям), которые предоставляются Amlogic для декодирования (amcodec) и ускорения графики (libMali).
Мне пока не удалось получить этой инфы даже от представителей Khadas (которые напрямую общаются с разработчиками Amlogic, те им то же отказали).
А без этого, все превращается в тягомотное копание в чужом коде, что-бы найти хоть какую то инфу, как это работает, какой параметр и в какой форме нужно передать, что-бы что-то сработало.
Т.е. представьте, есть утилита mount, которая в нормальной системе вам сама выдаёт список своих ключей и опций, есть куча описаний в инете, которые вы легко используете, а теперь представьте другую утилиту, которая что-то может, но нет ни какой инфы, как с ней работать, есть только готовый образ, в котором что-то с ней работает на уровне бинарника .... то бишь чёрный ящик, с не понятным набором опций и условий использования ....
На самом деле libMali - нафик не нужна для видео на платформе ARMv8 , она предназначена для ускорения вывода картинок от интерфейса , типа менюшек в KODI, для ускорения графики игрушек и т.д. Обратите внимание - Mate|XFCE|IceWM без проблеме крутиться и все окошки (интерфейсы) летают без всяких libMali. Если бы разрабы KODI не упирались в свой сильно устаревший и тормозной вариант кроссплатформенного интерфеса (в котором для вывода примитивного набора менюшек используют тормозные алгоритмы и тормозной набор универсальных библиотек вместо оптимизации по платфрмам), то KODI летал бы на любой системе при 4 шустрых ядрах.
На само видео libMali почти не влияет, во всяком случае все ее функции легко заменяет софтовая обработка на основных CPU. Я предполагаю, как раз по этой причине отказались от лицензии для S912, его 8 ядер за глаза для этих целей. Что подтверждают тестовые образы GSTPlay, в которых 4 K видео без проблем работает без всяких libMali. Главное для видео - наличие аппаратного декодера VPU, который представлен в виде набора модулей для ядра (под каждый вариант кодека свой ). За это отвечает набор amcodec. Вот если удастся его прикрутить к ffmpeg, бОльшая часть проблем с ускорением видео на S9xxx будет решена в корне. Есть правда gstreamer, который выполняет аналогичные функции, но его еще нужно перетащить из BUILDROOT в обычный Linux и прикрутить воспроизводилки к нему, тут то же куча заморочек - с отсутствием документации.
Кстати, насколько я смог понять из кода разных плееров и KODI в том числе, все они работают по одному принципу, ffmpeg или другая мультимедиа библиотека занимается только чтением разных форматов, что-бы получать фиксированные данные, а уже само декодирование выполняет amcodec. Т.е. плеер умеет комбинировать получение данных из стандартных библиотек с декодированием и выводом через фирменные библиотеки Amlogic, для которых нет нормального описания, как их компилировать., как их использовать и Amlogic не хотят давать эту инфу (возможно за бабло это решается). В результате то же MPV использует ffmpeg только в софтовом варианте, когда чтение и декодирование выполняются на основных CPU, которые не заточены на это. Кстати, это хорошо видно в KODI, если убрать пользователю доступ к модулям amcodec он автоматически переходит на софтовые кодеки из состава ffmpeg вместо am-h264 и прочее.
В принципе, если бы выпустили чип с 10-12 ядрами, тогда видео будет работать без всяких закрытых библиотек и можно вообще не ставить VPU, всё будет работать на стандартном общем софте. Кто из производителей быстрее это реализует, получит хороший шанс, с минимальными затратами на разработку специфичного софта для VPU, получить универсальное решение, не нужно будет заниматься разработкой и поддержкой новых вариантов кодеков в своих VPU.