Bonjour la liste,
Je me demandais si dans la "salle" il y avait des spécialistes (ou bons connaisseurs) de l'outil gstreamer (http://gstreamer.freedesktop.org/ / https://fr.wikipedia.org/wiki/GStreamer / http://nicolargo.developpez.com/tutoriels/audio/gstreamer-theorie/).
En réalité voici mon besoin : J'ai une cible embarquée à base d'un processeur ARM i.MX6 (DualCore), équipée d'un écran tactile, sur lequel nous affichons une application IHM (en JAVA avec Xfbdev, c'est à dire X sur framebuffer) pour le conducteur d'une machine de chantier (je n'en dit pas plus, ceux qui me connaissent auront trouvé de quoi je parle ;)).
Nous avons besoin de générer un flux vidéo sur lien Ethernet (pour transmission à distance), reflétant exactement ce qui est affiché à l'écran (en gros une copie du framebuffer en instantané). Ce flux doit être généré aux formats RTP/RTSP (un standard donc dans le monde du "video streaming protocol" où je suis plus que novice) et répondre à la norme ONVIF (www.onvif.org http://www.onvif.org ) et plus particulièrement ONVIF Profil S.
Je n'ai pas encore bien avancé sur le sujet ONVIF, mais je sais déjà que la distribution Linux sur ma cible ARM contient déjà gstreamer et tout les outils associés (gst-inspect, etc) ainsi que de nombreux plugins (peut-être pas tous, mais facilement re-cross-compilables).
Le besoin serait donc d'avoir en "entrée" l'exact copie de la mémoire framebuffer (ce qui est donc affiché à l'écran) et de générer un flux vidéo encodé en mjpeg de préférence (moins lourd en compression qu'un format H264 de meilleur qualité, mais demandant plus de ressources). Le "rafraîchissement" vidéo demandé est très faible (maximum 5 images par secondes).
Je suis déjà parvenu à faire tourner sur la cible un gst-launch (v0.10) en générant une mire de test (plugin "videotestsrc") et l'afficher avec un gst-launch côté PC hôte (Ubuntu). Sur la cible (ARM) je lance la commande suivante : gst-launch-0.10 videotestsrc ! vpuenc codec=6 ! queue ! rtph264pay ! udpsink host=192.168.6.3 -v Sur le PC hôte la commande suivante : gst-launch udpsrc port=4951 ! "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, sprop-parameter-sets=(string)"Z0JAFKaBQfkA\,aM4wpIAA", payload=(int)96, ssrc=(uint)3107460846, clock-base=(uint)2578035245, seqnum-base=(uint)11130" ! rtph264depay ! queue ! ffdec_h264 ! xvimagesink sync=false -v
Jusque là ça fonctionne bien, je pense que je génère donc un flux compressé en H264, lu de l'autre côté en UDP, et ça ne prends "que" 9% du CPU côté ARM ce qui est tout à fait acceptable.
Mais je ne parviens pas à "prendre" comme source d'entrée le framebuffer. Et je ne suis pas très à l'aise avec les plugins et les pipeline pour bien comprendre comment cela fonctionne... J'ai tenter avec des plugins comme "multifile" ou "v4l" avec comme point d'entrée /dev/fb0 (le framebuffer donc) mais sans succès... Idem pour la compression en mjpeg (plutôt que H264).
Quelqu'un aurait-il une solution à mon problème et peut-être de bon liens/tutoriaux de gstreamer "pour les nuls" car pour le moment tout ce que j'ai pu lire sur le WEB est assez complexe et je patauge un peu...
En vous remerciant,
À bientôt,
Vincent BRACH
Le 14/08/2015 14:51, Vincent BRACH a écrit :
Bonjour la liste,
Je me demandais si dans la "salle" il y avait des spécialistes (ou bons connaisseurs) de l'outil gstreamer (http://gstreamer.freedesktop.org/ / https://fr.wikipedia.org/wiki/GStreamer / http://nicolargo.developpez.com/tutoriels/audio/gstreamer-theorie/).
En réalité voici mon besoin : J'ai une cible embarquée à base d'un processeur ARM i.MX6 (DualCore), équipée d'un écran tactile, sur lequel nous affichons une application IHM (en JAVA avec Xfbdev, c'est à dire X sur framebuffer) pour le conducteur d'une machine de chantier (je n'en dit pas plus, ceux qui me connaissent auront trouvé de quoi je parle ;)).
Nous avons besoin de générer un flux vidéo sur lien Ethernet (pour transmission à distance), reflétant exactement ce qui est affiché à l'écran (en gros une copie du framebuffer en instantané). Ce flux doit être généré aux formats RTP/RTSP (un standard donc dans le monde du "video streaming protocol" où je suis plus que novice) et répondre à la norme ONVIF (www.onvif.org http://www.onvif.org ) et plus particulièrement ONVIF Profil S.
Je n'ai pas encore bien avancé sur le sujet ONVIF, mais je sais déjà que la distribution Linux sur ma cible ARM contient déjà gstreamer et tout les outils associés (gst-inspect, etc) ainsi que de nombreux plugins (peut-être pas tous, mais facilement re-cross-compilables).
Le besoin serait donc d'avoir en "entrée" l'exact copie de la mémoire framebuffer (ce qui est donc affiché à l'écran) et de générer un flux vidéo encodé en mjpeg de préférence (moins lourd en compression qu'un format H264 de meilleur qualité, mais demandant plus de ressources). Le "rafraîchissement" vidéo demandé est très faible (maximum 5 images par secondes).
Je suis déjà parvenu à faire tourner sur la cible un gst-launch (v0.10) en générant une mire de test (plugin "videotestsrc") et l'afficher avec un gst-launch côté PC hôte (Ubuntu). Sur la cible (ARM) je lance la commande suivante : gst-launch-0.10 videotestsrc ! vpuenc codec=6 ! queue ! rtph264pay ! udpsink host=192.168.6.3 -v Sur le PC hôte la commande suivante : gst-launch udpsrc port=4951 ! "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, sprop-parameter-sets=(string)"Z0JAFKaBQfkA\,aM4wpIAA", payload=(int)96, ssrc=(uint)3107460846, clock-base=(uint)2578035245, seqnum-base=(uint)11130" ! rtph264depay ! queue ! ffdec_h264 ! xvimagesink sync=false -v
Jusque là ça fonctionne bien, je pense que je génère donc un flux compressé en H264, lu de l'autre côté en UDP, et ça ne prends "que" 9% du CPU côté ARM ce qui est tout à fait acceptable.
Mais je ne parviens pas à "prendre" comme source d'entrée le framebuffer. Et je ne suis pas très à l'aise avec les plugins et les pipeline pour bien comprendre comment cela fonctionne... J'ai tenter avec des plugins comme "multifile" ou "v4l" avec comme point d'entrée /dev/fb0 (le framebuffer donc) mais sans succès... Idem pour la compression en mjpeg (plutôt que H264).
Quelqu'un aurait-il une solution à mon problème et peut-être de bon liens/tutoriaux de gstreamer "pour les nuls" car pour le moment tout ce que j'ai pu lire sur le WEB est assez complexe et je patauge un peu...
En vous remerciant,
À bientôt,
Vincent BRACH _______________________________________________ Linux06 mailing list Linux06@lists.linux-azur.org https://lists.linux-azur.org/mailman/listinfo/linux06
Je ne sais pas si cela va aider mais si vlc à été porté sur ta plateforme il fait cela trés bien. ( choix de l'entrée, de la sortie video, des codecs à utilser et support rtp/rtsp (aussi avec des plugins)
JPB
Re bonjour la liste et bonjour JPB,
Je ne sais pas si cela va aider mais si vlc à été porté sur ta plateforme il fait cela trés bien. ( choix de l'entrée, de la sortie video, des codecs à utilser et support rtp/rtsp (aussi avec des plugins)
JPB
Disons que vlc serait "portable" (avec un gros effort tout de même) sur ma plateforme, mais ne convient pas je pense au besoin : Petite précision nécessaire : je cherche une solution autonome, en ligne de commande (pas avec une interface graphique utilisateur).
La fonctionnalité de générer ce flux vidéo en RTP doit être totalement transparente pour l'utilisateur de l'appareil. Il ne doit pas avoir à lancer un logiciel particulier pour que cette fonctionnalité soit présente, il n'y a d'ailleurs aucun gestionnaire de session ou de fenêtrage sur cette cible sur l'écran (uniquement notre IHM en plein écran).
Donc je ne pense pas que vlc qui fait beaucoup (presque trop) de choses par rapport au besoin soit la bonne solution.
Je pense que gstreamer est vraiment LA solution , mais ne connais pas assez ses méandres...
Merci en tout cas JPB pour la réponse.
Vincent BRACH
VLC est entièrement pilotable en ligne de commande shell.
Knut BORSI
Le 14 août 2015 à 16:17, Vincent BRACH v.brach@smie.com a écrit :
Re bonjour la liste et bonjour JPB,
Je ne sais pas si cela va aider mais si vlc à été porté sur ta plateforme il fait cela trés bien. ( choix de l'entrée, de la sortie video, des codecs à utilser et support rtp/rtsp (aussi avec des plugins)
JPB
Disons que vlc serait "portable" (avec un gros effort tout de même) sur ma plateforme, mais ne convient pas je pense au besoin : Petite précision nécessaire : je cherche une solution autonome, en ligne de commande (pas avec une interface graphique utilisateur).
La fonctionnalité de générer ce flux vidéo en RTP doit être totalement transparente pour l'utilisateur de l'appareil. Il ne doit pas avoir à lancer un logiciel particulier pour que cette fonctionnalité soit présente, il n'y a d'ailleurs aucun gestionnaire de session ou de fenêtrage sur cette cible sur l'écran (uniquement notre IHM en plein écran).
Donc je ne pense pas que vlc qui fait beaucoup (presque trop) de choses par rapport au besoin soit la bonne solution.
Je pense que gstreamer est vraiment LA solution , mais ne connais pas assez ses méandres...
Merci en tout cas JPB pour la réponse.
Vincent BRACH _______________________________________________ Linux06 mailing list Linux06@lists.linux-azur.org https://lists.linux-azur.org/mailman/listinfo/linux06
Re bonjour,
Le 14/08/2015 16:48, Sappas a écrit :
VLC est entièrement pilotable en ligne de commande shell.
Knut BORSI
Oui mais peut-il se lancer sans lancer l'interface graphique ? Il ne faudrait pas que la GUI de vlc apparaisse à l'écran...
Merci Knut pour cette réponse.
Vincent BRACH
Le 14/08/2015 16:17, Vincent BRACH a écrit :
Re bonjour la liste et bonjour JPB,
Je ne sais pas si cela va aider mais si vlc à été porté sur ta plateforme il fait cela trés bien. ( choix de l'entrée, de la sortie video, des codecs à utilser et support rtp/rtsp (aussi avec des plugins)
JPB
Disons que vlc serait "portable" (avec un gros effort tout de même) sur ma plateforme, mais ne convient pas je pense au besoin : Petite précision nécessaire : je cherche une solution autonome, en ligne de commande (pas avec une interface graphique utilisateur).
La fonctionnalité de générer ce flux vidéo en RTP doit être totalement transparente pour l'utilisateur de l'appareil. Il ne doit pas avoir à lancer un logiciel particulier pour que cette fonctionnalité soit présente, il n'y a d'ailleurs aucun gestionnaire de session ou de fenêtrage sur cette cible sur l'écran (uniquement notre IHM en plein écran).
Donc je ne pense pas que vlc qui fait beaucoup (presque trop) de choses par rapport au besoin soit la bonne solution.
Je pense que gstreamer est vraiment LA solution , mais ne connais pas assez ses méandres...
Merci en tout cas JPB pour la réponse.
Vincent BRACH _______________________________________________ Linux06 mailing list Linux06@lists.linux-azur.org https://lists.linux-azur.org/mailman/listinfo/linux06
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; il y a eu une phase transitoire ou l'on pouvais choisir entre gstreamer et vlc; maintenant le défaut est vlc et les fontionnalités de vlc sont accessibles en ligne de commande. j'ais déjà utiliser le forum avec succès: http://www.videolan.org/support/ et la doc est dispo à: http://www.videolan.org/doc/
JPB
Re,
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.
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 !
il y a eu une phase transitoire ou l'on pouvais choisir entre gstreamer et vlc; maintenant le défaut est vlc et les fontionnalités de vlc sont accessibles en ligne de commande.
Je vais regarder ce qui est jouable avec vlc comme input=framebuffer et output=flux RTP en MJPEG avant de me lancer dans l'aventure d'une cross compilation de vlc.
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...
j'ais déjà utiliser le forum avec succès: http://www.videolan.org/support/ et la doc est dispo à: http://www.videolan.org/doc/
Ok super merci JPB pour ces liens.
JPB
Vincent BRACH
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
Le 14/08/2015 17:55, piernov a écrit :
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.
oui c'est vrai que je n'ais pas pensé à la couche phonon qui n'a aucune raison d'être disponible sur cette sorte d'environnement; merci pour la précision.
JPB
-
jpb -
piernov -
Sappas -
Vincent BRACH