Centre multimédia "Kodi" et projet Yocto

Introduction au projet Yocto

Yocto Project est un projet Open Source collaboratif visant à simplifier le développement de distributions pour les systèmes embarqués. Yocto contient un grand nombre de modèles, de métadonnées et d'outils de construction. Dans Yocto Project, vous pouvez connecter un grand nombre de couches BSP (Platform Support Package) pour toutes sortes de plates-formes matérielles.

L'objectif principal de l'article est une tentative de montrer l'assemblage d'un package de distribution typique dans le projet Yocto en utilisant le célèbre centre multimédia Kodi, version 17.6 pour un ordinateur Raspberry Pi 3B à carte unique à titre d'exemple.

Si, quelque part au fond de votre âme, vous sentez que vous êtes un collectionneur, mais que vous n'avez pas encore décidé ce que vous souhaitez collecter, cet article est pour vous. Si vous utilisez déjà le projet Yocto dans votre travail quotidien, vous pouvez faire défiler cet article. Allez directement au dernier chapitre et préparez-vous.

L'article est purement pratique et démontre la possibilité d'utiliser les réalisations du projet Yocto et d'OpenEmbedded pour construire le centre multimédia "Kodi". Les couches Yocto sont gérées à l'aide de l'utilitaire Repo de Google. Un article dans le document cette série.

Alors: allons-y.

Contenu:

Installer Yocto Project sur Ubuntu
Moteur de construction de distribution dans le projet Yocto
Utilisation d' OpenEmbedded avec le projet Yocto
Package de support de plateforme (BSP)
Gérer les calques Yocto avec Repo
Installer Repo
Manifeste de création de distribution
Contenu du manifeste
Description du manifeste
Structure du manifeste BS
Initialisation des variables Poky
Initialisation du référentiel
Synchronisation de référentiel
Création d' une configuration de projet Yocto
Fichier de configuration build / conf / local.conf
Fichier de configuration build / conf / bblayers.conf
Couche pour assembler un centre multimédia
Structure de couche
Configuration de la couche
Composition de recettes-berserk
Composition des recettes-core
Composition des recettes-noyau
Recettes de composition -Mediacentre
Composition de recettes-multimédia
Kodi Build Recipe Supplement
Ajout d'un nouvel élément au menu des paramètres Kodi
Paramètres de mise en mémoire tampon maximum pour la vidéo
Regarder la télévision sur IPTV
Regarder Youtube avec le plugin Kodi
Extension de configuration réseau du shell de la console
Recette de construction de distribution
Un bref guide pour créer une image de distribution
Postscript

Installer Yocto Project sur Ubuntu

Pour créer la distribution à l'aide du projet Yocto sur Ubuntu, vous devez installer les packages suivants:

sudo apt-get install -y --no-install-suggests --no-install-recommends \ gawk wget git-core diffstat unzip texinfo gcc-multilib \ build-essential chrpath socat cpio python python3 python3-pip python3-pexpect \ xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev \ xterm 

Les packages sont installés à l'aide de la commande apt-get install et de la commande élévation de privilèges sudo . Dans le système Ubuntu, c'est une pratique répandue lorsque la commande sudo est utilisée pour effectuer des actions administratives (lors de la création de l'utilisateur principal du système, elle est automatiquement enregistrée dans le groupe «sudo»).

Vous pouvez voir des instructions d'installation plus détaillées ici:

Moteur de construction de distribution dans le projet Yocto

Dans le projet Yocto, chaque unité de programme est décrite à l'aide d'une recette d'assemblage. Le langage de description de recette ressemble à «bash» avec la possibilité d'insérer des morceaux de code dans le langage python. Vous pouvez obtenir des informations de syntaxe de base dans le manuel du projet Yocto . Un ensemble de recettes d'assemblage, selon le but, peut être combiné en couches d'assemblage distinctes.

Les couches sont divisées en couches dépendantes du matériel - couches BSP, couches UI (interface utilisateur), couches Yocto spécifiques, ainsi que des couches qui implémentent certaines fonctionnalités:
par exemple, couches d'OpenEmbedded => multimédia, python, perl, ruby, réseau, systemd, serveur Web, etc.

Utilisation d'OpenEmbedded avec le projet Yocto

Et pourtant, si vous utilisez le projet Yocto, vous aurez certainement besoin de couches avec des fonctionnalités supplémentaires, c'est-à-dire Un large éventail de recettes pour toutes les occasions. Et il existe un tel ensemble - ce sont des recettes d'OpenEmbedded. OpenEmbedded est une infrastructure de construction de packages pour Linux embarqué.

OpenEmbedded est entièrement compatible avec le projet Yocto, car ce projet a été pris comme base pour le projet Yocto. C'est peut-être pour cela que le projet Yocto a une stabilité légèrement meilleure, une meilleure documentation et un support légèrement meilleur (mais en gros c'est toujours le même OpenEmbedded).

Package de support de plateforme (BSP)

Le Board Support Package est une ou plusieurs couches distinctes et spécialisées pour une carte spécifique qui définit les caractéristiques matérielles de la plate-forme, c'est-à-dire implémente les éléments spécifiques qui distinguent une carte d'une autre: fonctionnalités du processeur, interruptions, adressage, fonctionnalités du chargeur de démarrage, fonctionnalités de l'adaptateur vidéo (GPU), etc.

Cet article utilise la couche BSP - meta-raspberrypi
Le référentiel de couches est situé à: git.yoctoproject.org/git/meta-raspberrypi

