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(a)lists.linux-azur.org https://lists.linux-azur.org/mailman/listinfo/linux06