Pilotage de MPlayer sous DOS en mode esclave

Version imprimable

10/10/2008, 14h37
Yop

Pilotage de MPlayer sous DOS en mode esclave

Bonjour à tous,

Je viens d'une autre section du forum où malheureusement, ils n'ont pas réussi à m'apporter de réponses donc c'est pour cela que je passe vous voir :)

Alors pour faire bref: le problème est que je n'arrive pas à piloter MPlayer en mode esclave sous invité de commande (boite MS-DOS). En fait, j'arrive à le lancer mais après je n'arrive pas à lui donner "d'ordre". Dans la documentation de MPlayer (http://www.mplayerhq.hu/DOCS/tech/slave.txt), il est indiqué de mettre le lecteur en esclave (avec l'argument -slave), ce que je fais sans problème et ensuite de le piloter grâce à des commandes à rentrer et là je n'y arrive pas :(
D'après leur site, il est indiqué de faire ça:
"To try slave mode out by hand, run
mplayer -slave -quiet <movie>
and type slave commands into the console window."
Ça ne fonctionne pas....je n'arrive à taper aucune commande dans la fenêtre MS-DOS (console). Par exemple, je voudrai avoir la durée de la vidéo en seconde avec la commande : 'get_time_length' mais il n'y a rien pour prendre en compte cette commande dans la console.

En espérant que vous pourrez m'aider, je vous remercie d'avance.
04/11/2008, 21h44
maxim_um

Salut yop, bienvenue à toi sur le forum.

Ton message date un peu. Je ne sais pas s'il est encore d'actualité, mais en tout cas, je souhaite que tes cheveux soient encore en place vu le nombre de site et forum dans lesquels tu as posté ta demande. À moins que tu ne sois "hyper" polyglotte, j'ai remarqué qu'un grand nombre d'individus se trouvent dans la même situation que toi, et ça m'a intrigué.

Alors, en fin de soirée, j'ai téléchargé le programme en question, sa doc et ses codes sources. Un rapide tour d'horizon m'a fait comprendre que mplayer à comme territoire de prédilection Linux. Bien qu'une version Windows existe, certaines fonctionnalités inédites ne sont nativement accessible que sous Linux, elles-mêmes inhérentes au système de fichier de ce système d'exploitation.

Ainsi, l'exemple qui te préoccupe,

Citation:

To try slave mode out by hand, run

mplayer -slave -quiet <movie>

and type slave commands into the console window.

You can also use a fifo file (named pipe):

mkfifo </tmp/fifofile>
mplayer -slave -input file=</tmp/fifofile> <movie>

ne peut tout simplement pas être exécuté sur Windows. Je t'accorde le fait qu'on est tenté de lire "console windows" au lieu de "console window", ce qui peut vraiment prêter à confusion.

Enfin, pour que tu ne restes pas dans l'ombre, j'ai quand même essayé d'aller plus loin.

Tout d'abord, j'ai reproduit la fonctionnalité de la commande Linux mkfifo, soit la genèse d'un «tube nommé» (windows named pipe). Le problème c'est que mplayer, dans sa version actuelle, ne peut lire directement dans ce type de "pseudo fichier" Windows. Pour que cela soit possible, il faudrait implémenter cette fonctionnalité dans le code source de mplayer, puis compiler.

Ensuite, une autre possibilité consiste à utiliser la communication interprocessus (IPC). Ici, il s'agit de transmettre des instructions à Mplayer vers son entrée standard (stdin) préalablement redirigée grâce aux pipes anonymes. J'ai fait un programme de test et ça fonctionne très bien. En plus d'être intéressant, ce type de mécanisme à un potentiel fort important.

En conclusion, si tu souhaites piloter Mplayer depuis ta ligne de commande, la réalisation d'une interface de contrôle est un passage obligé.

Voilà, j'espère avoir répondu à ta question et que désormais, comme qui dirait, ton horizon s'est éclairci.

A plus.
17/12/2008, 18h33
ninjasam

Controller mplayer

Bonjour,

Je suis super intéressé pour savoir comment tu as fait pour transmettre des instructions à Mplayer vers son entrée standard (stdin) sous windows. Si tu as encore tes codes sources ou si tu peux vaguement m'aiguiller, ça m'aiderait beaucoup.

Merci d'avance

Cordialement

Samuel

--------
Page perso : http://www.samuelboudet.com
- Enigmes difficiles
- Matlab (Tutorial)
- l'Eléctroencéphalographie et le filtrage d'artefacts
18/12/2008, 21h37
maxim_um
Salut ninjasam, bienvenu à toi sur le forum.