Gérer les calques Yocto avec Repo

Yocto Project peut utiliser un grand nombre de couches de différents fournisseurs - développeurs d'équipements, et tout cela doit être géré d'une manière ou d'une autre. Imaginez que vous ayez une douzaine de cartes différentes, et chaque carte est livrée avec un référentiel git BSP distinct, et cela ne compte pas l'infrastructure du projet Yocto lui-même, ainsi que les fonctionnalités supplémentaires possibles d'OpenEmbedded.

Dans cette situation, vous ne vous en sortirez pas avec un script d'installation simple séparé. Willy-nilly, doit chercher des outils qui peuvent bien le faire. Encore plus que bien. L'un des meilleurs outils de ce type est l'utilitaire Google - Repo.

Repo est le principal outil de gestion des référentiels GIT lors de la construction du système d'exploitation Android avec sa grande base de code. Repo vous permet de gérer une douzaine, sinon une centaine de référentiels git séparés dans un projet, dont vous pouvez spécifier soigneusement les versions dans un fichier xml du Manifeste

et pour la synchronisation correcte de toutes les versions de tous les référentiels, il vous suffit d'exécuter une seule commande

synchronisation de repo

Installer Repo

En utilisant l'ensemble de commandes suivant, vous pouvez installer Repo dans votre répertoire personnel ~ / bin
(la commande curl peut être installée séparément: sudo apt-get install curl)

 PATH=${PATH}:~/bin mkdir ~/bin curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo chmod a+x ~/bin/repo 

et à l'avenir, vous aurez juste besoin d'utiliser la commande dans la console: repo

ou alors
si le répertoire HOME / bin n'est pas ajouté automatiquement avec le chemin de démarrage standard
voir le fichier HOME / .profile

$
$ PATH = $ {PATH}: ~ / bin
$ repo
$

Manifeste de création de distribution

La distribution recueillie dans le cadre de l'article, je dois l'appeler quelque chose. Que ce soit le nom Torvin . Nom de code Torvin, il contiendra une distribution Linux minimaliste avec l'assemblage d'un seul programme. Cela fait référence à un programme utilisateur d'application - Kodi, et rien de plus (tout le reste est un niveau système). Pour un centre multimédia, à mon avis, cela suffit.

Contenu du manifeste

Le fichier torvin-0.2.5.xml est utilisé pour gérer les couches de distribution .

  <?xml version="1.0" encoding="UTF-8"?> <manifest> <default sync-j="4" revision="rocko"/> <remote fetch="https://git.yoctoproject.org/git" name="yocto"/> <remote fetch="https://github.com/openembedded" name="oe"/> <remote fetch="https://github.com/berserktv" name="bs"/> <project remote="bs" revision="master" name="bs-manifest" path="sources/bs-manifest"> <linkfile dest="setup-environment" src="setup-environment"/> <linkfile dest="shell.sh" src="raspberry/shell.sh"/> <linkfile dest="sources/base" src="raspberry/rocko"/> </project> <project remote="yocto" revision="rocko" name="poky" path="sources/poky"/> <project remote="oe" revision="rocko" name="meta-openembedded" \ path="sources/meta-openembedded"/> <project remote="yocto" revision="rocko" name="meta-raspberrypi" \ path="sources/meta-raspberrypi"/> <project remote="bs" revision="rocko" name="berserk" path="sources/berserk"/> </manifest> 

Description du manifeste

Au début du manifeste, les balises distantes désignent deux référentiels GIT principaux et un auxiliaire:

https: ⁄⁄git.yoctoproject.org / git - Dépôt Yocto nommé yocto
https: ⁄⁄github.com / openembedded - Référentiel OpenEmbedded nommé oe
https: ⁄⁄github.com / berserktv - référentiel GIT auxiliaire nommé bs

Dans la partie suivante du manifeste, en utilisant une dénomination abrégée, nous travaillons avec des projets situés dans ces référentiels, la balise de projet contient les attributs suivants:

remote - le nom du référentiel nommé distant
revision - le nom de la version de branche ou de hachage
name - nom du projet dans le référentiel spécifié
path - le chemin du projet local dans votre système de fichiers

    <project remote="bs" revision="master" name="bs-manifest" path="sources/bs-manifest"> </project>  xml      : git clone https://github.com/berserktv/bs-manifest -b master sources/bs-manifest 

Dans le corps de la balise de projet , j'ai indiqué des commandes pour créer des liens symboliques vers l'infrastructure de scripts auxiliaires d'initialisation initiale et de démarrage régulier du système de construction Poky dont j'ai besoin

    linkfile <project remote="bs" revision="master" name="bs-manifest" path="sources/bs-manifest"> <linkfile dest="setup-environment" src="setup-environment"> <linkfile dest="shell.sh" src="raspberry/shell.sh"> <linkfile dest="sources/base" src="raspberry/rocko"> </project>        : ln -s src dest .. #      ln -s sources/bs-manifest/setup-environment setup-environment ln -s sources/bs-manifest/raspberry/shell.sh shell.sh #    ,  #      cd sources ln -s bs-manifest/raspberry/rocko base 

Structure du manifeste BS

 ├── COPYING.MIT
 ├── framboise
 │ ├── rocko
 │ │ ├── conf
 │ │ │ ├── bblayers.conf
 │ │ │ └── local.conf
 │ │ └── torvin-0.2.5.xml
 │ └── shell.sh
 ├── README.md
 └── environnement de configuration

