Слышал давно об русском проекте AceStream, который пытается создать конкурента для Content Delivery Network в лице своей децентрализованной сети. Но с той поры прошло много времени и вот один пользователь пригласил на форум AceStream, обратив моё внимание на печальное состояние репозитория для Ubuntu. Беглый осмотр показал, что всё хорошо только для Ubuntu 14.04 LTS. Решено было попробовать представить AceStream в виде снап пакета и залить его в Ubuntu Store для многих.
Архитектурно AceStream выглядит так. Существует AceStream Engine, к которому подключается AceStream Player, созданный на базе VLC с расширенным функционалом. Есть ещё acestream-mozilla-plugin, но стало сразу понятно, что им придётся пожертвовать. Сейчас невозможно представить плагин, образно говоря, из мира snap в браузере, установленным из мира deb. Софт в snap работает в профиле от AppArmor и ограничен. Плагин - это тоже софт, но плагин - это код, который расширяет функционал "другого кода". Возможно в будущем можно будет реализовать такой сложнейший вариант, как плагин в профиле AppArmor может быть соединён с обычным софтом, но пока выходом из ситуации могло быть упакование браузера с нужным AceStream Plugins вместе с Engine и Player, но по ряду причин не стал так делать.
Сначала знакомимся. Ставим в виртуальной среде Ubuntu 14.04 LTS и ставим AceStream из репозитория проекта. Анализ deb пакетов и советы из официальной документации типа sudo apt-get install python-setuptools python-m2crypto python-apsw python-gtk2 python-appindicator
дают ясно понять, что движок написан на Python. Это радует, так как Питона мы ещё не паковали . Движок нужен не только для одного лишь Player'а. Сам по себе движок, запущенный на различных серверах, позволяет реализовать различные клёвые штуки, типа источник трансляции с несколькими узлами поддержки, поэтому решил его представить как отдельную сущность наравне с плеером для тех людей кто будет использовать такой функционал. На сборочном сервере в пустой папке ваяю snapcraft.yaml, в котором есть строки.
name: acestreamplayer version: "3.0.2-snap2" summary: Ace Stream – P2P Multimedia Platform description: | Ace Stream is an innovative multimedia platform of a new generation, which includes different products and solutions for ordinary Internet users as well as for professional members of the multimedia market. confinement: strict architectures: [amd64] apps: engine: command: run.sh engine plugs: [home, unity7, x11, pulseaudio, network, network-bind, opengl, gsettings] acestreamplayer: command: run.sh player plugs: [home, unity7, x11, pulseaudio, network, network-bind, opengl, gsettings]
То есть для вызова просто плеера нужно вызвать acestreamplayer (полная нотация acestreamplayer.acestreamplayer), а "доступ" к движку можно получить через acestreamplayer.engine. Run.sh - это честно сворованный desktop-launch, который разработчики предоставляют в рамках cloud parts. Desktop-launch постоянно хорошеет, но мне часто требуется добавлять для запуска программы какие-либо рихтующие строки и поэтому всегда поступаю так: украл, выпил, в тюрьму ... переименовал, подправил под нужды. Решил не плодить стартовых скриптов-врапперов и сделать один, в котором через if вызывать нужное. Внутри run.sh есть строки типа if [ "$1" == "engine" ]; then
Первая итерация упаковки и acestreamplayer.engine --client-console
даже не запустился, выплюнув ругань Питона - а дескать где мои файлы? Добавляем в run.sh строку export PYTHONHOME=$SNAP/usr - вот они, дорогой! Движок стал стартовать, но беда пришла откуда не ждали. Для обычной работы лучше автоматически перед стартом плеера запускать движок с ключом --client-gtk. Это даст удобный графический индикатор ко многим опциям.
Нужно было реализовать проверку, чтобы в одну единицу времени был запущен один движок. С помощью if pgrep -x "acestreamengine" > /dev/null определяется есть движок в памяти? Но было замечено, что после --client-gtk, --client-console показывает наличие проблем с его "базой". То есть первый, чистый старт --client-console и всё отлично! Стоит раз запустить движок через --client-gtk и у нас проблемы! В этом месте чуть ушёл не туда в размышлениях. Анализ системных журналов указывал что AppArmor блокирует доступ к системному /tmp/. Оказалось что эти попытки, которые были пресечены, вызваны из-за sqlite. Для переопределения папки временного пользования существует переменная окружения для этой базы-библиотеки. Добавил в run.sh создание подкаталога tmp в папке куда есть доступ на запись у программы в snap пакете и указание использовать эту папку через переменную SQLITE_TMPDIR.
if [ ! -e "$SNAP_USER_COMMON/tmp" ]; then mkdir -p "$SNAP_USER_COMMON/tmp" fi export SQLITE_TMPDIR="$SNAP_USER_COMMON/tmp"
И всё! Движок через run.sh стартовал нормально с любыми своими опциями и был готов обслуживать запросы.
Теперь дело за Player'ом. Сначала тупо переписал все имена пакетов из Depends у deb пакетов. Но мир не стоит на месте и многие пакеты исчезли или их имя стало другим. Нужно было в stage-packages вписать актуальные имена пакетов, чьё содержимое запакуют в итоговый snap вместе с программой. Но даже розыск актуальных имён пакетов не помог до конца.
К примеру, не смог разыскать в каком пакете теперь искать библиотеку libdirac_encoder.so. В Убунту 14.04 dpkg -S libdirac_encoder.so
указывал на одноимённый пакет, которого нет в современных релизах. Сайт packages.ubuntu.com также подтверждал что релиз Ubuntu 14.04 Trusty Tahr последний кто видел сей пакет.
С библиотекой libgcrypt.so.11 случился конфуз. В новых релизах есть только пакет libgcrypt20, но попытка сделать символическую ссылку libgcrypt.so.11 -> libgcrypt.so.20 и обмануть программу - завершилась фейлом. Часто бывает, что старшая версия библиотеки меняет API/ABI и нельзя вот так подсунуть софту старшую версию вместо младшей.
Решил тупо наскрести таких библиотек из Ubuntu 14.04 и просто подложить программе в процессе упаковки в snap без использования всяких stage-packages. Есть подкаталог files2/ где уже расположен движок в opt/ и плеер в usr/bin/. В snapcraft.yaml есть мой кусочек project-files, который с помощью плагина dump разместит структуру внутри files2 в будущем снап.
parts: project-files: plugin: dump source: files2/ after: [integration]
А дерево каталогов внутри files2/ такое до 3 уровня вложенности:
├── bin ├── lib │ └── x86_64-linux-gnu ├── opt │ └── acestream │ ├── data │ └── lib └── usr ├── bin ├── lib │ └── acestreamplayer └── share ├── acestreamplayer ├── applications ├── icons ├── kde4 ├── locale ├── man └── menu
Ещё одна итерация и вуаля! AceStream Player, который VLC, запустился и подсоединился к запущенному мною ранее движку. Можно было указать ему на локальные мультимедиа файлы и прослушать/просмотреть. Попробовал скормить AceStreamPlayer'у torrent файл мультика Sintel и через пару секунд начался просмотр.
Сначала не обратил внимание на то что его интерфейс всегда на английском. Такое уже решалось и казалось ещё пару штрихов и всё. Но всё сложилось иначе. Есть такой баг Snaps built from deb can't be gettext translated, который объясняет что часть софта не может правильно понять сдвинутый на величину $SNAP путь к локализации. Сейчас большинство софта нормально понимает и подгружает свои файлы локализации, если в stage-packages добавить увесистый пакет locales-all и в стартовом скрипте есть
export LOCPATH=$SNAP/usr/lib/locale
Ситуация с локализацией внутри снап нельзя назвать идеальной на данный момент. Кто-то ждёт поддержки локализации внутри ubuntu-core и интерфейса, который даст нужное, или отдельного snap пакета локализации, к которому можно будет попросить connect. Locales-all весят почти 127 Мб и просить их с собой в snap пакет - удовольствия мало!
Но у меня впервые поддержка локализации не работала как класс. Спасибо разработчику Oliver Grawert, который указал в комментарии к багу возможность через хак обмануть строптивую программу. Нужно было скомпилировать из исходников небольшую библиотеку bindtextdomain.so, которая через механизм LD_PRELOAD сделает нужное. В стартовый run.sh добавил нужные переменные окружения
export LD_PRELOAD=$SNAP/usr/lib/bindtextdomain.so export TEXTDOMAIN=acestreamplayer export LOCALEDIR=${SNAP}/usr/share/locale
Наконец-то, родной язык и родной интерфейс.
Что сам протестировал? Стартовый скрипт run.sh правильно определяет наличие в памяти Engine и, если нужно запускает его до запуска Player. Если к примеру вы запустили движок самостоятельно в Терминале через acestreamplaer.engine --client-console
, то плеер подключится к нему, не запуская движок в графическом режиме.
Плеер открывает локальные мультимедиа файлы и проигрывает их. Можно скормить плееру torrent файл и начать просмотр буквально через пару секунд буферизации.
Опечалила общая "стабильность" Player. Иногда плеер падает с сообщением в Терминале. Пока отметил, что падения будут чаще если использовать плейлист и часто взаимодействовать с плеером во время проигрывания.
[0xf1c7f8] qt4 interface debug: IM: Setting an input [0xf1c7f8] qt4 interface warning: This shouldn't happen: 1129 acestreamplayer: ../../../../vlc-2.1.4/modules/gui/qt4/input_manager.cpp:321: virtual void InputManager::customEvent(QEvent*): Assertion `0' failed. Аварийный останов (сделан дамп памяти)
Вину́ беру на себя! Из-за этого решил пока залить snap пакет на канал beta в Ubuntu Store, чтобы обычный пользователь не увидел пакет через графический Ubuntu Software, и попросить помощи у сообщества в обкатке пакета. Поставить AceStreamPlayer в snap Ubuntu, используя канал beta, нужно так: sudo snap install --beta acestreamplayer
Как было сказано выше, движок может использоваться отдельно от плеера, и всё богатство возможностей описано в официальной вики Streaming. Был бы благодарен тем кто обкатает работу движка в snap именно как отдельную сущность, а не как приблуду для плеера.
AceStream Player лучше всегда запускать в Терминале с ключом -vvv или -I qt4 -vvv, чтобы в случае проблем иметь на руках ошибки. Остальные опции можно взять с VLC command-line help.
Ожидаю решения администрации форума AceStream, чтобы открыли для данного вопроса отдельную ветку обсуждения и позднее добавлю ссылку на неё в эту статью. Будьте на связи и отслеживайте изменения.
Дата последней правки: 2023-12-26 17:26:13