Voila je poste cette petite "astuce" tout en vous demandant votre aide :)
J'ai réussi a faire du streaming de tres bonne qualité grace a vlc tout en restant lisible sous windows et linux.
En comparant avec msn gnomemeeting et le reste c'est bien supérieur.
J'utilise cette solution, car pas de moi, fonctionnant à la fois pour les windowsiens.. et les linuxiens..
vlc v4l:/dev/video0:size=320x240 --sout #transcode{vcodec=WMV1, vb=180}:duplicate{dst=display,dst=standard{access=mmsh,mux=asfh,url=:1234}}' -v --noaudio
La commande est en une seule ligne ;)
vb est en kilobit à régler selon votre upload.
c'est accessible via cette url: mms://ip:1234
Vous allez me dire "wmv ca pu c'est pas libre", certes mais ca marche en attendant et ne pose pas de problème majeur aux personnes qui ne connaissent pas trop l'informatique, ils cliquent sur le lien et ca affiche votre webcam :)
Juste une question en passant window média player charge pratiquement instantanément le flux alors qu'en local xine prends sont temps (presque une minute) et le comble c'est que j'arrive pas à l'afficher avec vlc :(
Petit bémol un temps de latence persistant du à la compression vidéo et à l'upload.
Bon comme vous aurez pu le constater c'est du TCP/IP.. pas toujours tip top pour du stream, j'ai désespérément chercher une solution avec l'udp mais en vain :( . La doc sur le sujet est un peu flou. Si quelqu'un pouvait nous montrer un exemple en udp marchant de vlc à vlc (commandes client/serveur svp), en précisant que le broadcasting est à exclure puisque le but est de fonctionné avec n'importe quel client sur internet :)
Le second désavantage c'est que d'après ce que j'ai compris l'encapsulation mms ne permet pas de protéger votre flux par mot de passe. Pour ce faire faut passer par un stream en http et le mot de passe est configurable dans le menu de configuration dans l'interface graphique (j'ai pas trouvé la ligne de commande correspondante). A priori un seul user est configurable, mais la encore rien de sur.
Donc si quelqu'un pouvait partager ses trouvailles avec vlc ca serait bien.
J'ai vu qu'un programme manipulait le v4l et permettait d'ajouter des effets spéciaux assez marrant... à priori ca marche pour les noyau 2.6.X
EffecTV: http://effectv.sourceforge.net(...)
vloopback: http://www.lavrsen.dk/twiki/bin/view/Motion/VideoFourLinuxLoopbackD(...)
NB: Je n'ai pas encore la dernière version de vlc.
Idée pour les devs de clients Jabber: Inclure cette méthode dans un plugin pour les clients Jabber (lance vlc en fond et envoie l'url à notre correspondant doit pas être si difficile mais par manque de temps) ca aurait l'avantage d'être portable.
à vos vlc ;)
Have fun
# Doc un peu floue > vision mal adaptée ?
Posté par symoon . Évalué à 8.
http://www.videolan.org/doc/videolan-howto/fr/(...)
Si quelqu'un pouvait nous montrer un exemple en udp marchant de vlc à vlc (commandes client/serveur svp)
Serveur : http://www.videolan.org/doc/videolan-howto/fr/ch09.html(...)
Affichez le flux, et envoyez le sur deux adresses IP unicast :
% vlc -vvv input_stream --sout '#duplicate{dst=display,dst=
standard{access=udp,mux=ts,url=192.168.1.12},
dst=standard{access=udp,mux=ts,url=192.168.1.42}}'
Client : http://www.videolan.org/doc/videolan-howto/fr/ch03.html(...)
Recevez un flux unicast
% vlc -vvv udp:
Ce n'est pas "à la demande", c'est à dire que tu enverras le flux même si la personne n'a pas fait la requête. Ou sinon utilises RTSP comme indiqué dans la doc.
[^] # Re: Doc un peu floue > vision mal adaptée ?
Posté par ~ lilliput (site web personnel) . Évalué à 1.
quand au RTSP j'ai pas compris l'exemple
vlc -vvv input_stream --sout '#rtp{dst=192.168.0.12,port=1234,sdp=http://server.example.org:8080/test.sdp(...)}'
http://server.example.org:8080/test.sdp(...) ca correspond a http://IP_LOCAL:PORT/fichier_virtuel.sdp(...) lien que je dois donner a mon correspondant c ca ?
est ce toujours de l'udp ?
http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk
[^] # Re: Doc un peu floue > vision mal adaptée ?
Posté par Marc (site web personnel) . Évalué à 1.
UDP reste quand même plus adapté à ce genre d'applications que TCP. Evidement, quand UDP n'est pas permis...
[^] # Re: Doc un peu floue > vision mal adaptée ?
Posté par Marc (site web personnel) . Évalué à 2.
RTSP ne transporte pas la video ou l'audio, c'est RTP qui s'en charge. Et RTP en général, c'est de l'UDP (UDP reste plus adapté à ce genre d'application que TCP).
J'avais regardé un peu qui savait faire du RTSP et ai mis ça dans un (très) rapide résumé (super court):
http://www.kataplop.net/pafpifpouf.py?s=stream(...)
[^] # Re: Doc un peu floue > vision mal adaptée ?
Posté par ~ lilliput (site web personnel) . Évalué à 1.
Juste pour préciser que pour l'udp j'ai essayé avec un pote à plusieurs reprise. Etant donné que je fait mes études à l'étranger, j'ai fait pas mal de teste avec l'udp.. mais en vain. Donc j'aimerai savoir si quelqu'un avait réussi à faire fonctionner vlc avec la contrainte des passerelles (une redirection de ports d'un des deux gateway est obligatoire)
Merci d'avance
http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk
# Solution pour l'usb
Posté par ~ lilliput (site web personnel) . Évalué à 1.
X.X.X.X est la persone a qui je veux envoyé le stream
Y.Y.Y.Y est son ip de sous rezo
les minuscules sont le numéro de ports
le gateway doit rediriger le flux arrivant en X.X.X.X:xxxx sur Y.Y.Y.Y:yyyy
émeteur
vlc v4l:/dev/video0:size=320x240 --sout '#transcode{vcodec=mp4v,scale=1,vb=120}:std{access=udp,mux=ts,url=X.X.X.X:xxxx}' -v --noaudio --sout-udp-ttl 50
récepteur
vlc udp://@Y.Y.Y.Y:yyyy
C'est un stream unicast bon ce qui est pas super c'est que c'est la personne qui recoit le stream qui doit ouvrir ses ports...
Et puis pour l'émetteur, il emet même quand la personne ne lit pas.
Sinon petite amélioriation par rapport au delay.
http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.