Le projet bs-manifest est utilisé pour une gestion de configuration flexible, en tenant compte des assemblages de différentes versions de la distribution. J'ai cette version - 0.2.5

Initialisation des variables Poky

L' environnement de configuration du script d'initialisation est issu du projet Freescale Community (dans l'environnement yocto, c'est une solution courante). Le script est responsable de l'initialisation des variables du système de construction Poky, le script crée une structure de répertoire dans laquelle il est très bien divisé:

• build - répertoire de construction
• source - code source des recettes d'assemblage
• download - répertoire pour télécharger le code du programme (bases de données git, archives tar.gz)

Le contenu du script setup-environment peut être consulté ici:


Ce script racine sert à initialiser les variables de configuration de l'environnement de génération et est généralement appelé au début d'une session.

Initialisation du référentiel

Pour initialiser le dépôt, vous devez exécuter la commande:

 mkdir torvin cd torvin repo init -u https:⁄⁄github.com/berserktv/bs-manifest -m raspberry/rocko/torvin-0.2.5.xml 

où -u https: ⁄⁄github.com / berserktv / bs-manifest indique à GIT le chemin vers le projet de manifeste

remarque: vous pouvez également spécifier -b nom_arbre
(si vous ne spécifiez pas le commutateur -b, la branche principale est supposée (par défaut))

où le chemin -m framboise / rocko / torvin-0.2.5.xml vers le fichier de configuration indique ce qui suit:

1. Le nom de la plate-forme matérielle pour laquelle l'assemblage est effectué - framboise
2. Le nom de la principale branche de travail Yocto / OpenEmbedded est rocko
3. Le nom de code de la version est torvin (toutes les versions de la série 0.2.x)
4. Le numéro de version numérique en cours d'assemblage est 0,2,5

Synchronisation de référentiel

pour démarrer ou synchroniser ultérieurement, il suffit d'exécuter la commande:

 repo sync 

qui récupérera toutes les dernières versions des projets GIT spécifiées dans le fichier manifeste (les branches sont généralement indiquées), si vous avez un commit de hachage ou un nom de balise dans l'attribut de révision, la version de ce référentiel git ne changera pas. Le nom de la balise peut être spécifié comme ceci: revision = "refs / tags / v0.2.5"

Création d'une configuration de projet Yocto

Une fois la commande repo sync exécutée, vous pouvez commencer à créer la configuration principale du projet Yocto:

 ./shell.sh 

une fois le script terminé, le répertoire build / conf sera créé:
avec deux fichiers principaux:

• local.conf - Variables de contrôle d'assemblage:
  nom de la plateforme, type de packages de distribution et de build, etc.
• bblayers.conf - configuration des couches connectées du projet Yocto

par défaut, le script setup-environment recherche les sources / base / conf
configuration initiale et si les fichiers local.conf et bblayers.conf
existent, ils sont copiés dans build / conf
(voir la variable TEMPLATES dans setup-environment)

c'est-à-dire les fichiers proviennent de sources / bs-manifest / raspberry / rocko / conf
voir créer un lien symbolique vers la base

Fichier de configuration build / conf / local.conf

Fichier de configuration build / conf / bblayers.conf

les principales variables du fichier local.conf - auxquelles vous devez faire attention:

• MACHINE - le nom de la plate-forme sous laquelle l'assemblage est effectué
• DISTRO - nom de la catégorie de distribution
• PACKAGE_CLASSES - format de package pour l'installation du logiciel
• LICENSE_FLAGS_WHITELIST - utilisation de licences supplémentaires

paramètres spécifiques pour la famille de cartes Raspberry Pi

• GPU_MEM = "128" - la quantité de mémoire vidéo pour l'adaptateur vidéo GPU (allouée à partir de la RAM)
• GPU_MEM_256 = "112" - le même que pour les cartes avec une taille totale de RAM = 256 Mo
• GPU_MEM_512 = "160" - le même que pour les cartes avec une taille totale de RAM = 512 Mo
• GPU_MEM_1024 = "320" - il en va de même pour les cartes avec une taille totale de RAM = 1024 Mo

note:
par exemple, si vous ne laissez que la variable GPU_MEM = "128",
puis pour toutes les cartes RPI, RPI2, RPI3
quelle que soit la quantité de RAM réelle
sur la carte sera toujours alloué pour le GPU - 128 Mo
(et la taille totale de la RAM diminue de cette valeur)

si toutes les variables sont spécifiées, les directives GPU_MEM_256, GPU_MEM_512, GPU_MEM_1024 sont plus prioritaires.

Pour l'assemblage du Multimedia Center, en plus des couches Yocto régulières, voir le fichier bblayers.conf

 ${BSPDIR}/sources/poky/meta \ ${BSPDIR}/sources/poky/meta-poky \ ${BSPDIR}/sources/poky/meta-yocto-bsp \ 

J'ai connecté quatre couches avec des fonctionnalités supplémentaires d'OpenEmbedded.

Kodi Multimedia Center - est un programme complexe qui utilise un grand nombre de bibliothèques externes et vous devez créer chaque bibliothèque en utilisant la recette de construction, donc si possible j'utiliserai toutes les recettes d'OpenEmbedded dans la catégorie Multimédia

Donc, j'ai une couche multimédia connectée et les couches dont elle dépend

 ${BSPDIR}/sources/meta-openembedded/meta-oe \ ${BSPDIR}/sources/meta-openembedded/meta-python \ ${BSPDIR}/sources/meta-openembedded/meta-networking \ ${BSPDIR}/sources/meta-openembedded/meta-multimedia \ 

