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

Автор Тема: s905 ffmpeg c аппаратным (HW) ускорением  (Прочитано 39543 раз)

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

Оффлайн baloven

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

Оффлайн sfs

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

Оффлайн balbes150

  • Ветеран
  • *****
  • Сообщений: 599
  • Репутация: +5/-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

  • Пользователь
  • **
  • Сообщений: 38
  • Репутация: +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

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

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

Оффлайн baloven

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

Оффлайн balbes150

  • Ветеран
  • *****
  • Сообщений: 599
  • Репутация: +5/-0
Аппаратное ускорение через c2play. для s912. Я думаю это можно портировать и в s905.

https://forum.armbian.com/topic/2138-armbian-for-amlogic-s912/?do=findComment&comment=59694


Кстати, в LE уже почти готово HW для ядра 4.1x на базе s9xxx. В тестовых образах LE работает воспроизведение через драйвер v4l-m2m на s905x. Постепенно это добавляется в основное ядро и по инфе от разработчиков, аппаратное ускорение использует общее железо на всех s9xxx. Так что скоро можно ожидать появление полноэкранного видео в LInux через ffmpeg и gstreamer на всех S9xxx.

Оффлайн baloven

  • Пользователь
  • **
  • Сообщений: 38
  • Репутация: +0/-0
Как я удачно заглянул :)
balbes150 - это очень радует, мессадж посмотрел, спасибо, только насколько я понял (без переводчика :) ) автор еще не готов все собрать воедино из того что он использовал - но то что он добился работы на одной платформе однозначно говорит о том что сделанное им с большой долей вероятности можно будет использовать и на других CPU

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33965
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Хорошая новость. Но мне в первую очередь для использования линукса на таких девайсах не хватало легкого браузера. Например palemoon. Тут без улучшений. aarch64 так и не появился
Seamonkey похуже, но в репе есть и обновляется

Оффлайн balbes150

  • Ветеран
  • *****
  • Сообщений: 599
  • Репутация: +5/-0
Собрал вариант ffmpeg с поддержкой HW на базе v4l2m-m2m из исходников от LE. Проверил через него декодирование , вроде работает, ошибок нет. Но при попытке запустить видео в ffplay с декодером v4l2m, вроде стартует, но потом выдаёт ошибку (что-то про фильтр), я глянул доки на ffplay - там больше тысячи разных опций, что пробовать, не ясно  ....  ???

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33965
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Где-то выложено?
А mpv не удалось прикрутить?
или может, как-то можно портировать плеер из ЛЕ...

Оффлайн balbes150

  • Ветеран
  • *****
  • Сообщений: 599
  • Репутация: +5/-0
Где-то выложено?
да
https://yadi.sk/d/3-_Y-TO3nYiE3g

тут уже пробуют заставить работать, но пока без результата, возможно сам пакет собран криво, нужно разбираться
https://forum.armbian.com/topic/7930-armbian-for-amlogic-s9xxx-kernel-41x-ver-555/?do=findComment&comment=67820

А mpv не удалось прикрутить?
пока не пробовал, надо разбираться с процессом сборки MPV, но на всё не хватает времени (главная проблема - все хотят получить на халяву рабочее, но не хотят ни как участвовать в этом).

может, как-то можно портировать плеер из ЛЕ
плеер в LE - это KODI, нужно тащить его весь. Я уже пробовал собирать его под X11, вроде собирается, но пока не получилось заставить его использовать аппаратные декодеры, видно при сборке LE что-то используют, что заставляет его "знать" как использовать новые декодеры, проблема та же - время ...

Оффлайн pro777

  • Новичок
  • *
  • Сообщений: 2
  • Репутация: +0/-0
Аппаратное ускорение через c2play. для s912. Я думаю это можно портировать и в s905.

Привет, balbes150,
Задействовать аппаратное ускорение при проигрывании видео на s905 гораздо, по-моему, проще, чем на s912.
У меня нет аппарата на s905, но если я не ошибаюсь, то на s905 имеются драйвера Mali для Linux "из коробки".
Поэтому остается установить в систему только три пакета: libamcodec, ffplay с поддержкой libamcodec и c2play, которые надо собрать из репозитариев.
С MPV так просто не получится - в нем, насколько я помню, нет поддержки libamcodec.
« Последнее редактирование: 16 Декабрь 2018, 15:03:54 от pro777 »

Оффлайн balbes150

  • Ветеран
  • *****
  • Сообщений: 599
  • Репутация: +5/-0
Задействовать аппаратное ускорение при проигрывании видео на s905 гораздо, по-моему, проще, чем на s912.
Привет pro777
В ядре 4.19 используется общий драйвер для декодирования видео на S905 и s912, отличие только в прошивке, которую использует драйвер в работе. Т.е. VPU который используется для декодирования у них общий.
но если я не ошибаюсь, то на s905 имеются драйвера Mali для Linux "из коробки".
не ошибаетесь, для ядра 3.14 Amlogic предоставил блобы для mali450, а для T8xx не дал. но это уже не столь актуально, сейчас идут активные работы по разработке свободных драйверов, для s905 они уже почти готовы (lima), кстати, при желании вы можете их попробовать в живую в образах LE с LIMA (есть у меня на ядиске), работает вполне прилично уже сейчас. Для s912 - это panfrost , есть уже тестовые варианты , крутит тестовые утилиты с HW на s912. Chewitt и Narmstrong уже даже собрали LE с ними, но пока это очень ранняя альфа и многое не доделано.

Оффлайн pro777

  • Новичок
  • *
  • Сообщений: 2
  • Репутация: +0/-0
В ядре 4.19 используется общий драйвер для декодирования видео на S905 и s912
А что за драйвер? v4l2-m2m?
Если я правильно понимаю, то задействовать его успешно еще не получается?
« Последнее редактирование: 16 Декабрь 2018, 14:59:22 от pro777 »