Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

Raspbian mis à jour : accélération matérielle dans VLC, trois images différentes (lite, base, full)

Faites votre choix

Raspbian mis à jour : accélération matérielle dans VLC, trois images différentes (lite, base, full)

Le 19 novembre 2018 à 07h00

Si une image de base existait pour Raspbian afin d'utiliser un Raspberry Pi comme un serveur, celle destinée à un usage bureautique était forcément livrée avec un certain nombre de logiciels. C'est désormais fini. Dans le même temps, VLC gère l'accélération matérielle des GPU VideoCore. 

Il y a quelques jours, la fondation Raspberry Pi mettait en vente la version 3 A+ de sa machine ultra compacte, supportée depuis la mouture d'octobre du système d'exploitation Raspbian. Mais ce dernier a tout de même été mis à jour dans la foulée, et les nouveautés ne sont pas vraiment anodines.

Accélération matérielle dans VLC et petites retouches

On retrouve bien entendu un nouveau noyau (4.14.79) et le dernier firmware en date. Le plugin Pepper Flash est présent dans sa dernière déclinaison et quelques correctifs ont été intégrés. L'éditeur Python Thonny passe à la version 3.0.5, avec un nouveau lien permettant d'opter pour la version classique de l'interface plutôt que la version simple, activée par défaut.

Mais surtout, VLC est désormais présent avec l'accélération matérielle du GPU VideoCore intégrés aux SoC Broadcom utilisés par les RaspberryPi. Elle est active par défaut. Le billet de blog précise que l'optimisation va continuer, mais que les résultats sont déjà très bons. De quoi ravir ceux qui utilisent une telle machine pour en faire une solution multimédia.

Pour installer VLC, utilisez les commandes suivantes :

sudo apt update
sudo apt install vlc

De petites modifications sont aussi intervenues pour unifier la gestion des paramètres d'apparence et de configuration de LXDE. En cas de changement dans vos fichiers, un répertoire oldconffiles est placé dans celui de l'utilisateur.

Trois images pour mieux s'adapter aux besoins

Enfin, trois images sont désormais proposées, plutôt que deux. Cela correspond à une demande de longue date de la part de la communauté. Raspbian Lite ne contient toujours que les éléments vitaux au fonctionnement d'un Raspberry Pi. Pour la version de bureau, une version de base est désormais proposée sur le même concept.

Elle se limite à Chromium, VLC, Python et quelques applications accessoires. Des logiciels comme LibreOffice, Thonny, Scratch, Scratch 2, Sonic Pi, Minecraft, Python Games, SmartSim ou SenseHAT Emulator ne sont ainsi pas présents. Ils sont seulement intégrés dans l'image complète, considérés comme des « logiciels recommandés ».

Raspbian Images

Ils font ainsi leur apparition dans l'application créée l'été dernier, permettant de gérer simplement les outils installés via une interface graphique. Cette image « Full » gagne au passage des outils comme Mathematica, BlueJ, Greenfoot, Node-RED, Claws Mail ou encore VNC Viewer. Les fichiers de localisation du support de LibreOffice sont installés si nécessaire.

Une façon de faire plus modulaire. La fondation précise que la nouvelle image de base permettra de limiter la quantité de données à télécharger, chacun pouvant ensuite sélectionner les outils qu'il souhaite. Ceux qui continuent à vouloir un pack complet sans téléchargement ultérieur nécessaire peuvent opter pour la complète. 

Les fichiers téléchargés pèsent respectivement 351 Mo, 1 Go et 1,84 Go pour des images de 1,73 Go, 3,17 Go et 4,93 Go. 

Commentaires (31)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

En parlant d’accélération matérielle, lorsque je visionne une vidéo en bonne qualité par le net (en passant par Chromium ou Firefox), le RPI n’arrive pas à suivre malgré une allocation mémoire GPU de 512Mo.



Par contre, aucun problème pour du FHD sur KODI. Espérons qu’il en soit de même pour VLC.

votre avatar

C’est l’heure de mettre à jour.

votre avatar

Vous pouvez utiliser OMXPlayer qui est full opti Raspberry<img data-src=" />

votre avatar



Mais surtout, VLC est désormais présent avec l’accélération matérielle du GPU VideoCore intégrés aux SoC Broadcom utilisés par les RaspberryPi.





Enfin une bonne raison d’acheter un Pi ! <img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />



Plus sérieusement, un support d’accélération matérielle, c’est toujours bon à prendre. À suivre de près !

votre avatar

Question à coté de la plaque. Vous avez quoi comme alimentation durable pour vos pi3 ? J’en ai acheté plusieurs et dans le temps en alimentation continue elles n’arrivent plus forcément à tenir les 2,5⁄3 ampères requis.

votre avatar







wanou2 a écrit :