puis une autre couche OpenEmbedded est connectée pour fonctionner avec les systèmes de fichiers

 ${BSPDIR}/sources/meta-openembedded/meta-filesystems \ 

en outre connecté la couche BSP principale de la plate-forme Raspberry Pi

 ${BSPDIR}/sources/meta-raspberrypi \ 

Eh bien, à la toute fin, une couche supplémentaire est connectée, qui est chargée d'assembler l'image de distribution avec les fonctionnalités du "Multimedia Center"

 ${BSPDIR}/sources/berserk/meta-berserk \ 

Couche pour assembler un centre multimédia

À mon avis, le projet Yocto est une combinaison industrielle pour créer des distributions intégrées. Mais si vous avez déjà travaillé avec le système de construction Buildroot, alors Yocto peut vous sembler lourd. Il utilise une énorme quantité d'espace libre sur le disque dur. Pour un fonctionnement normal, Yocto nécessite environ 80 à 100 Go d'espace libre, et cela ne prend généralement en compte l'assemblage que pour une seule plate-forme.

Yocto fait face à son objectif principal - prendre en charge autant de plates-formes matérielles différentes que possible, et cela nécessite le mécanisme le plus flexible pour commuter les assemblages. Et ce mécanisme a besoin de temps et de lieu. Construire une distribution dans Yocto n'est pas un processus rapide.

Donc, toutes les fonctionnalités d'assemblage du "Multimedia Center" que j'ai avec une couche séparée:

 https://github/berserktv/berserk 

(Titre tiré de mon livre préféré, The Hammer and the Cross, de Harry Harrison.)
(Torvin est également un personnage de ce livre.)

Pour créer les fonctionnalités dont j'ai besoin, j'utiliserai les soi-disant modules complémentaires pour les recettes, qui se trouvent dans des fichiers avec l'extension .bbappend
dans le fichier .bbappend, vous pouvez ajouter vos propres appels de commande pour la méthode de recette de génération standard, par exemple, à la méthode do_configure, do_compile, do_install, etc.

Structure de couche

 ├── COPYING.MIT
 ├── meta-berserk
 │ ├── conf
 │ │ └── layer.conf
 │ ├── recettes-berserk
 │ │ ├── bs-net
 │ │ ├── première manche
 │ │ ├── images
 │ │ └── tv
 │ ├── recettes-core
 │ │ ├── init-ifupdown
 │ │ └── psplash
 │ ├── noyau de recettes
 │ │ └── linux
 │ ├── recettes-mediacentre
 │ │ ├── kodi
 │ │ └── plugins kodi
 │ └── recettes-multimédia
 │ └── ffmpeg
 ├── README.md
 └── changelog.txt

Composition de couche:

• conf - configuration des couches
• recipes-berserk - recette de construction de distribution, tv, réseau et premières recettes de lancement
• recipes-core - recettes de base, en particulier une modification de la recette de démarrage
• recipes-kernel - Recettes de construction de noyau Linux
• recipes-mediacentre - recettes pour construire Kodi et ses plugins
• recipes-multimedia - recettes multimédias, assemblage ffmpeg

configuration des couches

Le fichier contient une indication de la version de la bibliothèque ffmpeg, le numéro de version du noyau linux, ainsi que le nombre de consoles virtuelles (tty), et inclut les fonctionnalités du kit de distribution - wifi x11

DISTRO_FEATURES_append + = "wifi x11"

PREFERRED_VERSION_ffmpeg = "3.1.11"
SYSVINIT_ENABLED_GETTYS = "1"

PREFERRED_VERSION_linux-raspberrypi? = "4.9%"

composition de recettes-berserk

 ├── bs-net
 │ └── bs-net_0.1.3.bb
 ├── première manche
 │ ├── fichiers
 │ │ └── first-run.sh
 │ └── first-run.bb
 ├── images
 │ └── berserk-image.bb
 └── tv
     ├── fichiers
     │ └── berserk.m3u8
     ├── tv-config.bb
     └── tv-dir.inc

où:

• bs-net_0.1.3.bb - recette pour la construction d'extensions shell pour les interfaces WLAN / Ethernet
• first-run.bb - recette pour la première exécution, partitionnement de disque supplémentaire
• first-run.sh - script shell de la première exécution (exécution au niveau d'exécution S)
• berserk-image.bb - recette pour construire l'image de distribution
• tv-config.bb - recette pour configurer les chaînes de télévision en utilisant IPTV
• berserk.m3u8 - configuration des chaînes de télévision publiques (format m3u8)

recettes-composition de base

 ├── init-ifupdown
 │ ├── fichiers
 │ │ └── interfaces
 │ └── init-ifupdown_1.0.bbappend
 └── psplash
     ├── fichiers
     │ └── psplash-berserk-img.h
     └── psplash_git.bbappend

où:

• interfaces - fichier avec le paramètre réseau actuel
• init-ifupdown_1.0.bbappend - extension pour la recette de configuration du réseau
• psplash-berserk-img.h - image de l'économiseur d'écran de démarrage
  fichier d'en-tête obtenu à l'aide de l'utilitaire gdk-pixbuf-csource
• psplash_git.bbappend - extension de la recette pour démarrer l'économiseur d'écran de démarrage

La configuration réseau sur le périphérique cible se trouve dans le fichier:

 /etc/network/interfaces 

Après avoir ajouté l'extension de la recette init-ifupdown, je remplace le fichier de configuration normal par le mien et change l'ordre (priorité) du script exécuté pour les niveaux d'exécution

 INITSCRIPT_PARAMS = "start 98 2 3 4 5 . stop 10 0 6 1 ." 

À l'heure actuelle, presque toutes les distributions Linux modernes incluent un écran de démarrage. En règle générale, l'économiseur d'écran de démarrage affiche l'état actuel du téléchargement, c'est-à-dire indicateur du temps écoulé depuis le démarrage du système. À cet égard, Yocto ne fait pas exception et vous pouvez changer l'image de l'économiseur d'écran de démarrage standard en une image arbitraire.

Pour ce faire, vous devez:

1. FILESEXTRAPATHS_prepend - ajoute un répertoire pour les ressources
2. SRC_URI - ajouter un fichier d'en-tête avec une image arbitraire
3. SPLASH_IMAGES - modifier la variable de contrôle du package

et plus loin dans la recette d'image "berserk-image.bb", il est nécessaire d'ajouter l'image de démarrage de démarrage comme caractéristiques de l'image

 IMAGE_FEATURES += "splash" #          SPLASH = "psplash-berserk" 

composition de recettes-noyau

 └── linux
     ├── fichiers
     │ ├── db.txt.patch
     │ └── rbpi.cfg
     └── linux-raspberrypi_4.9.bbappend

où:

• db.txt.patch - correctif avec la base du domaine réglementaire (utilisé pour le WiFi)
• rbpi.cfg - Fragment de configuration du noyau Linux
• linux-raspberrypi_4.9.bbappend - extension de la recette de construction du noyau 4.9 pour Raspberry Pi

Les appareils Wi-Fi fonctionnent à certaines fréquences et pour eux, il existe un domaine réglementaire - c'est le paramètre qui indique le pays dans lequel cet appareil est censé fonctionner.

Le noyau Linux possède une base de données complémentaire dans laquelle les fréquences autorisées et la puissance autorisée pour celles-ci sont enregistrées pour chaque pays.

Dans le cas le plus simple, cette base de données peut être directement incluse statiquement dans le noyau en spécifiant un paramètre:
CONFIG_CFG80211_INTERNAL_REGDB = y
c'est exactement ce que j'ai fait en connectant un patch à cette base de données db.txt.patch

Et encore une chose: dans Yocto, il existe des fragments de configurations de noyau. Habituellement, un fragment de configuration, un fichier avec l'extension cfg, contient uniquement les paramètres du noyau dont vous avez clairement besoin à certaines fins. Et ce morceau de configuration est ajouté aux paramètres par défaut qui sont déjà présents dans la recette lors de la construction du noyau.

En plus de la recette bbappend, vous pouvez également modifier les paramètres qui sont passés au noyau lors du démarrage:

c'est-à-dire remplacer la variable
CMDLINE voir fichier linux-raspberrypi_4.9.bbappend

recipes-mediacentre

 ├── kodi │  ├── kodi │  ├── kodi_17.bbappend │  ├── kodi-dir.inc │  ├── kodi-runner.bb │  ├── kodi-settings.bb │  └── kodi-version.inc └── kodi-plugins ├── files ├── kodi-language-ru_3.0.10.bb ├── kodi-pvr-iptvsimple.bb ├── plugin-video-youtube_5.5.1.bb ├── screensaver-kodi-universe_0.1.2.bb ├── script-berserk-network_0.2.5.bb └── script-module-requests_2.12.4.bb 

où:

1. kodi/
   
   • kodi — icon,run,settings
     
   • kodi_17.bbappend — Kodi
   • kodi-dir.inc — Kodi
   • kodi-runner.bb — Kodi
   • kodi-settings.bb — Kodi
   • kodi-version.inc — Kodi
   
   
2. kodi-plugins/
   
   
   • files — tar.gz
   • kodi-language-ru_3.0.10.bb — ( Kodi)
   • kodi-pvr-iptvsimple.bb — Kodi pvr-iptvsimple
   • plugin-video-youtube_5.5.1.bb — Kodi «Youtube»
   • screensaver-kodi-universe_0.1.2.bb — screensaver-kodi-universe
   • script-berserk-network_0.2.5.bb —
   • script-module-requests_2.12.4.bb — Youtube
   
   

recipes-multimedia

└── ffmpeg
    ├── ffmpeg
    │  ├── 0001-ffmpeg-Call-get_format-to-fix-an-issue-with-MMAL-ren.patch
    │  ├── h264_parser.patch
    │  └── pfcd_hevc_optimisations.patch
    └── ffmpeg_3.1.11.bb

où:

• 0001-ffmpeg-Call-get_format-to-fix-an-issue-with-MMAL-ren.patch — ffmpeg
• h264_parser.patch — h264
• pfcd_hevc_optimisations.patch — Raspberry Pi
• ffmpeg_3.1.11.bb — ffmpeg (, )

FFmpeg - bibliothèque OpenSource pour l'encodage / décodage d'un grand nombre de formats vidéo et audio. FFmpeg prend en charge près de 400 codecs (ffmpeg -codecs)
et plus de 300 formats (ffmpeg-formats).

Ajout d'une recette de construction Kodi

La couche OpenEmbedded a une recette régulière pour construire Kodi, mais elle est assez générale, et j'aimerais obtenir une version légèrement plus stable et testée pour la plate-forme Raspberry Pi.

Les développeurs de logiciels ont un patch de port inversé. Le logiciel est constamment mis à jour et chaque nouvelle version comprend à la fois de nouvelles fonctionnalités et la correction d'erreurs connues. Le patch de portage inverse vous permet de transférer certaines des modifications de la nouvelle version du programme vers une ancienne, la rendant ainsi plus stable. Mais c'est un travail très dur et laborieux, qui est toujours effectué par un grand nombre de développeurs.

Dans le monde de la communauté OpenSource, il existe plusieurs projets bien connus utilisant Kodi, dont le meilleur (à mon avis) est LibreElec (OpenElec). LibreElec a une bonne version pour la plate-forme Raspberry Pi. Ici, ils l'ont et il est préférable de prendre le patch de port inverse pour Kodi. Ainsi, vous pouvez vous débarrasser d'un grand nombre de problèmes sans même en avoir connaissance.

Le centre multimédia Kodi se concentre sur la lecture du contexte «Media», et à mon avis, la composante la plus critique est la combinaison de Kodi et FFmpeg, c'est-à-dire l'interaction de certaines versions de ces programmes, d'autres bibliothèques peuvent être laissées à partir des couches Yocto et OpenEmbedded.

Pour l'assemblage, j'ai pris la version stable de Kodi 17.6 et la version FFmpeg 3.1.11


Le fichier de description de version inclus sera tel kodi-version.inc

 FILESEXTRAPATHS_prepend := "${THISDIR}/kodi:" #  Krypton SRCREV = "a9a7a20071bfd759e72e7053cee92e6f5cfb5e48" PV = "17.6+gitr${SRCPV}" 

La branche Yocto et OpenEmbedded que je considère - rocko , contient Kodi version 17.3, et pour passer à la version 17.6, il suffit d'ajouter un petit ajout à la recette - kodi_17.bbappend

 require kodi-version.inc #     (   17.3) SRC_URI_remove = "file://0013-FTPParse.cpp-use-std-string.patch" #  ,   systemd   SRC_URI_remove = "file://0004-handle-SIGTERM.patch" #      RPI   libreelec SRC_URI_append += "file://kodi-krypton-rpb-backports.patch" #  error adding symbols: DSO missing from command line SRC_URI_append += "file://vchostif.patch" MENU_ICON = "addons/skin.estuary/media/icons/settings" #       ( ) SRC_URI_append += "file://bs-menu.patch file://icon/bs-network.png" do_configure_prepend() { install -m 0644 ${WORKDIR}/icon/bs-network.png ${S}/${MENU_ICON} } #    kodi plugins RRECOMMENDS_${PN}_append = "\ python-xml python-misc python-db \ python-crypt python-threading python-math python-email \ python-io python-netserver python-urllib3 python-datetime" #     Raspberry Pi #  OPENGL    --enable-gles #  kodi     docs/README.linux => libxmu libxinerama # libxtst xdpyinfo #      DISTRO_FEATURES   "x11" #   kodi  RPI1  RPI2,3    --disable-x11 BS_RPI = " --disable-gl --enable-openmax --enable-player=omxplayer \ --with-platform=raspberry-pi --disable-x11" BS_RPI3 = " --disable-gl --enable-openmax --enable-player=omxplayer \ --with-platform=raspberry-pi2 --disable-x11" EXTRA_OECONF_append = "${@bb.utils.contains('MACHINE', 'raspberrypi', \ '${BS_RPI}', '', d)}" EXTRA_OECONF_append = "${@bb.utils.contains('MACHINE', 'raspberrypi2', \ '${BS_RPI3}', '', d)}" EXTRA_OECONF_append = "${@bb.utils.contains('MACHINE', 'raspberrypi3', \ '${BS_RPI3}', '', d)}" #       Kodi   #  ,  USB  microSDHC  ( ) EXTRA_OECONF_append = " --enable-optical-drive" 

L'option de construction "--enable-Optical-Drive" vous permet de connecter le mécanisme de notification pratique que Kodi utilise lors de la connexion d'un disque optique. Dans ce cas, le module MediaManager (a) (xbmc / storage / MediaManager.cpp) surveille la connexion / déconnexion des nouvelles partitions de disque et affiche un message contextuel à ce sujet.

Exemple udev de connexion / déconnexion de disques:

 ACTION=="add" SUBSYSTEM=="block" ENV{ID_FS_TYPE}=="vfat" \ KERNEL=="sd[az][0-9]" \ RUN+="/bin/mkdir -p /media/%k", \ RUN+="/bin/mount -o iocharset=utf8,noatime /dev/%k /media/%k" ACTION=="add" SUBSYSTEM=="block" ENV{ID_FS_TYPE}=="ntfs" \ KERNEL=="sd[az][0-9]" \ RUN+="/bin/mkdir -p /media/%k", \ RUN+="/usr/bin/ntfs-3g -o \ iocharset=utf8,noatime,windows_names /dev/%k /media/%k" ACTION=="add" SUBSYSTEM=="block" ENV{ID_FS_TYPE}=="ext2|ext3|ext4" \ KERNEL=="sd[az][0-9]" \ RUN+="/bin/mkdir -p /media/%k", \ RUN+="/bin/mount -o noatime /dev/%k /media/%k" ACTION=="remove" SUBSYSTEM=="block" KERNEL=="sd[az][0-9]" \ RUN+="/bin/umount /media/%k", RUN+="/bin/rmdir /media/%k" 

 :  rmdir     ,       ( Linux    -  )       . 

Ajout d'un nouvel élément au menu des paramètres Kodi

Dans Kodi 17.6, les fichiers de configuration xml sont responsables de l'affichage des éléments de menu. Pour ajouter un élément supplémentaire dans le menu "Paramètres", ajustez simplement le fichier:
kodi / addons / skin.estuary / xml / Settings.xml

où skin.estuary est le thème de conception de menu par défaut, la

description de l'élément ressemble à ceci:

<item>
    <label> $ LOCALIZE [13279] </label>
    <onclick> RunAddon (script.berserk.network, butnetwork) </onclick>
    <icon> icônes / paramètres / bs-network.png </icon>
</item>

où:

étiquette - nom de l'élément de menu
onclick - gestion de l'événement en appuyant sur le bouton de menu
(lancement du plug-in, avec le premier argument passant la chaîne "butnetwork")
icône - icône de l'élément de menu (chemin vers l'image png)