J'aurais bien voulu de transmettre le code source, mais il y a quelque temps, faute de place, j'ai dû faire le ménage dans mon disque dur. Même mes EDI préférés y sont passés. Mais rassure-toi, la tâche de programmer une interface pour mplayer n'a rien d'insurmontable.

Voilà le principe:

On sait que mplayer accepte un ensemble d'instructions depuis son entrée standard et l'objectif (voire premier message de la discussion) était de pouvoir transmettre des consignes à ce lecteur multimédia depuis notre interpréteur de commande CMD.
L'ennui, c'est que ce contexte est au premier abord restrictif. Restrictif, car l'entrée standard du lecteur est accessible uniquement au moment de son démarrage et plus après.

voilà quelques exemples de ce qu'on peut faire sous CMD:
Code:

1 2 3 mplayer flvmediafile.flv echo pause | mplayer -slave flvmediafile.flv echo loadfile mp3mediafile.mp3 | mplayer -slave flvmediafile.flv
Ces rapides exemples nous montrent bien que le pilotage de mplayer est possible. Dès lors, il nous reste plus qu'à faire en sorte que l'accès à l'entrée standard du lecteur soit persistant. Comment? Grâce aux pipes anonymes par exemple.

Dans un code, cela peut se traduire par quelque chose de ce genre:

On génère une paire de pipes anonymes (une entrée, une sortie, accès en lecture, accès en écriture)
Ensuite on lance un processus enfant, en l'occurrence mplayer (mplayer.exe -slave -quiet ...) avec en information de démarrage la redirection de ses entrée et sortie (hstdin, hstdout) vers les pipes (hstdin=handle_pipe1...)

Grâce à cette liaison, tout ce qui est écrit dans le pipe est instantanément reproduit sur l'entrée standard du lecteur. Ainsi, mplayer peut désormais recevoir des instructions.

À ce stade, l'essentiel est fait.

Maintenant pour ce qui est de l'interface utilisateur.

Ici, les possibilités sont très nombreuses. Ce que je pourrais qualifier de fun en mode CLI pourrait être un pipe nommé ou encore un système serveur. Pour mon test, il me semble que je m'étais contenté d'un simple fichier temporaire. L'avantage de ce dernier est qu'en plus d'être facilement accessible depuis CMD, me permettait pour les besoins du test de pouvoir contrôler la chaine de transmission des données très facilement.

Enfin, en ce qui concerne le fonctionnement du programme dans son ensemble, c'était plutôt direct.

Depuis CMD j'écrivais une instruction mplayer dans le fichier temporaire (echo ...). Le programme détecte la nouvelle instruction, l'écrit dans le pipe, et ainsi la donnée est transmise à mplayer qui s'exécute le plus simplement possible.

En me relisant, je me dis que ça aurait été tout aussi bien de réécrire un code, encor aurait-il fallu le commenter. En tout cas, j'espère t'avoir apporté les éléments de réponses que tu attendais.

Bonne continuation à toi.

Bonjour, tu peu aussi utiliser autoit pour contrôler mplayer, voici un bout de code :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Local $foo = Run('mplayer.exe -slave -quiet -vf cropdetect -ss 00:30:00 -vo null -ao null -identify "'&$fich&'"',@SystemDir, @SW_HIDE, $STDIN_CHILD + $STDERR_CHILD + $STDOUT_CHILD) ; Local $line $i = 0 While 1 $line = StdoutRead($foo) If @error Then ExitLoop if StringInStr($line,"[CROP]") Then $i=$i+1 if $i = 5 Then StdinWrite($foo,"seek +240"&@lf) ElseIf $i = 10 Then StdinWrite($foo,"seek +240"&@lf) elseif $i = 15 then $cropt = _StringBetween($line, "(-vf crop=", ")") $crop = $cropt[0] ProcessClose($foo) ExitLoop EndIf EndIf ConsoleWrite($line) Wend
la commande qui t'intéressera le plus c'est StdinWrite($foo,"seek +240"&@lf) qui comme expliqué dans le slave.text avance dans la vidéo de 240s

il est en théorie possible d'utiliser les pipes dont parle maxim, un UDF nommé namedpipes étant présent dans l'aide de autoit. malheureusement il n'y a pas d'exemple de code et je n'est rien pigé :(

moi je cherche au contraire a envoyer la sortie de mplayer vers l'entré stdin d'un encodeur sans succès. si quelqu'un sait comment faire, je suis preneur.