Hey,
Le 14/08/2015 17:05, Vincent BRACH a écrit :
hum; pas pour mettre en avant vlc (je ne sais même pas si ce que je dit va fonctionner) mais sur la distro que j'utilise (mageia pour ne pas la nommer) le "moteur"/backend multimédia était historiquement gstreamer;
Ok, attention toutefois il y a des grosses différences (et outils disponibles ou non) entre les distro "classiques" pour PC et les distro embarqué (qui là est un ptxdist pour ne pas le nommer :) ) sur lesquels il n'y a pas forcément tout de disponible.
Oui, et ici ce n'est même pas une question de distribution. En réalité il est question de Phonon (le framework multimédia de KDE4) qui fournit une API d'abstraction pour xine, GStreamer et VLC par exemple. Sous Mageia on peut donc installer soit phonon-vlc soit phonon-gstreamer lorsqu'on installe une application utilisant Phonon (on peut aussi choisir manuellement phonon-xine). En revanche il est vrai que depuis Mageia 5, le paquet installé par défaut lorsqu'on installe le bureau KDE4 est phonon-vlc, en remplacement de phonon-gstreamer. Cela ne change rien pour l'utilisateur.
Ensuite si vlc "sait faire" (ce qu'il reste en effet à confirmer) et lance un gstreamer derrière il me suffirait peut-être simplement de voir comment vlc lance gstreamer (avec quelles options de ligne de commande) et de le lancer de la même manière (uniquement gstreamer) sur la cible.. À voir, mais ça peut être une bonne piste, merci pour l'idée !
Au délà de cette particularité qu'a KDE4 à proposer ce choix, les autres applications sont conçus pour utiliser un framework particulier. D'ailleurs, VLC peut reposer sur FFmpeg pour certains traitement, il sait aussi utiliser directement certaines bibliothèques, mais n'est pas conçu pour utiliser GStreamer. Sinon on peut tout à fait lancer VLC en ligne de commande avec `cvlc` (il devrait pouvoir se compiler sans interface graphique). Il peut lire le framebuffer et générer un stream, mais il y a peu de chance qu'on puisse faire de l'encodage matériel avec. (je pense que sur ta plateforme il n'existe pas de bibliothèque prise en charge par VLC) On peu utiliser aussi FFmpeg, mais ça sera probablement le même résultat que VLC (avec moins de dépendances en revanche).
En tout cas c'est sur que je préfèrerais utiliser "uniquement" gstreamer qui est déjà (bien) cross-compilé et présent sur la cible ARM : cela simplifierait énormément la tâche et la charge de travail...
Je ne m'y connais pas vraiment en GStreamer, mais cette commande permet au moins d'enregistrer ce qui passe dans le framebuffer :
gst-launch-1.0 -v multifilesrc location=/dev/fb0 ! videoparse format="rgbx" width=1280 height=720 framerate=75906/1000 ! decodebin ! videoconvert ! jpegenc ! queue ! avimux name=mux ! filesink location=test.avi
Avec évidemment certains paramètres à adapter pour la configuration du framebuffer. Voir http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/section-ty... pour le paramètre format (à mettre en minuscule). Ici on encode bien en MJPEG et on enregistre ça dans un conteneur AVI (on pourrait aussi envoyer un flux RTSP). En revanche, il y'a plusieurs désavantages: Pas d'encodage matériel, donc des performances minables. Dans ta commande tu utilisais le plugin `vpuenc` qui semble faire de l'encodage matériel sur ta plateforme, en h264, donc évidemment ça ne demande quasiment rien au CPU. Je viens de tester l'encodage MJPEG sur un Atom, je dois même pas sortir du 1 FPS. De ce que vois d'une certaine documentation ( https://community.freescale.com/docs/DOC-93447 ), on peut encoder en MPEG-4, H.263, H.264, et MJPG, respectivement codec=0, 5, 6 ou 12. À tester sur ton matériel. Vidéo désynchronisée, donc on se retrouve avec des frames désordonnées. Vu que l'encodage est très lent, il faut peut être ajouter un buffer en entrée.
-- //piernov