La fonctionnalité ci-dessus, ainsi que la connexion de plusieurs plug-ins Kodi supplémentaires, est intégrée à en utilisant le fichier bs-menu.patch

Paramètres de mise en mémoire tampon maximum pour la vidéo

Dans Kodi Multimedia Center, pour maximiser les performances, vous pouvez spécifier les paramètres de mise en mémoire tampon maximum:

 <advancedsettings> <cache> <buffermode>1</buffermode> <memorysize>139460608</memorysize> <readfactor>20</readfactor> </cache> </advancedsettings> 

buffermode = 1
- demandes de tampon pour tous les systèmes de fichiers (y compris le

readfactor local)
- ajuste la vitesse de téléchargement en fonction du débit binaire vidéo moyen. Ainsi, par exemple, si vous lisez une vidéo avec un taux de transfert de données moyen de 5 Mbit / s et définissez le taux de lecture du tampon sur 2,0, cela limitera la vitesse de téléchargement (et donc le taux de remplissage du cache) à environ 10 Mbit / s, donc:

readfactor = 20
supprime la restriction sur la vitesse de téléchargement

memorysize = 139460608
- la taille du tampon est de 133 Mo, tout en utilisant 133 * 3 RAM, c'est-à-dire environ 400 Mo de RAM

Regarder la télévision sur IPTV

