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