Salut à tous,

J'essaye de récupérer la video d'un sketch processing sous UbuntuStudio pour l'envoyer dans LPMT qui est un logiciel de projection mapping.
A l'aide d'un autre programme, v4l2loopback, il y a moyen de récupérer le flux d'un pipeline à l'aide de commande de ce type :
yuv4mpeg_to_v4l2 /dev/video1 < /tmp/pipe

Je ai seulement trouvé le moyen de récupérer un flux dans Processing à l'aide de Gstreamer, pas de l'envoyer.

Est-ce que je dois abandonner cette piste ?

Je suis pas du tout au fait avec processing mais pourquoi envoyer la sortie de ton vloopback dans un pipe ?
LPMT semble d'après ce que j'ai rapidement vu sur leur site pouvoir prendre des caméras donc un périphérique v4l2 (la sortie de ton /dev/video1) .
EDIT :
En fait en te relisant je comprends Processing vers un "Pipe" vers un périf. v4l2loopback vers LPMT . .
Là pour processing je sais pas trop mais ce que je sais c'est que j'ai essayé des manip. du genre .
gephex vers un "fifo" (named-pipe) >> sortie fifo vers un vloopback >>> vloopback vers Puredata .
Un des soucis c'est que le "pipe" est bloquant : il n'écrit que si le client est lancé en lecture et souvent réciproquement .
çà marche impec avec 2 instances de gephex celà dit .

Si il y a moyen de ne pas pas passer par v4l2loopback, c'est encore mieux.
Tu penses qu'il y a moyen en ligne de commande de sortir un sketch processing vers un /dev/video1 ?