Kodi Media Center est un outil très puissant pour visualiser le contenu numérique.

La fonction principale pour laquelle j'ai collecté "Media Center" est la fonction de regarder la télévision numérique en utilisant IPTV (Internet Protocol Television) ie télévision sur le protocole Internet. Avec cette fonction, vous pouvez regarder la télévision numérique depuis votre fournisseur Internet.

C'est l'option la plus moderne et optimale à la fois en termes de qualité d'image et en termes de fonctionnalités supplémentaires, c'est-à-dire services fournis. Par exemple, des chaînes de télévision peuvent être fournies dans l'archive, dans laquelle l'enregistrement vidéo souhaité est disponible pendant un certain temps après la diffusion.

Pour prendre en charge IPTV dans Kodi, il existe plusieurs options de plugin, dont je me suis installé sur le pluginpvr.iptvsimple

Pour construire le plugin, utilisez la recette:

    └── plugins kodi
        └── kodi-pvr-iptvsimple.bb

Le plug-in est connecté / configuré via:
Menu principal Kodi => «Modules complémentaires» => «Mes modules complémentaires» => «Clients PVR» => «PVR IPTV Simple Client»

Pour vérifier le fonctionnement de la télévision IPTV dans le cadre de Kodi, j'ai pris plusieurs chaînes d'actualités publiques et les a ajoutés à la liste au format m3u8, et ont également activé le lancement automatique du plugin «pvr.iptvsimple» au début du media center.

Regarder Youtube avec le plugin Kodi

Les programmeurs qui ont développé Kodi ont fourni la flexibilité nécessaire pour étendre ses fonctions. Ceci est fait pour que tout passionné, s'il le souhaite, puisse ajouter à Kodi ce dont il a vraiment besoin. Et ces plugins pour Kodi sont l'obscurité. Eh bien, vous obtenez le point.Il y en a tellement qu'ils méritent une description dans un article séparé.

Les plugins sont installés très simplement, connectez simplement Kodi à Internet et appuyez sur quelques boutons dans le menu. Vous pouvez le lire sur l'un des forums dédiés à Kodi. Mais l'assemblage, il y a l'assemblage, et je vais inclure un autre plugin dans le kit de distribution comme exemple.

Le plugin (ohm) le plus intéressant et le plus répandu pour Kodi est à mon avis le plugin de vue Youtube. Kodi est un centre multimédia, et Youtube est le plus grand référentiel de ce contenu très multimédia, donc le plug-in Youtube pour Kodi est presque obligatoire.

Le plugin est écrit en python, et c'est un mécanisme de plug-in normal, vous n'avez pas besoin de compiler quoi que ce soit, copiez simplement le plug-in terminé dans le répertoire racine avec les plug-ins et spécifiez le nom du plug-in dans le fichier manifeste xml:
"System / addon-manifest.xml"

Le plugin provient du dépôt officiel, et son code source est inclus dans l'archive:
recipes-mediacentre / kodi-plugins / files / plugin.video.youtube.tar.gz Voir l'

emplacement de la recette d'assemblage du plugin dans chapitre "recettes-composition du mediacentre"

Extension de configuration réseau du shell de la console

