Сайт | Скачать | Видео | Wiki

Автор Тема: Компиляция ffmpeg и медиаплееров c аппаратным ускорением  (Прочитано 3869 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн baloven

  • Пользователь
  • **
  • Сообщений: 36
  • Репутация: +0/-0
Редко же я вспоминаю про интересующие меня вопросы :)
Всем доброго...
Вот вспомнил и решил вмешаться, хотя мысль сея давно летает, но все ее не выскажу...
sfs, balbes150 - я уже даже и позабыл где это читал, кажется в мануалах от Amlogic, там упоминалось (если я конечно ничего не путаю), что Mali - это не GPU в чистом виде, а фактически аппаратный эмулятор-ускоритель OpenGL (для краткости OGL).
отсюда у меня вокруг ваших разговоров летает мысль, может она и неправильная, но хоть в какой-то степени поможет, что по сути libmali - это некий интерфейс-прокладка заворачивающая обращения к GPU и преобразовывающая их в вызовы функций OGL ну и падающая их не в программный ускоритель OGL как например в винде этим DirectX занимается, а в аппартатный ускоритель-обработкик Mali - чем скорее всего и достигается ускорение.
Это я к тому, что ИМХО нужно все же разбираться с этой "прокладкой" libmali как, что, откуда и куда она вызывает и передает, и ее как-то нужно поставить правильно в системе чтобы все шло в нее предназначенное для GPU, тогда абсолютно без разницы какой плеер и как собран и собран ли он с поддержкой или без libmali.
Я понимаю что это во первых теория, а во вторых если это так, то это уйма работы... но все же - может есть в это истина?
ведь на Амлоджике есть тесты видео они выводят видео в чистой коммандрой строке... т.е. скорее всего нет в системе ничего кроме этой прокладки правильно установленной и правильно завернутыми запросами......
Надеюсь эти рассуждения хоть немного Вам помогут :)

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 22132
  • Репутация: +164/-0
    • PuppyRus-A
Для разбора с этой проблемой надо быть программистом. Нам даже чужие исходники скомпилить не удалось.

Оффлайн balbes150

  • Модератор
  • Постоялец
  • ****
  • Сообщений: 159
  • Репутация: +2/-0
Нам даже чужие исходники скомпилить не удалось.
Не совсем так. Разобраться можно, но на это уйдёт куча времени при не ясном результате. Проще написать свой код с нуля, чем разбираться в чужом коде. Еще одна проблема 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.
« Последнее редактирование: 05 Июнь 2018, 11:04:20 от balbes150 »

Оффлайн baloven

  • Пользователь
  • **
  • Сообщений: 36
  • Репутация: +0/-0