Question à coté de la plaque. Vous avez quoi comme alimentation durable pour vos pi3 ? J’en ai acheté plusieurs et dans le temps en alimentation continue elles n’arrivent plus forcément à tenir les 2,5⁄3 ampères requis.







Moi j’ai opté pour ça et j’ai un peu plus de périphériques USB sans taper directement dans l’alim du Raspberry


votre avatar







Lyaume a écrit :



En parlant d’accélération matérielle, lorsque je visionne une vidéo en bonne qualité par le net (en passant par Chromium ou Firefox), le RPI n’arrive pas à suivre malgré une allocation mémoire GPU de 512Mo.





Je ne suis pas sûr que Chromium ou Firefox utilise l’accélération matérielle (en tous cas pas sur ma configuration).

“une allocation mémoire GPU de 512Mo” : à quoi ça sert ? Pour décoder de la vidéo, il n’y aucunement besoin d’une telle quantité de mémoire, c’est énorme.







Goreman a écrit :



Vous pouvez utiliser OMXPlayer qui est full opti Raspberry<img data-src=" />





Question de profane (je n’ai pas de RPi), je suppose que Raspbian est livré depuis le début avec un “player” utilisant l’accélération matérielle ?







wanou2 a écrit :



Vous avez quoi comme alimentation durable pour vos pi3 ? J’en ai acheté plusieurs et dans le temps en alimentation continue elles n’arrivent plus forcément à tenir les 2,5⁄3 ampères requis.





Comment ça elles n’arrivent plus à tenir ? L’intensité max a diminué depuis que tu as commencé à l’utiliser ?

(ça me paraît bizarre pour une alimentation)


votre avatar







OlivierJ a écrit :



Je ne suis pas sûr que Chromium ou Firefox utilise l’accélération matérielle (en tous cas pas sur ma configuration).&nbsp;



Chromium, c’est certain : il n’y a pas d’accélération matérielle sous Linux, même si on force le réglage et que le navigateur dit le contraire. Et c’est pas près de changer.


votre avatar

Je suis content pour la nouvelle image, j’en avais marre d’avoir besoin d’installer Minecraft et Mathematica (et surtout de les mettre à jour) quand je veux tester rapidement un script ou faire un PoC.

votre avatar

j’utilise une alim a découpage à intégrer, il y en a des très petite pour le 5V, il est possible d’ajuster le 5v et de la placer dans une petite boite en plastique.&nbsp; C’est utilisé pour l’alim de LED en général.



&nbsp;Avec à mon avis l’avantage de choisir le courant de sortie vers les 4A, pour être confortable pour le RPI.



&nbsp;

votre avatar







OlivierJ a écrit :



Je ne suis pas sûr que Chromium ou Firefox utilise l’accélération matérielle (en tous cas pas sur ma configuration).

“une allocation mémoire GPU de 512Mo” : à quoi ça sert ? Pour décoder de la vidéo, il n’y aucunement besoin d’une telle quantité de mémoire, c’est énorme.



A la base, le RPI alloue seulement 64Mo pour la partie GPU. L’augmenter à 256 voir 512 est conseillé si tu lis des vidéos en FHD sur Kodi par exemple.

&nbsp;





Trit’ a écrit :



Chromium, c’est certain : il n’y a pas d’accélération matérielle sous Linux, même si on force le réglage et que le navigateur dit le contraire. Et c’est pas près de changer.





Bon et bien j’ai ma réponse. Je ne savais pas que l’accélération matérielle n’était pas de la partie… Dommage, car même sur Youtube il y a des problèmes de lecture…


votre avatar







Lyaume a écrit :



A la base, le RPI alloue seulement 64Mo pour la partie GPU. L’augmenter à 256 voir 512 est conseillé si tu lis des vidéos en FHD sur Kodi par exemple.





Je note, mais ça m’étonne. Je ne vois pas à quoi sert cette mémoire.

Pour stocker le contenu d’un écran HD (1080p) en 24 bits, il suffit de 1920x1080x3 ~= 6 Mo. Si on multiplie par 2 pour du double-buffering, on arrive à 12, et si on ajoute 3 écrans en plus pour le calcul du mouvement (je dis ça au pif), on arrive à 30.


votre avatar

Je ne suis pas expert, mais le décodage des vidéos demande de multiples passes de traitement sur la donnée source pour arriver à l’image finale à afficher. A chaque passe, il faut stocker les données traitées qui font probablement une taille non négligeable, à mon avis le calcul que tu fais est trop simple et ça ne m’étonne pas du tout qu’il soit nécessaire d’avoir beaucoup plus de ram que les 30 Mo dont tu parles.

votre avatar







slemaire a écrit :



