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 .

Dernière modification par sakramh (2013-05-07 15:40:59)

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++ ) .
Là hier il m'est venu (parce que çà doit pas être bien compliqué ) écrire un code tel que :

Dernière modification par sakramh (2013-05-08 11:09:02)

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 .

Dernière modification par sakramh (2013-05-09 15:55:10)

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 .

Dernière modification par sakramh (2013-05-08 15:47:55)

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 .

Dernière modification par sakramh (2013-05-08 23:35:06)

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

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

Dernière modification par sakramh (2013-05-11 11:28:24)

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" .
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é .

Dernière modification par sakramh (2013-05-13 18:18:09)