pour répondre au titre du post :

dans pdp il y a pdp_netsend qui permet d'envoyer des paquets non compressés... ça fonctionne bien, avec une latence d'une image constatée sur mon réseau local.

pour répondre à la première question du post :

pour une webcam, il y a aussi la solution mjpeg-streamer ( http://sourceforge.net/projects/mjpg-streamer/ )
ça permet de générer un flux mjpg qui ne consomme pratiquement pas de CPU (c'est la webcam qui encode) qui est lisible sur une adresse http, soit dans un browser soit dans vlc...
il est aussi scriptable dans un sens, et il y a une petite lib javascript pour la lecture voire l'analyse de mouvement des flux dans un navigateur...
à vrai dire je n'ai pas encore eut l'occasion de tenter d'inclure un stream mjpg de la sorte dans un patch PD mais nous ne manqueront pas de tester ça au prochain pd circle bxl
(je l'ai fait dans le blender game engine par contre il y a un bail)


gstreamer est très puissant, mais assez mal documenté.
"il faudrait" faire une bonne page bien complète avec les ressources disponibles et un tas de "recettes" toutes faites...
j'en ai quelques une, mais je crois pas être le seul

pour les archives, je colle ici une ligne gstreamer pour créer un flux ogg/theora (sans son) vers un serveur icecast (depuis mon RasPi) :

gst-launch-0.10 v4l2src device=/dev/video0 ! video/x-raw-yuv,width=320,height=240 ! ffmpegcolorspace ! theoraenc quality=1 ! oggmux !  shout2send ip=yourip port=8000 password=password mount=/test.ogg

citation :

gstreamer est très puissant, mais assez mal documenté.
"il faudrait" faire une bonne page bien complète avec les ressources disponibles et un tas de "recettes" toutes faites...

on avance, on avance ....  c'est vrai qu'une page ressources ou genre ... parce que la doc en effet ....
y'en a marre de bourrer l'historique du terminal avec des tas de lignes qui plantent
un gros plus de Gstreamer est sa relative légèreté .
pour les paresseux de la ligne de commande y'a çà  http://codelab.fr/3893 mais çà reste du graphe façon PD et la commande Gstreamer n'est pas "révélée" .

Dernière modification par sakramh (2013-01-07 17:44:44)

Bonjour a tous,

désolé je séterre un peu le post, mais j'ai trouvé une solution a mon probleme grace a la raspberry pi, et ayant un peu galéré je poste la solution que j'ai trouvé pour le moment, au cas ou ca en interresserait d'autre.

Du coup je suis parti sur l'utilisation de gstreamer avec une raspberrypi en wifi qui capte le flux dune webcam, et envoie le tout a mon eepc qui recupere le flux gstreamer et le fait passer dans un v4l2loopback, de facon a etre exploitable par puredata.

Je streame donc du 320*240  (ca me suffit pour ce que je veux faire, mais je pense qu'il doit y avoir moyen de faire un peu mieux), avec assez peu de latence (difficile a mesurer, mais je pense que c'est entre 0.5 et 1 seconde)

Pour Gstreamer, j'ai repris certains exemple du blog de nico largo www.blog.nicolargo.com, en les modifiant un peu pour utiliser le v4léloopback.

Sur la machine cliente (a lancer en premier) :
gst-launch-0.10 -v udpsrc port=1234 ! theoradec ! v4l2sink device=/dev/video1
Sur la pi
gst-launch -v v4l2src device=/dev/video0 ! ffmpegcolorspace ! videoscale method=1 ! video/xraw-yuv,width=320,height=240
! theoraenc bitrate=150 ! udpsink host=<IP_client> port=1234

Ce qui m'a surtout pris beaucoup de temps, c'est de comprendre pourquoi l'image recuperer par V4l2loopback était déformé.

Le probleme venait sans doute de la version de v4l2loopback (3.0) qui était packagé pour ma distribution ubuntu hardy.
Apres avoir compile la derniere version (6.0) du module v4l2loopback depuis le github https://github.com/umlaeute/v4l2loopback, tout marche bien.  (attention cependant, ce module ne peut pas etre compilé sur des noyaux inferiieur a 2.6).

il suffit d'un modprobe v4l2loopback pour charger le module v4l2loopback dans le noyau, ce qui crée la device virtuelle.


En esperant que ca puisse servir a quelqu'un.....