La norme H264 peut faire ses prédictions sur une profondeur de 32 images. Un tel flux n’est pas “temps réel”, mais pour un média en différé cela peut aider en particulier en présence d’images éclairées avec un éclairage stroboscopique.





Merci pour l’info sur les 32 images (ça paraît énorme). Il faudrait que je regarde dans les réglages du codec x264 sur combien d’images il regarde, selon le réglage (entre des “superfast” et des “veryslow”).



Sauf erreur de ma part, c’est aussi comme ça que sont compressés les flux temps réels, comme la télévision TNT en France. J’ai gardé longtemps ma télé hertzienne analogique et j’ai pu comparer avec les voisins en TNT (sur du foot), j’avais plusieurs secondes d’avance ; j’avais trouvé le délai assez important d’ailleurs, ça m’avait surpris.







slemaire a écrit :



Par résilience, j’entends que sur un OS non temps réel, il me semble difficile de garantir que l’on va lire quelques gigas pendant plusieurs heures sans jamais souffrir d’une coupure supérieure à une frame (env 1⁄30 sec) à partir d’un disque dur partagé par plusieurs autres applications. Pour y parvenir il faut des buffers.





Ben on stocke le flux vidéo justement (celui qu’on lit et qui est compressé), pas le flux décodé ; ça prend infiniment moins de mémoire. Aucun besoin de décoder à l’avance plusieurs images si c’est ça.


votre avatar

C’est arrivé en 2015&nbsp; :https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=111144



Du coup je n’ai effectivement pas installé de pi depuis ^^

votre avatar

question de novice, ca peut decoder quoi comme flux video un Pi 3B+? Est ce qu’il “digere” les h264/x264 et H265/x265?

votre avatar

Normalement la décompression est un processus (beaucoup) plus simple que la compression (déjà rien qu’en terme de demande CPU ça l’indique bien), et se base essentiellement sur la différence entre 2 images et les références à l’image précédente (avec des vecteurs de mouvement par exemple quand un élément subit une simple translation).

En principe tu as besoin de 2 buffers seulement, l’image actuelle, et la future en construction. Le décodage de blocs d’une image ne devrait pas nécessiter plus de mémoire que celle d’une image complète, donc ajoutons un 3e buffer, on est à 18 Mo vu comme ça.

Il faudrait que je regarde plus en détail.

votre avatar







goaryser a écrit :



question de novice, ca peut decoder quoi comme flux video un Pi 3B+? Est ce qu’il “digere” les h264/x264 et H265/x265?





D’aprèsfr.wikipedia.org Wikipediatous les Pi :

“Broadcom VideoCore IV78, OpenGL ES 2.0, MPEG-2 et VC-1 (avec licence), 1080p30 h.264/MPEG-4 AVC high-profile decodeur et compresseur”


votre avatar







OlivierJ a écrit :



&nbsp;

Comment ça elles n’arrivent plus à tenir ? L’intensité max a diminué depuis que tu as commencé à l’utiliser ?

(ça me paraît bizarre pour une alimentation)







C’est ça, j’ai acheté des chinoiseries et l’intensité à la sortie n’est plus suffisante.&nbsp; Je pense que je vais investir dans une bonne alimentation prévue pour le marché européen.


votre avatar







sscrit a écrit :



j’utilise une alim a découpage à intégrer, il y en a des très petite pour le 5V, il est possible d’ajuster le 5v et de la placer dans une petite boite en plastique.&nbsp; C’est utilisé pour l’alim de LED en général.



&nbsp;Avec à mon avis l’avantage de choisir le courant de sortie vers les 4A, pour être confortable pour le RPI.



&nbsp;



&nbsp;

Tu arrives à avoir quelque chose de suffisamment stable&nbsp;pour pouvoir te connecter directement sur les broches du gpio ou bien tu passes tout de même par le micro usb pour plus de sécurité ?


votre avatar

Sur le papier ça donne peut être si peu, mais dans les faits, si la mémoire allouée n’est pas augmentée les vidéos deviennent illisibles. Je ne suis pas un pro concernant le traitement vidéo mais es-tu sûr qu’il n’y a pas d’autres facteurs qui rentrent en compte ?



Et depuis un navigateur, sans accélération matérielle les vidéos deviennent rapidement illisibles, d’où mon interrogation.

votre avatar

c’est suffisamment costaud pour le modèle que j’ai pris, ca ressemble quand même vachement a une alimentation AT en plus petit et sans ventilo.



genre ça



surtout régler la tension avec un voltmètre avant de le brancher,&nbsp; le mien a été réglé à l’arrache <img data-src=" />

votre avatar

L’idée du double buffering est idéale pour des animations où l’image est calculée image après image, mais en vidéo H264, une image est codée d’après la ou les précédentes donc il en faut bien plus.

De plus, il faut des buffers pour éviter les coupures…



