Suite à ce fil http://codelab.fr/4242#p22720 j'ai le plaisir d'annoncer qu'il est de nouveau possible de router vers un vloopback .
En effet depuis le kernel 2.6.39 impossible de compiler le module vloopback (version v4l1) et impossible de lire ou écrire dans le module v4l2loopback même avec un
export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libv4l/v4l2convert.so #et/ou export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libv4l/v4l1compat.so
sur Debian installer le module v4l2loopback (doit y avoir un bug dkms avec le kernel 3.8, çà veut pas donc le faire avec un 3.2) *
récupérer les sources ici juste pour compiler l'utilitaire yuv4mpeg_to_v4l2 : https://github.com/umlaeute/v4l2loopback
preuve par l'image:
note*: le module a été mis à jour depuis
Dernière modification par sakramh (2015-01-26 11:52:36)
Hors ligne
avec Gstreamer excellente , VLC met en tampon 0.3s donc au total y'a bien pas loin de la seconde . Pd-extended pas mal mais pas encore quantifié .
ce que je peux dire déjà c'est que c'est beaucoup plus rapide qu'une webcam .
l'utilitaire yuv4mpeg_to_v4l2 bouffe presque rien en ressources : 1% de 1 coeur soit 0.25 % d'un quadri à 3Ghz .
Dernière modification par sakramh (2013-05-11 18:03:29)
Hors ligne
à vue de nez moins d'une demie seconde avec GEM/pix_video.help.pd . Rien de gênant .
Bip-bip .... le coyotte n'a qu'à bien se tenir
mais la maison décline toute responsabilité si vous n'avez pas installé un GROS ventilateur supplémentaire .
Gare au cpu qui brûle !!!
Dernière modification par sakramh (2013-05-12 00:35:39)
Hors ligne
En fait niveau latence çà semble pas mesurable à l'oeil . Genre : ainsyphon phon phon les petits 4l2loopback (air connu) ....
Sans compter le temps de réaction/traitement des softs , les mises en tampon etc ...
Quand j'aurais le courage je ferai une petite video avec une série d'images genre un décompte . Pour quantifier la latence en images (à 25fps)
Dernière modification par sakramh (2013-05-12 23:06:14)
Hors ligne
Hors ligne
sakramh a écrit:
Gare au cpu qui brûle !!!
C'est quasi-la même chose que syphon sur mac, c'est bien ça (et on l'a encore une fois eu bien avant, dommage que ça soit tombé dans les limbes) ? Ça bouffe autant de ressources sur un ordi pomme ? Parce qu'effectivement, d'après mes souvenirs, c'est vraiment pas anodin question cpu...
Hors ligne
Non non charger le module v4l2loopback (avec autant de devices que l'on veut) dans le kernel ne prend absolument aucune ressource (si ce n'est un tout petit peu de mémoire) .
Un "FIFO" rien non plus de par son principe .
Quand à l'utilitaire yuv4mpeg_to_v4l2 comme écrit ci-dessus çà consomme environ 0.25 % d'un quadri coeur cadencé à 2.88 GHz .
J'ai écrit gare au cpu qui brule parce que c'est trop tentant de chaîner quatre applications bien lourdes .
Type gephex dans processing dans pd-extended dans ffmpeg ou Gstreamer .
En fait le module a été écrit et packagé depuis plus de 3 ans (depuis l'exclusion de v4l1 du kernel) en remplacement d'un module semblable qui existait lui depuis les kernel 2.4 et dont je me servais beaucoup pour contourner les problèmes liés aux FIFO .
Là c'est juste que le développeur a écrit en plus un petit utilitaire caché aux fond de ses sources .
Et si j'avais pas peur d'ennuyer sa boite à lettre je me fendrai d'un grand merci !
Dernière modification par sakramh (2013-05-15 09:43:34)
Hors ligne
dwan a écrit:
sakramh a écrit:
Gare au cpu qui brûle !!!
C'est quasi-la même chose que syphon sur mac, c'est bien ça (et on l'a encore une fois eu bien avant, dommage que ça soit tombé dans les limbes) ?
non pas vraiment syphon attaque directement la carte graphique et son framebuffer. Le partage ne passe donc pas par le CPU dans le cas de syphon, c'est pour ça que ça arrache grave...
Hors ligne
merci des précisions les gens !
Hors ligne
un petit outil rudimentaire pour mesurer la latence d'un soft à l'autre en p.j.
chez moi moins de une image à 25 fps entre gephex et pd-extended et mplayer .
Hors ligne