Ben çà dépend du logiciel récepteur ... le plus simple étant un FIFO avec la restriction qu'il faut que le tuyau soit ouvert des 2 cotés .
sinon Gstreamer (avec ou sans v4l2 ) si le soft récepteur le permet .
J'ai un peu regardé hier du coté de MJPEG-Tools (basé sur des tuyaux aussi ) mais j'ai pas tout compris encore .
(je suis sur ce genre de problématique aussi : comment faire communiquer plusieurs softs de traitement entre eux sans monter une usine à gaz et en utilisant les outils existant (pas avoir à coder en dur soi même) . (j'arrive tout juste à hacker 2/3 lignes de bash ou c/c++ :rolleyes: ) .
Là hier il m'est venu (parce que çà doit pas être bien compliqué ) écrire un code tel que :

Ok merci

J'ai un peu aussi regarder du côté de processing pour enregistrer une image, l'ouvrir dans LPMT puis l'écraser à chaque nouvelle frame de Processing mais LPMT ne rafraichit pas les images donc le mieux pour moi serait une pipeline.

J'essaye ce soir et je te tiens au courant.

tu as essayé d'écrire dans un "FIFO" ?
tu lui donne un nom trompeur genre myfim.mpeg de façon que LPMT ne fasse pas trop la gueule .
Lancer le client lecteur(ici lmpt) avant l'écrivain .
Mais bien sûr cette fois envoyer un stream uyv4mpeg2 .

citation :

Lancer le client lecteur(ici lmpt) avant l'écrivain .

je rectifie :(
je viens de faire l'essai suivant (enfin concluant) :
1- lancement du soft qui génére un stream yuv4mpeg (chez moi Gephex) vers un FIFO (namedpipe) appelé movie.mpeg
2- vlc >> ouvrir un fichier >> movie.mpeg
3- çà marche !!!
4- ne PAS fermer vlc  avant le soft qui génère sinon il reçoit un SIGPIPE qui le bloque .
5- arrêter ou mettre en pause etc ... le générateur de stream avant donc ... en ce cas le lecteur reste sur la dernière image reçue et attends sagement que çà revienne .
6- essai concluant avec VLC, serait étonnant que pas avec un soft du genre . En ce cas engueuler les développeurs . :rolleyes:

EDIT AGAIN !!!
mouais çà marche pas à tous les coups en fait . (çà m'agace !!!)
en tout cas pas avec Mplayer .
Il doit y avoir un ordre précis à respecter mais j'arrive pas à trouver lequel .

Salut,

J'ai essayé pas mal de truc mais j'ai toujours la même erreure dans LPMT :
OF: OF_LOG_WARNING: GStreamer: cannot query time duration

** (LPMT:6352): WARNING **: gstvideo: failed to get caps of pad sink:sink
OF: OF_LOG_ERROR: GStreamer: cannot query width and height
deleting video player

après avoir créer une pipeline avec la comande suivante :
v4l2loopback-ctl set-caps "video/x-raw-yuv, width=200, height=200" /dev/video1
suivie de :
./mysketch >> /dev/video1

Il doit rester le truc avec le FIFO et la création du fichier mais je ne sais pas comment faire.

man mkfifo
#chezmoi
mkfifo /home/moi/film.mpeg

c'est un fichier vide qui fera toujours 0 octet . en fait il existe sur le système de fichier (ici mon disque) mais virtuellement .
c'est dans le kernel qu'il existe vraiment .
çà fonctionne mais c'est bloquant si un des cotés n'est pas ouvert ou se ferme .
Je cherche aussi une solution avec gstreamer . Je pense qu'il ne faut pas utiliser v4l2-ctl  ni v4l2vloopback-ctl .
Sauf à maîtriser entièrement .
Parce que çà fixe les propriétés  du /dev/videox pendant sa durée de vie .
Et que donc le pipeline Gstreamer ne fonctionnera pas si ses arguments ne sont pas exactement les mêmes .
Il m'a semblé qu'en lançant gst-launch ....! mes pipes ! et v4l2src ... ! mes pipes !.... cela initialise le vloopback avec les bon paramètres de size fps format .

Sinon on peut aussi créer un VRAI fichier /home/moi/movie.mpeg dans lequel on écrit vraiment .
çà çà roule . Mais le souci c'est que ce fichier grossit très vite avec un stream yuv4meg en 640x480 .
J'ai tenté de l'effacer (le vider) périodiquement avec un simple > movie.mpeg mais en ce cas le lecteur signale qu'il n'y a plus les headers .
Sinon si on laisse tourner sur un gros GROS GROS disque çà peut être une solution une heure ou deux .

j'imagine que tu as vu çà : https://github.com/umlaeute/gst-v4l2loopback

reste à trouver le moyen d'envoyer processing vers Gstreamer .

----exemples relevés sur  http://github.com/umlaeute/v4l2loopback/wiki----

citation :

--- FORCING FPS ---
$ v4l2loopback-ctl set-fps 25 /dev/video0
or
$ echo '@100' | sudo tee /sys/devices/virtual/video4linux/video0/format

--- FORCING A GSTREAMER (0.10) CAPS ---
$ v4l2loopback-ctl set-caps "video/x-raw-yuv, width=640, height=480" /dev/video0

--- SETTING STREAM TIMEOUT ---
$ v4l2-ctl -d /dev/video0 -c timeout=3000
(will output null frames by default)
$ v4l2loopback-ctl set-timeout-image service-unavailable.png /dev/video0
this currently requires GStreamer 0.10 installed

---- d'autre part----
j'ai compilé https://github.com/umlaeute/gst-v4l2loopback
( faire make install en tant que simple user et non root, çà sera installé dans /home/.gstreamer-0.10/plugins  et reconnu par gst-inspect )

du coup une commande du genre :

gst-launch videotestsrc ! videoscale ! video/x-raw-yuv,width=640,height=480 ! v4l2loopback device=/dev/video0

donne un résultat bien mieux lisible dans par exemple Gem ou VLC (pas de grosses barres vertes non décodées)
que la commande habituelle du genre:

gst-launch videotestsrc ! videoscale ! video/x-raw-yuv,width=640,height=480 ! v4l2sink device=/dev/video0

décidément va falloir ouvrir une rubrique GStreamer  :rolleyes:

OF: OF_LOG_WARNING: GStreamer: cannot query time duration

me laisse penser que LMPT s'attend à un fichier vidéo et non à un stream

Ben mon gars ! :)
grâce à toi et au développeur de v4l2loopback , gros succès ce jour ! :cool:

J'étais intrigué par ta commande yuv4meg_to_v4l2 < file . Je voyais vraiment pas de quel soft elle était tirée . J'avais cherché un peu partout (mjpeg-tools etc..)
Et puis en fouinant les sources de https://github.com/umlaeute/ je tombe dessus et tout s'éclaire .
Je compile le machin et je lance .

Donc si LMPT sait lire un périphérique V4L2 et Processing écrire dans un FIFO çà doit rouler .

note : juste un petit "loup" . Pas réussi à construire le module v4l2loopback sur le kernel 3.8 rt . Obligé de rester sur le 3.2 :(
et çà m'a permis de réviser mes notions de redirection, pipe sur Unix aussi .

et aussi cela s'affiche aussi avec un :

gst-launch v4l2src device=/dev/video0 ! xvimagesink

Tu veux parler de ce bug :
https://bugs.launchpad.net/ubuntu/+sour … ug/1112644

Tu sais si il vont le corriger rapidement ? C'est un problème du kernel ou de v4l2loopback ?

J'ai pas fouillé . Mais c'est bien le même bug . Affecte le kernel 3.8 x86-64 Debian aussi . J'ai la chance d'avoir gardé le 3.2 sur lequel le module s'est bien construit . Quand à la correction ... Debian va attendre celle Ubuntu et réciproquement .  Y'a même des chances que çà soit Ubuntu qui corrige en premier vu que le bug affecte les utilisateurs de "Skype" . :rolleyes:
Tu en en es où , toi ?
C'est que du bonheur ce petit utilitaire yuv4mpeg_to_v4l2 . Pas de latence, pas de bouffe ressources, et surtout pas de blocage du fifo quand un des 2 cotés est fermé .

Je suis passé sur ubuntuStudio 13.04 en effaçant ma 12.04,
donc la pour le moment j'attends que que le bug soit résolu.

Mais ça ne fait rien, le principale c'est que je sais que ça fonctionne
je peux envisager de concevoir mon projet avec ces outils.
En attendant il y a beaucoup d'autres choses à régler avant que ce ne soit fini.

hummm... çà fait un bout de temps que le bug est signalé . Il ne l'était pas chez Debian . Je viens de le faire .
En général dernière mouture de Ubuntu=Debian-Sid . Des fois c'est un peu ...chaud .

en fait il y'a eu deux nouvelles versions , mais comme ce module est en "urgency=low" personne n'a bougé .
Lesquelles ont fixé le problème avec les kernels >= 3.6
ici : http://packages.qa.debian.org/v/v4l2loopback.html

citation :

A new upstream version is available: 0.6.3 , you should consider packaging it.

ou sur le github branche experimental .
Bien dé-installer  tout ce qui pourrait trainer de v4l2loopback .
Juste faire $ make et # make install . A refaire à chaque nouvelle version de Kernel avec cette méthode .
Méthode pas très "debian way" mais vu que j'ai pas les sources dkms pour cette version ben çà attendra .
L'utilitaire v4l2loopback-ctl et la page de man seront pas installés non plus .
Mais le binaire de -ctl est contruit donc on peut tjs le lancer à partir du ./build tout comme les examples .

J'ai essayé comme tu as expliqué mais il fait freezer LMPT sans aucun message d'erreur.

J'ai installer la version 3.6 de v4l2loopback et voici toutes mes commandes.

sudo modprobe v4l2loopback devices=nb 
mkfifo /home/mathieu/test.mpeg
./yuv4mpeg_to_v4l2 /dev/video2 < /home/mathieu/test.mpeg & 
# qui indique  '[1] 6406' donc qui semble marcher
./myProcessingSketch >> /dev/video2

Je me rappelle quand j'ai compilé la version 3.6, j'ai eu ce message

A mon avis il n'est pas installé ou à moitié vu que je n'ai pas de répertoire /build.
Where is the bug ?

non c'est juste un WARNING . sans doute relatif à une façon pas très orthodoxe d'installer un module kernel
J'ai écrit ./build pour dire répertoire de construction .
Pour vérifier après

quand au freeze de LMPT , sais pas .
Y'a quand même un ordre logique .
1. charger le module dans le kernel
2. lancer sa commande yuv4mpeg_to_v4l2 ...
3. lancer son soft "WRITER"
4. lancer son (ses) soft "READER"
ordre inverse pour l'extinction (le process en fond yuv4mpeg_to_v4l2 se termine d'ailleurs à l'exticntion du "WRITER"
heu ...aussi bien sûr lancer les soft à partir d'un même endroit avec le chemin complet . Ou alors à partir de terminaux différents
note : un petit "sudo ldconfig" après "sudo make install" pour relister les lib .

Avec dmesg je ne trouve pas ces lignes :

[13695.563529] media: Linux media interface: v0.10
[13695.579894] Linux video capture interface: v2.00
[13695.589068] v4l2loopback driver version 0.6.3 loaded

tandis que "locate" affiche bien les 3 "v4l2loopback.ko"

J'ai essayé derécupérer le flux dans vlc, il ne plante pas mais affiche quand je le coupe l'erreure suivante :
[0x94ee448] main stream error: cannot pre fill buffer

Je me demande si processing écrit bien dans le flux /dev/video0
ou si v4l2loopback est bien installé.

Je répète ici car je reconnais n'avoir pas toujours été très clair .

!!!! Bien avoir dé installé  les paquets loopback, loopback-dkms, loopback-ctl (ensemble par synaptic)(celà enlève le module de l'arbre dkms) !!!!
Juste un doute là .
Tu as bien fait    :

make (en simple utilisateur)

puis  :

sudo make install

et pas tout d'un coup ?
remarque on peut faire make && sudo make install
mais c'est plus clair la première forme je trouve . (chaque chose en son temps)
ensuite :

 sudo ldconfig -v

ensuite :

locate v4l2loopback.ko

qui doit renvoyer :

/lib/modules/3.2.0-4-rt-amd64/extra/v4l2loopback.ko
/lib/modules/3.8-1-rt-amd64/extra/v4l2loopback.ko

selon les kernels pour lesquels la "lib" a été compilée .
ensuite :

sudo modprobe videodev

(optionnel , normalement c'est chargé au boot, si ta webcam intégrée est déjà là c'est pas la peine)
ensuite :

ensuite :

 dmesg

qui doit renvoyer dans les dernières lignes :

[13695.563529] media: Linux media interface: v0.10
[13695.579894] Linux video capture interface: v2.00
[13695.589068] v4l2loopback driver version 0.6.3 loaded

les n° seront pas forcément les mêmes .
si tout est bon tu peux compiler le yuv4mpeg_to_v4l2 et JOUJOU !

Je vais tenter LMPT pour voir quand j'aurais un peu de temps .

WOuahou ! je viens de voir ...

citation :

./myProcessingSketch >> /dev/video2

meuh non !!!

./myProcessingSketch >> monFIFO

et là au moins vlc devrait lire .
c'est LMPT qui va prendre un truc du genre --device /dev/videoX

J'ai bien avancé,

Tout comme toi v4l2loopback et  yuv4mpeg_to_v4l2 sont compilés
Mais lorsque je donne à vlc de regarder dans  dev/video1
j'ai cette erreure :

libv4l2: error getting pixformat: Argument invalide
[0xb09c0ec0] v4l2 access error: cannot set input 0: Invalid argument
libv4l2: error getting pixformat: Argument invalide
[0xb5301a18] main input error: open of `v4l2:///dev/video1' failed

Alors qu'il arrive à lire ma webcam.

essaie avec gstreamer

gst-launch v4l2src device=/dev/video1 ! xvimagesink

histoire de mettre hors cause vlc (ou non)

Même problème :

Il manque peut-être des infos au fichier .mpeg

Oui pas simple .
Dans gephex j'ai pas de soucis vu qu'il y a une boiboite qui code en YUV4MPEG2 .
Tout fonctionne .
Mais avec une autre source , par exemple un "videotestsrc" ou un "filesrc" dans un pipeline gstreamer , j'ai eu droit à un peu tout .
Un message de yuv4mpeg_to_v4l2 : headers malformed .
Des messages du pipe gstreamer "writer" pipeline éronné .
Des messages du pipe "reader"  Could not negotiate format   Check your filtered caps, if any
ai essayé d'inclure le plug y4menc idem ....
trouvé çà pour essayer de comprendre un peu mieux  http://www.metal3d.org/ticket/2012/08/1 … -gstreamer
pfff... pas grand chose nulle part .
Ce qui est sûr c'est que le flux qui est écrit dans le FIFO doit être conforme à yuv4mpeg .

Cela dit l'exemple dans le README de /v4l2loopback/examples/

fonctionne impec . Il faut donc trouver comment écrire un fichier.y4m sans monter une usine à gaz .
Si j'ai bien compris les headers doivent contenir la taille width et eight , le framerate et "jenesaisquoiencore"
(quelques indications dans le yuv4mpeg_to_v4l2.c) .
J'ai cherché avec google mais rien de clair .
Il n'y a pas une lib qui fait çà dans processing ?

Trouvé çà qui fonctionne

/home/sakramh/Sources/v4l2loopback_3.8/v4l2loopback-0.6.3/examples/yuv4mpeg_to_v4l2 /dev/video0 < /home/sakramh/fifo0 & sleep 2 && gst-launch-0.10 videotestsrc ! 'video/x-raw-yuv,format=(fourcc)I420,width=640,height=480,framerate=(fraction)25/1' ! y4menc ! filesink location=fifo0
## format=(fourcc)Y41B fonctionne aussi

pour le lecteur Mplayer ou Gstreamer car si VLC fonctionne il rame (pas copain avec le débit ou autre)

mplayer TV:// /dev/video0
## ou 
gst-launch v4l2src device=/dev/video0 ! xvimagesink

mais c'est inexploitable : la conversion en .y4m avec Gstreamer prend genre 20% de ressources + 10 % pour la conversion vers V4l2
Je vais tenter de comprendre la différence avec le stream de Gephex qui lui ne donne aucun travail à yuv4mpeg_to_v4l2
A y réfléchir , je pense qu'il vaudrait mieux , dans ton cas , inclure la conversion en stream lisible par LMPT dans ton code Java .
Sait pas si y'a des librairies pour çà ....

Assez incompréhensible : avec Gephex , sans l'intermédiaire de Gstreamer donc, VLC fonctionne impec (çà on savait ) mais donne exactement les mêmes infos : Codec Planar 4:2:0 YUV (I420)
idem dans Mplayer .
J'en déduit juste que le plug y4menc de Gstreamer fait pas bien son job ou que ma ligne ci-dessus c'est pas encore çà .

Ok je vais reagarder du côté de Java mais je pense que mes chances sont maigres.
Ce n'est pas grave je peux adapter mon projet, j'ai de nouvelles idées maintenant.

Merci pour ton aide

Je relaie ici ce post : http://codelab.fr/4276#p22891
Dans le lien il est question de bibliothèques pour créer des pipes GStreamer dans Processing
Paragraphe "Solutions logicielles pour réaliser du light painting en temps réel"