Une autre façon de compter.

20 Go pour 90 minutes, cela donne presque 4 Mo par seconde pour le flux compressé.

Et dans ton calcul 6Mo x 30 img/sec = 180 Mo / sec d’images décompressées



Il n’est pas tellement surprenant qu’un décodeur résilient ait une consommation mémoire proche de la seconde.

votre avatar







OlivierJ a écrit :



Pour stocker le contenu d’un écran HD (1080p) en 24 bits, il suffit de 1920x1080x3 ~= 6 Mo.





À moins d’avoir un écran monochrome, il faut encore multiplier par trois pour du RGB.


votre avatar







OlivierJ a écrit :



D’aprèsfr.wikipedia.org Wikipediatous les Pi :

“Broadcom VideoCore IV78, OpenGL ES 2.0, MPEG-2 et VC-1 (avec licence), 1080p30 h.264/MPEG-4 AVC high-profile decodeur et compresseur”





merci!, l faudra que je teste :)

&nbsp;


votre avatar

Le 3 de son calcul correspond à cela : 24 bits / 8 bits/octet= 3 octets par pixel.

votre avatar







slemaire a écrit :



L’idée du double buffering est idéale pour des animations où l’image est calculée image après image, mais en vidéo H264, une image est codée d’après la ou les précédentes donc il en faut bien plus.





Normalement c’est après LA précédente, car plus tu remontes en arrière, moins tu retrouves de points communs. Ça remonterait à combien d’images en arrière, selon toi ?







slemaire a écrit :



De plus, il faut des buffers pour éviter les coupures…





Coupure de quoi ?

Si on n’a plus de flux vidéo en entrée, on ne peut rien décoder.







slemaire a écrit :



Une autre façon de compter.

20 Go pour 90 minutes, cela donne presque 4 Mo par seconde pour le flux compressé.

Et dans ton calcul 6Mo x 30 img/sec = 180 Mo / sec d’images décompressées





Mais pourquoi on aurait besoin de stocker 30 images d’affilée ?

Le système de décodage a juste besoin d’avoir, grosso modo, l’image précédente, et les données qui indiquent les différences avec l’actuelle (je parle d’une trame “B” (bidirectionnelle) ou “P” (prédictive) bien sûr, pour une trame “I” aucun besoin d’image précédente) ; peut-être quelques images précédentes mais je n’en suis pas sûr.







slemaire a écrit :



Il n’est pas tellement surprenant qu’un décodeur résilient ait une consommation mémoire proche de la seconde.





Honnêtement je ne pige pas ton histoire de résilience.







Zebulon84 a écrit :



À moins d’avoir un écran monochrome, il faut encore multiplier par trois pour du RGB.





Tu as dû louper un truc dans le calcul. <img data-src=" />







fred42 a écrit :



Le 3 de son calcul correspond à cela : 24 bits / 8 bits/octet= 3 octets par pixel.





Merci.


votre avatar

l’image “lite” est sans X11 donc ? Du coup c’est nouveau ça,&nbsp; avec jessie ça n’existait pas

votre avatar

Je peux me tromper, mais je crois que Rasbian lite a toujours été fourni sans X11.

votre avatar

Je crois qu’OMXPlayer est fournis de base mais sans GUI.

votre avatar







OlivierJ a écrit :



Normalement c’est après LA précédente, car plus tu remontes en arrière, moins tu retrouves de points communs. Ça remonterait à combien d’images en arrière, selon toi ?



Mais pourquoi on aurait besoin de stocker 30 images d’affilée ?



Honnêtement je ne pige pas ton histoire de résilience.





La norme H264 peut faire ses prédictions sur une profondeur de 32 images. Un tel flux n’est pas “temps réel”, mais pour un média en différé cela peut aider en particulier en présence d’images éclairées avec un éclairage stroboscopique.



Par résilience, j’entends que sur un OS non temps réel, il me semble difficile de garantir que l’on va lire quelques gigas pendant plusieurs heures sans jamais souffrir d’une coupure supérieure à une frame (env 1⁄30 sec) à partir d’un disque dur partagé par plusieurs autres applications. Pour y parvenir il faut des buffers.



Ajouté à cela la problématique du son, avec une volumétrie très inférieure, mais sur lequel nous entendons la moindre coupure. En cas de coupure, l’œil ou plutôt le cerveau extrapole les images manquantes ou ne remarque pas que l’image est figée, avec le son le moindre scratch est audible. Cela fait qu’il y a du buffering, sur les flux images et son, et enfin pour le décodage…


Raspbian mis à jour : accélération matérielle dans VLC, trois images différentes (lite, base, full)

  • Accélération matérielle dans VLC et petites retouches

  • Trois images pour mieux s'adapter aux besoins

Fermer