Je cherche depuis un petit moment, et je me dis qu'il y a peut-être ici
quelqu'un connaissant une solution.
Je cherche à "exporter" (par analogie au DISPLAY pour X) le son d'un
micro intégré de webcam, de façon _simple_ (c'est à dire sans rentrer
dans une usine à gaz).
Pour la vidéo seule, je peux faire un stream simplement par mjpg_stream
qui fonctionne très bien pour mon besoin, ou encore par ssh -Y :
mplayer tv:// -tv driver=v4l2:width=640:height=480:fps=25:device=/dev/
video0
Je cherche maintenant à inclure le son, qui lui, à ma connaissance, n'est
pas "exporté".
Je peux enregistrer le son par arecord -D default
Je peux aussi enregistrer vidéo+audio avec :
mencoder tv:// -tv driver=v4l2:width=640:height=480:fps=25:device=/dev/
video0:forceaudio:alsa=1:adevice=default -ovc lavc -oac mp3lame -lameopts
cbr:br=64:mode=3 -o
Donc mon problème n'est pas dans la récupération des flux mais dans leur
export, si possible, ensemble, au pire, séparément.
Ça parle à quelqu'un ?
Dans tous les cas, je poursuis mes recherches.
Christophe PEREZ , dans le message <jnsolu$8mc$, a écrit :
Mais pour le 1) $! ne renvoie pas le PID, donc je dois passer par un ps grep etc... Par contre, quand je tue le process ssh, j'ai toujours mon process mplayer qui reste tourner sur l'autre machine (alors que la fenêtre s'est bien fermée)
Ça me paraît très suspect : si sa fenêtre a été fermée brutalement, mplayer aurait dû être tué par les fonctions de la Xlib. Quelle versions de mplayer est-ce exactement ?
Au fait, as-tu pensé au « < /dev/null » ? MPlayer, par défaut, lit sur son entrée standard, ça peut perturber des choses s'il est lancé en arrière plan.
J'ai essayé en virant le -f de ssh en rajoutant le & en fin, et en récupérant le PID par $!, mais le résultat est le même.
Si tu n'as pas de mot de passe à saisir pour te connecter, il vaut mieux faire la mise en arrière plan par le shell que par le client ssh.
Christophe PEREZ , dans le message <jnsolu$8mc$1@serveur1.novazur.fr>, a
écrit :
Mais pour le 1) $! ne renvoie pas le PID, donc je dois passer par un ps
grep etc... Par contre, quand je tue le process ssh, j'ai toujours mon
process mplayer qui reste tourner sur l'autre machine (alors que la
fenêtre s'est bien fermée)
Ça me paraît très suspect : si sa fenêtre a été fermée brutalement, mplayer
aurait dû être tué par les fonctions de la Xlib. Quelle versions de mplayer
est-ce exactement ?
Au fait, as-tu pensé au « < /dev/null » ? MPlayer, par défaut, lit sur son
entrée standard, ça peut perturber des choses s'il est lancé en arrière
plan.
J'ai essayé en virant le -f de ssh en rajoutant le & en fin, et en
récupérant le PID par $!, mais le résultat est le même.
Si tu n'as pas de mot de passe à saisir pour te connecter, il vaut mieux
faire la mise en arrière plan par le shell que par le client ssh.
Christophe PEREZ , dans le message <jnsolu$8mc$, a écrit :
Mais pour le 1) $! ne renvoie pas le PID, donc je dois passer par un ps grep etc... Par contre, quand je tue le process ssh, j'ai toujours mon process mplayer qui reste tourner sur l'autre machine (alors que la fenêtre s'est bien fermée)
Ça me paraît très suspect : si sa fenêtre a été fermée brutalement, mplayer aurait dû être tué par les fonctions de la Xlib. Quelle versions de mplayer est-ce exactement ?
Au fait, as-tu pensé au « < /dev/null » ? MPlayer, par défaut, lit sur son entrée standard, ça peut perturber des choses s'il est lancé en arrière plan.
J'ai essayé en virant le -f de ssh en rajoutant le & en fin, et en récupérant le PID par $!, mais le résultat est le même.
Si tu n'as pas de mot de passe à saisir pour te connecter, il vaut mieux faire la mise en arrière plan par le shell que par le client ssh.
Christophe PEREZ
Le Thu, 03 May 2012 07:35:59 +0000, Nicolas George a écrit :
Ça me paraît très suspect : si sa fenêtre a été fermée brutalement, mplayer aurait dû être tué par les fonctions de la Xlib. Quelle versions de mplayer est-ce exactement ?
Je ne l'ai pas sous les yeux mais c'est la dernière à jour sous Gentoo.
Au fait, as-tu pensé au « < /dev/null » ? MPlayer, par défaut, lit sur son entrée standard, ça peut perturber des choses s'il est lancé en arrière plan.
Euh, j'avoue ne pas y avoir pensé, non, mais j'avoue aussi ne pas trop savoir ou mettre ça dans ma commande ;) qui est : ssh -Y ${IPHOST} "mplayer -really-quiet -fps 15 tv:// -tv driver=v4l2:widthd0:heightH0:device=/dev/video0 2>&1 >/dev/null" &
Je suppose un peu n'importe où, mais je ne peux pas encore tester.
Si tu n'as pas de mot de passe à saisir pour te connecter, il vaut mieux faire la mise en arrière plan par le shell que par le client ssh.
C'est ce que j'avais cru comprendre. Merci de me l'avoir confirmé.
Je reviens quand j'aurai pu tester le < /dev/null mais je ne voulais pas laisser ton post sans réponse trop longtemps :D
Le Thu, 03 May 2012 07:35:59 +0000, Nicolas George a écrit :
Ça me paraît très suspect : si sa fenêtre a été fermée brutalement,
mplayer aurait dû être tué par les fonctions de la Xlib. Quelle versions
de mplayer est-ce exactement ?
Je ne l'ai pas sous les yeux mais c'est la dernière à jour sous Gentoo.
Au fait, as-tu pensé au « < /dev/null » ? MPlayer, par défaut, lit sur
son entrée standard, ça peut perturber des choses s'il est lancé en
arrière plan.
Euh, j'avoue ne pas y avoir pensé, non, mais j'avoue aussi ne pas trop
savoir ou mettre ça dans ma commande ;) qui est :
ssh -Y ${IPHOST} "mplayer -really-quiet -fps 15 tv:// -tv
driver=v4l2:widthd0:heightH0:device=/dev/video0 2>&1 >/dev/null" &
Je suppose un peu n'importe où, mais je ne peux pas encore tester.
Si tu n'as pas de mot de passe à saisir pour te connecter, il vaut mieux
faire la mise en arrière plan par le shell que par le client ssh.
C'est ce que j'avais cru comprendre. Merci de me l'avoir confirmé.
Je reviens quand j'aurai pu tester le < /dev/null mais je ne voulais pas
laisser ton post sans réponse trop longtemps :D
Le Thu, 03 May 2012 07:35:59 +0000, Nicolas George a écrit :
Ça me paraît très suspect : si sa fenêtre a été fermée brutalement, mplayer aurait dû être tué par les fonctions de la Xlib. Quelle versions de mplayer est-ce exactement ?
Je ne l'ai pas sous les yeux mais c'est la dernière à jour sous Gentoo.
Au fait, as-tu pensé au « < /dev/null » ? MPlayer, par défaut, lit sur son entrée standard, ça peut perturber des choses s'il est lancé en arrière plan.
Euh, j'avoue ne pas y avoir pensé, non, mais j'avoue aussi ne pas trop savoir ou mettre ça dans ma commande ;) qui est : ssh -Y ${IPHOST} "mplayer -really-quiet -fps 15 tv:// -tv driver=v4l2:widthd0:heightH0:device=/dev/video0 2>&1 >/dev/null" &
Je suppose un peu n'importe où, mais je ne peux pas encore tester.
Si tu n'as pas de mot de passe à saisir pour te connecter, il vaut mieux faire la mise en arrière plan par le shell que par le client ssh.
C'est ce que j'avais cru comprendre. Merci de me l'avoir confirmé.
Je reviens quand j'aurai pu tester le < /dev/null mais je ne voulais pas laisser ton post sans réponse trop longtemps :D
Christophe PEREZ
Le Thu, 03 May 2012 22:58:24 +0000, Christophe PEREZ a écrit :
Au fait, as-tu pensé au « < /dev/null » ? MPlayer, par défaut, lit sur son entrée standard, ça peut perturber des choses s'il est lancé en arrière plan.
Euh, j'avoue ne pas y avoir pensé, non, mais j'avoue aussi ne pas trop savoir ou mettre ça dans ma commande qui est : ssh -Y ${IPHOST} "mplayer -really-quiet -fps 15 tv:// -tv driver=v4l2:widthd0:heightH0:device=/dev/video0 2>&1 >/dev/null" &
Je suppose un peu n'importe où, mais je ne peux pas encore tester.
Ben non, même avec : ssh -Y ${IPHOST} "mplayer -really-quiet -fps 15 tv:// -tv driver=v4l2:widthd0:heightH0:device=/dev/video0 2>&1 >/dev/null </dev/ null" & le kill $! laisse tourner un mplayer sur la machine distante.
Le Thu, 03 May 2012 22:58:24 +0000, Christophe PEREZ a écrit :
Au fait, as-tu pensé au « < /dev/null » ? MPlayer, par défaut, lit sur
son entrée standard, ça peut perturber des choses s'il est lancé en
arrière plan.
Euh, j'avoue ne pas y avoir pensé, non, mais j'avoue aussi ne pas trop
savoir ou mettre ça dans ma commande qui est : ssh -Y ${IPHOST}
"mplayer -really-quiet -fps 15 tv:// -tv
driver=v4l2:widthd0:heightH0:device=/dev/video0 2>&1 >/dev/null" &
Je suppose un peu n'importe où, mais je ne peux pas encore tester.
Ben non, même avec :
ssh -Y ${IPHOST} "mplayer -really-quiet -fps 15 tv:// -tv
driver=v4l2:widthd0:heightH0:device=/dev/video0 2>&1 >/dev/null </dev/
null" &
le kill $! laisse tourner un mplayer sur la machine distante.
Le Thu, 03 May 2012 22:58:24 +0000, Christophe PEREZ a écrit :
Au fait, as-tu pensé au « < /dev/null » ? MPlayer, par défaut, lit sur son entrée standard, ça peut perturber des choses s'il est lancé en arrière plan.
Euh, j'avoue ne pas y avoir pensé, non, mais j'avoue aussi ne pas trop savoir ou mettre ça dans ma commande qui est : ssh -Y ${IPHOST} "mplayer -really-quiet -fps 15 tv:// -tv driver=v4l2:widthd0:heightH0:device=/dev/video0 2>&1 >/dev/null" &
Je suppose un peu n'importe où, mais je ne peux pas encore tester.
Ben non, même avec : ssh -Y ${IPHOST} "mplayer -really-quiet -fps 15 tv:// -tv driver=v4l2:widthd0:heightH0:device=/dev/video0 2>&1 >/dev/null </dev/ null" & le kill $! laisse tourner un mplayer sur la machine distante.
Nicolas George
Christophe PEREZ , dans le message <jo253l$q5m$, a écrit :
Ben non, même avec : ssh -Y ${IPHOST} "mplayer -really-quiet -fps 15 tv:// -tv driver=v4l2:widthd0:heightH0:device=/dev/video0 2>&1 >/dev/null </dev/ null" & le kill $! laisse tourner un mplayer sur la machine distante.
Ton problème n'est pas avec mplayer mais avec le fait de mettre ssh en arrière plan : ssh, ça lit sur son entrée standard, donc si on le met en arrière plan, le contrôle du terminal va le suspendre. Mais c'est assez instable, parce que comme ssh multpilexe sur du réseau, il utilise poll pour savoir s'il peut lire sur l'entrée standard, donc il ne se trouvera suspendu que s'il fait un poll pile entre le moment où tu appuies sur une touche et le moment où le shell la lit. Et comme il est très occupé à déchiffrer des images X11, ça se fait rarement, donc l'essentiel du temps ça marche. Et quand tu le tues, sa mort est retardée jusqu'au moment où il est désuspendu.
La version courte, c'est que tu dois mettre < /dev/null sur le ssh en plus/à la place de mplayer.
Accessoirement, tu devrais mettre les options V4L2 dans .mplayer/config, ce serait plus confortable pour toi.
Christophe PEREZ , dans le message <jo253l$q5m$1@serveur1.novazur.fr>, a
écrit :
Ben non, même avec :
ssh -Y ${IPHOST} "mplayer -really-quiet -fps 15 tv:// -tv
driver=v4l2:widthd0:heightH0:device=/dev/video0 2>&1 >/dev/null </dev/
null" &
le kill $! laisse tourner un mplayer sur la machine distante.
Ton problème n'est pas avec mplayer mais avec le fait de mettre ssh en
arrière plan : ssh, ça lit sur son entrée standard, donc si on le met en
arrière plan, le contrôle du terminal va le suspendre. Mais c'est assez
instable, parce que comme ssh multpilexe sur du réseau, il utilise poll pour
savoir s'il peut lire sur l'entrée standard, donc il ne se trouvera suspendu
que s'il fait un poll pile entre le moment où tu appuies sur une touche et
le moment où le shell la lit. Et comme il est très occupé à déchiffrer des
images X11, ça se fait rarement, donc l'essentiel du temps ça marche. Et
quand tu le tues, sa mort est retardée jusqu'au moment où il est désuspendu.
La version courte, c'est que tu dois mettre < /dev/null sur le ssh en plus/à
la place de mplayer.
Accessoirement, tu devrais mettre les options V4L2 dans .mplayer/config, ce
serait plus confortable pour toi.
Christophe PEREZ , dans le message <jo253l$q5m$, a écrit :
Ben non, même avec : ssh -Y ${IPHOST} "mplayer -really-quiet -fps 15 tv:// -tv driver=v4l2:widthd0:heightH0:device=/dev/video0 2>&1 >/dev/null </dev/ null" & le kill $! laisse tourner un mplayer sur la machine distante.
Ton problème n'est pas avec mplayer mais avec le fait de mettre ssh en arrière plan : ssh, ça lit sur son entrée standard, donc si on le met en arrière plan, le contrôle du terminal va le suspendre. Mais c'est assez instable, parce que comme ssh multpilexe sur du réseau, il utilise poll pour savoir s'il peut lire sur l'entrée standard, donc il ne se trouvera suspendu que s'il fait un poll pile entre le moment où tu appuies sur une touche et le moment où le shell la lit. Et comme il est très occupé à déchiffrer des images X11, ça se fait rarement, donc l'essentiel du temps ça marche. Et quand tu le tues, sa mort est retardée jusqu'au moment où il est désuspendu.
La version courte, c'est que tu dois mettre < /dev/null sur le ssh en plus/à la place de mplayer.
Accessoirement, tu devrais mettre les options V4L2 dans .mplayer/config, ce serait plus confortable pour toi.
Christophe PEREZ
Le Sat, 05 May 2012 07:21:47 +0000, Nicolas George a écrit :
La version courte, c'est que tu dois mettre < /dev/null sur le ssh en plus/à la place de mplayer.
Merci d'avoir compris que la version courte serait indispensable ;) Je teste ça dès que possible.
Accessoirement, tu devrais mettre les options V4L2 dans .mplayer/config, ce serait plus confortable pour toi.
Je le note, et je regarde comment ça se fait, parce que j'avoue ne jamais avoir utilisé de fichier de conf pour mplayer.
Le Sat, 05 May 2012 07:21:47 +0000, Nicolas George a écrit :
La version courte, c'est que tu dois mettre < /dev/null sur le ssh en
plus/à la place de mplayer.
Merci d'avoir compris que la version courte serait indispensable ;)
Je teste ça dès que possible.
Accessoirement, tu devrais mettre les options V4L2 dans .mplayer/config,
ce serait plus confortable pour toi.
Je le note, et je regarde comment ça se fait, parce que j'avoue ne jamais
avoir utilisé de fichier de conf pour mplayer.