sfs - ну я программист :) но разбираться в чужом коде (не видел его) и тем более со слов Balbes150 без док и если он скорее всего еще и не комменторован - это либо застрелиться - либо вариант предложенный Balbes150 - писать с 0.... но это тоже палка о 2х концах - потому как если один из участников проекта ("писать с 0") уйдет - то тот кто прийдет вместо него должен будет все же иметь возможность прочитать код, тот код должен писаться читаемым и документированным (хотябы комментированным) - иначе, опять же сделанную работу ушедшим - начинаем с начала :(
Вторая проблема: для упрощения и на случай ухода одного из участников - код должен быть модульным!!!! и должны быть обозначены сначала общие принципы "ядра" проекта документированы входы и выходы, чтобы модуль мог через "ядро" общаться с остальными модулями.
третья: время :( здесь увы я скорее потребитель - мне действительно настоящий вопрос интересен, и в некотором плане есть необходимость его использования по работе - что уже описывал, но времени самому вникать просто нет :(
ну и так далее - попытаться конечно можно - но это нужно организовывать платформу разработки....

Balbes150 - я с некоторыми тезисами не соглашусь, в основном насчет полного отказа от ускорения и использования CPU для графики.... по сути это означает выкинуть GPU который есть, но он же есть!!!! - это тоже самое что вы мне год назад предлагали переходник с HDMI на CSVB купить при том что есть же родной CSVB выход :) Опять же непомню где читал уже наверно больше года назад по мойму как раз на армбиан в какой-то ветке - что основная проблема, в том что Амлоджик вроде как дает готовые бинарники, без раскрытия их работы, под конкретную систему за символические 50к американских денежных единиц. Итог: производители просто порой и не могут себе позволить такие затраты на 1 версию платформы, так как изменения в аппартной части потребуют заказа нового бинарника - яркий пример мои "убитые" боксы. Так же увеличение количества ядер - это удорожание.... а разобраться с корректной работой в текущем варианте - можно получить ооооочень дешевые устройства, аналоги которых стоят в 4-10 раз больше - про использование которых писал в паралельной теме. Вот нужно мне дистанционно управляемое устройство, которое может принимать IPTV поток и выдавать его в CSVB, без вывода всяких меню и прочего.... аналоги таких устройств стоят порядка 300..... и выше $. И ведь чисто технически это все реализуемо даже на боксах на 8хх серии и их по сути было бы достаточно для этого при цене вопроса в 12-16$, и уж тем более с такой задачей справится S905X 1/8Gb.... а если развить вопрос. то можно и дополнительные задачи на бокс повесить... вот мне интересно проверить (решив проблему с использованием GPU) насколько бокс смог бы справиться с кодированием стрима, изменением в нем кодека, разрешения... и прочее связанные вопросы, которых масса у тех кто занимается IPTV и OTT и они как правило весьма дорогостоящие... и если даже 1 бокс сможет в онлайн на лету обрабатывать хотябы один тв канал - то это гораздо дешевле по всем параметрам (в том числе и по потребляемому электричеству), чем ставить сервак за пару тысяч баксов и на нем иметь возможность обработки до 80 каналов

Оффлайн balbes150

  • Модератор
  • Постоялец
  • ****
  • Сообщений: 159
  • Репутация: +2/-0
Есть хорошие новости, совместными усилиями нескольких сообществ, процесс добавления стандартной поддержки декодирования видео для платформы Amlogic, постепенно начинает решаться, через использование v4l2 mem2mem. И ведутся работы по добавлению свободной реализации mali-450. Если есть желающие принять участие - вэлком.

baloven , главная заморочка для использования GPU - нет открытых исходников, только блобы. И вторая сторона - если интерфейс написан правильно, эффективность использования 4\8 "обычны" ядер может быть выше, чем использование GPU. Это как стрельба из пушки по воробьям. GPU эффективен только тогда, когда нужны сложные математически расчёты картинки, при банальном выводе теста и простого фона - нет смысла "заводить комбайн ради одного колоска", накладные расходы будут не увеличивать, а снижать общую скорость.

Оффлайн baloven

  • Пользователь
  • **
  • Сообщений: 36
  • Репутация: +0/-0
Balbes150, я полностью согласен что для математики - CPU более чем достаточно. я без проблем на t95x завел стрим-сервер, одна проблема - на моих боксах сетевая 100 мегабит всего :( - это то что касается чистой математики...
Я же вел речь именно за обработку видео, обработку стримов, перекодирование и прочее что умеет ffmpeg - по сути в iptv и OTT лишь малая часть задач касается получения и ввод стримов - основная головная боль - это их стандартизация на выходе и изготовление разных выходных шаблонов для разных устройств... на хабре с полгода назад сотрудники ivi в своем блоге очень много проблем описали с которыми им приходится сталкиваться и их причины, ну и некоторые способы их решения и основная - как и я описал выше - это получение потоков с разным разрешением, а это уже чистой воды GPU. Там же они описали проблемы по работе с контентом который к ним поступает от правообладателей - и у каждого правообладателя он свой - а на выходе нужно получить то что сможет пережевать устройство абонента и далеко не всегда, что одно устройство один поток с одними параметрами после ffmpeg воспримет - а другое просто не будет его вопроизводить потому что в нем кодеки устаревшие и производители их не обновляют. и одно делать перекодирование и обработку в офф-Нлайне (те же фильмы), и совсем другое это делать в online режиме для ТВ-вещания.
На практике многие пытаются для этих целей использовать последние модели видеокарт NVIDIA и AMD, - но количество используемых потоков - в них ограниченно и народ пытается все это любыми правдами обойти, чтоб не платить энтерпрайз лицензии - и опять же в новых поисках теперь вот появились CPU с интегрированными GPU - но их ценники ого-го... а энергопотребление что видеокарт, что последних процев интел - нельзя назвать средним...