Étant donné que le kit de distribution collecté dans le cadre de cet article est une démo, les exigences de configuration des «Interfaces réseau» sont minimales. Je ne voulais pas faire glisser de gestionnaire de réseau lourd pour cela, ce qui était très incompréhensible pour moi et très lourd, et j'ai donc écrit deux scripts shell qui complètent la configuration du mécanisme de configuration normal:

 ############################################################## #     /etc/network/interfaces: ############################################################## auto eth0 iface eth0 inet manual up /etc/network/eth-manual $IFACE up down /etc/network/eth-manual $IFACE down auto wlan0 iface wlan0 inet manual up /etc/network/wlan $IFACE up down /etc/network/wlan $IFACE down 

Pour configurer facilement les interfaces réseau Ethernet / WLAN via l'interface graphique, j'utilise un autre petit plugin Kodi "script.berserk.network". C'est presque le seul plugin Kodi que j'ai compris, mais pour cela, j'ai dû l'écrire. Il est extrêmement compact et minimaliste et est écrit en langage python.

Ces deux composants sont collectés à l'aide de recettes:

• recipes-berserk / bs-net / bs-net_0.1.3.bb
• recipes-mediacentre / kodi-plugins / script-berserk-network_0.2.5.bb

À ce stade, je voudrais m'attarder sur les détails. Ainsi, toute la flexibilité d'utilisation de Yocto réside dans différents ensembles de recettes, c'est-à-dire connecté un ensemble de recettes - le gestionnaire de réseau le plus simple a été ajouté au kit de distribution, connecté un autre ensemble - ajouté votre gestionnaire de réseau préféré en utilisant par exemple systemD, etc.

Pour me connecter automatiquement à un point d'accès WiFi au démarrage du système, j'utilise la règle udev: /etc/udev/rules.d/80-wifi-start.rules

 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", KERNEL=="wlan*", \ RUN+="/etc/network/wlan-runner $env{INTERFACE} up" SUBSYSTEM=="net", ACTION=="remove", DRIVERS=="?*", KERNEL=="wlan*", \ RUN+="/etc/network/wlan-runner $env{INTERFACE} down" 

Le script wlan-runner exécute simplement les commandes:
/ etc / network / wlan $ IFACE up
ou
/ etc / network / wlan $ IFACE down

Recette de construction de distribution

Le projet Yocto dispose d'un mécanisme de réutilisation. Il existe des classes dont vous pouvez hériter (directive "hériter"), et il existe des recettes de base que vous pouvez connecter (directive "inclure").

Je montrerai l'héritage en utilisant l'exemple de classe:
poky / meta / clasess / core-image.bbclass

La classe est chargée de décrire les groupes de packages que vous pouvez inclure dans une recette particulière. Pour ce faire, il suffit d'indiquer la construction au début de la recette:
hériter core-image

Même dans le texte de cette classe, vous pouvez voir les fonctionnalités de l'image, chaque fonctionnalité est responsable d'un groupe de fonctions incluses dans l'image, et chaque groupe décrit finalement un ensemble de programmes ou de bibliothèques installés.

Les caractéristiques de l'image sont indiquées comme suit:

 IMAGE_FEATURES += "ssh-server-dropbear splash" 

Il existe également DISTRO_FEATURES - fonctionnalités de distribution qui peuvent être spécifiées dans le fichier de configuration de couche. Ce sont des fonctions au niveau de la distribution, et si par exemple vous modifiez une fonctionnalité (par exemple x11), l'assembly suivant commencera à réassembler tous les packages qui dépendent de cette option (cela peut prendre un certain temps).

La recette de base de base que j'utilise:
poky / meta / recipes-core / images / core-image-minimal.bb



Je voudrais préciser que, par exemple , le package kernel-modules installera
tous les modules du noyau spécifiés dans le fichier defconfig dans l'image de distribution.

Mais si vous personnalisez fortement quelque chose, alors bien sûr, vous n'aurez peut-être même pas besoin de tous les modules du noyau, auquel cas il est pratique d'ajouter chaque module par son nom, comme indiqué dans la variable BS_WLAN , c'est comme une feuille de triche, spécifiez uniquement ce dont vous avez besoin et après avoir vérifié le package "Kernel-modules" supprimer, vérifier, etc.

Un bref guide pour créer une image de distribution

Postscript

Les capacités d'OpenSource ces dernières années ne font qu'augmenter.

Mais ces opportunités ne sont pas petites, pour des exemples vous n'avez même pas besoin d'aller loin. Il est peu probable que le même "Microsoft" s'attendait à ce que la technologie OpenSource la rejette du marché des systèmes d'exploitation mobiles. Je veux dire l'OS de Google - "Android", qui a jeté du jour au lendemain le "Pionnier" des systèmes mobiles. Et il n'est pas clair si Microsoft pourra y revenir à nouveau.

Bien sûr, "Google", une énorme société avec des finances presque illimitées et d'excellents développeurs, mais toujours, comme on dit "sans le Core et pas ici et là".

Les meilleurs projets OpenSource au fil du temps deviennent une œuvre d'art (par exemple Kodi, Openelec / libre, etc.)

Et aujourd'hui, tout le monde peut rejoindre les meilleures pratiques en OpenSource, pour ainsi dire sans sortir de Github (a). Cet article est à ce sujet.

Ayez beaucoup d'assemblages bons et différents pour vous, et souvenez-vous que "le monde de l'Internet des objets arrive".